agentleFS
harshsinghmpharshsinghmp/muse-skills/skills/quality-review/dead-letter/SKILL.md

dead-letter

Skill1 starsChanged 18 days agoMITView on GitHub

Capture a failed or blocked task before it disappears. Categorizes the failure mode, distinguishes transient from permanent failures, verifies actual state before any retry, preserves partial work and orphaned resources, and generates either a bounded autonomous retry packet with the root cause fixed or an escalation message with a specific decision question. Recovery follows a strict ordered sequence with baseline regression comparison against the last-known-good state, close-out can generate a repro test pack (exact reproduction steps, preconditions, expected-vs-actual, minimal failing test) for Dev/QA handoff, and the status sweep clusters open records by root cause so repeated failures across tasks surface as one systemic finding with one fix — with a findings ledger that deduplicates recurring sweeps and measures convergence.

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 9 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every invocation resolves to exactly one mode.

    line 38
  2. Distinctive:

    After a long-running subagent batch or background command fails.

    line 49
  3. Distinctive:

    Before reporting an unresolvable failure to the user or orchestrator.

    line 50
  4. Distinctive:

    When an in-progress task must be abandoned and resumable later.

    line 51
  5. Very specific:

    When sweeping open dead-letter records (dead-letter status) — past-SLA or high-retry records need triage.

    line 52
  6. Very specific:

    When a bug or blocker is worth handing to Dev/QA as a reproduction case (repro pack).

    line 53
  7. Distinctive:

    Read full error logs, terminal stderr, or subagent exit messages.

    line 77
  8. Very specific:

    Before authoring any retry packet, verify against references/circuit-breaker.md:

    line 83
  9. Very specific:

    Circuit Breaker Status: If the same (code, root-cause) failed $\ge 2$ times on this task or blast radius $\ge 3$, the circuit is TRIPPED.

    line 84
  10. Distinctive:

    Never retry blindly. A "failed" state can be mid-backoff, mid-poll, or already partially applied.

    line 89
  11. Very specific:

    Atomic Persistence: Write initially to .agents/artifacts/.tmp-dl-* and atomically rename to prevent corruption under concurrent subagent …

    line 96
  12. Distinctive:

    Generic Error Codes: Never classify as *"Unknown Error"*.

    line 137
  13. Distinctive:

    Discarding Partial Work: Always list and preserve partial code files created before failure.

    line 138
  14. Distinctive:

    Open-Ended Escalations: Every escalation must include a clear, binary or multiple-choice decision question.

    line 139

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

📮 dead-letter — Failed Task Triage & Capture

Capture a failed or blocked task before context clears. Categorizes failure modes into a 9-part taxonomy, distinguishes transient from permanent failures, verifies actual state before any retry, preserves partial work and orphaned resources, and generates either a bounded autonomous retry prompt or an escalation decision point. Recovery follows a strict ordered sequence — classify → decide → precondition → fix → verify-against-baseline → close — tracked step-by-step in the record so a retry resumes exactly where recovery stopped. At close-out, deterministic failures can be converted into a repro test pack: the capture that documents a failure becomes the regression test that prevents its recurrence. The status sweep clusters open records by root cause — repeated failures across different tasks surface as one systemic finding with one fix, not a storm of individual retries.


Modes

Every invocation resolves to exactly one mode. Load only the matched reference:

ModeTrigger phrasesBehaviorReference
circuit-breaker"dead-letter circuit-breaker", "circuit-breaker"Toxic Task Circuit Breaker & Concurrency Safetyreferences/circuit-breaker.md
record-schema"dead-letter record-schema", "record-schema"Dead-Letter Record Schemareferences/record-schema.md
sweep-protocol"dead-letter sweep-protocol", "sweep-protocol"Status Sweep & Cluster Triage Protocolreferences/sweep-protocol.md

When to Use

  • An agent returns "I can't proceed", "blocked on", "error:", or a partial result.
  • After a long-running subagent batch or background command fails.
  • Before reporting an unresolvable failure to the user or orchestrator.
  • When an in-progress task must be abandoned and resumable later.
  • When sweeping open dead-letter records (dead-letter status) — past-SLA or high-retry records need triage.
  • When a bug or blocker is worth handing to Dev/QA as a reproduction case (repro pack).
  • On a scheduled sweep (nightly failure triage) — open records get clustered by root cause so systemic issues surface once, not per-task.

