self-healing-ci

自愈 CI

self-healing 的 CI 专用变体。针对拉取请求和定时工作流事件，以无头模式运行“诊断 → 修补 → 验证 → 记录”循环。

安装

gh skill install pskoett/pskoett-skills self-healing-ci

使用 Agent Skills CLI 的备用安装方式：

npx skills add pskoett/pskoett-skills/skills/self-healing-ci

目的

在 CI 中运行自愈流程，无需交互式聊天循环：

• 检查失败的 PR 检查（测试／构建／Lint／扫描／部署），并解析日志以找出根本原因
• 提出经过最少改动且已验证的修补方案，作为 PR 评论或后续提交
• 将一条 HEAL- 记录提交到 .learnings/HEALS.md，并附上验证证明（如果工作流无法重新运行检查，则标记为 pending-verify）
• 新建记录前，按 Pattern-Key 搜索已有的 HEAL 记录，避免重复记录再次发生的问题
• 当 Recurrence-Count >= 3 时，附加 Handoff 区块，以便通过 self-improvement-ci 提交改进

交互式／本地会话请使用 self-healing。

上下文限制（重要）

CI Agent 无法获得原始实现会话中的完整任务上下文。Agent 读取的是 CI 日志和代码，而不是在专注实现期间所拥有的完整上下文。影响如下：

• 倾向于做出保守诊断——如果无法确定，就记录为 pending-verify 并告知 PR 作者
• 在声称状态为 verified 前，必须进行验证——在同一次工作流运行中重新运行失败的检查
• 未明确通过验证前，绝不修改项目代码；除非工作流配置为自动提交，否则应将更改作为 PR 评论提出
• 将不确定或影响较大的建议交由交互式审核

先决条件

1. 已为仓库启用 GitHub Actions
2. 已在工作流中通过 GitHub CLI 完成身份验证（gh auth status）
3. 已安装 gh-aw，用于编写和验证：

gh extension install github/gh-aw

4. .learnings/HEALS.md 已提交到仓库（或在首次运行时创建；引导模式请参阅 references/workflow-example.md）

CI 约定

CI 技能必须：

1. 读取 CI 日志、PR 差异和现有的 .learnings/HEALS.md，不得读取 PR 作者机器上的其他内容
2. 默认避免直接修改代码；通过 PR 评论或由标签控制的提交来提出更改
3. 应用建议的修补方案后，重新运行失败的检查（可行时）——状态为 verified 必须满足这一条件；如果无法重新运行，则如实标记为 pending-verify
4. 输出机器可读的 YAML（见输出架构）
5. 只有重新运行成功后，才提交经过验证的 HEAL- 记录；已放弃的修复仍需记录，但应单独提交并清楚标注

输出架构

self_healing_ci:
  source:
    pr_number: 123
    commit_sha: "abc123def"
    failed_check: "test (node 20)"
    workflow_run_id: 4567891234
  heal:
    heal_id: "HEAL-20260524-001"
    status: "verified"            # verified | pending-verify | abandoned
    trigger: "tool-failure"       # free-form
    active_context: "ci"          # optional
    area: "tests"                 # free-form
    pattern_key: "env.lockfile_mismatch"
    diagnosis: "Project uses pnpm; CI workflow ran `npm ci`."
    fix:
      summary: "Switch the CI install step from `npm ci` to `pnpm install --frozen-lockfile`."
      diff_path: ".learnings/heals/HEAL-20260524-001/patch.diff"   # only if files generated
    verification:
      command: "pnpm install --frozen-lockfile"
      exit_code: 0
      output_excerpt: "Lockfile is up to date, resolution step is skipped"
    recurrence_count: 1
    promotion_ready: false        # true at recurrence_count >= 3
  summary:
    heals_filed: 1
    verified: 1
    pending_verify: 0
    abandoned: 0
    promotion_candidates: 0

在 CI 中先验证再持久化

在 CI 中，验证步骤具体指：应用建议的修补方案后，在同一次工作流运行中重新运行失败的检查：

原始失败	CI 中的验证步骤
pnpm test 失败	修补后重新运行 pnpm test
构建（tsc、cargo build）失败	重新运行构建步骤
Lint（eslint、ruff）失败	重新运行 Lint 步骤
部署预览失败	重新运行部署步骤（如果工作流允许）
快照差异	如适用，使用确定性桩重新运行

如果无法重新运行（检查需要仅在生产工作流中提供的密钥；故障是暂时性的；修补方案需要人工审核后才能提交），则应将 HEAL 标记为 pending-verify，并明确说明需要什么证据才能证明修补有效。

绝不要伪造 verified 状态。 伪造正是此技能旨在防止的问题；而在 CI 中，其后果比交互式会话更严重，因为后续 PR 可能会自动应用未经验证的“修复”。

重现与提升规则

• 提交新的 heal 之前，先按 Pattern-Key 搜索 .learnings/HEALS.md
• 如果匹配：递增 Recurrence-Count，更新 Last-Seen，并将新出现记录追加到 See Also
• 提升阈值（与交互式流程相同）：
  • Recurrence-Count >= 3
  • 在至少 2 个不同的 PR/任务中出现
  • 时间跨度在 30 天以内
  • 修复具有通用性（并非特定于某个项目）
• 提升时：在现有 HEAL 中追加一个 Handoff 块，其中包含 Promotion Target（CLAUDE.md / AGENTS.md / .github/copilot-instructions.md / new-skill）和一行 Distilled Rule
• self-improvement-ci 会读取 Handoff 块，并通过 PR 提议提升

建议的工作流触发器

触发器	使用场景
workflow_run（已完成，结论：失败）	最常见——响应其他工作流失败
pull_request（使用 if: 检查状态）	对每个 PR 运行，但在所有检查均通过时跳过
schedule（每晚）	查找过时的不稳定测试，发现逐个 PR 运行遗漏的模式
workflow_dispatch	手动针对特定 PR 或提交重新运行

编写模式和示例 .github/workflows/*.lock.yml 文件位于 references/workflow-example.md。在明确决定启用 CI 自动化之前，请勿将示例工作流放入 .github/workflows。

CI 中的反模式

交互式技能中的所有反模式同样适用。需要留意的 CI 特有反模式：

1. 自动提交未经验证的修复。 未通过重新运行检查的补丁绝不应自动合入分支。请改为通过 PR 评论提出。
2. 重新触发循环。 如果 heal 会触发自身的工作流，请使用 if: github.actor != 'github-actions[bot]' 作为条件，以防止无限循环。
3. 静默重试不稳定测试。 除非补丁确实解决了非确定性问题，否则不稳定测试不应作为 heal 候选。反复重新运行同一个不稳定测试直到通过，只是在掩盖问题，而非修复问题。
4. 跨 PR 的 Pattern-Key 冲突。 如果两个 PR 命中相同的 Pattern-Key，但根本原因不同，说明键的粒度太粗——应细化键，而不是让它们合并。
5. 修复不由你负责的基础设施。 不要在 CI 内修改第三方操作的源码——请改为提出版本固定或配置变更建议。

交叉引用

• self-healing — 与之对应的交互式技能；文件格式和验证规范相同
• self-improvement-ci — 接收 heal 的 Handoff 块；提议将其提升到记忆文件
• simplify-and-harden-ci — heal 稳定 PR 后进行质量检查
• verify-gate — 交互式验证门；self-healing-ci 的验证是重新运行 CI 工作流
• references/workflow-example.md — gh-aw 工作流模板和编写说明