full-output-enforcement

# Full-Output Enforcement ## Baseline Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions. ## Single-voice craft (do NOT parallelize) This is an output-discipline directive applied to ONE generation pass. Keep it that way: - **No fan-out.** Never split the deliverable across parallel sub-agents and stitch the pieces — stitched output reintroduces the exact seams (duplicated imports, mismatched state, "// from the other half") this skill exists to ban. One author, one continuous pass, top to bottom. - **One coherent voice.** Naming, formatting, and abstraction level stay uniform across the whole deliverable. A reader must not be able to tell where one "section" ended and the next began. - **Sequential over the token limit, never sharded.** If output exceeds one response, continue it *serially* via the resumable breakpoint below — that is the only legal split. It is not parallelism. ### Completeness without fabrication Completeness is never an excuse to invent. When real content is unknown: - Do **not** hallucinate an API, a function body, a config value, or a file path to "fill the gap." A confident wrong implementation is worse than an honest gap. - If a fact/contract is genuinely missing, write the real code you *can* and mark the unknown explicitly as a typed `TODO(needs: <exact thing>)` — and surface it in the closing summary so the gap is visible, not buried. (This is the ONE sanctioned exception to the `// TODO` ban: a flagged, surfaced unknown, never a silent stub for laziness.) - Prefer asking for the missing input over guessing it — but inside a dispatched/autonomous run, pick the most reasonable concrete value, implement it fully, and flag the assumption. ## Output contract Every response governed by this skill MUST deliver: 1. **The complete deliverable(s)** — every requested file/function/section/answer, fully written, runnable, no placeholders. 2. **A scope ledger** at the end: `Delivered X of Y` matching the count locked in step 1 of Execution Process. If `X < Y`, name exactly what is outstanding and why (token limit → resume marker; missing input → typed TODO). 3. **Any flagged assumptions/TODOs** surfaced explicitly, not hidden mid-file. **Verify before sending:** re-run the Quick Check below AND confirm the scope ledger count equals the locked deliverable count. A response that fails either is not finished — do not send it. ## Banned Output Patterns The following patterns are hard failures. Never produce them: **In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code **In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise" **Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it. ## Execution Process 1. **Scope** — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number. 2. **Build** — Generate every deliverable completely. No partial drafts, no "you can extend this later." 3. **Cross-check** — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding. ## Handling Long Outputs When a response approaches the token limit: - Do not compress remaining sections to squeeze them in. - Do not skip ahead to a conclusion. - Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section). - End with: ``` [PAUSED — X of Y complete. Send "continue" to resume from: next section name] ``` On "continue", pick up exactly where you stopped. No recap, no repetition. ## Quick Check Before finalizing any response, verify: - No banned patterns from the list above appear anywhere in the output - Every item the user requested is present and finished - Code blocks contain actual runnable code, not descriptions of what code would do - Nothing was shortened to save space