用途
Feature 是一个仓库维护自动化的技能，目标是在 GitHub 仓库上「构建、增强或唤醒」代码。它把三种仓库工作模式合并到一个选择器之下，避免能力分散：
- watched 模式：遍历所有被关注的仓库，每个仓库提交一个功能 PR，适合做每周的广泛推进。
- external 模式：每次只针对一个仓库，做一次最佳的单项增强，也可以定向修复某个 issue。
- dormant 模式：选取一个评分最高的休眠仓库，用一次可见的修复让它重新活跃起来。
主要能力
技能通过运行变量 ${var} 决定进入哪个分支。选择器语法包括：空值或 watched 表示遍历所有关注仓库（每个仓库一个 PR）；watched:<feature-spec> 表示只在第一个关注仓库上构建指定功能；external 表示自动挑选一个仓库做最佳增强；external:<owner/repo> 与 external:<owner/repo>#N 分别定向到具体仓库或具体 issue；dormant 与 dormant:<owner/repo> 用于唤醒休眠仓库。尾部可加 --fix-issues，让分支优先处理开着的 GitHub issue 而不是主动改动。
此外还有两条特殊拦截逻辑。第一条是受控修复通道：当变量匹配 repair:<owner/repo#N>@<40位小写 sha> 时，会获取该 PR 并校验其仍处于打开状态且 HEAD SHA 完全一致，只有在存在匹配该目标与 SHA、且级别为 [CRITICAL] 或 [ISSUE] 的审查发现时才继续，检出 PR 现有分支进行修复，绝不新建分支或 PR，一次调用只做一轮修复。第二条是 Telegram 强制回复拦截：当变量以 build: 开头时，去掉前缀后按外部构建目标处理，其内容可以是 owner/repo、issue URL、owner/repo#N 或自由文本指令。
使用方式
所有分支读取 memory/ 下的操作者控制文件：memory/watched-repos.md 是候选仓库池（每行一个 owner/repo，# 开头为注释），memory/topics/repos.md 是带描述、技术栈与机会的完整仓库目录（external 分支的首选来源，缺失时回退到 watched-repos.md），memory/topics/stale-models.md 只在 dormant 分支的过时模型审计中使用，缺失时该分支跳过模型审计并记录 REPO_REVIVE_NO_MODEL_CONFIG。
运行前需要先读取 memory/MEMORY.md 与最近 7 天的 memory/logs/，并在通知前过滤掉最近约 3 天已经上报过的内容。
为避免重复工作，技能要求在选定工作项并确定分支名之后、克隆或构建之前，先用 ./scripts/feature-open-pr.sh covered "$REPO" "$BRANCH" 询问 GitHub：exit 0 表示已有开放 PR 覆盖，记录 FEATURE_SKIP 并换下一个候选；exit 2 表示 GitHub 无法读取，按已覆盖处理并跳过该仓库；exit 1 表示无人覆盖，可以构建。每个工作项只检查一次，因为同一技能的计划运行会在工作流并发组上串行化。
如果 PR 正文写了 Closes #N，需要先用 ./scripts/feature-open-pr.sh issue-open "$REPO" N 校验，exit 1 时移除该行、说明改动关联的 issue、记录 FEATURE_ISSUE_MISMATCH 并在通知中说明不匹配。
watched 分支的流程为：加载目标列表，对每个仓库独立执行 A3–A10（单个仓库失败不影响其他仓库，使用各自独立的临时目录）；按优先级挑选要构建的内容（指定 feature-spec、昨日 repo-actions 输出、带 ai-build 标签的开放 issue、MEMORY.md 中的计划功能），选中后设置 BRANCH 并做开放 PR 检查；用 gh repo clone 克隆到临时目录，阅读代码库与近期提交，实现功能，沿用既有的代码风格、不引入非必要依赖、不重构无关代码；然后建分支、提交、推送，用 gh pr create 开 PR；最后写入日志并针对每个成功 PR 分别发送通知。
通知模板要求包含功能名称、通俗描述、为何重要、具体构建内容（文件/组件级别）、工作原理与技术实现、后续工作以及 PR 链接，明确禁止压缩成一两行。如果所有仓库都被跳过，则完全不发送通知，只记录每个仓库的跳过行。
适用场景
适合以 GitHub 仓库为对象的、可自主实现的连续小步改进：每周对所有关注仓库做一次广泛推进；对某个外部仓库做一次定向增强或 issue 修复；把长期休眠的高星仓库用一次可见修复重新激活；或在审查之后对指定 PR 的指定提交做一轮受控修复。
限制与注意事项
报告与实现必须基于事实：不能把未验证的 issue 修复写成已完成，issue 校验失败时要如实说明不匹配，exit 2 时保留 PR 并记录未校验。受控修复通道只允许一轮，不得递归派发其他智能体，也不得声称后续审查已通过。
对于内容过滤敏感的文档（如 CODE_OF_CONDUCT.md、滥用与审核政策、骚扰举报文档），技能要求不要自由生成正文，而是用 curl -fsSL ... -o CODE_OF_CONDUCT.md 直接把上游标准文本写到磁盘，避免正文经过模型输出触发过滤；随后只用一次定点 Edit 修改执行联系行，并且不把正文粘贴进结果文本。
写作风格上，若 soul/SOUL.md 与 soul/STYLE.md 已填写，则按操作者语气；若为空模板或不存在，则使用清晰、直接、中性的语气。
关于收费、价格、平台支持范围与效果等事实，本资料暂未提供。