用途：yagni 是一套在会话中生效的规则，用于约束设计与编码行为，让产出保持简单、清晰、可维护。
主要能力：设计层面要求不过度设计，从代码库和产品层面检查全局一致性、完整性与优化，遵循仓库约定，并在适用时使用 Clean Architecture、YAGNI、DRY、SOLID 和依赖流规则。若更优雅、更 DRY/SOLID、性能更好或更安全的改动有充分理由，可以提出建议，但最终决定权在人。属于产品决策的事项应标记并交回给人。
代码层面要求只写解决问题所需的最少代码，不写推测性内容，不添加请求之外的功能，不为单一用途的代码添加抽象，不添加未请求的灵活性或可配置性，不为不可能发生的场景添加错误处理。只改必要之处，只清理自己改动造成的问题，不顺手改进相邻代码、注释或格式，不重构未损坏的代码，沿用现有风格。优先让代码自解释，必要注释保持简短。若改动导致导入、变量或函数未使用则删除；发现无关死代码应告知人，未经要求不删除。每一行改动都必须与请求直接相关。
写作层面要求使用平实语言，遵循 Chicago Manual of Style 的机械规则，用词简单精确，不使用破折号，不刻意显得聪明，不使用复杂的管理或高管语言，用最少的词保持含义与准确。格式上保持段落简短，步骤和选项用列表，名称、路径和命令用代码格式，粗体只用于少量关键词，列表嵌套不超过两层。链接应写成命名目标的短文本，例如 PR #123，不写裸 URL。图表遵循图表规则。
团队聊天：同样适用写作规则，第一行写要点或请求，注意格式，避免一大段难看的文字，每条消息只谈一个主题，细节链接到文档，使用列表，不使用标题或表格，图表宽度不超过 60 列，否则改为链接，只有对方必须执行动作时才 @ 提及。
限制：资料未提供该规则的安装方式、平台支持、收费或价格信息，也未提供具体使用步骤。