关于 repository-governance-lifecycle
repository-governance-lifecycle 是面向 Agent 运维仓库的治理技能,适用于应用、库、工具及其他项目类型。它将伦理边界、架构决策记录、常设文档、品牌规范和计划清理串成“决策—记录—清理”流程。
主要功能
- 01检查伦理边界与仓库原则
- 02记录重要架构决策
- 03更新设计与开发常见问题文档
- 04执行品牌语调规范
- 05清理过期计划并规划证据
适用场景
- 01处理会改变仓库政策或职责的提案
- 02让架构决策与日常文档保持一致
- 03整理陈旧计划和治理资料
MCP 相关
MCP 未在输入中说明。
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ arenukvern/ mcp_flutter --skill repository-governance-lifecycle安装后在 Claude Code 中输入/repository-governance-lifecycle确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
evals/cases/evidence-routing-trigger.yamlgovernance-adr-trigger.yamllogo-work-dormant.yamlnorth-star-impact-trigger.yamlroutine-repair-dormant.yamlreferences/adr-format.mdbrand-guidelines.mdcharter-and-ethics.mdevals.mdfaq-format.mdnorth-star-rules.mdsources.md详细介绍
仓库治理生命周期
这是治理由 Agent 操作的仓库的中枢神经系统。它适用于应用、库、工具、插件、执行框架和元仓库;Skill Steward 本身仍是一个结构治理仓库,而非领域教程目录。它将伦理、品牌、架构决策记录(ADR)和持续更新的文档(FAQ)整合为一个连贯的闭环:决策 → 记录 → 清理。
每当 Agent 提议或执行结构调整、声明变更、持久政策变更或文档体系变更时,都必须走完此闭环。常规仓库修复应优先保留原始目标并遵循原生门禁;只有当修复会改变持久归属、政策、证据、ADR/FAQ 中的事实或计划规范时,才使用此治理闭环。
治理闭环
1. 检查伦理与边界(NORTH_STAR)
做出任何决策之前,都要检查仓库的基础章程和伦理基准。
- 阅读 章程与伦理,确保拟议的更改不会违反仓库的道德边界(例如,不夸大宣传;Skill Steward 中不包含领域教程;如果领域文档属于受治理产品仓库的产品,则应放在该产品仓库中)。
- 阅读 北极星规则,了解扩展模型。
- 对持久结构性变更,将
north_star_impact分类为none、applies、clarifies、sub_star、amends或conflicts。只有当归属、政策、证据事实、ADR/FAQ 中的事实或仓库的核心可能发生变化时,才使用此流程。 - 编辑持久治理内容之前,先回答门禁问题:是什么痛点引发了这项变更;它服务于哪条北极星价值路径;它是一种机制还是新的核心;它是否改变了仓库的职责范围或拒绝事项;如果是,ADR 在哪里;如果不是,有什么检查可防止机制变成使命。
none和applies按原生工作流处理,clarifies通过 FAQ/技能/地图/检查更新处理,sub_star通过明确的父子边界处理,amends或conflicts则在实施前通过 ADR 和北极星差异进行处理。
2. 记录决策(ADR)
如果你做出了架构层面的重要决策(或触发了 T1-T8 阈值),就必须将其记录下来。决策不能只存在于 Agent 的上下文窗口中。
- 遵循 ADR 格式 中的格式规则,撰写正式的决策记录。
3. 更新持续维护的文档(FAQ)
决策会改变仓库的日常运作方式。必须更新持续维护的事实记录。
- 更新
docs/DESIGN_FAQ.mdx(为什么)或docs/DX_FAQ.mdx(如何做)。 - 遵循 FAQ 格式 中的确切结构规则,确保问题便于搜索且表述直接。
4. 应用品牌与语气规范
撰写 ADR、FAQ 或任何面向用户的文档时,必须严格遵守仓库的语气规范。
- 不要使用企业营销术语。
- 查看 品牌指南 中的禁用词列表(例如,不要使用 “unlock”“supercharge”“ultimate”)。
5. 规划文档卫生(清理)
不要将过时的规划文档(task.md、implementation_plan.md)永久保留为文档。
- 更新 ADR 和 FAQ 后,知识便已持久化。
- 提取剩余的有用信息,并删除或忽略临时文件。
- 对过时或内容重叠的非规划文档,编辑前先确定一种处理方式:保留、合并、移至 ADR、移至 FAQ、移至 skill、移至 check、移至 evidence、移至 consumer proof,或删除。
- 思考这次变更能让哪些现有文档缩减或消失。
- 将规范架构保留在所属仓库中;使用方仓库应记录采用证明、本地差异、受阻状态以及指向所属仓库的链接。
- 对于拆分、压缩、提升、降级、删除或保持原生等更广泛的表面形态决策,请通过 repo-quality-system-lifecycle 和 Evolutionary simplicity 处理,不要另行制定仅适用于治理的原则。
- 在 ADR/evidence 说明中提升 steward、adoption、harness-ready 或成熟度相关表述前,运行
steward claim check --claim <claim> --evidence <path> --json。将not_rejected视为否定门槛结果,而非接受结论。
6. 有目的地归类证据
不要把每次运行、规划或讨论都转化为证据。请依据 Evidence artifacts 中的归类规则:
- ADR:持久化的决策、权衡、状态或后果。
- FAQ:人类和 Agent 会反复询问的常见原因/方法。
- Skill:可重复的 Agent 操作流程或解读流程。
- Check/工具/schema/测试:确定性地检测漂移、新鲜度、形态或受阻状态。
- 当前台账:最弱但真实的当前状态和重新运行路径。
- Evidence artifact:真实运行证明、受阻状态、模式审查、PDSA 循环、事后复盘、未知情形,或用于保护某项主张或改变未来行为的参考资料。
- 删除/移除:已完成的检查清单、过时规划或模板(前提是有用信息已提取)。
创建或实质性更新 evidence artifact 时,请使用 Evidence artifacts 中的规范封装格式。ADR 0023 说明了该封装格式存在的原因。
安装
npx skills add arenukvern/skill_steward --skill repository-governance-lifecycle