mcpField
R
repository-governance-lifecycle

repository-governance-lifecycle

github.com/arenukvern开发39444 次安装2 周前更新
代码仓库

关于 repository-governance-lifecycle

repository-governance-lifecycle 是面向 Agent 运维仓库的治理技能,适用于应用、库、工具及其他项目类型。它将伦理边界、架构决策记录、常设文档、品牌规范和计划清理串成“决策—记录—清理”流程。

主要功能

  1. 01检查伦理边界与仓库原则
  2. 02记录重要架构决策
  3. 03更新设计与开发常见问题文档
  4. 04执行品牌语调规范
  5. 05清理过期计划并规划证据

适用场景

  1. 01处理会改变仓库政策或职责的提案
  2. 02让架构决策与日常文档保持一致
  3. 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.yaml
governance-adr-trigger.yaml
logo-work-dormant.yaml
north-star-impact-trigger.yaml
routine-repair-dormant.yaml
references/
adr-format.md
brand-guidelines.md
charter-and-ethics.md
evals.md
faq-format.md
north-star-rules.md
sources.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

来源

请参阅 references/sources.md。

评论

支持 Markdown