full-output-enforcement

name	full-output-enforcement
description	ALWAYS use this when the request matches Full Output Enforcement: Use when a task requires exhaustive unabridged output, complete files, or strict prevention of placeholders and skipped code.

Full-Output Enforcement

Selective Reading Rule

Start with:

• references/senior-master-standard.md
• references/usage-routing.md
• references/quality-checklist.md

Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.

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, , , , , , , bare standing in for omitted code