Full Output Enforcement
Force your coding agent to ship whole files and full component sets instead of `// ...` stubs and “want me to continue?” truncation.
Overview
Full-Output Enforcement is a journey-wide agent skill that stops truncation and placeholder code—usable whenever a solo builder needs complete, paste-ready output before committing to a build or ship step.
Install
npx skills add https://github.com/leonxlnx/taste-skill --skill full-output-enforcementWhat is this skill?
- Hard-bans placeholder patterns in code (`// ...`, bare `...`, TODO stubs) and prose deferrals (“for brevity”, “let me kn
- Treats partial output as broken output with a scope-first execution process: count deliverables, then fulfill each compl
- Blocks structural shortcuts: skeletons when full implementation was requested, first/last-only sections, one-example-plu
- Explicit baseline: optimize for completeness on production-critical tasks, including clean handling when token limits fo
- Pairs with any SKILL.md workflow that must end in paste-ready artifacts, not narrated gaps
- Documents hard-fail banned patterns across code blocks, prose deferrals, and structural shortcuts in three categories
Adoption & trust: 91.4k installs on skills.sh; 37.9k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps returning abbreviated files, `// ...` gaps, and “I can continue if you want” instead of the full implementation you asked for.
Who is it for?
Solo builders generating multi-file features, full components, or long configs who keep hitting agent truncation and placeholder shortcuts.
Skip if: Tasks where the user explicitly wants a short summary, a high-level outline only, or exploratory brainstorming without full code.
When should I use this skill?
Any task requiring exhaustive, unabridged output—full files, counted deliverables, or production-critical completeness.
What do I get? / Deliverables
Deliverables match the requested count and depth with banned placeholder patterns eliminated, including explicit continuation strategy when token limits require a split rather than silent omission.
- Complete implementations with zero banned placeholder patterns
- Explicitly scoped multi-deliverable output matching the counted request
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Generate a complete multi-route prototype without skeleton pages that only describe missing screens.
Ship all five React components in one pass instead of one example plus “similarly for the rest.”
Deliver full route handlers and middleware with no `// implement here` stubs.
Output an entire test file covering every case named in the spec, not the first three tests and an ellipsis.
Patch production configs end-to-end when extending env templates across every service.
How it compares
Behavioral completion policy for agent replies—not a linter, formatter, or test runner.
Common Questions / FAQ
Who is full-output-enforcement for?
Solo and indie builders using agentic IDEs who need entire files, full component sets, and exhaustive implementations without placeholder comments or deferred continuations.
When should I use full-output-enforcement?
Use it during Build when drafting frontend or backend code, during Ship when generating full test suites or configs, during Validate when you need a complete prototype scaffold, and anytime across the journey a partial artifact would block the next step.
Is full-output-enforcement safe to install?
It is instructional procedural knowledge with no mandated shell, network, or secret access; review the Security Audits panel on this Prism page before enabling it in your agent workflow.
SKILL.md
READMESKILL.md - 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. ## 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