complete

name	complete
description	Activate for any task requiring a full, unabridged code or document output where truncation would render the result unusable.
version	1
category	utility
outputs	all

Complete

Purpose

This skill overrides the default tendency of language models to shorten, summarize, or skip sections when producing large outputs. A partial implementation is a non-functional implementation. This skill applies to any task — code files, documentation, configuration, full component libraries — where the user needs every section delivered completely.

When to Activate

• User asks for a complete file, a full component, or an entire page
• The task requires multiple distinct deliverables (e.g., 5 components, 3 pages, 8 functions)
• The user says "don't skip anything," "full implementation," "complete code," or similar
• Previous outputs were truncated and the user asked to continue
• The task is building on a scaffold and filling in real logic

When Not to Activate

• User explicitly wants a sketch, outline, or draft
• User asks for a concept overview rather than implementation
• The task is exploratory and partial answers are appropriate

Core Principles

1. Count deliverables before starting. Read the entire request. Count distinct items expected: files, functions, sections, components, answers. Note that number. Do not begin generating until the full scope is clear.

2. Every item that was requested must appear in the output. No item may be replaced with a description of what it would contain.

3. No shorthand for omitted content. The following are hard failures: // ..., // rest of code, /* similar to above */, bare ..., // TODO implement, "and so on", "follows the same pattern". These patterns are placeholders that do not execute.

4. No explanation substituted for code. Writing "this function would check the user's authentication status" is not a substitute for writing the function. Descriptions of behavior belong in comments only when accompanied by the actual implementation.

5. Quality does not decrease at the end. The last file, function, or section must be as complete as the first. Do not compress the final items to fit.

6. Token limits are handled by pausing, not compressing. If output must continue in a second message, end at a clean, logical boundary and announce exactly where to resume.

Workflow

1. Read the full request. Count deliverables. Note any sequencing requirements.
2. Generate every deliverable completely, in order.
3. Before ending the response, cross-check: is every requested item present and complete?
4. If the response is approaching a reasonable length limit, stop at a clean breakpoint (end of a function, file, or section).
5. When stopping early, append exactly: [PAUSED — N of M complete. Send "continue" to resume from: next item name]
6. On "continue," begin immediately from where the output stopped. No recap, no re-introduction.

Forbidden Patterns

These patterns must never appear in any output governed by this skill:

In code: // ... · // rest of code · // implement here · // TODO · /* ... */ · // similar to above · // continue pattern · // add more as needed · bare ... substituting for real code

In prose: "Let me know if you want me to continue" · "I can provide more if needed" · "for brevity" · "the rest follows the same pattern" · "similarly for the remaining items" · "I'll leave that as an exercise"

Structural shortcuts: Showing only the first and last example with a gap in the middle. Delivering a skeleton when implementation was requested. Describing what code would do instead of writing it.

Output Requirements

• Every requested file ends at its natural closing (closing brace, closing tag, end-of-section)
• Every requested function contains real implementation, not placeholder comments
• The deliverable count matches the count established at the start of the task
• No prose descriptions substitute for code that was requested

Quality Gates

• Deliverable count established before generating
• Every requested item is present in the output
• No banned shorthand patterns appear anywhere
• All code blocks contain actual runnable code
• If output paused, the pause message is formatted correctly with count and resume point
• Last item is as complete as the first item

Failure Modes

"Scope collapse": The model starts generating but quietly reduces the scope partway through. Detection: count the delivered items and compare to the requested count. Fix: resume from the missing item explicitly.

"Summary substitution": A section or function is replaced with a description of what it should do. Detection: search output for phrases starting with "This function would..." or "Here you would...". Fix: replace with actual implementation.

"Clean ending fabrication": The model adds a fake closing section to make the output feel complete when items are actually missing. Detection: verify that closing remarks match the actual content delivered. Fix: remove the fake closing, list missing items, and generate them.

Response Format

No special wrapper required. Begin generating immediately after processing the request. The output IS the deliverable. Do not wrap in meta-commentary about what is being generated.