‹ 首页

full-output-enforcement

@leonxlnx · 收录于 1 周前 · 上游提交 1 周前

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.

适合你,如果常遇到LLM输出被截断或出现占位符的问题

/ 通过 npx 安装 校验哈希
npx oh-my-skill add leonxlnx/taste-skill/full-output-enforcement
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- leonxlnx/taste-skill/full-output-enforcement
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify leonxlnx/taste-skill/full-output-enforcement
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
61322GitHub stars
~574上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 b177427 · 表述以原文为准
它做什么

安装后,Claude 会强制输出完整内容,不会截断代码或使用“// 此处省略”等占位符。如果输出过长,会在自然断点处暂停并提示继续。

什么时候触发

当你要求 Claude 生成完整代码、多个文件或详细回答时触发。

装好后可以这样说
Claude 会输出完整代码,不会省略任何部分。
Claude 会逐一列出,不会用“等等”代替。
Claude 会输出完整文件,不会只给骨架。
技能原文 SKILL.md作者撰写 · MIT · b177427

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
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。