원클릭으로 Manus에서 모든 스킬 실행

failure-archaeology

스타24

포크8

업데이트2026년 7월 20일 09:30

Never re-fight a settled battle. Discipline for recording and RETRIEVING past failures — gotchas, incidents, postmortems, dead ends, reverted fixes — as symptom → root cause → evidence → status. Use before debugging anything that smells familiar, when an incident closes, when a fix gets reverted, when an approach is abandoned, or when asked to document a bug just solved, write a postmortem, do failure archaeology, incident memory, or "did we hit this before". Not for capturing general knowledge (use brain_capture / brain_write) or live task tracking.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

usecompai

usecompai/compound-operations-model

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Failure Archaeology

the reference deployment already pays for its lessons — knowledge/platform/gotchas/ holds ~90 entries (91 files incl. _index.md, counted 2026-07-05). The failure mode is not capture, it's retrieval: an agent burns 40 minutes re-deriving why Codex OAuth died when openai-codex-refresh-token-reused-2026-05-14.md already settled it. This skill makes the archive load-bearing in both directions.

The rule that matters most

Before investigating any failure, search the archaeology first. 60 seconds of search beats re-fighting a settled battle:

brain_search("<distinctive error string or symptom keyword>")
brain_search("<system name> <failure verb>")   # e.g. "codex auth", "qmd hang", "mcp timeout"
brain_list("knowledge/platform/gotchas")        # scan filenames — they are date-stamped symptom slugs

If a hit explains your symptom: read it, apply the settled fix, and note in your output that the archaeology resolved it. If a hit is close but different, say explicitly how your case differs — that difference is the new entry's opening line.

When to write an entry

Write to knowledge/platform/gotchas/<symptom-slug>-YYYY-MM-DD.md when ANY of:

An investigation took >20 minutes and ended in a root cause.
A fix was reverted or an approach abandoned — dead ends are the highest-value entries because they are invisible in the final system.
The same symptom appeared for the second time (recurrence = the first entry failed retrieval; improve its keywords too).
An external system behaved contrary to its docs (API quirks, auth flows, rate limits).

Entry format (the four fields that make it retrievable)

# <Symptom in plain words> — YYYY-MM-DD

**Symptom:** what was observed, with the LITERAL error strings (future agents grep these).
**Root cause:** the actual mechanism, 2-4 sentences. Not the fix — the WHY.
**Evidence:** commands run + output that proved it (paths, dates, numbers).
**Status:** settled | open | recurring (Nth time: link prior entries)

**Fix / decision:** what was done or deliberately NOT done.
**Wrong paths tried:** approaches that looked right and weren't — one line each, so nobody retries them.

Rules:

Literal error strings verbatim — retrieval works by substring; "token error" finds nothing, refresh_token_reused finds the entry.
Symptom in the filename, not the fix ("mcp-timeout-long-deliberations" not "async-job-pattern").
One incident per file. If a root cause explains several symptoms, one file owns the cause, others link it.
No secret values in evidence — variable names and file paths only.

Consolidation (quarterly, or when a domain accumulates 5+ entries)

Individual entries answer "did we hit this?"; a chronicle answers "what does this system keep teaching us?". When a domain (Codex auth, QMD, MCP transport…) accumulates entries, write/update a chronicle doc knowledge/platform/gotchas/_chronicle-<domain>.md: a table of symptom → root cause → status → entry link, ordered by date, with the standing invariant extracted on top (e.g. "Codex refresh tokens are single-use; any sharing across profiles eventually kills all of them — gotcha entries 2026-05-14, 05-20, 05-25, 05-26, plus the 2026-07-03 channel change recorded inside codex-handoff/SKILL.md"). The chronicle is the transfer of criterion; entries are its evidence.

Guardrails

❌	✅
Start debugging a familiar smell from scratch	brain_search the symptom first, always
Write the war story (chronology of your session)	Extract symptom/cause/evidence/status; the session narrative dies with the session
Record only what worked	Record reverted fixes and dead ends explicitly
Paraphrase error messages	Paste them verbatim — they are the search keys
Treat recurrence as bad luck	Recurrence = retrieval failure; strengthen the old entry's keywords + link entries
Bury root causes in daily memory/ files only	memory/ is a diary; gotchas/ is the archive. Cause goes to gotchas, memory links it

Verification

