القائمة
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.