# Task Brief Creator > Generate an executable implementation work-plan Markdown at `docs/briefs/` from planning notes or a rough task description. Work brief, task brief, handoff brief, implementation ticket, and task spec remain trigger aliases. Nine required sections are keyed to Conventional Commits types so coding agents switch behavior (refactor → preserve, fix → reproduce first, perf → measure first). Briefset mode emits a parent execution-management document plus N child briefs when the input describes multiple execution contexts. Explicit task intent only — use when the user invokes this skill or asks for a work plan, implementation plan, work brief, task brief, handoff brief, implementation ticket, or task spec for a coding agent. Not for prose summaries, status reports, design docs, or meeting notes. For the plain-language caveman variant, use task-brief-creator-caveman instead. - Skill: `buyoung/task-brief-creator` (Agent Skill, multi-file: 17 files) - Install (CLI): `npx skillmds@latest add buyoung/task-brief-creator` - Raw SKILL.md: https://api.skillmd.com/api/skills/buyoung/task-brief-creator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: buyoung (https://skillmd.com/u/buyoung) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/buyoung/task-brief-creator --- # Task Brief Creator Produce an executable implementation work plan under `docs/briefs/` that one coding agent authors and another coding agent can execute without reconstructing the route or re-interviewing the requester. The historical work-brief and handoff names remain activation aliases; the saved artifact's primary identity is a code-execution PLAN. The plan is the *execution artifact*. Its job is to let a coding agent recover the first stage, intended order, stage deliverables and handoffs, replan boundaries, and whole-work completion criteria — while routing it to the right files and fixing the behavior envelope. **The plan is an executable work instruction — nothing else.** It is not a scope-control memo, discussion summary, background briefing, or rationale document. Every section must answer *"what does the coding agent do next?"* — if a section reads like meeting minutes, negotiation history, or context prose, rewrite it until it routes to files, decisions, or verifiable outcomes. A plan that makes the coding agent reconstruct its execution sequence or re-interview the requester is a **failed plan**, regardless of how polished it reads. **"Executable, not discursive" is a *prose style* rule, not a *content reduction* rule.** It tells you how each bullet should read — direct, action-routing, no rationale prose. It does not tell you to *drop* distinct concerns, *merge* unrelated bullets, or *summarize* the input down to its highlights. A brief that omits a concern from the input is also a failed brief, because the downstream agent will silently miss it. Tight prose, full enumeration: short bullets are fine and encouraged, but every distinct concern from the input and the codebase review must land somewhere in the brief. --- ## Modes This skill operates in one of two **output modes**: - **Single-plan mode** (default; historical single-brief name remains) — emits one executable work plan per invocation. The workflow below covers this case end to end. - **Briefset mode** — emits a parent execution-management document plus N independently executable child briefs. Used when the input describes **multiple execution contexts** that need coordination (independent completion criteria, mixed work types, ordered dependencies, parallelizable waves, or shared conflict hotspots). Selected by the criteria in `references/briefset.md`; long input, many files, or many related edit points alone never trigger briefset mode. Output-mode selection happens at Stage 1 alongside the ambiguity gate and is author-owned when the input and codebase make it evident. In briefset mode, follow the workflow below with the per-stage adaptations in `references/briefset.md` (parent template, naming, decomposition decision table, dual-validator save). **Stage 4 always runs an ownership pass.** When user-owned decisions remain after codebase review, present only those decisions in a Markdown table with `순번`, `내용`, `수정 추천안`, and `근거`. Codebase-resolvable facts, output mode, evident work type, and reversible implementation choices are decided by the author or worker; product intent, scope, compatibility breaks, external ownership, and acceptance thresholds remain user-owned. The decision table is the output of the ownership pass when it has rows, not a separate mode. See `references/stage-4-interview.md` for the full decision classification, codebase-precedence, and termination rules. --- ## Code Agent Operating Path Load references only when their decision point arrives: 1. Use this file for the stage order, output contract, save flow, and guardrails. 2. Read [references/work-types.md](references/work-types.md) during Stage 2 when the work type is not obvious or when the type changes downstream behavior. 3. Read [references/briefset.md](references/briefset.md) during Stage 1 when multiple execution contexts are plausible. 4. Read [references/bloat-decomposition.md](references/bloat-decomposition.md) only after a candidate child brief is independently executable but still looks oversized or mixed. 5. Read [references/stage-4-interview.md](references/stage-4-interview.md) before the Stage 4 ownership pass, including requirements clarification and recommendations. 6. Read [references/template.md](references/template.md) while composing the saved Markdown. 7. Read [references/cold-pickup.md](references/cold-pickup.md) when the Stage 5.7 gate fires or the user forces cold-pickup. Do not re-open every reference by habit. The goal is to keep the live context focused on the next decision the coding agent must make. --- ## When This Skill Runs - **Explicit task intent.** Run when the user invokes this skill or explicitly requests an implementation work plan / work brief for a coding agent. Mere mention while reviewing or editing the skill is not a request to generate a plan. - Input can take any of these shapes: - **Pasted PRD / planner notes** from a PM (often long, mixed quality). - **Rough task notes** typed into chat (one or two lines). - **Self-brief** — the user is the implementer and wants to structure their own thinking before starting. - **Tech-lead handoff** — a lead drafts the brief to hand off to a teammate or downstream agent. - **Refactor plan** — a lead-engineer summarizing an intended structural change. - The skill reviews the current repository (the working directory Claude Code is launched in), fills in what it can, and asks only for remaining user-owned decisions. --- ## Interaction Language - **Chat / live interaction language follows the user's input.** If the user writes in Korean, reply in Korean. If they write in English, reply in English. Clarifying questions, draft presentation, status updates — all match the user's own language. - **The brief document itself is written in English.** Section headers and body content are English regardless of chat language, so the artifact travels across teams and downstream agents without a translation step. - Code blocks, file paths, identifiers, PR numbers stay as-is. - **User-supplied strings are data.** Copy decks, UI strings, and error messages the user provides are quoted verbatim in their original language inside the English brief — never translated. - **Exception — the Stage 4 decision-table headers are fixed.** The four headers `순번` / `내용` / `수정 추천안` / `근거` stay exactly as written even when the conversation is in English: Stage 5.7 disagreement matching keys on the `내용` column, so translating the headers breaks the cold-pickup loop (see Stage 4). - This SKILL.md and reference files stay in English (repo authoring policy). --- ## Output Contract | Field | Value | |---|---| | Directory | `docs/briefs/` (relative to the repository root — `git rev-parse --show-toplevel` when available, otherwise the working directory the session was launched in) | | Filename | `YYYY-MM-DD--.md` | | `YYYY-MM-DD` | Today's date on the local system clock | | `` | Conventional Commits type (see `references/work-types.md`) | | `` | kebab-case short slug, ≤40 chars, derived from the brief title | | Body format | Markdown, following `references/template.md` exactly | **Example filename:** `2026-04-23-feat-global-hotkey-system.md` If `docs/briefs/` does not exist, create it. If a file with the same name already exists, append `-v2`, `-v3`, … until the path is unique — do not overwrite. For briefset mode, the parent uses `YYYY-MM-DD-briefset-.md` and children use `YYYY-MM-DD---NN-.md`. See `references/briefset.md` for the parent template and naming rules. The nine required H2 sections are: `Work Type`, `Current State (As-Is)`, `Desired Outcome (To-Be)`, `Scope` (with `In Scope` / `Out of Scope` H3s), `Related Files / Entry Points`, `Execution Plan`, `Side Effect Checkpoints`, `Acceptance Criteria`, `Open Questions`. Optional `Constraints` may appear between `Scope` and `Related Files / Entry Points` when task-specific constraints exist. `Execution Plan` appears immediately after `Related Files / Entry Points` and before `Side Effect Checkpoints`. Put stage-local completion under each stage's `Ends when`. Reserve `Acceptance Criteria` for whole-work completion after all required stages and side-effect checkpoints finish. Three work types require an **additional H2 section** between `Current State (As-Is)` and `Desired Outcome (To-Be)`: - `fix` → `## Reproduction` - `perf` → `## Baseline Measurement` - `refactor` → `## Behavior Contract` These exist because the work type changes the downstream agent's behavior (reproduction-first, measurement-first, behavior-preservation), and the brief must carry the type-specific input that behavior depends on. The escape hatch when the section legitimately has nothing concrete to capture is a single bullet `- N/A — `. See `references/template.md` and `references/work-types.md` for the per-section guidance. Bullet count is not capped. The rule is cohesion plus completeness, not brevity: - Each bullet should describe one coherent unit of context, scope, risk, or verification. - **Enumerate every distinct concern.** If the input or the Stage 3 codebase review surfaces N distinct concerns that map to a section, the section gets ≥ N bullets. Sections expand to fit the work; they are not capped. A section reduced to one bullet when the input contained multiple concerns for it is the failure mode this rule exists to prevent. - Do not merge unrelated concerns into one bullet just to keep the document short. - Write as many bullets as the task needs; do not compress larger work into vague combined bullets. Short prose per bullet is fine and encouraged — short *count* is the failure. Completeness does not mean "put every discovered issue in scope." When review surfaces many valid concerns, separate them before saving: - **Must fix in this brief** — issues that directly block the user's stated goal or would make the downstream task unsafe / wrong if left unresolved. - **Check while here** — nearby contract or documentation consistency checks that are cheap and directly connected to the must-fix work. - **Defer / record** — valid follow-up issues that do not have to change for this brief to succeed. `In Scope` should usually hold the must-fix set plus tightly coupled checks, not the whole discovery list. Record deferred items in `Out of Scope` as `[deferred]`; use `Open Questions` only for non-blocking user-owned decisions with a safe default and reconfirm milestone. If more than five independent must-fix concerns remain after this triage, reconsider briefset mode or ask the user to choose the first slice only when slicing is a user-owned scope decision. --- ## Workflow ### Stage 1 — Ambiguity Gate (HALT or CONTINUE) Before full codebase review, check whether the input contains enough signal to ground the brief. Use the **four-anchor heuristic**: | Anchor | What it answers | Maps to | |---|---|---| | **PROBLEM** | What is wrong or what is changing? | § Current State (As-Is) | | **GOAL** | What should be true when it's done? | § Desired Outcome (To-Be) | | **SCOPE** | Where does this apply (module, feature area, user surface)? | § In/Out of Scope | | **TARGET** | Which part of the system is touched (file, subsystem, layer)? | § Related Files / Entry Points | Count how many anchors are derivable from the input. Derivable = a reasonable engineer could answer the anchor from the user's input without inventing intent. - **All 4 anchors present** → **CONTINUE** to Stage 2. - **3 anchors present, TARGET missing** → run a narrow target probe before deciding. Use at most a few `rg` / glob queries to find likely files, directories, routes, commands, or modules. If a concrete entry point emerges, **CONTINUE**. If not, **HALT** and ask the user for the target area. - **3 anchors present, PROBLEM or GOAL or SCOPE missing** → **CONTINUE** only when the missing anchor can be stated in one concrete sentence derived from the input (write that sentence into the brief; vague fillers like "make it better / cleaner" do not count). Otherwise **HALT** and ask for that anchor. Detail that survives this check gets filled in Stage 3 via codebase review or Stage 4 via user questions. - **2 or fewer anchors present** → **HALT**. Respond in the user's chat language naming exactly which anchors are missing, and ask for more input. Do NOT proceed through Stages 2–6 on an underspecified input. The briefset-mode check below also waits — never split an underspecified input into multiple equally underspecified child briefs. Example halt messages: **English:** > I can't ground the brief from this input alone. > Missing — **PROBLEM** (what is being fixed or changed) and **TARGET** (which area / file / subsystem is touched). > Can you paste the spec or add one or two lines? **Korean:** > 입력만으로는 브리핑 만들기 어려워. > 다음이 아직 확인 안 돼 — **PROBLEM**(뭘 고치거나 바꾸는지)과 **TARGET**(어느 영역/파일/시스템을 건드리는지). > 더 얹어줄래? > 기획서 붙여넣거나 한두 줄 더 써주면 돼. **Why halt instead of guess:** an underspecified brief is worse than no brief — the downstream agent commits to the wrong problem framing and the rework cost eats the whole savings. Pushing back early is cheaper than producing a confident-looking but wrong document. **Edge case — pasted spec that looks long but is content-light:** word count is not a proxy for the four anchors. A 2,000-word product narrative without a concrete PROBLEM or TARGET still halts. Judge by anchor coverage, not length. See `examples/03-halt-ambiguous.md` for a worked halt case. **Briefset signal check (after CONTINUE):** once anchors clear, also evaluate whether the input describes multiple execution contexts. Do not use file count, line count, input length, or several related edit points as triggers by themselves. Those are supporting evidence only. If briefset signals are strong, select briefset mode and state the evidence before Stage 2. If the candidate contexts are fully independent — no ordering, dependencies, or shared conflict hotspots — select separate single-plan invocations instead: a parent whose coordination sections are all `- None — ` adds overhead without value. If the evidence is unclear, default to single-plan mode. Ask only when output topology depends on a user-owned delivery boundary, release unit, or scope choice; do not ask the user to choose a document shape when code and input already settle it. Several stages inside one cohesive execution context do not justify briefset mode; consult `references/bloat-decomposition.md` before splitting an oversized candidate. ### Stage 2 — Work Type Selection Determine the Conventional Commits type. Consult `references/work-types.md` for the full list and per-type behavior hints. - If the input explicitly names a type (e.g., "this is a refactor"), use it when the input evidence agrees. - If the named type conflicts with the described outcome, classify by the outcome and record the mismatch; ask only if resolving it requires a user-owned behavior or scope decision. - If the type is implicit but high-confidence, assign it without a confirmation round-trip. - If the implicit type is low-confidence but technically resolvable, probe the codebase or put the distinction into the first `Execution Plan` stage as an investigation with a `Replan when` boundary. - Ask in Stage 4 only when the work type depends on an underlying product or scope choice the user owns; derive the type from that answer. See `references/work-types.md` for the full author-selection routing table. ### Stage 3 — Codebase Review The goal is enough context to fill `Current State (As-Is)` and `Related Files / Entry Points`, not exhaustive exploration. Use whatever code search / read / symbol tooling fits the host environment and repository guidance — default `Grep` / `Read` / `Glob`, allowed semantic tools, language servers, or a short-lived subagent (e.g. `Explore`) when parallel lookups or main-context isolation is worth it. Tool choice is the runtime's call; this stage only fixes the *purpose* and *budget* of the review. Review budget (soft limits): - At most ~15 file reads - At most ~10 search queries - Stop when you can confidently enumerate the **primary** entry points and major affected areas implied by the input — not just the first file or symbol that grounds the brief. If likely input-implied surfaces remain unverified within the review budget, add a bounded investigation stage with a named deliverable and `Replan when` condition. Strategy: 1. Start wide with keyword search on terms from the input — feature names, function names, error strings, routes, type names. 2. Narrow to a list of candidate files, then read the 2–4 most promising ones. 3. If the input mentions a subsystem (e.g., "auth middleware", "checkout flow"), look at likely directories first. 4. Capture an As-Is picture by coherent context units: how each relevant function, module, behavior, integration, or user surface is shaped today. 5. Capture concrete Related File / entry-point hints with one-line purposes. At least one entry point must be solid before saving the brief. Active judgement: - Let the user's goal drive any extra probing. If the first code reads surface a nearby signal that could change the work direction — a dependency, style hook, comment, product doc, older brief, or unused surface that clearly belongs to the same feature — check just enough to decide how it affects the brief. Do not turn this into a mandatory repo-wide audit. - Prefer a reasoned recommendation over asking the user. If a nearby signal is relevant but not required for the requested slice, encode the judgment in `Constraints`, `Out of Scope` as `[deferred]`, `Side Effect Checkpoints`, or `Acceptance Criteria`. Ask only when the choice changes product behavior, scope, ownership, or acceptance in a way the requester must own. - Separate implementation completion from user / operator success when both exist. Code may already expose a pass condition, event, return value, validator status, or stored state that says "done"; the user-facing or operator-facing success may be different. Capture both when they matter: put the existing pass condition in `Current State (As-Is)` / `Side Effect Checkpoints`, and put the intended observable outcome in `Desired Outcome (To-Be)` / `Acceptance Criteria`. - If a nearby signal is weak, mention it in the Stage 6 save report instead of bloating the brief. The brief stays executable; the report can carry useful "noticed while reviewing" context. Evidence discipline: - Mark load-bearing findings as **confirmed** when the codebase review directly verified them. A confirmed finding cites the file and a stable locator: section heading, function / class name, validator message, command output, or nearby quoted token. Line numbers are useful as secondary hints, but do not rely on line numbers alone because they drift after edits. - Mark risk statements as **inferred** when they describe likely downstream behavior rather than a fact already present in a file. Name what would confirm the inference, such as a validator fixture, an execution-reconstruction check, or a specific command. - Do not write an inferred risk as if it were a confirmed defect. The saved brief may stay concise, but the wording must let the downstream agent tell evidence from judgment. - Prefix every load-bearing `Current State (As-Is)` bullet with `[confirmed]` or `[inferred]`. The validator checks the label shape only; Stage 5.6 and human review own the truthfulness of the classification. Contract discipline: - Name the existing contracts that must keep speaking the old shape while the change lands. Contracts can be public APIs, persisted ids, database rows, event names, config keys, file formats, CLI flags, i18n keys, analytics events, generated schemas, or cross-process payloads. - Put contract-preservation facts in `Constraints` or `Side Effect Checkpoints`, not as vague `Out of Scope` filler. Good: `- [ ] Existing saved sessions with status "pending" still deserialize.` Bad: `- [ ] Do not break compatibility.` - If the requested outcome requires changing a contract, surface the compatibility choice in Stage 4 unless the user already explicitly approved the break. **Source-of-truth inputs.** When the user provides a checklist, TODO file, review rubric, audit notes, or any document as the source of truth, do not turn it into a representative summary. - Treat each listed item as a required concern until it is mapped, explicitly deferred / out of scope, or represented as a non-blocking user-owned Open Question with a safe default. - Preserve the source's own dimensions, such as named variants, files, examples, sections, or checklist groups. Do not collapse them unless the user asks for a summary rather than an executable brief. - Use searches only for literal terms that come from the user's source document or the target files being reviewed. Do not invent generic banned-pattern searches unless the user, repository rules, or source document defines those patterns. - The saved brief does not need to expose an internal ledger, but Stage 5.6 must be able to trace each source item to a concrete bullet or checklist item. If the source document is long, keep a private coverage ledger during review. The ledger does not need to be saved, but every source item must end as one of: in scope, out of scope / deferred, execution stage, acceptance criterion, side-effect checkpoint, related file, constraint, or structured non-blocking open question. **Do not:** - Read entire large files when symbolic / targeted-range reads suffice. - Chase tangential code just to pad the brief. If it does not tighten `Current State (As-Is)` or `Related Files / Entry Points`, skip it. - Make architectural claims the code does not support. If uncertain, label it `[inferred]` and route confirmation into an investigation stage or `Replan when` boundary. **Already-satisfied gate.** Before Stage 4, compare the full requested outcome and acceptance boundary against current code plus current verification signals. - If all requested outcomes are confirmed, all acceptance checks already hold, and no edit, integration, migration, or evidence-producing work remains, create no plan. Report `no-work-needed` in the user's language with the inspected paths, verification action, and observed signal, then stop. - If the user explicitly asked for a saved verification record despite the already-satisfied state, create a verification-only plan that expects no edits and records the no-change evidence route. Its first stage must also say what happens if the proof fails: stop dependent work, return to the owning plan, activate bounded correction plus re-verification work, then re-run the briefset topology and handoffs before continuing. - If only part of the outcome is already satisfied, keep the remaining work and make the no-change branch explicit instead of directing an unconditional edit. - In briefset mode, re-run topology after this gate: zero active children means `no-work-needed`, one means single-plan mode, and two or more retain briefset mode. Follow `references/briefset.md` for the child and handoff rules. This outcome is called `no-work-needed`; do not confuse it with Stage 5.7's `No-op pass`, which describes a review-loop termination. ### Stage 4 — User Decision Table After Stage 3 has gathered enough codebase context, run an ownership pass and collect only remaining user-owned decisions into a Markdown decision table. Stage 4 is not a pre-review guessing interview: ask only after the codebase has been checked enough to state the uncertainty, the recommended change, and the evidence behind it. Use this exact table shape for user-decision questions: ```markdown | 순번 | 내용 | 수정 추천안 | 근거 | |---|---|---|---| | 1 | | | | ``` Keep these four headers exactly as written, even when the surrounding conversation is not Korean. They are the stable decision-table contract: number, decision content, recommended change, and rationale. **Intent before enumeration.** Preserve each requirement's meaning, not an unresolved interpretation of its words. If input and bounded review leave multiple plausible goals, behaviors, scope boundaries, or completion criteria, ask the user before treating one interpretation as the task. Use the existing decision table to show the ambiguity, concrete alternatives, recommended interpretation, and supporting evidence. Distinguish a missing condition needed for the stated goal from an optional enhancement; label recommendations as proposals, not existing requirements. Offer only task-relevant additions. An unanswered optional enhancement stays excluded; do not enlarge the plan to make it look more complete. Ask first and allow an opportunity to answer. If no answer arrives and a safe fallback exists, save it with its reconfirmation milestone in `Open Questions`; never label it approved. If no safe fallback exists, halt without saving. A task cancellation stops authoring; it is not permission to use fallbacks and continue. User-owned gaps to close before drafting: - **Desired Outcome (To-Be)** — confirm when absent, ambiguous, or when the codebase review suggests more than one plausible interpretation. - **Out of Scope** — the most valuable guardrail for the downstream agent. Put unclear or high-risk scope boundaries in the decision table with a recommended exclusion/inclusion. - **Acceptance Criteria** — what makes the task verifiably done. If the code has a separate internal completion condition and the user has a separate success condition, carry both instead of collapsing them into one vague criterion. - **Compatibility and ownership** — ask before breaking a contract or crossing an externally owned boundary. - **Open Questions** — keep only non-blocking user-owned decisions with a safe fallback and reconfirm milestone. The author determines output mode, work type, entry points, side-effect checks, and technical sequencing when the input and codebase make them evident. Technical unknowns become investigation stages, bounded `Worker decision` fields, `Replan when` conditions, constraints, or author-selected defaults. Ask the user for relevant observations or access details only when they hold information unavailable from the reviewed artifacts; do not ask them to perform the technical investigation. **Decision-table rule.** Each row must request a real decision or a specific unavailable user-held observation, not a vague status note. `내용` states what the user must decide. `수정 추천안` states the concrete brief change you recommend. `근거` cites the input, codebase finding, existing pattern, or risk. After the user answers, patch the draft plan in memory before composing the brief. An unanswered or skipped question is not approval: non-blocking rows use their declared safe fallback, remain in structured `Open Questions` form, and proceed; any blocking row halts without writing. Full decision classification, table rules, and termination rules live in `references/stage-4-interview.md`. Before writing `Open Questions`: - Make one active judgement pass. Ask: would a downstream coding agent still need to ask the requester what to do, or can the brief make a reasonable call? - Do not use `Open Questions` to avoid making an implementation recommendation. If the answer is a reasonable bounded choice, put it into `Worker decision`, `Constraints`, or the relevant execution stage. - Keep `Open Questions` for user-owned decisions only. Product direction, scope expansion, compatibility breaks, acceptance thresholds, and external ownership can require a question. - Save a question only when it is non-blocking and use exactly `- [non-blocking] — Default: ; Reconfirm before: `. - If the user has not answered a blocking decision and no safe fallback exists, **HALT** and create no file. - `Open Questions: None` is acceptable only after this pass. It means "a downstream agent can proceed without re-interviewing the requester," not "nothing interesting was found." ### Stage 5 — Save + Validate Once Stage 4 closes, compose the final Markdown internally and **write it straight to disk** — do not paste the full brief into chat first. The user reviews the file in their editor in Stage 6, where real markdown rendering and diff tooling are available. 1. Compute the filename per the **Output Contract** above. 2. Ensure `docs/briefs/` exists; create it if not. 3. Resolve filename collisions by appending `-v2`, `-v3`, …. 4. Render the complete template from `references/template.md` and write the file (English section headers, English body). 5. **Run the structural validator** — a fast smoke test for the template contract: ```bash python3 /scripts/validate_brief.py docs/briefs/.md ``` If the brief is stored in an isolated artifact tree while its entry-point paths belong to another checkout, add `--repo-root ` before the brief path. `` is the installed skill package directory — the directory containing this SKILL.md (resolve it from wherever this skill was loaded, e.g. `~/.claude/skills/task-brief-creator` or a plugin cache). Never assume the user's repository contains the script: the brief lives in the user's repo, the validator lives with the skill. - Exit **0** → continue to Stage 5.5; the validator result is reported in the Stage 6 banner. - Exit **1** (structural failure) → fix the file and rerun the validator without asking the user. If the same structural cause still fails after two repair attempts, leave the file in place and carry the residual failure into Stage 6. - Exit **2** (file I/O error) → inspect the actual error: invalid arguments, invalid `--repo-root`, missing artifact, or unreadable file. Correct the cause; do not infer that a saved file disappeared or recreate it unnecessarily. The validator only checks **structural** conformity (section presence, checklist format, filename pattern, type coherence). It does *not* judge content quality — that's what the Stage 5.5 execution-reconstruction check, Stage 5.6 self-check, Stage 5.7 cold-pickup, and the human review in Stage 6 are for. Passing validator ≠ good brief; failing validator = malformed brief. ### Shared Validation Budget and Artifact State A validation run covers the single plan or the entire parent-and-children set. It has at most **five rounds**, including the initial round. A round starts from one saved artifact state, runs structural validation, Stage 5.5, Stage 5.6, and gated Stage 5.7 in that order. Keep the existing two-repair limit for the same structural cause; structural repairs before Stage 5.5 remain inside that round. Any content edit after Stage 5.5 starts the next round from structural validation; do not restart a stage-local unlimited loop or reset the counter for a child. Collect briefset reports against the same artifact state before applying related patches together. Unchanged children need not be rewritten, but each round still covers every required document. At each round start, snapshot all authored files to a unique scratch directory outside the repository and record the round, file membership, content hashes, findings, decisions, and checks actually completed. Do not apply a content patch unless a round remains to validate it. At round five, retain the latest well-formed artifact or restore a previously checked snapshot when a demonstrated regression requires it; stop automatic repairs and report remaining gaps. Restoration is set-wide: restore parent and affected children from the same recorded state, remove only files created by this run that are absent from that snapshot, and rerun structural validation. Reuse an earlier semantic result only for exactly the restored content hashes and unchanged input/decisions; otherwise report it unverified. Restoration does not open a sixth repair round. A new user answer or requested edit starts a new validation run. An internal retry, unavailable agent, or renamed file does not reset the budget. Delete scratch snapshots after the final state and residuals have been reported. The Stage 5.7 reference uses this shared bookkeeping and adds no per-child retry budget. ### Stage 5.5 — Downstream Execution-Reconstruction Check After the structural validator passes, run a blind downstream execution-reconstruction check before any cold-pickup verification. This is not a review prompt and not a rubric-driven validation prompt. Its purpose is to observe how a fresh coding agent naturally reconstructs the saved plan as work to start. The explanation must recover the first stage, intended order, each stage's deliverable and addressable handoff, verification input and expected signal when present, any no-change branch, replan boundaries, and the whole-work completion basis after side-effect checks. This checks direction and executability, not full input coverage; Stage 5.6 remains the coverage and missing-content check. Use a new sub-agent with no inherited conversation, prior findings, or reused reviewer context, and enforce a read-only task boundary. Send only a natural work-start request in the user's ordinary style, containing the saved brief path. The agent explains intended work; it must not execute the plan, edit files, or run its implementation commands. If independent context or read-only operation cannot be provided, or the agent fails without a usable result, record Stage 5.5 as unavailable with the reason. Do not claim an aligned reconstruction or substitute an informed self-review. For briefset mode, include only the briefset parent path. Do not include the original user request, Stage 3 findings, Stage 4 decisions, suspected gaps, validation criteria, expected answer format, or any hint about what might be wrong. Do not ask the sub-agent to "verify", "review", "audit", "compare", or "find missing items". Example shape only — do not hard-code this sentence: ```text 작업 진행할꺼야. 우선 이 브리프 파일을 확인하고 어떻게 작업할껀지 의도 설명해줘. ``` Compare the sub-agent's natural reconstruction against the user's original request, the saved `Execution Plan`, and any user-locked Stage 4 decisions. Treat only material drift as a failure: - The work purpose is different. - The understood scope is materially wider or narrower. - The first work direction points away from the intended entry points or workflow. - The first stage, intended order, stage deliverable, handoff, or replan boundary cannot be recovered. - Stage-local `Ends when` checks are confused with whole-work `Acceptance Criteria`. - A user constraint, exclusion, or acceptance threshold is missing from the reconstruction. - The sub-agent assumes work that the brief did not intend. If material drift appears, patch only within the shared round budget, restart from structural validation (`validate_brief.py` for a single brief, `validate_briefset.py` for a parent), and run a fresh reconstruction check with the same information boundary. Do not fix drift by changing the sub-agent prompt. Fix the brief. This check is mandatory whenever the host can spawn a sub-agent. Do not downgrade it to a self-check because the brief looks obvious or because Stage 5.6 is clean. The failure being tested is not "did I cover the input?" but "does a fresh agent naturally read the brief the way I intended?" If the host cannot spawn a sub-agent, report the execution-reconstruction check as unavailable in Stage 6. Do not block the workflow waiting for sub-agent support; continue to Stage 5.6 and mark Stage 5.5 as unavailable in the save report. Do not replace it with a self-check; the point is the downstream agent's natural read. ### Stage 5.6 — Content-Level Self-Check The structural validator confirms the file has the required sections. It does not confirm the file is a *complete* work instruction. Before handing off in Stage 6, re-read the saved brief from disk and run a content-coverage self-check against the original input plus Stage 3 / Stage 4 findings. This checks whether input and codebase concerns survived into the brief; do not treat a clean Stage 5.5 reconstruction as proof that nothing is missing. The brief is a work instruction, not a summary. Any concern that existed in the input must survive into the brief — possibly reshaped into the right section, never silently dropped. Run this checklist: - [ ] **Input coverage:** every distinct concern named in the input, including referenced spec section headings that change the coding route, maps to at least one bullet or stage somewhere in the brief (In Scope, Out of Scope, Related Files, Execution Plan, Constraints, Side Effect Checkpoints, Acceptance Criteria, or structured non-blocking Open Questions, depending on the concern's shape). If a spec section is intentionally not implemented now, it appears in `Out of Scope` as `[hard]` or `[deferred]`, or in `Open Questions` only when a non-blocking user decision has a safe default. Two unrelated implementation or verification obligations are never merged into one bullet. - [ ] **Source-of-truth coverage:** if the user supplied a checklist, TODO file, review rubric, audit notes, or other source-of-truth document, every listed item is represented in the saved brief, explicitly deferred / out of scope, or saved as a structured non-blocking user question. Representative theme coverage is not enough. - [ ] **Scope triage:** every discovered concern is either must-fix in this brief, a tightly coupled check, explicitly deferred / out of scope, or left for a user decision. The brief does not turn a broad review into an unbounded implementation task. - [ ] **Stage 3 coverage:** every primary entry point or major affected area surfaced during the codebase review appears in `Related Files / Entry Points`, and every technical uncertainty is resolved or routed into an investigation stage, `Worker decision`, or `Replan when` boundary. - [ ] **Contract preservation:** existing contracts discovered in Stage 3 that must not change are named in `Constraints`, `Side Effect Checkpoints`, or `Acceptance Criteria`; compatibility-sensitive changes are not hidden behind generic wording. - [ ] **Success split:** when internal completion and user / operator success are different, both are represented; the brief does not treat an event firing, validator passing, or state transition as proof that the user's goal was achieved unless that is actually the goal. - [ ] **Section depth:** no section was reduced to a single bullet when the input or Stage 3 findings contain multiple distinct concerns for it. Sections expand to fit the work; they are not capped. - [ ] **No content compression:** no bullet was shortened by dropping qualifiers, quantities, units, thresholds, versions, environment conditions, or ordering words (`only on cold start`, `≤ 5KB gzipped`, `iOS Safari 17+`, `after move end`). "Executable, not discursive" is a *prose* rule, not a *content* rule. - [ ] **Evidence clarity:** every load-bearing current-state bullet uses `[confirmed]` or `[inferred]`; confirmed facts cite stable evidence, inferred risks name what will confirm them, and line numbers are not the only locator. - [ ] **Execution continuity:** Stage 1 has a concrete precondition; stage numbers are consecutive; every stage has a bounded outcome, deliverable, local completion checks, explicit handoff, and replan boundary; each handoff gives the next stage what its `Starts when` requires. - [ ] **Already-satisfied discipline:** the plan does not force an edit when current evidence already satisfies the requested outcome; full satisfaction exited as `no-work-needed` unless the user explicitly requeste …(truncated)