mcpField
F
fable-tend

fable-tend

github.com/immamdouhaboammar开发329 次安装5 天前更新
代码仓库

关于 fable-tend

fable-tend 是面向代码仓库维护的自主技能,用于诊断 CI 故障、分诊问题、处理合并冲突和开展预防性维护。它坚持最小化修改,并要求人工审批合并。

主要功能

  1. 01诊断并修复 CI 故障
  2. 02为问题分诊并制作复现测试
  3. 03处理过期分支的合并冲突
  4. 04检查死代码、依赖和文档漂移
  5. 05验证变更并提交人工审核

适用场景

  1. 01排查构建或测试失败
  2. 02用可复现测试分诊新问题
  3. 03解决过期 PR 分支冲突
  4. 04定期检查依赖和文档

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/immamdouhaboammar/get-fable --skill fable-tend

安装后在 Claude Code 中输入/fable-tend确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

.gitignore
.pre-commit-config.yaml
AGENTS.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.yaml
wt.toml
.config/codex-cloud/
environment.sh
README.md
.github/
actionlint.yaml
SECURITY.md
.github/workflows/
ci.yaml
integration-secrets.yaml
publish-site.yaml
pypi-release.yaml
review-reviewers.yaml
tend-ci-fix.yaml
tend-mention-relay.yaml
tend-mention.yaml
tend-nightly.yaml
tend-notifications.yaml
tend-review-runs.yaml
tend-review.yaml
tend-triage.yaml
tend-weekly.yaml
worker-deploy.yaml
agents/
openai.yaml
assets/
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. 阶段 1 — 接收与分流:
    • 解析触发流程的 CI 失败日志或问题描述。
    • 提出明确假设,指出确切的失败机制(编译错误、间歇性测试、并发超时、依赖偏差)。
    • 如果是在分流问题,则在修改代码前,尝试在干净的临时工作树中复现。
  2. 阶段 2 — 精准诊断与修复:
    • 对于 CI 失败:检查确切的测试失败或构建跟踪。检查 git log,查看近期提交的变更。
    • 应用所需的最小精准变更。绝不将顺手清理打包进维护修复中。
    • 对于合并冲突:基于目标分支进行变基,保留双方原有意图,并在变基后确认所有测试均通过。
  3. 阶段 3 — 自主验证:
    • 运行本地测试套件(bun test、npm test、cargo test、pytest)。
    • 确认代码检查、类型检查和格式检查均通过。
    • 保存经机器检查的执行凭证。
  4. 阶段 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