Full-Output Enforcement: No Placeholders, No Stubs
A short rule set that bans TODO comments, skeleton code, and 'rest follows the same pattern' shortcuts so Claude always delivers complete, runnable output
Ask for 5 components and get 2 finished plus 3 stubs marked '// implement here.' This playbook bans the entire family of placeholder shortcuts and gives Claude a clean way to pause and resume on genuinely long jobs instead of quietly truncating.
Who it's for: developers on any coding task, not just frontend work, anyone tired of finding TODO comments in what was supposed to be finished code, teams running Claude on batch or multi-file jobs
Example
"Write all 5 CRUD endpoints for this API" → Claude counts the 5 deliverables up front, writes each one completely, and cross-checks the count before responding instead of writing 2 in full and summarizing the rest
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Full-Output Enforcement
Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
## 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
Get new playbooks like this one
One email a week with new Claude Code workflows. Free, like everything here.
No spam. Unsubscribe anytime.
What This Does
Bans the shortcuts models reach for when a response gets long: // TODO, // rest of code, // similar to above, "I can provide more details if needed." It applies to any task with a countable number of deliverables, files, functions, sections, or answers, not just frontend or design work.
The template locks a deliverable count at the start of a task, generates every item in full, and cross-checks the count before responding. When a response is genuinely going to hit the token limit, it defines a clean pause-and-resume format instead of letting Claude compress or skip content to fit.
Quick Start
Step 1: Create a Project Folder
mkdir -p ~/Documents/FullOutput
Step 2: Download the Template
Click Download above, then:
mv ~/Downloads/CLAUDE.md ~/Documents/FullOutput/
Step 3: Start Working
cd ~/Documents/FullOutput
claude
Works from any project folder. Drop the CLAUDE.md into an existing repo if you want the rule to apply project-wide instead of running it from a scratch folder.
The Process
- Scope — Read the full request, count the distinct deliverables, lock that number.
- Build — Generate every deliverable completely. No "you can extend this later."
- Cross-check — Re-read the original request before responding and compare the deliverable count against what was scoped.
Handling Long Outputs
When a response approaches the token limit, Claude writes at full quality up to a clean breakpoint (end of a function, file, or section) and ends with:
[PAUSED — X of Y complete. Send "continue" to resume from: next section name]
Sending "continue" picks up exactly where it stopped, no recap, no repetition.
Limitations
- A hard rule set, not a substitute for scoping a task sensibly. Asking for 50 files in one message still hits real limits; this just makes the stopping point explicit instead of silent.
- Doesn't improve code correctness, only completeness. Full output can still contain bugs.