AI Skill
Pass
Audit score 90

full-output-enforcement

leonxlnx/taste-skill

Enforce complete, unabridged LLM output—no truncation, no placeholders, no shortcuts.

What is full-output-enforcement?

This skill overrides default LLM truncation behavior to guarantee exhaustive output delivery. It bans placeholder patterns (like "...", "TODO", "and so on"), enforces production-quality completeness, and handles token-limit splits cleanly by pausing at logical breakpoints. Use it for any task where partial output is unacceptable.

  • Prevents LLM from using truncation shortcuts and placeholder patterns in code and prose
  • Enforces delivery of all requested deliverables (files, functions, sections) without omission
  • Handles token-limit splits by pausing at clean breakpoints and resuming on command
  • Validates output completeness before responding via scope-locking and cross-checking
  • Bans 20+ common evasion patterns including ellipsis, TODO comments, and "for brevity" language

How to install full-output-enforcement

npx skills add https://github.com/leonxlnx/taste-skill --skill full-output-enforcement
Claude Code
Cursor
Windsurf
Cline

How to use full-output-enforcement

  1. 1.Install the skill using the provided npm command
  2. 2.State your full request clearly, specifying the number and type of deliverables expected
  3. 3.Let the skill scope the request and lock the deliverable count
  4. 4.Receive complete output with no truncation or placeholder patterns
  5. 5.If output pauses mid-response, send "continue" to resume from the exact breakpoint without recap

Use cases

Good for
  • Generating complete multi-file projects or large codebases where partial output breaks functionality
  • Writing exhaustive documentation or API references that cannot skip sections
  • Implementing repeated logic patterns across many components without collapsing to one example
  • Producing full test suites or configuration files where every item must be present
  • Handling responses that exceed token limits by pausing and resuming at logical section boundaries
Who it's for
  • Developers building production systems requiring complete, runnable code
  • Technical writers creating comprehensive documentation without gaps
  • Engineers working with agents on large-scale code generation tasks
  • Teams needing guaranteed exhaustive output from LLM-based tools

full-output-enforcement FAQ

What happens if my request is too large for one response?

The skill pauses at a clean breakpoint (end of function, file, or section) and outputs a resume marker showing progress (e.g., "[PAUSED — 3 of 5 complete]"). Send "continue" to pick up exactly where it stopped.

Does this skill guarantee no placeholders will appear?

Yes. The skill explicitly bans 20+ placeholder patterns including "...", "TODO", "// rest of code", "and so on", and prose evasions like "for brevity". Any violation is treated as a hard failure.

Can I use this for small, focused tasks?

Yes. The skill applies to any task—it simply ensures that whatever you request is delivered completely. For small tasks, it prevents unnecessary brevity; for large ones, it prevents truncation.

What if I only need part of a deliverable?

Be explicit in your request. The skill locks the scope based on what you ask for. If you ask for "the first 3 functions", it delivers exactly those 3, complete.

How does this differ from just asking for complete output?

This skill enforces completeness systematically: it bans specific evasion patterns, validates scope before building, cross-checks against the original request, and handles token limits gracefully without quality loss.

Full instructions (SKILL.md)

Source of truth, from leonxlnx/taste-skill.


name: full-output-enforcement description: 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.

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