Entry is done when: brain_search("<its literal error string>") returns it, status field present, and no secret values inside. Chronicle is done when every linked entry resolves via brain_read.

Cross-references

Capture tools: brain_capture, brain_write (general knowledge — not failure-specific)
Debug delegation with gotcha-doc requirement built in: internal codex-handoff skill, template B (not included in this public package)
Audit that uses closed-loop evidence: brain-due-diligence
Exemplary existing entries: knowledge/platform/gotchas/openai-codex-refresh-token-reused-2026-05-14.md, knowledge/platform/gotchas/qmd-vps-raw-overindexing-and-embed-hang-2026-06-01.md

Provenance and maintenance

Gotchas dir + ~95 entries: verified 2026-07-05 via brain_list("knowledge/platform/gotchas"). Re-verify the same way.
No chronicles exist yet as of 2026-07-05 (first candidates: Codex/OAuth auth — 4+ entries; QMD — 6+ entries).

Cambios

Fecha	Cambio	Por
2026-07-05	Created — tomicz failure-archaeology pattern grafted onto existing the reference deployment gotchas practice; adds retrieval-first rule, entry format, chronicles.	Claude Code (Fable 5)

이 저장소의 다른 Skills

같은 저장소

research-prompting

usecompai/compound-operations-model

Write research prompts that come back decision-ready — zero-prior-knowledge framing, evidence hierarchy, fact/inference separation, and a mandatory gap round. Use when formulating a research prompt, deep research request, competitive research, market research, due diligence question, or when delegating research to exa_search, an agent, Codex, or an external researcher. Not for running the research itself end-to-end (deep-research, autoresearch, gemini-deep-research, exa_search EXECUTE research — this skill writes the brief that feeds them), not for the reference deployment strategic deliberation (use council/punta-de-flecha), and not for Brain lookups (brain_search first, always).

2026-07-2024

session-handoff

usecompai/compound-operations-model

Transfer full working context to a fresh agent session with zero memory — end of session, before compaction, switching models/agents mid-project, or pausing multi-day work. Use when asked for a handoff, handoff doc, session transfer, "deja esto listo para la próxima sesión", context dump for another agent, or when a long session is about to hit context limits. Not for delegating a bounded task (use codex-handoff) or for task cards (use handoff-task / brain_task tools).

2026-07-2024

skill-evaluation

usecompai/compound-operations-model

Evaluate whether a the reference deployment skill actually works — blind runner + separate judge against a bar, rubric scoring, pass-rate on re-runs, and defect diagnosis. Use when asked to evaluate a skill, eval skills, run a blind eval, score against a rubric, test a skill, audit skill quality, grade a skill, review the skill library, or before promoting a new skill to the company master prompt or the whole swarm. Not for writing skills (use skill-authoring-standards) or deciding which to create (use suggest-skills).

2026-07-2024

spec-driven-execution

usecompai/compound-operations-model

Turn a big or ambiguous technical task into a spec of independently verifiable slices, implement slice-by-slice with verification gates, and close the spec with a claim audit. Use when asked to write a spec, implement a spec, plan a build, break down a feature, structure a multi-day or multi-week technical project or migration, or when a Codex/agent delegation is too big for one self-contained prompt. Not for small tasks (single codex-handoff prompt suffices) or non-technical plans.

2026-07-2024

visual-review

usecompai/compound-operations-model

Verify visual work with evidence instead of vibes — screenshot critique by a fresh judge, before/after comparison, crops of the disputed detail, and a distance-not-verdict mindset. Use when reviewing a UI, landing, email template, dashboard, canvas, or design change; when doing a screenshot critique, comparing screenshots, doing visual QA or UI QA on a landing page, checking a clone against a reference, or before declaring any visual deliverable done. Not for choosing a design direction or running a dedicated accessibility audit.

2026-07-2024

omnichannel-foot-traffic-attribution

usecompai/compound-operations-model

Cruza foot traffic Store A/Store B con Meta geo spend, GA4 city sessions y Shopify POS. Estima halo effect por tienda y recomienda redistribucion spend.

2026-07-1224

