메뉴
How to write a useful failure report. Not "it's wrong" — what's wrong, why it matters, what the spec says, what the code does, and a path forward.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Complete reference for the factory CLI — all commands, arguments, options, and usage. Use when an agent needs to invoke factory commands, check correct syntax, or understand available options.
When and how to write a human-action-needed entry to memory/{agent}/needs.md. Agents write these entries when they hit blockers that only a human can resolve.
When you encounter a failure, correction, or new pattern, write a learning and optionally propose a skill.
How the factory workspace is organized and what each directory means.
What to examine during a reflection pass and how to write observations to memory/{agent}/needs.md.
When and how to write scenario holdouts for factory verification.
| name | failure-reporting |
| description | How to write a useful failure report. Not "it's wrong" — what's wrong, why it matters, what the spec says, what the code does, and a path forward. |
A failure report exists to enable resolution — not to document that something failed. It must contain enough information for Builder (or a human) to understand and fix the gap without having to re-read the spec and re-examine the code from scratch.
Every failure report must include:
Summary — One paragraph: what was verified, what the overall finding is, and the score. Do not make this a list of failures — that belongs in the artifact assessment.
Artifact-by-Artifact Assessment — For each deliverable the spec describes:
Satisfaction Score — The numeric score with reasoning (see satisfaction-scoring skill).
Path to Resolution — Concrete steps Builder would need to take to bring the score above the passing threshold. Not vague guidance — specific changes.
Generalizable Learning — The class of failure, why it occurred, what future
specs or implementations should do differently. See verification-protocol skill.
Good:
parser.error() for empty name strings (Verification Criteria #3).
The implementation accepts empty strings silently and prints 'Hello, '. Fix: add
if not args.name: parser.error('name cannot be empty') after parsing."Poor:
The difference is specificity. A poor failure report sends Builder back to the spec. A good failure report tells Builder exactly what to change.