impact-triage
Skill2 starsChanged 34 days agoMITView on GitHub
Craft impact-triage phase - re-verify every impact the run deferred through a read-only triager, show the verdicts, file the backlog-worthy ones under the backlog-write policy, and list them in the PR body.
In this repository20 other files it gives its agents.
- architectureSkill
- decisionsSkill
- designSkill
- documentationSkill
- implementationSkill
- initSkill
- integrateSkill
- lessonsSkill
- metricsSkill
- planningSkill
- promote-configSkill
- proposeSkill
- pruneSkill
- refactoringSkill
- requirementsSkill
- reviewSkill
- runSkill
- tuneSkill
- validationSkill
- workspaceSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Cross-phase wait: start only once the in-session awaitingHarnesses set is empty — every awaited executing-harness has landed, its triage is …
- Very specific: line 17
Standalone: no open run means no store.
- Very specific: line 43
No filing target → append NO-OP(impact-triage): no file-backed backlog — verdicts in the PR body only, go to step 5.
- Very specific: line 54
Commit docs(<slug>): file triaged impacts, then append one FILED(<file>): I<n> <title> — not folded: <reason> line per filed entry.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
craft:impact-triage
Preamble (always runs — non-overridable)
- Manifest read (run
manifest-lint.shif standalone). Resolve the filing target perdocs/contributing/specs/backlog.mdFiling:source: file→ itsref; nosourcekey → the rootBACKLOG.mdwhen it exists, else none;source: custom→ none. - Cross-phase wait: start only once the in-session
awaitingHarnessesset is empty — every awaited executing-harness has landed, its triage is done (the documentation late-EXCEPTION synthesis included) and its gate is green, or it was released byauto-skip,NO-OPor a waiver. Not yet → wait. This phase is never itself awaited. - Standalone: no open run means no store. Say
no open run: no discovered-impacts storein the final output and stop, writing nothing. Resolve the store:
ledger="${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/run-ledger.sh" store="$("$ledger" dir)/<run-id>.impacts.md"
Procedure (default body — a manifest override: replaces everything below)
Session-owned, never delegated, except the spawn in step 2: the ledger, the store writes and the BACKLOG write live in the session.
- Untriaged ids. The
I<n>of everyDEFERRED(line of this run with noTRIAGED(I<n>):line. None → go to step 5. - Spawn
craft:impact-triagerwith the store path, the untriaged ids, the worktree path, the filing target path (ornone), the base revision<base>, and the global + impact-triage-phasecontext:files verbatim. - Record each verdict. Pipe its one-line rationale into
"$ledger" verdict <run-id> I<n> <verdict>; the script appends the verdict to the store andTRIAGED(I<n>): <verdict> — <rationale>to the ledger. A returned id with no verdict, or a verdict the script refuses (exit 2), → re-spawn once for those ids only, then blocker{ impact-triage, reason, ≤3 options }. - Show, then file. Print the verdict table (id, verdict, title, rationale) before
anything is written.
- No filing target → append
NO-OP(impact-triage): no file-backed backlog — verdicts in the PR body only, go to step 5. - Else consult the
backlog-writeaction (defaultalways; seedocs/contributing/specs/policy.md). A refusal records itsPOLICY(...)line, writes nothing, and goes to step 5. - On proceed, write every drafted
backlog:*entry under one section### Open (scoped <date> — follow-ups surfaced by the <slug> run, triaged), following the repo's ordering convention. Proof output stays inside its fenced code block; any of it outside a fence is fenced before writing. Each entry keeps itsNot folded: <reason>sentence. A spike entry opens withSpike —and carriesQuestion: <what the probe must answer>. - Commit
docs(<slug>): file triaged impacts, then append oneFILED(<file>): I<n> <title> — not folded: <reason>line per filed entry. - No
backlog:*verdict → no section, no commit.
- No filing target → append
- PR trailer. Rewrite the drafted PR body's
- **Discovered impacts:**line as<n> deferred: <x> ready, <y> spike, <z> reject, then one line per entry (I<n> <verdict> — <title>), ornone.
The phase never gates propose beyond its own steps; a verdict never folds.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

