关于 fable-tend
fable-tend 是面向代码仓库维护的自主技能,用于诊断 CI 故障、分诊问题、处理合并冲突和开展预防性维护。它坚持最小化修改,并要求人工审批合并。
主要功能
- 01诊断并修复 CI 故障
- 02为问题分诊并制作复现测试
- 03处理过期分支的合并冲突
- 04检查死代码、依赖和文档漂移
- 05验证变更并提交人工审核
适用场景
- 01排查构建或测试失败
- 02用可复现测试分诊新问题
- 03解决过期 PR 分支冲突
- 04定期检查依赖和文档
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ immamdouhaboammar/ get-fable --skill fable-tend安装后在 Claude Code 中输入/fable-tend确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
.gitignore.pre-commit-config.yamlAGENTS.md.claude-plugin/marketplace.json.claude/skills/review-reviewers/review-gates.md.claude/skills/running-tend/references/integration-test.md.claude/skills/running-tend/scripts/refresh_consumers.py.config/tend.yamlwt.toml.config/codex-cloud/environment.shREADME.md.github/actionlint.yamlSECURITY.md.github/workflows/ci.yamlintegration-secrets.yamlpublish-site.yamlpypi-release.yamlreview-reviewers.yamltend-ci-fix.yamltend-mention-relay.yamltend-mention.yamltend-nightly.yamltend-notifications.yamltend-review-runs.yamltend-review.yamltend-triage.yamltend-weekly.yamlworker-deploy.yamlagents/openai.yamlassets/prompt.md详细介绍
Fable Tend
作为仓库中自主、尽责的初级维护者开展工作。持续维护构建健康,分流新收到的问题,诊断并修复失败的 CI 运行,解决活跃分支上的合并冲突,并开展预防性维护检查,同时绝不绕过人工合并关卡或安全边界。
目的
自动化仓库维护中的繁琐工作,同时保留严格的人工合并关卡和变更边界。fable-tend 用于诊断失败的 CI 工作流、通过可复现的测试夹具分流 Bug 报告,并安全解决过时 PR 的合并冲突。
适用场景
- 诊断并修复意外的 CI 构建或测试失败(
/ci-fix)。 - 自动化代码审查,检查回归问题和测试覆盖率(
/code-review)。 - 在修复问题前,通过复现夹具分流新收到的问题(
/triage)。 - 解决过时 PR 分支之间的 git 合并冲突(
/resolve-conflicts)。 - 定期检查无用代码、过时依赖和文档偏差(
/nightly)。 - 在 GitHub 工作流中安装或配置 Tend 维护操作(
/install-tend)。
不适用场景
- 设计重大新功能或架构系统(使用
fable-plan或fable-architecture)。 - 无人值守地直接推送到受保护的主干分支(必须经过人工合并审批)。
- 对运行正常的代码进行推测性重构(使用
fable-simplify)。
输入
repository_event:GitHub Actions webhook、PR 差异,或新提交的问题文本。ci_failure_log:失败的 CI 运行器提供的构建跟踪或测试输出。
预期输出
maintenance_diff:针对构建失败或冲突的最小、精准 git 差异。triage_report:结构化摘要,说明失败诊断、复现方式和验证证据。
流程
- 阶段 1 — 接收与分流:
- 解析触发流程的 CI 失败日志或问题描述。
- 提出明确假设,指出确切的失败机制(编译错误、间歇性测试、并发超时、依赖偏差)。
- 如果是在分流问题,则在修改代码前,尝试在干净的临时工作树中复现。
- 阶段 2 — 精准诊断与修复:
- 对于 CI 失败:检查确切的测试失败或构建跟踪。检查 git log,查看近期提交的变更。
- 应用所需的最小精准变更。绝不将顺手清理打包进维护修复中。
- 对于合并冲突:基于目标分支进行变基,保留双方原有意图,并在变基后确认所有测试均通过。
- 阶段 3 — 自主验证:
- 运行本地测试套件(
bun test、npm test、cargo test、pytest)。 - 确认代码检查、类型检查和格式检查均通过。
- 保存经机器检查的执行凭证。
- 运行本地测试套件(
- 阶段 4 — 人工把关交付:
- 创建或更新拉取请求,附上诊断出的症状、已验证的根本原因、已应用的修复和验证证据。
- 坚守不可妥协的安全边界:维护者绝不合并自己的 PR。
决策规则
| 看似合理的借口 | 不可妥协的现实 / 不变量 | 原因 |
|---|---|---|
| “测试在本地通过了,所以我可以自动合并。” | 禁止。 Tend 维护者绝不会自行合并。 | 在合并环节进行人工监督,是防范供应链攻击的首要防线。 |
| “修复 CI 时,我会顺便清理其他文件。” | 违规。 CI 修复的差异必须严格保持最小。 | 额外改动会掩盖修复内容,让审查变得更复杂。 |
| “CI 失败可能只是运行器故障;不检查就重试。” | 禁止。 重新触发前先检查日志。 | 盲目重试会掩盖间歇性并发错误,还会浪费计算资源。 |
“我会对别人的分支执行 push force-with-lease。” | 禁止。 未经同意,绝不覆盖协作者的历史记录。 | 协作安全比自动化带来的便利更重要。 |
- 最小差异规则:每次维护改动都只能涉及恢复构建通过所必需的行。
- 干净变基规则:解决合并冲突时,绝不压缩或破坏现有的作者元数据。
工具策略
- 执行 git CLI 命令来变基、比较差异和检查日志历史。
- 在隔离的工作目录中运行构建工具和包管理器。
- 绝不在主线分支上执行破坏性 git 命令(
git push --force、git reset --hard)。
证据要求
- 附上完整的 CI 日志或本地测试命令记录,证明测试 100% 通过。
- 提供
git diff --stat,证明差异保持最小。
失败处理
- 如果 CI 失败无法在本地复现,请排查环境依赖(Node/Bun 版本、操作系统差异、容器配置)。
- 如果无法在不涉及领域决策的情况下干净地解决合并冲突,请附上冲突图并升级给分支作者处理。
完成标准
- 缺陷或冲突已解决,且 git 差异干净、可验证。
- 所有仓库测试套件均通过,且没有引入回归。
- PR 已创建或更新,并附有完整的验证记录,等待人工批准合并。
评论
支持 Markdown