full-output-enforcement

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

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 f