Agent skill
principle-yagni
识别并消除过度设计,确保只实现当前明确需要的功能。当需要评审功能范围、重构冗余代码、权衡技术债务时使用。覆盖功能必要性、过度设计信号、技术债务权衡三大维度,提供具体的识别标准和删减建议。
Install this agent skill to your Project
npx add-skill https://github.com/tikazyq/agentic-spec-forge/tree/main/AGENTIC_SPEC_FORGE/spec_stage_skill/common_advanced/principle-yagni
SKILL.md
YAGNI Principle Skill
Scope: COMMON(全阶段通用)
版本: 0.1.0(占位)| 创建日期: 2025-11-27
概述
YAGNI(You Ain't Gonna Need It)是极限编程(XP)的核心原则:
┌─────────────────────────────────────────────────────┐
│ 🎯 YAGNI Principle │
├─────────────────────────────────────────────────────┤
│ "Always implement things when you actually need │
│ them, never when you just foresee that you │
│ need them." │
│ — Ron Jeffries │
└─────────────────────────────────────────────────────┘
检查维度
功能必要性
- 这个功能是当前需求明确要求的吗?
- 是否有用户/业务方确认需要?
- 删除这个功能会影响当前交付吗?
过度设计信号
- 是否为"将来可能需要"而设计?
- 是否有未使用的接口/参数/配置?
- 是否有"以防万一"的代码?
- 是否有过度抽象?
技术债务权衡
- 简单实现 vs 过度设计的成本
- 重构成本 vs 预测性设计成本
- 维护负担 vs 灵活性收益
YAGNI 违反示例
❌ 不好的做法:
- 为"未来扩展"添加未使用的参数
- 创建只有一个实现的接口
- 预留"可能需要"的配置项
- 实现"完整"功能但只用 20%
✅ 好的做法:
- 实现当前需要的最简方案
- 需要时再重构扩展
- 保持代码精简可读
分级检查策略
L1-STREAMLINED
- 检查 3 个核心问题
- 关注明显过度设计
- 通过标准:3 项中 2 项通过(≥67%)
L2-BALANCED
- 检查 6-8 个关键点
- 扫描未使用的代码/接口
- 通过标准:6 项中 5 项通过(≥83%)
L3-RIGOROUS
- 全面检查所有子项(10+ 项)
- 量化未使用代码比例(目标 < 3%)
- 记录技术债务和简化建议
- 通过标准:10 项中 9 项通过(≥90%)
>> 命令
>>yagni_check_l1 # YAGNI 快速检查
>>yagni_unused # 识别未使用的代码/功能
>>yagni_overdesign # 过度设计检测
相关 Skills
- 同类: principle-kiss, principle-dry, principle-soc(设计原则家族)
- 前置: vertical-slice(只实现当前切片需要的)
- 应用: task-breakdown(只分解当前需要的任务)
- 验证: code-review(检查过度设计)
TODO: 待细化过度设计的检测规则
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
code-review
执行代码审查流程(提交PR→自查→同行审查→反馈修改→合并),覆盖功能正确性、代码质量、测试完整性、安全合规四大维度。当提交Pull Request、进行结对编程、执行代码走查、需要知识共享时使用。支持L1/L2/L3三级审查深度。
code-quality
执行代码质量门禁检查(测试通过→覆盖率→Lint→GOAL追溯→可提交),验证单元测试覆盖率≥80%、集成测试通过率≥95%、代码规范零错误。当完成代码实现、准备提交代码、需要质量验证、进行提交前自检时使用。确保代码可合并。
tdd-cycle
执行 TDD 红绿重构循环(RED→GREEN→REFACTOR→REPEAT),通过先写失败测试、最小代码实现、保持绿色重构的节奏驱动开发。当启动功能开发、需要测试驱动节奏、进行迭代编码、追求高测试覆盖率时使用。提供检查清单和节奏控制。
refactoring
执行代码重构(识别坏味道→选择手法→小步修改→运行测试),在保持外部行为不变前提下改进内部结构。当TDD进入REFACTOR阶段、发现代码坏味道、需要消除重复代码、优化代码结构时使用。支持提取方法、类、参数对象等重构手法。
arch-options-compare
比较多个架构方案(单体/微服务等),从SOLID原则、成本、复杂度等维度评分,生成对比表和推荐方案。当需要向客户解释架构选择或ADR决策时使用。
dev-tech-view-supplement
根据设计补充Dev视角的技术细节(数据库/API/通信协议),帮助Dev快速进入实施。当L1/L2设计缺乏技术细节、或准备向Dev交付前使用。
Didn't find tool you were looking for?