Enforce Complete Code and Deliverable Generation

This skill enforces complete, unabridged output. Its baseline is that every task is production-critical and 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, and if the user asks for five components, deliver five components, with no exceptions. The skill is credited in its metadata to the taste-skill repository by Leonxlnx and lists claude, cursor, codex, and antigravity as tools.

It bans specific output patterns as hard failures:

• In code blocks: comment stubs such as "rest of code", "implement here", "TODO", "similar to above", "continue pattern", and "add more as needed", ellipsis comments, and a bare ellipsis standing in for omitted code.
• In prose: offers such as "Let me know if you want me to continue" and "I can provide more details if needed", and phrases such as "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" when it replaces actual content, and "I'll leave that as an exercise".
• Structural shortcuts: outputting a skeleton when a full implementation was requested, showing the first and last section while skipping the middle, replacing repeated logic with one example and a description, and describing what code should do instead of writing it.

The execution process has three steps. Scope: read the full request, count the distinct deliverables expected (files, functions, sections, answers), and lock that number. Build: generate every deliverable completely, with no partial drafts and no "you can extend this later". Cross-check: before output, re-read the original request and compare the deliverable count against the scope count, adding anything missing before responding.

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

It has stated limits. It enforces completeness but does not override token limits, safety constraints, missing source context, or user-provided scope boundaries. Do not invent unavailable code, credentials, private APIs, or project files just to satisfy a request for complete output.

The input is a request that expects a full deliverable. The output is that deliverable, finished, with nothing shortened to save space. Code blocks must contain actual runnable code, not descriptions of what code would do.

For long outputs, the rule is to handle the token limit gracefully. When a response approaches the limit, do not compress remaining sections to squeeze them in and do not skip ahead to a conclusion. Write at full quality up to a clean breakpoint such as the end of a function, file, or section, then end with a pause marker that says how many of the total parts are complete and names the next section to resume from. The user replies "continue", and the assistant picks up exactly where it stopped, with no recap and no repetition. Split long outputs into clearly labeled continuation chunks and check that each one connects cleanly to the previous one.

This is a behavioral skill with no external services. It can be combined with any code generation or writing task in the listed tools, and it is tagged for output, code generation, and quality.

Quick check before finalizing any response: no banned patterns appear anywhere in the output, every requested item is present and finished, code blocks contain real runnable code, and nothing was shortened to save space.

It is for developers and writers who have been burned by truncated answers, skeleton files, and placeholder comments, and want the assistant to deliver whole files and complete lists every time.