Quick Reference

CodeFailure ModeResolution Path
BLOCKED-CREDMissing credential / API keyRequest credential securely → Retry
BLOCKED-PERMPermission or human approval gateRoute to human / orchestrator with approval question
BLOCKED-DATAMissing file, schema, or mock dataIdentify producer → Generate missing prerequisite
BLOCKED-AMBIGUnderspecified goal / ambiguityRewrite handoff packet with explicit constraints
BLOCKED-RATERate limited / temporary outageApply exponential backoff delay → Retry
FAILED-LOGICDefective algorithm or broken logicRoute to code reviewer / PIP debugging
FAILED-TOOLCLI, dependency, or MCP tool crashFix dependency / provide isolated workaround
FAILED-SCOPEMissing required agent capabilityRe-route to specialized division
PARTIALPartial completion with clean breakpointCheckpoint written files → Handoff remaining steps

Procedure

Step 1: Ingest Failure Signals

Read full error logs, terminal stderr, or subagent exit messages.

Step 2: Classify Failure Mode

Assign exact code from the 9-part taxonomy.

Step 3: Recovery Decision & Circuit Breaker Check

Before authoring any retry packet, verify against references/circuit-breaker.md:

  1. Circuit Breaker Status: If the same (code, root-cause) failed $\ge 2$ times on this task or blast radius $\ge 3$, the circuit is TRIPPED. Immediately freeze execution, generate an incident packet at .agents/artifacts/incident-<task-id>-<timestamp>.md, and escalate. Do not author a retry packet.
  2. Transient or permanent? Transient (crash, network blip, rate limit): retry is legitimate. Permanent (defective logic, missing capability): a retry packet is forbidden — escalate or re-scope.
  3. Autonomy level: auto (mechanical fix — diagnose → fix → re-run up to 3 verification rounds without asking), confirm (recovery path obvious but non-mechanical — one approval question), escalate (ambiguous root cause, tripped circuit, or repeated failure — specific decision question, never open-ended).

Step 4: State Verification & Precondition Delta Gate

Never retry blindly. A "failed" state can be mid-backoff, mid-poll, or already partially applied.

  1. Emit one Precondition Check — a command or query confirming the system is in the retryable state.
  2. Require an explicit Precondition Delta: What concretely changed in the code or environment? (e.g., file edited, env var exported). If Precondition Delta is empty/none, RETRY IS STRICTLY FORBIDDEN — escalate immediately to prevent thrashing.

Step 5: Write Dead-Letter Record (Atomic & Sanitized)

