full-output-enforcement

1实现原理 · 为什么它能做到

纯行为约束型 prompt（49 行单文件）：基线把『完整性』设为第一优先级，直接覆写模型的 brevity 默认倾向。

占位模式以『硬失败』清单分三类封禁：代码块内、行文内、结构捷径，给出可直接判定的字面禁用串（// rest of code、'for brevity'、骨架代替全文等）。

三段执行流程 Scope→Build→Cross-check：先数清交付物数量并锁定，生成后对照原请求做数量核对，缺则补。

长输出按 token 上限设计分片协议：全质量写到干净断点（函数/文件/章节末尾）即停，输出固定 PAUSED 标记，'continue' 后从断点精确续写、禁止复述。

Quick Check 收尾：交付前复查禁用串、需求逐项在场、代码块是真实可运行代码、无因省空间而删减。

2核心能力

4风险提醒 风险提醒：绿色 · 放心使用

5第二遍独立确认

• [ok] 目录资产面（含隐藏/未跟踪文件） — git ls-files + ls -A 双查：该 skill 目录仅 1 个文件 SKILL.md，无 scripts/references/模板/数据/隐藏文件，无可执行代码。
• [ok] 执行类 token 扫描 — 逐文件扫描 bash/exec/child_process/curl/wget/fetch/axios/process.env/API_KEY/.env/fs./writeFile/.github 等零命中（brutalist 一处 'sans-serifs.' 单词结尾 fs. 为误报，人工复核排除）。
• [ok] 引文逐条 grep -F 字节复核 — 本 JSON 所用全部 quote 均以 grep -F 在 pin commit 工作树中逐条验证存在，无 paraphrase 冒充。
• [ok] 元数据与 pin 核对 — 本地 git HEAD == 任务 pin ccbc15639c97057cbfcf32ecebc38ef716e4bb37（README 显示该提交为 docs/sponsor 修订 #102，2026-08-24）；GitHub API 实查 stars=85698、MIT、pushed_at=2026-08-24T15:23:56Z。frontmatter name 与任务给定名一致。
• [ok] 功能声明 vs 实际能力夸大检查 — description 声称均由 SKILL.md 正文纯 prompt 机制兑现，无脚本可调用、无越界承诺（详见本文件 how_it_works 引文）。
• [ok] 『handles token-limit splits cleanly』是否有真实机制 — 正文给出完整协议：全质量写到干净断点→输出 [PAUSED — X of Y complete. Send "continue"…]→continue 后『pick up exactly where you stopped. No recap, no repetition.』，非空头承诺。
• [ok] 禁用清单与『用户要求简短』的冲突仲裁 — 正文无冲突仲裁条款（复查无 unless/user explicitly 等豁免表述）；已在 risks 中明示此缺口，不夸大其覆盖范围。
• [ok] 占位串检查是否覆盖常见变体 — bare `...`、/* ... */、// TODO、'Let me know if you want me to continue' 等均以字面列入；属提示强度问题而非缺陷，正文以『hard failures. Never produce them.』设最高语气。

6结论