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
- Distinctive: line 38
Every invocation resolves to exactly one mode.
- Distinctive: line 49
After a long-running subagent batch or background command fails.
- Distinctive: line 50
Before reporting an unresolvable failure to the user or orchestrator.
- Distinctive: line 51
When an in-progress task must be abandoned and resumable later.
- Very specific: line 52
When sweeping open dead-letter records (dead-letter status) — past-SLA or high-retry records need triage.
- Very specific: line 53
When a bug or blocker is worth handing to Dev/QA as a reproduction case (repro pack).
- Distinctive: line 77
Read full error logs, terminal stderr, or subagent exit messages.
- Very specific: line 83
Before authoring any retry packet, verify against references/circuit-breaker.md:
- Very specific: line 84
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.
- Distinctive: line 89
Never retry blindly. A "failed" state can be mid-backoff, mid-poll, or already partially applied.
- Very specific: line 96
Atomic Persistence: Write initially to .agents/artifacts/.tmp-dl-* and atomically rename to prevent corruption under concurrent subagent …
- Distinctive: line 137
Generic Error Codes: Never classify as *"Unknown Error"*.
- Distinctive: line 138
Discarding Partial Work: Always list and preserve partial code files created before failure.
- Distinctive: line 139
Open-Ended Escalations: Every escalation must include a clear, binary or multiple-choice decision question.
≈ “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.
Files
📮 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:
| Mode | Trigger phrases | Behavior | Reference |
circuit-breaker | "dead-letter circuit-breaker", "circuit-breaker" | Toxic Task Circuit Breaker & Concurrency Safety | references/circuit-breaker.md |
record-schema | "dead-letter record-schema", "record-schema" | Dead-Letter Record Schema | references/record-schema.md |
sweep-protocol | "dead-letter sweep-protocol", "sweep-protocol" | Status Sweep & Cluster Triage Protocol | references/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
| Code | Failure Mode | Resolution Path |
BLOCKED-CRED | Missing credential / API key | Request credential securely → Retry |
BLOCKED-PERM | Permission or human approval gate | Route to human / orchestrator with approval question |
BLOCKED-DATA | Missing file, schema, or mock data | Identify producer → Generate missing prerequisite |
BLOCKED-AMBIG | Underspecified goal / ambiguity | Rewrite handoff packet with explicit constraints |
BLOCKED-RATE | Rate limited / temporary outage | Apply exponential backoff delay → Retry |
FAILED-LOGIC | Defective algorithm or broken logic | Route to code reviewer / PIP debugging |
FAILED-TOOL | CLI, dependency, or MCP tool crash | Fix dependency / provide isolated workaround |
FAILED-SCOPE | Missing required agent capability | Re-route to specialized division |
PARTIAL | Partial completion with clean breakpoint | Checkpoint 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:
- 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. - 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.
- 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.
- Emit one Precondition Check — a command or query confirming the system is in the retryable state.
- 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):
| Component | Requirement |
| Reproduction steps | Exact, numbered, deterministic — each step observable, no "try again" ambiguity |
| Preconditions | Data, environment, config, versions — everything a stranger needs to reach the failing state |
| Expected vs actual | The assertion pair from the original failure — what the system should do vs what it did |
| Minimal failing test | One 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 note | The 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>.mdexists. - 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.mdexists 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.
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- BigCactusLabs/dead-letter★ 8same name
- Wh0FF24/whoff-agents★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- llms.txtllms.txt
- accountsSkill
- analyticsSkill
- automationSkill
- brandSkill
- client-commsSkill
- contentSkill
- crmSkill
- databaseSkill
- designSkill
- devopsSkill
- growthSkill
- gtmSkill
- incident-responseSkill
- mobileSkill
- opsSkill
- paidadsSkill
- qa-launchSkill
- researchSkill
- retainSkill
- sales-enablementSkill
- seoSkill
- smmSkill
- telegramSkill
- webdevSkill
- context-anchorSkill
- coupling-routerSkill
- evidence-ledgerSkill
- relaySkill
- secretarySkill
- gitSkill
- new-projectSkill
- updateagentsSkill
- updatedocsSkill
- animateSkill
- designscopeSkill
- refactorSkill
- auditSkill
- code-reviewSkill
- gauntlet-loopSkill
- humanizeSkill
- muse-securitySkill
- puaSkill
- clean-system-cacheSkill
- coachSkill
- periodic-retreatSkill
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.