Save record to .agents/dead-letter-<timestamp>.md using the canonical template in references/record-schema.md:

  • Zero-Credential Sanitization: Pass all captured stderr, stdout, and error dumps through the redaction filter (Bearer [REDACTED], sk-[REDACTED], postgres://...). Never write raw secrets to disk.
  • Atomic Persistence: Write initially to .agents/artifacts/.tmp-dl-* and atomically rename to prevent corruption under concurrent subagent crashes.
  • The record carries a Recovery Sequence — the ordered checklist (classify → decide → precondition → fix → verify-against-baseline → close) is the single resume point for any retry: completed steps are marked, and a retry resumes from the first unchecked step, never from an arbitrary point. Load the schema reference only when authoring a record.

Step 6: Emit Inline Summary

Output failure code and immediate next step to terminal.


Status Sweep & Cluster Triage (dead-letter status)

On request (or on a scheduled sweep — nightly failure triage), run the three-pass sweep (inventory → cluster by root cause → verdict per cluster) per references/sweep-protocol.md. Load that reference only when sweeping — capture and retry do not need it. Invariant: clusters form on root cause, not error-string similarity; verdicts are systemic / coincidental / cascade / escalate-cluster; a sweep that ends with retry authorization for a systemic cluster has failed. Recurring sweeps consult the findings ledger (.agents/artifacts/dead-letter-ledger.md) to deduplicate verdicts and measure convergence.


Repro Test Pack (close-out conversion)

A dead letter is high-signal evidence; a closed deterministic failure shouldn't just be archived — it should be converted into the regression test that prevents recurrence. At close-out (Recovery Sequence step 6), when the failure is deterministic (permanent-class: FAILED-LOGIC, FAILED-TOOL, or a BLOCKED-* with a stable local trigger) and the environment permits writing test files, generate a repro pack.

When NOT to generate (skip the pack, close the record plainly):

  • Transient or environment-dependent failures (network blips, rate limits) — a flaky repro is worse than none.
  • The fix is already verified against the Baseline Reference and shipped — the test suite already covers it.
  • The project has no test runner or the failure needs external systems (real APIs, prod data) — record the manual steps instead.

Where: .agents/artifacts/repro-<slug>-<timestamp>/ (working-artifacts rule: never the tracked tree; the record links the pack path).

What the pack contains (REPRO.md + one failing test when feasible):

ComponentRequirement
Reproduction stepsExact, numbered, deterministic — each step observable, no "try again" ambiguity
PreconditionsData, environment, config, versions — everything a stranger needs to reach the failing state
Expected vs actualThe assertion pair from the original failure — what the system should do vs what it did
Minimal failing testOne test, smallest surface, red on the un-fixed code — when the project has a test runner. The observed red is evidence; a red you have not seen is a claim
Spec noteThe expected behavior is the specification — if the behavior is actually correct, the spec is wrong: fix the spec, never the test to match broken behavior

The pack is a handoff artifact: Dev/QA (or a fresh agent) runs the test red → fixes → runs green, without re-deriving the failure from logs. The dead-letter record links the pack; on recurrence of the same root cause, the pack is the parent record's evidence attachment — the regression test makes the parent record's retry packet verifiable.


Pitfalls

  • Generic Error Codes: Never classify as "Unknown Error"; pinpoint the exact blocker code.
  • Discarding Partial Work: Always list and preserve partial code files created before failure.
  • Open-Ended Escalations: Every escalation must include a clear, binary or multiple-choice decision question.
  • Blind Retries: Retrying without the precondition check — a mid-backoff or half-applied state turns a clean failure into a corrupt one.
  • Permanent-Failure Retry Loops: Permanent-class failures (logic, capability gaps) get no retry packet; the third occurrence of the same root cause is always an escalation.
  • Leaked Resources: Closing a record without enumerating orphaned PRs, branches, or processes — cleanup commands go in the record, not in memory.
  • Improvised Recovery Order: Resuming a failed recovery from an arbitrary step — the record's Recovery Sequence is the single resume point; skip nothing, reorder nothing.
  • Clean-Exit Regression: Declaring success on a green exit code without comparing against the Baseline Reference — a fix that reintroduces old breakage must fail the verification round.
  • Unseen Red: Shipping a repro pack whose test was never observed failing — a red you have not seen is a claim; run the test against the un-fixed state and record the observed failure output in the pack.
  • String-Match Clustering: Grouping records by similar error text instead of root cause — identical stack traces can hide different causes, and different messages can share one. Read What-Was-Learned for the causal evidence before clustering.
  • Retry Storm on Systemic Clusters: Authorizing per-record retries for records sharing one root cause — the sweep's purpose is one fix covering all members; retrying members individually is the failure the sweep exists to prevent.

Verification

  • Confirm .agents/dead-letter-<timestamp>.md exists.
  • Confirm either a concrete retry prompt OR a routed escalation question is fully specified.
  • Confirm the Recovery Decision is filled (seen-before count, transient/permanent, autonomy level, circuit breaker status).
  • Confirm the Precondition Check ran and its observed result is recorded.
  • Confirm Precondition Delta is documented; if empty/none, confirm retry was forbidden.
  • Confirm Zero-Credential Sanitization passed (no raw tokens, keys, or passwords in stack dumps).
  • Confirm Orphaned Resources is enumerated (or "None.") — no silent leaks.
  • Confirm the Recovery Sequence tracks completed steps and a retry resumes from the first unchecked one.
  • Confirm a Baseline Reference exists when last-known-good state is available, and the verification loop compares against it — not just exit codes.
  • For deterministic failures closed with a pack: confirm REPRO.md exists at the linked path, the test was observed red (output recorded), and the spec note states which document is the source of truth.
  • For a status sweep: confirm clusters were derived from root-cause evidence (What-Was-Learned, precondition results) — not error-string similarity — and the report ends with a sweep action line; systemic clusters carry one fix/escalation, not per-record retries.

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.

Reviews can't be read right now.

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.