Full-Output Enforcement

When to Use

• Use when the user explicitly asks for full files, complete implementations, exhaustive lists, or unabridged deliverables.
• Use when placeholder code, skipped sections, TODO stubs, or descriptions in place of implementation would break the request.
• Use when a long answer may need clean continuation chunks without losing completeness or structural integrity.

Limitations

• This skill enforces completeness, but it does not override token limits, safety constraints, missing source context, or user-provided scope boundaries.
• Split long outputs into clearly labeled continuation chunks when necessary, and verify that each chunk connects cleanly to the previous one.
• Do not invent unavailable code, credentials, private APIs, or project files to satisfy a request for complete output.

Baseline

Match completeness to the requested deliverable and its actual stakes. 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. Respect the limitations above and report unavailable inputs honestly.

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).
• Continue through available tools, files and conversation continuation while authorization and context permit. Prefer a complete file artifact for outputs too large to display. Request a continuation only when the host actually requires user input; never introduce a checkpoint merely because a batch is large.

Quick Check

Before finalizing any response, verify:

• No placeholder patterns replace requested content; legitimate language syntax, quoted source and explicitly requested skeletons remain valid
• 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

Examples

Request: “Provide the complete Python file that converts Celsius to Fahrenheit, including input validation and two assertions.” Deliver the entire file, with no omitted validation or assertions:

def celsius_to_fahrenheit(value):
    if isinstance(value, bool) or not isinstance(value, (int, float)):
        raise TypeError("Temperature must be a number")
    return value * 9 / 5 + 32


assert celsius_to_fahrenheit(0) == 32
assert celsius_to_fahrenheit(100) == 212

If the request instead asks for a complete replacement of an unavailable project file, identify the missing input and obtain it before claiming a complete replacement; do not fabricate its existing interfaces.