agentleFS
NashEQifyNashEQify/forge/skills/risk_followup_routing/SKILL.md

risk-followup-routing

Skill2 starsChanged 7 days agoMITView on GitHub

Route a chief verdict's `remaining_findings:` entries by their `target:` annotation (instead of one task per finding). Triggers when a chief verdict carries remaining_findings: to route (build close, fix close); NOT for creating tasks directly (use task_creation).

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read and follow framework/work-principle.md before taking up work.

    line 17
  2. Very specific:

    spec_text batch: if non-empty, dispatch agents/spec-text-drift-batch.md once with the full list (per spec 306 §4.8).

    line 68
  3. Very specific:

    watch_item: if context/risk-watch.md doesn't exist, create from skills/_protocols/risk-watch-template.md.

    line 77
  4. Distinctive:

    accept: no file, no fix, no task, no trigger.

    line 80
  5. Distinctive:

    absorb_next: no immediate action; the verdict entry stays the record until a later change to that file closes it.

    line 82
  6. Distinctive:

    No semantic edit of finding content.

    line 107
  7. Distinctive:

    No task duplicate-check (delegated to chief verdict's finding-level dedup.

    line 109

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Read and follow framework/work-principle.md before taking up work. Resolve this reference against the framework root; retain the consumer CWD.

Skill: risk-followup-routing

Purpose

Dispatch each remaining_findings: entry from a chief verdict to the correct downstream destination based on its target: field. Replaces the legacy risk-followup-task step which created one task per finding (wrong granularity for the actual mix of finding types).

When to call

  • Build workflow close-bookkeeping gate, after chief verdict.
  • Fix workflow analogous gate, after chief verdict.
  • Review workflow analogous gate, after chief verdict.

The chief is responsible for annotating every entry with target: per the 7-value enum (spec 306 §4.7 + code_review_board/verdict.md §5). This skill assumes that annotation exists; if any entry has empty target:, the skill fails with a clear error and surfaces back to the chief for re-emit.

Input

  • Path to chief verdict file (e.g. docs/reviews/board/<id>-consolidated.md).
  • Path to consumer's context/risk-watch.md (created if absent per skills/_protocols/risk-watch-template.md).

Process

  1. Parse the chief verdict's remaining_findings: block. Validate that every entry has a target: field. On missing field: FAIL with target_missing_on_<id>.
  2. Group entries by target: value:
    • spec_text: collect all into a single batch.
    • new_task: each entry filed independently.
    • watch_item: collect for risk-watch append.
    • accept: the verdict entry is the record (accepted limitation — distinct from absorb_next: no future fix implied).
    • absorb_next: the verdict entry is the record; the next review brief for a touched file names it (code_review_board/brief-and-team.md §2).
    • closes_with: <id>: validate referenced finding exists in same verdict.
    • re_review: <reviewer>: collect for re-dispatch.
  3. Dispatch per group:
    • spec_text batch: if non-empty, dispatch agents/spec-text-drift-batch.md once with the full list (per spec 306 §4.8). If chief verdict is FAIL and MCA fix-pass dispatches in parallel, fire both in one tool message (the parallel-dispatch invariant is in §4.8).
    • new_task per entry: dispatch task_creation skill per entry. When called from this routing, skip the duplicate-check step of task_creation (the chief verdict already deduped at finding-level).
    • watch_item: if context/risk-watch.md doesn't exist, create from skills/_protocols/risk-watch-template.md. Append each entry verbatim under ## Entries.
    • accept: no file, no fix, no task, no trigger; the verdict entry records the known accepted limitation.
    • absorb_next: no immediate action; the verdict entry stays the record until a later change to that file closes it.
    • closes_with: assert the referenced finding exists in the same verdict. On miss: FAIL with closes_with_target_missing. On hit: no further action.
    • re_review: dispatch the named reviewer with the finding cluster as scoped focus. The re-review's verdict appends to the existing chief verdict (not a new pass). One-shot — if uncertainty persists, escalate to council per existing cross-layer-decision pattern.
  4. Aggregate routing report: <N> entries routed (<count> spec_text, <count> new_task, <count> watch_item, <count> accept, <count> absorb_next, <count> closes_with, <count> re_review).

Output

DELIVERS:

  • Spec-text patches applied (via spec-text-drift-batch sub-agent return, when spec_text entries exist).
  • Tasks filed (via task_creation per entry).
  • Risk-watch append (one or more entries).
  • accept / absorb_next / closes_with: the verdict entry is the record (no file).
  • Re-review dispatched for re_review entries.

DOES NOT DELIVER:

  • No semantic edit of finding content. The routing applies what the chief decided; it does not re-decide.
  • No task duplicate-check (delegated to chief verdict's finding-level dedup; explicit skip-flag passed to task_creation).

ENABLES:

  • Bulk-task-bloat avoidance (vs the legacy risk-followup-task which filed one task per finding regardless of type).
  • Mechanical traceability (every finding ends up in a known location: applied diff / task / risk-watch / verdict).

Failure modes

  • Missing target: field: chief verdict didn't annotate all entries. FAIL — return to chief for re-emit.
  • closes_with: <id> references non-existent finding: chief emit error. FAIL with locator.
  • re_review: <reviewer> references unknown reviewer: the reviewer name is not in the framework's persona registry. FAIL with reviewer name + suggestion to use a known persona.
  • spec-text-drift-batch returns PARTIAL: some entries skipped. Surface the skip reasons to user; the routing succeeds for the applied entries but flags partial-completion.

Replaces

  • Legacy risk-followup-task step in build / fix / review WORKFLOW.md. The legacy step's name is preserved as a deprecated alias for one release cycle to avoid breaking in-flight runs; new dispatches use risk-followup-routing.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.