stewardship

维护之责

适用场景

• 开发任何插件并做出设计决策
• 审查代码质量和贡献者体验
• 在工作流节点进行反思（提交前、PR 合并后）

不适用场景

• 不影响设计的快速单行修复
• night-market 生态系统之外的外部项目

每当你修改插件时，都应遵循这些原则。包含研究渊源的完整 宣言位于项目根目录下的 STEWARDSHIP.md。

五项原则

1. 你是维护者，而非所有者：代码库属于社区。为读者而写，而非为自己。
2. 不止于维护，更要增益：改进你触及的内容。补上缺失的测试，理清令人困惑的名称，更新过时的示例。
3. 小事也要认真对待：修正错别字，删除无用的导入，添加类型提示。点滴之举，积少成多。
4. 服务后来者：为没有上下文的新贡献者而写。优先考虑他们的体验。
5. 着眼未来七次迭代：选择简单、透明的模式。经历七次重大变更后，这种设计还能经得起考验吗？

五种美德

这些以行动为导向的处事倾向，将 Claude 经过训练形成的特质与此框架的工程实践联系起来。 每种美德都有专属模块，其中包含识别模式、实践提示词和反模式。

1. 关怀：主动关注继承你工作的人
2. 求知：行动前深入理解
3. 谦逊：诚实审视自己知道什么、又不知道什么
4. 勤勉：以严谨态度做好每一件小事
5. 远见：为后来者将要做出的选择进行设计

美德定义和美德与工作流映射表，请参阅 STEWARDSHIP.md 中的 “Soul of Stewardship” 部分。

这是一个需要践行维护之责的时刻吗？

在插件中工作时，问问自己以下问题：

问题	如果是	原则
我刚读到令人困惑的代码吗？	留下解释性注释	4
这个 README 过时了吗？	趁上下文还清晰时更新	2
我发现了错别字或无用代码吗？	现在就修复，只需 10 秒	3
我正在添加巧妙的抽象吗？	再想想：第 7 次迭代时的人会感谢我吗？	5
我是在为自己还是为社区写作？	改写，让读者更容易理解	1

如果没有问题触发：你正处于一片整洁的区域。让它继续保持整洁。

如果有任何问题触发：采取这个小小的行动。它只需几秒，却能让未来的每位读者受益。

各层级的具体指导

Meta（抽象层）

你维护着那些用于维护其他一切的工具。你的维护重点是：技能编写模式的稳定性和清晰度。评估框架一旦变化，下游插件就会受到影响。谨慎变更，详尽记录，严格测试。

Foundation（leyline、sanctum、imbue）

你维护着其他所有插件都依赖的基础设施。你的维护重点是：向后兼容和清晰的迁移路径。更改 leyline 模式时，可能有 15 个插件需要适配。优先采用增量式变更。不可避免地需要破坏性变更时，编写迁移指南。

Utility（conserve、conjure、hookify）

你维护着贡献者每天都会使用的工具。你的维护重点是：用户体验和低使用门槛。 如果钩子令人困惑，贡献者就会禁用它。如果规则噪声过多，贡献者就会忽略它。优化信号，而非数量。

Domain（其他所有插件）

你维护着专业领域知识。你的维护重点是：准确性和易用性。只有当他人能够获取领域知识时，它才有价值。编写示例，而不只是参考资料。随着底层领域的发展，及时更新领域技能。

反思

在自然的工作流节点（完成任务、准备提交、结束会话），使用反思模块，根据五种美德进行简短的自我评估。完整模板请参阅 modules/reflection.md。

退出标准

• 完成任何插件的工作前，检查所有五个“这是一个维护时刻吗？”问题；任何触发的问题都要采取相应的小行动（添加评论、更新 README、修复拼写错误、重新考虑抽象）
• 应用针对各层的指导：基础插件（leyline、sanctum、imbue）采用增量式变更，破坏性变更需附带迁移指南；领域插件应包含示例，而不只是参考资料
• 在提交前完成 modules/reflection.md 中的反思清单；输出针对五项美德（关怀、好奇、谦逊、勤勉、远见）的简短自评
• 未经“七次迭代”测试，不接受任何巧妙的抽象：设计必须经得起七次重大变更