// Triage accumulated learnings from the local harny inbox into GitHub Issues, CLAUDE.md edits, or discards. Walks one entry at a time, verifies claims against current code, opens issues with provenance. Sister of /learn.
| name | drain |
| description | Triage accumulated learnings from the local harny inbox into GitHub Issues, CLAUDE.md edits, or discards. Walks one entry at a time, verifies claims against current code, opens issues with provenance. Sister of /learn. |
| allowed-tools | Bash, Read, Edit, Write |
The drainable companion to /learn. Walks the user through the inbox at <cwd>/.harny/LEARNINGS.local.md (and optionally .harny/*/review.md files), classifying each entry into a destination — GitHub Issue, CLAUDE.md edit, or DISCARD — with evidence cited.
This skill is analytical and slow. Unlike /learn (which captures verbatim), drain verifies claims, decomposes multi-part actions, and writes back changes only with the user's approval per entry.
<cwd>/.harny/LEARNINGS.local.md — raw captures from /learn.<cwd>/.harny/*/review.md — per-run reviews produced by /review. Treat the "Architect proposals" section as drainable; inline review narrative is context only.If neither source has content, tell the user there's nothing to drain and stop.
Batch summary tables tempt bulk classification without thinking. Walk one entry at a time, human-in-the-loop.
For N > 10 entries, offer the user a pause marker mid-drain:
5 done, 7 remaining — continue, or pause here?
For each entry, in order:
So you both look at the same words.
Before classifying, check the code/repo:
Read, git log -- <path>, git show <sha>.dedup-task-trailer → fix likely landed. Check git log --all --oneline --grep <keyword>.If the entry has sub-actions (a), (b), (c), triage each separately. Common pattern: (a) and (b) landed, (c) is still open → opens an Issue scoped to (c) only, discards (a)+(b).
Would a fresh dev, reading only CLAUDE.md + code, hit the same friction?
If yes → there's still teaching to do (CLAUDE.md edit or Issue). If no → the lesson has been absorbed elsewhere → DISCARD.
Load the classification patterns once, early in the drain:
Read ${CLAUDE_SKILL_DIR}/patterns.md
Match the entry to one of the 6 patterns. Propose the destination with evidence.
Show:
Do not execute until the user says go.
Per verdict:
.harny/LEARNINGS.local.md to remove the entry. No other artifact created.gh issue list --search ... to dedup first; then gh issue create with proper title prefix and learning label. Remove inbox entry.gh discussion create with rfc: or decide: prefix. Remove inbox entry.[deferred YYYY-MM-DD: <reason>]. Keep entry.While verifying entries, you'll often spot unrelated documentation drift — a CLAUDE.md paragraph describing a value that changed months ago, a §N reference pointing at a deleted doc, etc.
Rule:
documentation rather than expanding the entry's verdict.Track classification cohorts during the walk. At the end, emit concise cluster alerts:
gh issue list --search "<key terms>" --state all --json number,title,state. Surface matches before opening.feat:, bug:, learning:, docs:, chore:.learning if origin was a drained entry, plus one of enhancement / bug / documentation.rfc: for debate, decide: for decision-shaped prompt.rfc or decision. Add resolved after the discussion concludes (enables ADR-style search via label:decision label:resolved)..harny/LEARNINGS.local.md.[deferred YYYY-MM-DD: <reason>]..harny/LEARNINGS.local.md, the proposed CLAUDE.md edits, and inline doc-drift fixes (each approved per-entry)./learn to capture first..harny/ dir was cleaned → state is gone, but the entry text is still drainable. Verify against current code instead.gh not authenticated → ask user to gh auth login. Do not proceed with Issue/Discussion actions./learn it; resume drain.Onboarding and router for the harny plugin. Teaches the harny mental model (run anatomy, .harny/ state, architect role) and routes to focused skills. Use when adopting harny or unsure where to start.
Walk a repo through the harny readiness checklist. Score 10 dimensions Red/Yellow/Green, surface anti-signals, output a scorecard + prep checklist. Use when adopting harny in a new repo, or troubleshooting why it struggles in a familiar one.
Append a one-line learning to the local harny inbox. Fast, non-analytical capture — copies text verbatim, no analysis, no follow-ups. Use when the user wants to note something about harny adoption mid-conversation without breaking flow.
Orchestrate a release cycle across multiple harny runs. Dispatch with product-vision prompts, parallelize when safe, code-review every merge, triage findings into NOW-blocks/NOW-quick/BACKLOG. Use as release manager across N runs.
Post-mortem of a single harny run. Reads state.json + plan.json + per-phase transcripts. Emits a leaves-to-trunk review with evidence-backed proposals (triaged NOW-blocks/NOW-quick/BACKLOG). Use after failed, retried, slow, or novel runs.