Source profileQuality 79/100

nexu-io/open-design/skills/output-skill/SKILL.md

full-output-enforcement

Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.

Source repository stars
91,167
Declared platforms
0
Static risk flags
0
Last source update
2026-08-25
Source checked
2026-08-25
DecisionCompatibilityInstallWorkflowPermissionsEvidenceSourceFAQ

Decision brief

What it does: where it fits

Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly.

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/nexu-io/open-design --skill "skills/output-skill"
    Safe inspection promptEditorial

    Inspect the Agent Skill "full-output-enforcement" from https://github.com/nexu-io/open-design/blob/edfa6b5f447e95cb120eae030f03baba00dc34de/skills/output-skill/SKILL.md at commit edfa6b5f447e95cb120eae030f03baba00dc34de. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Execution Process

      1. Scope — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number. 2. Build — Generate every deliverable completely. No partial drafts, no "you can extend this later." 3. Cross-check — Before output, re-re…

      Scope — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.Build — Generate every deliverable completely. No partial drafts, no "you can extend this later."Cross-check — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
    2. 02

      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.

      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 comp…
    3. 03

      Banned Output Patterns

      The following patterns are hard failures. Never produce them:

      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 for omitted codeIn prose: "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content),…
    4. 04

      Handling Long Outputs

      When a response approaches the token limit:

      Do not compress remaining sections to squeeze them in.Do not skip ahead to a conclusion.Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score79/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars91,167SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    nexu-io/open-design
    Skill path
    skills/output-skill/SKILL.md
    Commit
    edfa6b5f447e95cb120eae030f03baba00dc34de
    License
    Apache-2.0
    Collected
    2026-08-25
    Default branch
    main
    View the original SKILL.md

    Full-Output Enforcement

    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 for omitted code

    In prose: "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"

    Structural shortcuts: Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.

    Execution Process

    1. Scope — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
    2. Build — Generate every deliverable completely. No partial drafts, no "you can extend this later."
    3. Cross-check — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.

    Handling Long Outputs

    When a response approaches the token limit:

    • Do not compress remaining sections to squeeze them in.
    • Do not skip ahead to a conclusion.
    • Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
    • End with:
    [PAUSED — X of Y complete. Send "continue" to resume from: next section name]

    On "continue", pick up exactly where you stopped. No recap, no repetition.

    Quick Check

    Before finalizing any response, verify:

    • No banned patterns from the list above appear anywhere in the output
    • Every item the user requested is present and finished
    • Code blocks contain actual runnable code, not descriptions of what code would do
    • Nothing was shortened to save space

    Frequently asked questions

    What to verify before installation and use

    What does the full-output-enforcement source document cover?

    Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly.

    How do I install full-output-enforcement?

    The source record exposes this install command: npx skills add https://github.com/nexu-io/open-design --skill "skills/output-skill". Inspect the command and pinned source before running it.

    Alternatives

    Compare before choosing

    Computed 10045,511

    coreyhaines31/marketingskills

    ab-testing

    When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

    2026-08-240 platforms
    Computed 10029,034

    garrytan/gbrain

    bulk-ingestion

    End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.

    2026-08-250 platforms
    Computed 10024,921

    alirezarezvani/claude-skills

    app-store-optimization

    App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

    2026-08-240 platforms
    Computed 1005,241

    dotnet/skills

    migrate-vstest-to-mtp

    Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing

    2026-08-240 platforms