name	failure-archaeology
description	Never re-fight a settled battle. Discipline for recording and RETRIEVING past failures — gotchas, incidents, postmortems, dead ends, reverted fixes — as symptom → root cause → evidence → status. Use before debugging anything that smells familiar, when an incident closes, when a fix gets reverted, when an approach is abandoned, or when asked to document a bug just solved, write a postmortem, do failure archaeology, incident memory, or "did we hit this before". Not for capturing general knowledge (use brain_capture / brain_write) or live task tracking.
owner	platform
created	"2026-07-05T00:00:00.000Z"
created_by	claude-fable-5
validated_on	2026-07-06 blind eval — zero-context Sonnet runner discovered the skill via skill_search and produced _chronicle-codex-oauth.md (11 entries) + _chronicle-qmd.md (9 entries); separate judge verdict PASS/PASS, no defects
sources	adapted from tomicz/fable-5-train-opus-skills (failure-archaeology pattern, MIT), built on the reference deployment's existing knowledge/platform/gotchas/ practice

Failure Archaeology

The rule that matters most

Before investigating any failure, search the archaeology first. 60 seconds of search beats re-fighting a settled battle:

brain_search("<distinctive error string or symptom keyword>")
brain_search("<system name> <failure verb>")   # e.g. "codex auth", "qmd hang", "mcp timeout"
brain_list("knowledge/platform/gotchas")        # scan filenames — they are date-stamped symptom slugs

When to write an entry

Write to knowledge/platform/gotchas/<symptom-slug>-YYYY-MM-DD.md when ANY of:

An investigation took >20 minutes and ended in a root cause.
A fix was reverted or an approach abandoned — dead ends are the highest-value entries because they are invisible in the final system.
The same symptom appeared for the second time (recurrence = the first entry failed retrieval; improve its keywords too).
An external system behaved contrary to its docs (API quirks, auth flows, rate limits).

Entry format (the four fields that make it retrievable)

# <Symptom in plain words> — YYYY-MM-DD

**Symptom:** what was observed, with the LITERAL error strings (future agents grep these).
**Root cause:** the actual mechanism, 2-4 sentences. Not the fix — the WHY.
**Evidence:** commands run + output that proved it (paths, dates, numbers).
**Status:** settled | open | recurring (Nth time: link prior entries)

**Fix / decision:** what was done or deliberately NOT done.
**Wrong paths tried:** approaches that looked right and weren't — one line each, so nobody retries them.

Rules:

Literal error strings verbatim — retrieval works by substring; "token error" finds nothing, refresh_token_reused finds the entry.
Symptom in the filename, not the fix ("mcp-timeout-long-deliberations" not "async-job-pattern").
One incident per file. If a root cause explains several symptoms, one file owns the cause, others link it.
No secret values in evidence — variable names and file paths only.

Consolidation (quarterly, or when a domain accumulates 5+ entries)

Guardrails

❌	✅
Start debugging a familiar smell from scratch	brain_search the symptom first, always
Write the war story (chronology of your session)	Extract symptom/cause/evidence/status; the session narrative dies with the session
Record only what worked	Record reverted fixes and dead ends explicitly
Paraphrase error messages	Paste them verbatim — they are the search keys
Treat recurrence as bad luck	Recurrence = retrieval failure; strengthen the old entry's keywords + link entries
Bury root causes in daily memory/ files only	memory/ is a diary; gotchas/ is the archive. Cause goes to gotchas, memory links it

Verification

Entry is done when: brain_search("<its literal error string>") returns it, status field present, and no secret values inside. Chronicle is done when every linked entry resolves via brain_read.

Cross-references

Capture tools: brain_capture, brain_write (general knowledge — not failure-specific)
Debug delegation with gotcha-doc requirement built in: internal codex-handoff skill, template B (not included in this public package)
Audit that uses closed-loop evidence: brain-due-diligence
Exemplary existing entries: knowledge/platform/gotchas/openai-codex-refresh-token-reused-2026-05-14.md, knowledge/platform/gotchas/qmd-vps-raw-overindexing-and-embed-hang-2026-06-01.md

Provenance and maintenance

Gotchas dir + ~95 entries: verified 2026-07-05 via brain_list("knowledge/platform/gotchas"). Re-verify the same way.
No chronicles exist yet as of 2026-07-05 (first candidates: Codex/OAuth auth — 4+ entries; QMD — 6+ entries).

Cambios

Fecha	Cambio	Por
2026-07-05	Created — tomicz failure-archaeology pattern grafted onto existing the reference deployment gotchas practice; adds retrieval-first rule, entry format, chronicles.	Claude Code (Fable 5)