How the Output-Skill Prevents Truncated Output in the Taste-Skill Framework

The output-skill guarantees complete responses by locking a deliverable scope before generation, banning placeholder patterns like ellipses and "TODO," and emitting deterministic pause markers when token limits are reached rather than truncating content.

The output-skill in the Leonxlnx/taste-skill repository enforces an exhaustive output policy that prevents truncated responses through systematic scope management and validation. Unlike standard generation patterns that might abbreviate code with placeholders, this skill ensures every requested deliverable is fully produced or explicitly paused at a clean breakpoint for continuation.

Explicit Scope Definition and Locked Deliverables

Before generating any content, the output-skill performs a complete read of the incoming request to count the exact number of deliverables required—whether files, functions, or sections. This count is locked as the scope at the start of processing, creating an immutable contract that the generation must fulfill. According to the specification in skills/output-skill/SKILL.md (lines 24-26), this scope remains fixed throughout the session, preventing the model from silently reducing the number of items to fit token constraints.

Banned Output Patterns: Eliminating Placeholders

The skill maintains a hardcoded blacklist of forbidden shortcuts that indicate truncated or incomplete output. Any occurrence of ellipsis (...), the string "TODO", "rest of code", or prose promising "more later" triggers an immediate failure state. As defined in skills/output-skill/SKILL.md (lines 14-20), these banned patterns force the model to emit runnable, complete code rather than abbreviated placeholders. If the generator attempts to insert a comment like # TODO: implement rest, the validation layer rejects it before the response reaches the user.

The Full-Generation Process

The output-skill operates through a strict two-phase generation pipeline that ensures exhaustiveness.

Build Phase

During the build phase, the skill generates every item within the locked scope without omission. The specification in skills/output-skill/SKILL.md (lines 25-26) mandates that generation continues until the scope count is satisfied, regardless of response length. This means if a request asks for three helper functions, the skill cannot declare completion after producing only two.

Cross-Check Verification

Immediately following generation, the skill re-reads the original request and compares it against the produced output. As implemented in skills/output-skill/SKILL.md (lines 26-27), this cross-check verifies that the number of produced items matches the initial scope count. Any missing pieces are identified and added before the response is finalized, catching partial generations that might have escaped the initial build phase.

Graceful Token Limit Handling with Pause Markers

When a response approaches the model's token ceiling, the output-skill does not compress or skip content to force completion. Instead, it identifies a clean breakpoint—such as the end of a function, file, or section—and emits a standardized pause marker. According to skills/output-skill/SKILL.md (lines 30-38), the marker follows this exact format:

[PAUSED — X of Y complete. Send "continue" to resume from: next section name]

This deterministic pause tells the caller precisely where generation stopped. A subsequent request containing "continue" resumes generation exactly at the specified point without repetition or loss of context. For example, if a module contains three functions but only two fit within the token limit, the marker indicates the third function by name, ensuring the follow-up request generates only the missing content.

Final Verification Safety Net

Before any output is returned to the caller, the skill executes a final quick-check routine defined in skills/output-skill/SKILL.md (lines 43-49). This verification ensures:

• No banned patterns appear in the text.
• All requested items from the original scope are present and finished.
• Code blocks contain executable code rather than descriptions.
• No content was shortened for brevity.

This safety net captures any accidental truncation that might have bypassed earlier validation stages.

Practical Implementation Examples

When requesting a complete Python module, the interaction follows predictable validation steps:

{
  "task": "Provide the complete `utils.py` module with three helper functions."
}

The output-skill responds by:

1. Locking the scope count to three functions.

2. Generating full source code for all functions without # TODO placeholders.

3. If the token limit is reached after the second function, emitting the pause marker:

[PAUSED — 2 of 3 complete. Send "continue" to resume from: function `process_data`]

A follow-up call with "continue" then generates exactly the process_data function without re-emitting the previous two functions.

Summary

• Scope Locking: The output-skill counts deliverables before generation and treats this count as immutable (lines 24-26).
• Pattern Banning: Ellipsis, "TODO", and "rest of code" are forbidden and trigger regeneration (lines 14-20).
• Two-Phase Verification: Build generation followed by cross-check verification catches missing items (lines 25-27).
• Deterministic Pausing: Token limits trigger breakpoint pauses with resumption markers rather than truncation (lines 30-38).
• Pre-Output Validation: A final check ensures completeness, executable code, and absence of placeholders (lines 43-49).

Frequently Asked Questions

How does the output-skill define and enforce the scope of deliverables?

The skill reads the entire request upfront to calculate the exact number of files, functions, or sections required. This number is locked as the scope at lines 24-26 of skills/output-skill/SKILL.md, and the generation process cannot complete until that exact count is produced.

What specific patterns does the output-skill reject as truncation indicators?

The skill maintains a hardcoded list including ellipsis (...), "TODO", "rest of code", and prose indicating "more later." Any occurrence of these banned patterns (lines 14-20) causes the output to be rejected and regenerated until only complete, runnable code remains.

How does the pause mechanism work when reaching token limits?

Rather than truncating or compressing content, the skill stops at a clean structural breakpoint (end of function, file, or section) and emits a standardized pause marker indicating completion status and the next resumption point (lines 30-38). The next "continue" request picks up exactly at that named location without duplication.

Where is the output-skill behavior documented in the repository?

All enforcement policies, scope definitions, banned patterns, and pause logic are fully specified in skills/output-skill/SKILL.md at the root of the Leonxlnx/taste-skill repository.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}