SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场feature-manager

feature-manager

编程与开发

查看项目

更新于 10-15 10:30

技能介绍

用途

Feature Manager 用于跟踪和管理用户在 GitHub 上推动的多 PR 功能。一个“功能”由一个追踪 issue 加上实现它的多个 PR 组成，通常是一叠基于彼此的分支。用户只需注册一次功能，之后说“work on suggestion mode”之类的话，Claude 每次都会有一致的理解。该技能维护注册表，并能一次性对整个功能执行重复性事务。

注册表

每个功能对应一个 YAML 文件，位于 ~/.claude/features/<slug>.yaml，可手动编辑；用户可能不打招呼就改动它，因此每次任务开始时都要重新读取。示例字段包括 name、aliases、repo、tracking_issues、worktree、stack（自下而上，每个 base 是其前一个分支）、side_prs、bundle（可选 Playground bundle）、last_checked 和 notes。

名称解析：把用户所说的内容与目录中每个文件的 name 和 aliases 做不区分大小写的匹配，并忽略“feature”一词。匹配一个就用它；没有匹配则提议注册或列出已有内容；匹配多个则询问是哪一个。

任何事务的 PR 列表按顺序为：stack，然后 side PR，然后 bundle。已合并或关闭的 PR 会留在文件中，直到用户移除，执行 git 操作时跳过它们。

主要能力（可触发的操作）

  • 注册：“register X from #NNN” / “add this feature”。bash ~/.claude/skills/feature-manager/scripts/discover-feature.sh OWNER/REPO NNN，脚本输出 issue 正文引用的所有 PR，以及用户 base 已在集合中的开放 PR，并标注 depth（0 表示基于 trunk）和 bundle_candidate。据此构建建议文件：按 depth 排序的开放 PR 构成 stack；depth 0 但非链底、或与另一 PR 同 depth 的进入 side_prs；bundle candidate 进入 bundle。已合并和关闭的 PR 不写入。从 issue 标题取 slug 和两三个别名，把 last_checked 设为当前时间。写入前必须向用户展示完整建议文件并征得同意。
  • 状态：“status of X” / “check on X” / “how is X doing”。运行 feature-status.sh，输出一张表（按 stack 顺序、side PR、bundle），列为 PR、Title、CI、Merge、Behind、Threads、Last activity。Merge 字段除 MERGEABLE 外显示 mergeState（Clean、Blocked、Behind）。Behind 表示该 PR 自己的 base 上有但自己缺少的提交。标记草稿，并为每个 PR 加链接。随后输出最多五行“Needs you”，顺序为：冲突、CI 失败、要求修改、最后发言来自他人的未解决讨论、落后于 base 的 PR。若都不符合则说“all green”并停止。不建议合并，由用户决定。
  • 更新：“update X” / “bring X up to date” / “rebase X on trunk”。始终先干跑并展示结果：bash ~/.claude/skills/feature-manager/scripts/cascade-update.sh <worktree> trunk suggest/intent suggest/data ... suggest/e2e --bundle try/suggest-mode-combined --dry-run。干跑中的 UP-TO-DATE 是相对当前父分支而言；一旦 trunk 进入底层，上层就都需依次处理，这正是实际运行所做的事。若 worktree 有未提交改动，脚本会拒绝，需报告而非代为 commit 或 stash。然后去掉 --dry-run 正式运行，每层用 merge commit 合并其父分支并推送到 origin；bundle 最后合并 stack 顶部，因此仅 bundle 的提交能存活。遇到冲突（exit 3）时合并会保持进行中：报告分支和文件后停止，是否解决由用户决定。用户要求解决时，在该 worktree 中解决、提交、推送，并以已解决分支为 base 从下一个分支重新运行脚本。绝不 rebase、绝不 force push、绝不 reset --hard 共享分支。脚本只处理 origin 上的分支；来自贡献者 fork 的 PR 无法从这里级联，脚本会以 exit 2 提示 origin/<branch> 不存在，需报告这些 PR 及其 Behind 数量，交由作者处理。完成后运行 Status。
  • CI：“fix CI on X” / “get X green”。运行 Status，取出 ci: failing 的 PR，对每个在功能 worktree 中使用 ci-fixer 技能，从 stack 底部开始。底层修复常能在级联上传后一并解决上层，因此修完一层后先 Update 再处理下一层。报告哪些 PR 曾为红、改了什么、哪些仍在运行。
  • 反馈：“any feedback on X” / “anything new on X” / “what needs a reply”。运行 feature-feedback.sh，按目标分组，人优先，机器人（is_bot: true）单独放一小节且只列未解决项。每项说明谁、在哪（带链接）、一句话要点，以及分类：代码改动、回复或无需动作（已解决、感谢、机器人摘要）。对代码改动和回复，用一两行提出回应方案。此事务不修改或发布任何内容。用户选定后，代码改动在 worktree 中以原子提交进行，回复通过 post-review-gate 以 adams-voice 加 claude-attribution 发出。只有在摘要呈现在用户面前之后才更新注册表中的 last_checked，绝不在之前，以免崩溃的运行吞掉评论。
  • 开始工作：“work on X” / “open X” / “switch to X”。读取注册表，cd 到 worktree。若不存在则从仓库主检出创建：git worktree add ~/repositories/worktrees/<issue>-<slug> <branch>（当该仓库配置了 wt 时适用 worktrunk 技能）。检出用户指定的分支，默认检出 stack 顶部，从 origin 快进，并在仓库有 .nvmrc 时运行 nvm use。说明检出的是哪个分支、属于哪个 PR，然后等待实际任务。
  • 同步 issue：“update the tracking issue” / “sync the issue”。根据 Status 表构建状态块，放入追踪 issue 正文中 <!-- feature-manager:status --> 与 <!-- /feature-manager:status --> 之间，若缺失标记则在正文末尾添加。标记之外的文字绝不动。状态块以 claude-attribution 头部开头。这是以用户名义发布的帖子：先把完整新正文草稿写入文件，经 post-review-gate，再运行 gh issue edit NNN --repo OWNER/REPO --body-file <file>，并记为 kind issue。
  • 监控：“watch X” / “keep an eye on X”。使用 /loop，间隔三十分钟。每次 tick：以 --snapshot <slug> 运行 Status，并运行自 last_checked 起的 Feedback。若 changes 为空且没有来自人的新反馈，只说一句“no change”。否则只报告发生变化的内容（CI 变红、出现冲突、有评审落地），反馈则给出摘要。监控 tick 绝不执行 git 操作或发布内容。
  • 列表 / 遗忘：“what features am I working on” / “forget X”。列表：每个注册表文件一行，含名称、仓库、开放 PR 数和 last_checked。遗忘：确认后删除该文件及其在 ~/.claude/features/.snapshots/ 下的快照。

