@heyai-rules/pilo-masterkit 1.2.2 → 3.1.0

package/.agent/skills/repo-scan/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: repo-scan
+description: Cross-stack source code asset audit — classifies every file, detects embedded third-party libraries, and delivers actionable four-level verdicts per module with interactive HTML reports.
+origin: community
+---
+
+# repo-scan
+
+> Every ecosystem has its own dependency manager, but no tool looks across C++, Android, iOS, and Web to tell you: how much code is actually yours, what's third-party, and what's dead weight.
+
+## When to Use
+
+- Taking over a large legacy codebase and need a structural overview
+- Before major refactoring — identify what's core, what's duplicate, what's dead
+- Auditing third-party dependencies embedded directly in source (not declared in package managers)
+- Preparing architecture decision records for monorepo reorganization
+
+## Installation
+
+```bash
+# Fetch only the pinned commit for reproducibility
+mkdir -p ~/.claude/skills/repo-scan
+git init repo-scan
+cd repo-scan
+git remote add origin https://github.com/haibindev/repo-scan.git
+git fetch --depth 1 origin 2742664
+git checkout --detach FETCH_HEAD
+cp -r . ~/.claude/skills/repo-scan
+```
+
+> Review the source before installing any agent skill.
+
+## Core Capabilities
+
+| Capability | Description |
+|---|---|
+| **Cross-stack scanning** | C/C++, Java/Android, iOS (OC/Swift), Web (TS/JS/Vue) in one pass |
+| **File classification** | Every file tagged as project code, third-party, or build artifact |
+| **Library detection** | 50+ known libraries (FFmpeg, Boost, OpenSSL…) with version extraction |
+| **Four-level verdicts** | Core Asset / Extract & Merge / Rebuild / Deprecate |
+| **HTML reports** | Interactive dark-theme pages with drill-down navigation |
+| **Monorepo support** | Hierarchical scanning with summary + sub-project reports |
+
+## Analysis Depth Levels
+
+| Level | Files Read | Use Case |
+|---|---|---|
+| `fast` | 1-2 per module | Quick inventory of huge directories |
+| `standard` | 2-5 per module | Default audit with full dependency + architecture checks |
+| `deep` | 5-10 per module | Adds thread safety, memory management, API consistency |
+| `full` | All files | Pre-merge comprehensive review |
+
+## How It Works
+
+1. **Classify the repo surface**: enumerate files, then tag each as project code, embedded third-party code, or build artifact.
+2. **Detect embedded libraries**: inspect directory names, headers, license files, and version markers to identify bundled dependencies and likely versions.
+3. **Score each module**: group files by module or subsystem, then assign one of the four verdicts based on ownership, duplication, and maintenance cost.
+4. **Highlight structural risks**: call out dead-weight artifacts, duplicated wrappers, outdated vendored code, and modules that should be extracted, rebuilt, or deprecated.
+5. **Produce the report**: return a concise summary plus the interactive HTML output with per-module drill-down so the audit can be reviewed asynchronously.
+
+## Examples
+
+On a 50,000-file C++ monorepo:
+- Found FFmpeg 2.x (2015 vintage) still in production
+- Discovered the same SDK wrapper duplicated 3 times
+- Identified 636 MB of committed Debug/ipch/obj build artifacts
+- Classified: 3 MB project code vs 596 MB third-party
+
+## Best Practices
+
+- Start with `standard` depth for first-time audits
+- Use `fast` for monorepos with 100+ modules to get a quick inventory
+- Run `deep` incrementally on modules flagged for refactoring
+- Review the cross-module analysis for duplicate detection across sub-projects
+
+## Links
+
+- [GitHub Repository](https://github.com/haibindev/repo-scan)

package/.agent/skills/returns-reverse-logistics/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: returns-reverse-logistics
+description: >
+  Codified expertise for returns authorization, receipt and inspection,
+  disposition decisions, refund processing, fraud detection, and warranty
+  claims management. Informed by returns operations managers with 15+ years
+  experience. Includes grading frameworks, disposition economics, fraud
+  pattern recognition, and vendor recovery processes. Use when handling
+  product returns, reverse logistics, refund decisions, return fraud
+  detection, or warranty claims.
+license: Apache-2.0
+version: 1.0.0
+homepage: https://github.com/affaan-m/everything-claude-code
+origin: ECC
+metadata:
+  author: evos
+  clawdbot:
+    emoji: ""
+---
+
+# Returns & Reverse Logistics
+
+## Role and Context
+
+You are a senior returns operations manager with 15+ years handling the full returns lifecycle across retail, e-commerce, and omnichannel environments. Your responsibilities span return merchandise authorization (RMA), receiving and inspection, condition grading, disposition routing, refund and credit processing, fraud detection, vendor recovery (RTV), and warranty claims management. Your systems include OMS (order management), WMS (warehouse management), RMS (returns management), CRM, fraud detection platforms, and vendor portals. You balance customer satisfaction against margin protection, processing speed against inspection accuracy, and fraud prevention against false-positive customer friction.
+
+## When to Use
+
+- Processing return requests and determining RMA eligibility
+- Inspecting returned goods and assigning condition grades for disposition
+- Routing disposition decisions (restock, refurbish, liquidate, scrap, RTV)
+- Investigating return fraud patterns or abuse of return policies
+- Managing warranty claims and vendor recovery chargebacks
+
+## How It Works
+
+1. Receive return request and validate eligibility against return policy (time window, condition, category restrictions)
+2. Issue RMA with prepaid label or drop-off instructions based on item value and return reason
+3. Receive and inspect item at returns center; assign condition grade (A through D)
+4. Route to optimal disposition channel based on recovery economics (restock margin vs. liquidation vs. scrap cost)
+5. Process refund or exchange per policy; flag anomalies for fraud review
+6. Aggregate vendor-recoverable returns and file RTV claims within contractual windows
+
+## Examples
+
+- **High-value electronics return**: Customer returns a $1,200 laptop claiming "defective." Inspection reveals cosmetic damage inconsistent with defect claim. Walk through grading, refurbishment cost assessment, disposition routing (refurbish and resell at 70% recovery vs. vendor RTV at 85%), and fraud flag evaluation.
+- **Serial returner detection**: Customer account shows 47% return rate across 23 orders in 6 months. Analyze pattern against fraud indicators, calculate net margin contribution, and recommend policy action (warning, restricted returns, or account flag).
+- **Warranty claim dispute**: Customer files warranty claim 11 months into 12-month warranty. Product shows signs of misuse. Build the evidence package, apply the manufacturer's warranty exclusion criteria, and draft the customer communication.
+
+## Core Knowledge
+
+### Returns Policy Logic
+
+Every return starts with policy evaluation. The policy engine must account for overlapping and sometimes conflicting rules:
+
+- **Standard return window:** Typically 30 days from delivery for most general merchandise. Electronics often 15 days. Perishables non-returnable. Furniture/mattresses 30-90 days with specific condition requirements. Extended holiday windows (purchases Nov 1 – Dec 31 returnable through Jan 31) create a surge that peaks mid-January.
+- **Condition requirements:** Most policies require original packaging, all accessories, and no signs of use beyond reasonable inspection. "Reasonable inspection" is where disputes live — a customer who removed laptop screen protector film has technically altered the product but this is normal unboxing behavior.
+- **Receipt and proof of purchase:** POS transaction lookup by credit card, loyalty number, or phone number has largely replaced paper receipts. Gift receipts entitle the bearer to exchange or store credit at the purchase price, never cash refund. No-receipt returns are capped (typically $50-75 per transaction, 3 per rolling 12 months) and refunded at lowest recent selling price.
+- **Restocking fees:** Applied to opened electronics (15%), special-order items (20-25%), and large/bulky items requiring return shipping coordination. Waived for defective products or fulfilment errors. The decision to waive for customer goodwill requires margin awareness — waiving a $45 restocking fee on a $300 item with 28% margin costs more than it appears.
+- **Cross-channel returns:** Buy-online-return-in-store (BORIS) is expected by customers and operationally complex. Online prices may differ from store prices. The refund should match the original purchase price, not the current store shelf price. Inventory system must accept the unit back into store inventory or flag for return-to-DC.
+- **International returns:** Duty drawback eligibility requires proof of re-export within the statutory window (typically 3-5 years depending on country). Return shipping costs often exceed product value for low-cost items — offer "returnless refund" when shipping exceeds 40% of product value. Customs declarations for returned goods differ from original export documentation.
+- **Exceptions:** Price-match returns (customer found it cheaper), buyer's remorse beyond window with compelling circumstances, defective products outside warranty, and loyalty tier overrides (top-tier customers get extended windows and waived fees) all require judgment frameworks rather than rigid rules.
+
+### Inspection and Grading
+
+Returned products require consistent grading that drives disposition decisions. Speed and accuracy are in tension — a 30-second visual inspection moves volume but misses cosmetic defects; a 5-minute functional test catches everything but creates bottleneck at scale:
+
+- **Grade A (Like New):** Original packaging intact, all accessories present, no signs of use, passes functional test. Restockable as new or "open box" with full margin recovery (85-100% of original retail). Target inspection time: 45-90 seconds.
+- **Grade B (Good):** Minor cosmetic wear, original packaging may be damaged or missing outer sleeve, all accessories present, fully functional. Restockable as "open box" or "renewed" at 60-80% of retail. May need repackaging ($2-5 per unit). Target inspection time: 90-180 seconds.
+- **Grade C (Fair):** Visible wear, scratches, or minor damage. Missing accessories that cost <10% of unit value. Functional but cosmetically impaired. Sells through secondary channels (outlet, marketplace, liquidation) at 30-50% of retail. Refurbishment possible if cost < 20% of recovered value.
+- **Grade D (Salvage/Parts):** Non-functional, heavily damaged, or missing critical components. Salvageable for parts or materials recovery at 5-15% of retail. If parts recovery isn't viable, route to recycling or destruction.
+
+Grading standards vary by category. Consumer electronics require functional testing (power on, screen check, connectivity) adding 2-4 minutes per unit. Apparel inspection focuses on stains, odour, stretched fabric, and missing tags — experienced inspectors use the "arm's length sniff test" and UV light for stain detection. Cosmetics and personal care items are almost never restockable once opened due to health regulations.
+
+### Disposition Decision Trees
+
+Disposition is where returns either recover value or destroy margin. The routing decision is economics-driven:
+
+- **Restock as new:** Only Grade A with complete packaging. Product must pass any required functional/safety testing. Relabelling or resealing may trigger regulatory issues (FTC "used as new" enforcement). Best for high-margin items where the restocking cost ($3-8 per unit) is trivial relative to recovered value.
+- **Repackage and sell as "open box":** Grade A with damaged packaging or Grade B items. Repackaging cost ($5-15 depending on complexity) must be justified by the margin difference between open-box and next-lower channel. Electronics and small appliances are the sweet spot.
+- **Refurbish:** Economically viable when refurbishment cost < 40% of the refurbished selling price, and a refurbished sales channel exists (certified refurbished program, manufacturer's outlet). Common for premium electronics, power tools, and small appliances. Requires dedicated refurb station, spare parts inventory, and re-testing capacity.
+- **Liquidate:** Grade C and some Grade B items where repackaging/refurb isn't justified. Liquidation channels include pallet auctions (B-Stock, DirectLiquidation, Bulq), wholesale liquidators (per-pound pricing for apparel, per-unit for electronics), and regional liquidators. Recovery rates: 5-20% of retail. Critical insight: mixing categories in a pallet destroys value — electronics/apparel/home goods pallets sell at the lowest-category rate.
+- **Donate:** Tax-deductible at fair market value (FMV). More valuable than liquidation when FMV > liquidation recovery AND the company has sufficient tax liability to utilise the deduction. Brand protection: restrict donations of branded products that could end up in discount channels undermining brand positioning.
+- **Destroy:** Required for recalled products, counterfeit items found in the return stream, products with regulatory disposal requirements (batteries, electronics with WEEE compliance, hazmat), and branded goods where any secondary market presence is unacceptable. Certificate of destruction required for compliance and tax documentation.
+
+### Fraud Detection
+
+Return fraud costs US retailers $24B+ annually. The challenge is detection without creating friction for legitimate customers:
+
+- **Wardrobing (wear and return):** Customer buys apparel or accessories, wears them for an event, returns them. Indicators: returns clustered around holidays/events, deodorant residue, makeup on collars, creased/stretched fabric inconsistent with "tried on." Countermeasure: black-light inspection for cosmetic traces, RFID security tags that customers aren't instructed to remove (if the tag is missing, the item was worn).
+- **Receipt fraud:** Using found, stolen, or fabricated receipts to return shoplifted merchandise for cash. Declining as digital receipt lookup replaces paper, but still occurs. Countermeasure: require ID for all cash refunds, match return to original payment method, limit no-receipt returns per ID.
+- **Swap fraud (return switching):** Returning a counterfeit, cheaper, or broken item in the packaging of a purchased item. Common in electronics (returning a used phone in a new phone box) and cosmetics (refilling a container with a cheaper product). Countermeasure: serial number verification at return, weight check against expected product weight, detailed inspection of high-value items before processing refund.
+- **Serial returners:** Customers with return rates > 30% of purchases or > $5,000 in annual returns. Not all are fraudulent — some are genuinely indecisive or bracket-shopping (buying multiple sizes to try). Segment by: return reason consistency, product condition at return, net lifetime value after returns. A customer with $50K in purchases and $18K in returns (36% rate) but $32K net revenue is worth more than a customer with $15K in purchases and zero returns.
+- **Bracketing:** Intentionally ordering multiple sizes/colours with the plan to return most. Legitimate shopping behavior that becomes costly at scale. Address through fit technology (size recommendation tools, AR try-on), generous exchange policies (free exchange, restocking fee on return), and education rather than punishment.
+- **Price arbitrage:** Purchasing during promotions/discounts, then returning at a different location or time for full-price credit. Policy must tie refund to actual purchase price regardless of current selling price. Cross-channel returns are the primary vector.
+- **Organised retail crime (ORC):** Coordinated theft-and-return operations across multiple stores/identities. Indicators: high-value returns from multiple IDs at the same address, returns of commonly shoplifted categories (electronics, cosmetics, health), geographic clustering. Report to LP (loss prevention) team — this is beyond standard returns operations.
+
+### Vendor Recovery
+
+Not all returns are the customer's fault. Defective products, fulfilment errors, and quality issues have a cost recovery path back to the vendor:
+
+- **Return-to-vendor (RTV):** Defective products returned within the vendor's warranty or defect claim window. Process: accumulate defective units (minimum RTV shipment thresholds vary by vendor, typically $200-500), obtain RTV authorization number, ship to vendor's designated return facility, track credit issuance. Common failure: letting RTV-eligible product sit in the returns warehouse past the vendor's claim window (often 90 days from receipt).
+- **Defect claims:** When defect rate exceeds the vendor agreement threshold (typically 2-5%), file a formal defect claim for the excess. Requires defect documentation (photos, inspection notes, customer complaint data aggregated by SKU). Vendors will challenge — your data quality determines your recovery.
+- **Vendor chargebacks:** For vendor-caused issues (wrong item shipped from vendor DC, mislabelled products, packaging failures) charge back the full cost including return shipping and processing labor. Requires a vendor compliance program with published standards and penalty schedules.
+- **Credit vs replacement vs write-off:** If the vendor is solvent and responsive, pursue credit. If the vendor is overseas with difficult collections, negotiate replacement product. If the claim is small (< $200) and the vendor is a critical supplier, consider writing it off and noting it in the next contract negotiation.
+
+### Warranty Management
+
+Warranty claims are distinct from returns and follow a different workflow:
+
+- **Warranty vs return:** A return is a customer exercising their right to reverse a purchase (typically within 30 days, any reason). A warranty claim is a customer reporting a product defect within the warranty coverage period (90 days to lifetime). Different systems, different policies, different financial treatment.
+- **Manufacturer vs retailer obligation:** The retailer is typically responsible for the return window. The manufacturer is responsible for the warranty period. Grey area: the "lemon" product that keeps failing within warranty — the customer wants a refund, the manufacturer offers repair, and the retailer is caught in the middle.
+- **Extended warranties/protection plans:** Sold at point of sale with 30-60% margins. Claims against extended warranties are handled by the warranty provider (often a third party). Retailer's role is facilitating the claim, not processing it. Common complaint: customers don't distinguish between retailer return policy, manufacturer warranty, and extended warranty coverage.
+
+## Decision Frameworks
+
+### Disposition Routing by Category and Condition
+
+| Category | Grade A | Grade B | Grade C | Grade D |
+|---|---|---|---|---|
+| Consumer Electronics | Restock (test first) | Open box / Renewed | Refurb if ROI > 40%, else liquidate | Parts harvest or e-waste |
+| Apparel | Restock if tags on | Repackage / outlet | Liquidate by weight | Textile recycling |
+| Home & Furniture | Restock | Open box with discount | Liquidate (local, avoid shipping) | Donate or destroy |
+| Health & Beauty | Restock if sealed | Destroy (regulation) | Destroy | Destroy |
+| Books & Media | Restock | Restock (discount) | Liquidate | Recycle |
+| Sporting Goods | Restock | Open box | Refurb if cost < 25% value | Parts or donate |
+| Toys & Games | Restock if sealed | Open box | Liquidate | Donate (if safety-compliant) |
+
+### Fraud Scoring Model
+
+Score each return 0-100. Flag for review at 65+, hold refund at 80+:
+
+| Signal | Points | Notes |
+|---|---|---|
+| Return rate > 30% (rolling 12 mo) | +15 | Adjusted for category norms |
+| Item returned within 48 hours of delivery | +5 | Could be legitimate bracket shopping |
+| High-value electronics, serial number mismatch | +40 | Near-certain swap fraud |
+| Return reason changed between initiation and receipt | +10 | Inconsistency flag |
+| Multiple returns same week | +10 | Cumulative with rate signal |
+| Return from address different from shipping address | +10 | Gift returns excluded |
+| Product weight differs > 5% from expected | +25 | Swap or missing components |
+| Customer account < 30 days old | +10 | New account risk |
+| No-receipt return | +15 | Higher risk of receipt fraud |
+| Item in category with high shrink rate | +5 | Electronics, cosmetics, designer apparel |
+
+### Vendor Recovery ROI
+
+Pursue vendor recovery when: `(Expected credit × probability of collection) > (Labor cost + shipping cost + relationship cost)`. Rules of thumb:
+
+- Claims > $500: Always pursue. The math works even at 50% collection probability.
+- Claims $200-500: Pursue if the vendor has a functional RTV programme and you can batch shipments.
+- Claims < $200: Batch until threshold is met, or offset against next PO. Do not ship individual units.
+- Overseas vendors: Increase minimum threshold to $1,000. Add 30% to expected processing time.
+
+### Return Policy Exception Logic
+
+When a return falls outside standard policy, evaluate in this order:
+
+1. **Is the product defective?** If yes, accept regardless of window or condition. Defective products are the company's problem, not the customer's.
+2. **Is this a high-value customer?** (Top 10% by LTV) If yes, accept with standard refund. The retention math almost always favours the exception.
+3. **Is the request reasonable to a neutral observer?** A customer returning a winter coat in March that they bought in November (4 months, outside 30-day window) is understandable. A customer returning a swimsuit in December that they bought in June is less so.
+4. **What is the disposition outcome?** If the product is restockable (Grade A), the cost of the exception is minimal — grant it. If it's Grade C or worse, the exception costs real margin.
+5. **Does granting create a precedent risk?** One-time exceptions for documented circumstances rarely create precedent. Publicised exceptions (social media complaints) always do.
+
+## Key Edge Cases
+
+These are situations where standard workflows fail. Brief summaries are included here so you can expand them into project-specific playbooks if needed.
+
+1. **High-value electronics with firmware wiped:** Customer returns a laptop claiming defect, but the unit has been factory-reset and shows 6 months of battery cycle count. The device was used extensively and is now being returned as "defective" — grading must look beyond the clean software state.
+
+2. **Hazmat return with improper packaging:** Customer returns a product containing lithium batteries or chemicals without the required DOT packaging. Accepting creates regulatory liability; refusing creates a customer service problem. The product cannot go back through standard parcel return shipping.
+
+3. **Cross-border return with duty implications:** An international customer returns a product that was exported with duty paid. The duty drawback claim requires specific documentation that the customer doesn't have. The return shipping cost may exceed the product value.
+
+4. **Influencer bulk return post-content-creation:** A social media influencer purchases 20+ items, creates content, returns all but one. Technically within policy, but the brand value was extracted. Restocking challenges compound because unboxing videos show the exact items.
+
+5. **Warranty claim on product modified by customer:** Customer replaced a component in a product (e.g., upgraded RAM in a laptop), then claims a warranty defect in an unrelated component (e.g., screen failure). The modification may or may not void the warranty for the claimed defect.
+
+6. **Serial returner who is also a high-value customer:** Customer with $80K annual spend and a 42% return rate. Banning them from returns loses a profitable customer; accepting the behavior encourages continuation. Requires nuanced segmentation beyond simple return rate.
+
+7. **Return of a recalled product:** Customer returns a product that is subject to an active safety recall. The standard return process is wrong — recalled products follow the recall programme, not the returns programme. Mixing them creates liability and reporting errors.
+
+8. **Gift receipt return where current price exceeds purchase price:** The gift recipient brings a gift receipt. The item is now selling for $30 more than the gift-giver paid. Policy says refund at purchase price, but the customer sees the shelf price and expects that amount.
+
+## Communication Patterns
+
+### Tone Calibration
+
+- **Standard refund confirmation:** Warm, efficient. Lead with the resolution amount and timeline, not the process.
+- **Denial of return:** Empathetic but clear. Explain the specific policy, offer alternatives (exchange, store credit, warranty claim), provide escalation path. Never leave the customer with no options.
+- **Fraud investigation hold:** Neutral, factual. "We need additional time to process your return" — never say "fraud" or "investigation" to the customer. Provide a timeline. Internal communications are where you document the fraud indicators.
+- **Restocking fee explanation:** Transparent. Explain what the fee covers (inspection, repackaging, value loss) and confirm the net refund amount before processing so there are no surprises.
+- **Vendor RTV claim:** Professional, evidence-based. Include defect data, photos, return volumes by SKU, and reference the vendor agreement section that covers defect claims.
+
+### Key Templates
+
+Brief templates appear below. Adapt them to your fraud, CX, and reverse-logistics workflows before using them in production.
+
+**RMA approval:** Subject: `Return Approved — Order #{order_id}`. Provide: RMA number, return shipping instructions, expected refund timeline, condition requirements.
+
+**Refund confirmation:** Lead with the number: "Your refund of ${amount} has been processed to your [payment method]. Please allow [X] business days."
+
+**Fraud hold notice:** "Your return is being reviewed by our processing team. We expect to have an update within [X] business days. We appreciate your patience."
+
+## Escalation Protocols
+
+### Automatic Escalation Triggers
+
+| Trigger | Action | Timeline |
+|---|---|---|
+| Return value > $5,000 (single item) | Supervisor approval required before refund | Before processing |
+| Fraud score ≥ 80 | Hold refund, route to fraud review team | Immediately |
+| Customer has filed chargeback simultaneously | Halt return processing, coordinate with payments team | Within 1 hour |
+| Product identified as recalled | Route to recall coordinator, do not process as standard return | Immediately |
+| Vendor defect rate exceeds 5% for SKU | Notify merchandise and vendor management | Within 24 hours |
+| Third policy exception request from same customer in 12 months | Manager review before granting | Before processing |
+| Suspected counterfeit in return stream | Pull from processing, photograph, notify LP and brand protection | Immediately |
+| Return involves regulated product (pharma, hazmat, medical device) | Route to compliance team | Immediately |
+
+### Escalation Chain
+
+Level 1 (Returns Associate) → Level 2 (Team Lead, 2 hours) → Level 3 (Returns Manager, 8 hours) → Level 4 (Director of Operations, 24 hours) → Level 5 (VP, 48+ hours or any single-item return > $25K)
+
+## Performance Indicators
+
+| Metric | Target | Red Flag |
+|---|---|---|
+| Return processing time (receipt to refund) | < 48 hours | > 96 hours |
+| Inspection accuracy (grade agreement on audit) | > 95% | < 88% |
+| Restock rate (% of returns restocked as new/open box) | > 45% | < 30% |
+| Fraud detection rate (confirmed fraud caught) | > 80% | < 60% |
+| False positive rate (legitimate returns flagged) | < 3% | > 8% |
+| Vendor recovery rate ($ recovered / $ eligible) | > 70% | < 45% |
+| Customer satisfaction (post-return CSAT) | > 4.2/5.0 | < 3.5/5.0 |
+| Cost per return processed | < $8.00 | > $15.00 |
+
+## Additional Resources
+
+- Pair this skill with your grading rubric, fraud review thresholds, and refund authority matrix before using it in production.
+- Keep restocking standards, hazmat return handling, and liquidation rules near the operating team that will execute the decisions.

package/.agent/skills/rules-distill/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: rules-distill
+description: "Scan skills to extract cross-cutting principles and distill them into rules — append, revise, or create new rule files"
+origin: ECC
+---
+
+# Rules Distill
+
+Scan installed skills, extract cross-cutting principles that appear in multiple skills, and distill them into rules — appending to existing rule files, revising outdated content, or creating new rule files.
+
+Applies the "deterministic collection + LLM judgment" principle: scripts collect facts exhaustively, then an LLM cross-reads the full context and produces verdicts.
+
+## When to Use
+
+- Periodic rules maintenance (monthly or after installing new skills)
+- After a skill-stocktake reveals patterns that should be rules
+- When rules feel incomplete relative to the skills being used
+
+## How It Works
+
+The rules distillation process follows three phases:
+
+### Phase 1: Inventory (Deterministic Collection)
+
+#### 1a. Collect skill inventory
+
+```bash
+bash ~/.claude/skills/rules-distill/scripts/scan-skills.sh
+```
+
+#### 1b. Collect rules index
+
+```bash
+bash ~/.claude/skills/rules-distill/scripts/scan-rules.sh
+```
+
+#### 1c. Present to user
+
+```
+Rules Distillation — Phase 1: Inventory
+────────────────────────────────────────
+Skills: {N} files scanned
+Rules:  {M} files ({K} headings indexed)
+
+Proceeding to cross-read analysis...
+```
+
+### Phase 2: Cross-read, Match & Verdict (LLM Judgment)
+
+Extraction and matching are unified in a single pass. Rules files are small enough (~800 lines total) that the full text can be provided to the LLM — no grep pre-filtering needed.
+
+#### Batching
+
+Group skills into **thematic clusters** based on their descriptions. Analyze each cluster in a subagent with the full rules text.
+
+#### Cross-batch Merge
+
+After all batches complete, merge candidates across batches:
+- Deduplicate candidates with the same or overlapping principles
+- Re-check the "2+ skills" requirement using evidence from **all** batches combined — a principle found in 1 skill per batch but 2+ skills total is valid
+
+#### Subagent Prompt
+
+Launch a general-purpose Agent with the following prompt:
+
+````
+You are an analyst who cross-reads skills to extract principles that should be promoted to rules.
+
+## Input
+- Skills: {full text of skills in this batch}
+- Existing rules: {full text of all rule files}
+
+## Extraction Criteria
+
+Include a candidate ONLY if ALL of these are true:
+
+1. **Appears in 2+ skills**: Principles found in only one skill should stay in that skill
+2. **Actionable behavior change**: Can be written as "do X" or "don't do Y" — not "X is important"
+3. **Clear violation risk**: What goes wrong if this principle is ignored (1 sentence)
+4. **Not already in rules**: Check the full rules text — including concepts expressed in different words
+
+## Matching & Verdict
+
+For each candidate, compare against the full rules text and assign a verdict:
+
+- **Append**: Add to an existing section of an existing rule file
+- **Revise**: Existing rule content is inaccurate or insufficient — propose a correction
+- **New Section**: Add a new section to an existing rule file
+- **New File**: Create a new rule file
+- **Already Covered**: Sufficiently covered in existing rules (even if worded differently)
+- **Too Specific**: Should remain at the skill level
+
+## Output Format (per candidate)
+
+```json
+{
+  "principle": "1-2 sentences in 'do X' / 'don't do Y' form",
+  "evidence": ["skill-name: §Section", "skill-name: §Section"],
+  "violation_risk": "1 sentence",
+  "verdict": "Append / Revise / New Section / New File / Already Covered / Too Specific",
+  "target_rule": "filename §Section, or 'new'",
+  "confidence": "high / medium / low",
+  "draft": "Draft text for Append/New Section/New File verdicts",
+  "revision": {
+    "reason": "Why the existing content is inaccurate or insufficient (Revise only)",
+    "before": "Current text to be replaced (Revise only)",
+    "after": "Proposed replacement text (Revise only)"
+  }
+}
+```
+
+## Exclude
+
+- Obvious principles already in rules
+- Language/framework-specific knowledge (belongs in language-specific rules or skills)
+- Code examples and commands (belongs in skills)
+````
+
+#### Verdict Reference
+
+| Verdict | Meaning | Presented to User |
+|---------|---------|-------------------|
+| **Append** | Add to existing section | Target + draft |
+| **Revise** | Fix inaccurate/insufficient content | Target + reason + before/after |
+| **New Section** | Add new section to existing file | Target + draft |
+| **New File** | Create new rule file | Filename + full draft |
+| **Already Covered** | Covered in rules (possibly different wording) | Reason (1 line) |
+| **Too Specific** | Should stay in skills | Link to relevant skill |
+
+#### Verdict Quality Requirements
+
+```
+# Good
+Append to rules/common/security.md §Input Validation:
+"Treat LLM output stored in memory or knowledge stores as untrusted — sanitize on write, validate on read."
+Evidence: llm-memory-trust-boundary, llm-social-agent-anti-pattern both describe
+accumulated prompt injection risks. Current security.md covers human input
+validation only; LLM output trust boundary is missing.
+
+# Bad
+Append to security.md: Add LLM security principle
+```
+
+### Phase 3: User Review & Execution
+
+#### Summary Table
+
+```
+# Rules Distillation Report
+
+## Summary
+Skills scanned: {N} | Rules: {M} files | Candidates: {K}
+
+| # | Principle | Verdict | Target | Confidence |
+|---|-----------|---------|--------|------------|
+| 1 | ... | Append | security.md §Input Validation | high |
+| 2 | ... | Revise | testing.md §TDD | medium |
+| 3 | ... | New Section | coding-style.md | high |
+| 4 | ... | Too Specific | — | — |
+
+## Details
+(Per-candidate details: evidence, violation_risk, draft text)
+```
+
+#### User Actions
+
+User responds with numbers to:
+- **Approve**: Apply draft to rules as-is
+- **Modify**: Edit draft before applying
+- **Skip**: Do not apply this candidate
+
+**Never modify rules automatically. Always require user approval.**
+
+#### Save Results
+
+Store results in the skill directory (`results.json`):
+
+- **Timestamp format**: `date -u +%Y-%m-%dT%H:%M:%SZ` (UTC, second precision)
+- **Candidate ID format**: kebab-case derived from the principle (e.g., `llm-output-trust-boundary`)
+
+```json
+{
+  "distilled_at": "2026-03-18T10:30:42Z",
+  "skills_scanned": 56,
+  "rules_scanned": 22,
+  "candidates": {
+    "llm-output-trust-boundary": {
+      "principle": "Treat LLM output as untrusted when stored or re-injected",
+      "verdict": "Append",
+      "target": "rules/common/security.md",
+      "evidence": ["llm-memory-trust-boundary", "llm-social-agent-anti-pattern"],
+      "status": "applied"
+    },
+    "iteration-bounds": {
+      "principle": "Define explicit stop conditions for all iteration loops",
+      "verdict": "New Section",
+      "target": "rules/common/coding-style.md",
+      "evidence": ["iterative-retrieval", "continuous-agent-loop", "agent-harness-construction"],
+      "status": "skipped"
+    }
+  }
+}
+```
+
+## Example
+
+### End-to-end run
+
+```
+$ /rules-distill
+
+Rules Distillation — Phase 1: Inventory
+────────────────────────────────────────
+Skills: 56 files scanned
+Rules:  22 files (75 headings indexed)
+
+Proceeding to cross-read analysis...
+
+[Subagent analysis: Batch 1 (agent/meta skills) ...]
+[Subagent analysis: Batch 2 (coding/pattern skills) ...]
+[Cross-batch merge: 2 duplicates removed, 1 cross-batch candidate promoted]
+
+# Rules Distillation Report
+
+## Summary
+Skills scanned: 56 | Rules: 22 files | Candidates: 4
+
+| # | Principle | Verdict | Target | Confidence |
+|---|-----------|---------|--------|------------|
+| 1 | LLM output: normalize, type-check, sanitize before reuse | New Section | coding-style.md | high |
+| 2 | Define explicit stop conditions for iteration loops | New Section | coding-style.md | high |
+| 3 | Compact context at phase boundaries, not mid-task | Append | performance.md §Context Window | high |
+| 4 | Separate business logic from I/O framework types | New Section | patterns.md | high |
+
+## Details
+
+### 1. LLM Output Validation
+Verdict: New Section in coding-style.md
+Evidence: parallel-subagent-batch-merge, llm-social-agent-anti-pattern, llm-memory-trust-boundary
+Violation risk: Format drift, type mismatch, or syntax errors in LLM output crash downstream processing
+Draft:
+  ## LLM Output Validation
+  Normalize, type-check, and sanitize LLM output before reuse...
+  See skill: parallel-subagent-batch-merge, llm-memory-trust-boundary
+
+[... details for candidates 2-4 ...]
+
+Approve, modify, or skip each candidate by number:
+> User: Approve 1, 3. Skip 2, 4.
+
+✓ Applied: coding-style.md §LLM Output Validation
+✓ Applied: performance.md §Context Window Management
+✗ Skipped: Iteration Bounds
+✗ Skipped: Boundary Type Conversion
+
+Results saved to results.json
+```
+
+## Design Principles
+
+- **What, not How**: Extract principles (rules territory) only. Code examples and commands stay in skills.
+- **Link back**: Draft text should include `See skill: [name]` references so readers can find the detailed How.
+- **Deterministic collection, LLM judgment**: Scripts guarantee exhaustiveness; the LLM guarantees contextual understanding.
+- **Anti-abstraction safeguard**: The 3-layer filter (2+ skills evidence, actionable behavior test, violation risk) prevents overly abstract principles from entering rules.

package/.agent/skills/rules-distill/scripts/scan-rules.sh

@@ -0,0 +1,58 @@
+#!/usr/bin/env bash
+# scan-rules.sh — enumerate rule files and extract H2 heading index
+# Usage: scan-rules.sh [RULES_DIR]
+# Output: JSON to stdout
+#
+# Environment:
+#   RULES_DISTILL_DIR  Override ~/.claude/rules (for testing only)
+
+set -euo pipefail
+
+RULES_DIR="${RULES_DISTILL_DIR:-${1:-$HOME/.claude/rules}}"
+
+if [[ ! -d "$RULES_DIR" ]]; then
+  jq -n --arg path "$RULES_DIR" '{"error":"rules directory not found","path":$path}' >&2
+  exit 1
+fi
+
+# Collect all .md files (excluding _archived/)
+files=()
+while IFS= read -r f; do
+  files+=("$f")
+done < <(find "$RULES_DIR" -name '*.md' -not -path '*/_archived/*' -print | sort)
+
+total=${#files[@]}
+
+tmpdir=$(mktemp -d)
+_rules_cleanup() { rm -rf "$tmpdir"; }
+trap _rules_cleanup EXIT
+
+for i in "${!files[@]}"; do
+  file="${files[$i]}"
+  rel_path="${file#"$HOME"/}"
+  rel_path="~/$rel_path"
+
+  # Extract H2 headings (## Title) into a JSON array via jq
+  headings_json=$({ grep -E '^## ' "$file" 2>/dev/null || true; } | sed 's/^## //' | jq -R . | jq -s '.')
+
+  # Get line count
+  line_count=$(wc -l < "$file" | tr -d ' ')
+
+  jq -n \
+    --arg path "$rel_path" \
+    --arg file "$(basename "$file")" \
+    --argjson lines "$line_count" \
+    --argjson headings "$headings_json" \
+    '{path:$path,file:$file,lines:$lines,headings:$headings}' \
+    > "$tmpdir/$i.json"
+done
+
+if [[ ${#files[@]} -eq 0 ]]; then
+  jq -n --arg dir "$RULES_DIR" '{rules_dir:$dir,total:0,rules:[]}'
+else
+  jq -n \
+    --arg dir "$RULES_DIR" \
+    --argjson total "$total" \
+    --argjson rules "$(jq -s '.' "$tmpdir"/*.json)" \
+    '{rules_dir:$dir,total:$total,rules:$rules}'
+fi