readiness-fix

Readiness Fix

这是流程类 Skill，默认仅在用户显式调用 $readiness-fix 时运行。移植自 Factory Droid 内置 /readiness-fix；与原版的唯一差异是删除了云端报告读取：失败信号一律读 $readiness-report 的本地存储，不调用任何远端 API。

正文为原版提示词原文（三个分支模板已实例化），评估与修复语义以本文为准。

开始时加载 $readiness-report，由它提供 signals.md 中的评估契约和按需生成报告的流程；不读取 sibling Skill 路径。

Local report source: the latest run in ${XDG_CACHE_HOME:-~/.cache}/readiness-report/<repo-slug>/history.json plus its reports/<run-id>.json. Use scripts/pick_failing.py to list the failing signals (id, name, current score, category) — it reads local files only. Wherever the branches below say "the failing signals listed above", that list is the output of pick_failing.py (the original inlined a Report Summary and Failing Signals block from the cloud report; see 本地运行差异 at the end).

---

The following block is the original i2I text the binary appends to every branch:

Fix Instructions

For each signal you are fixing:

1. Explore the repository to understand the current state related to the signal
2. Make substantive improvements to the codebase that genuinely address the signal
3. Verify your fix addresses the issue (e.g., run linter if fixing lint_config, run tests if adding tests)
4. Keep changes focused on the signal - don't refactor unrelated code

Completion

• Provide a succinct summary of what you changed and why it genuinely improves the codebase

CRITICAL: Quality Standards

Your fix must genuinely improve the codebase. Do NOT use workarounds or shortcuts:

• NO empty placeholder files (e.g., empty test files, stub configs)
• NO minimal implementations that technically pass but provide no real value
• NO disabling checks or adding skip markers to pass validation
• NO trivial changes that game the metric without improving quality

Examples of BAD fixes:

• Adding an empty test.js file to satisfy "has tests" criterion
• Creating a .eslintrc that disables all rules
• Adding // @ts-nocheck to satisfy TypeScript requirements