安全护栏

每个任务都重新读取注册表，因为用户会手动编辑。绝不合并 PR、绝不强制推送、绝不 rebase、绝不在未被要求时解决冲突。没有经过 post-review-gate，任何内容都不发布，包括回复和 issue 正文编辑。发现是建议性的，由用户确认；不写入用户未见过的注册表文件。范围限于单个功能；跨仓库的“接下来该做什么”属于 pr-status-review 的职责，修复红色检查属于 ci-fixer 的职责，应委托而非重新实现。当名称或分支有歧义时，一次只问一个问题，猜错会推到错误分支。

常见误区提醒

文档列出若干“想到这些就意味着停下”的情形：“冲突很小我直接解决吧”——用户要的是更新而非解决，报告后停止；“rebase 历史更干净”——用户选择 merge 以保持讨论串锚定，应用 merge；“机器人的建议对，我直接应用”——反馈只提议，由用户挑选，放进摘要；“发现结果显然正确，直接保存”——用户才清楚哪个 PR 是 bundle、哪个是 side quest，先展示；“我现在就更新 last_checked 免得忘”——应在摘要进入对话后再更新，否则崩溃会丢失评论。

依赖与平台

脚本位于 ~/.claude/skills/feature-manager/scripts/（安装后），仅依赖 gh 和 jq，且从不修改注册表。适用于 GitHub 工作流和 Claude 技能环境。

暂未提供的信息

资料未说明收费、价格、平台支持范围、安装命令等细节，暂未提供。