principle-soc
实现关注点分离，确保不同职责模块化和边界清晰。当需要架构分层设计、模块职责划分、横切关注点处理时使用。覆盖层次分离、功能分离、横切关注点三大维度，提供分离检查清单和耦合问题的诊断修复方法。
principle-solid
应用面向对象设计五大原则（单一职责、开闭、里氏替换、接口隔离、依赖倒置），系统化评审类与模块设计质量。当需要评审架构设计、重构现有代码、审查类职责划分时使用。支持多层次检查清单和违反原则的诊断修复。
principle-yagni
识别并消除过度设计，确保只实现当前明确需要的功能。当需要评审功能范围、重构冗余代码、权衡技术债务时使用。覆盖功能必要性、过度设计信号、技术债务权衡三大维度，提供具体的识别标准和删减建议。
document-quality
多维度审查 Markdown 文档质量，覆盖结构、内容、格式、引用、元数据五大维度。当需要评审文档质量、统一格式规范、验收交付文档时使用。提供分级检查清单、通过标准、常见问题修复指南，支持从快速检查到深度审计的多层次需求。
principle-dry
识别并消除知识重复，确保系统中每条知识有唯一权威表示。当需要重构代码、整理文档、优化配置、建立单一数据源时使用。覆盖代码重复、数据冗余、文档重复三大维度，提供具体消除策略和权衡建议。
principle-invest
评估用户故事质量的六维度框架（独立性、可协商、有价值、可估算、小粒度、可测试），系统化审查需求质量。当需要编写用户故事、评审需求文档、拆分史诗故事时使用。提供分级检查清单和低质量故事的改进建议。
principle-kiss
保持设计和实现的简单性，识别并消除不必要的复杂度。当需要架构设计评审、代码简化重构、接口设计优化时使用。覆盖代码、架构、接口、流程四大维度，提供简单性检查清单和过度复杂性的诊断修复方法。
arch-options-compare
比较多个架构方案（单体/微服务等），从SOLID原则、成本、复杂度等维度评分，生成对比表和推荐方案。当需要向客户解释架构选择或ADR决策时使用。
client-arch-explain
生成客户友好的架构说明（通俗语言解释架构层次、数据流、技术选型），适合演示和评审会议。当准备客户演示或用户验收前使用。
design-consistency-check
检查VS↔SD/DM一致性（value_path是否与序列图/数据模型匹配），生成不一致项清单和修复建议。当Self-Reflection报告一致性问题或准备CONSTRAINT验收前使用。
dev-tech-view-supplement
根据设计补充Dev视角的技术细节（数据库/API/通信协议），帮助Dev快速进入实施。当L1/L2设计缺乏技术细节、或准备向Dev交付前使用。
entry-point-check
验证 VS 的 entry_points 字段是否与 SPEC_PRJ_ENTRYPOINTS（入口类型标签）一致，生成缺失入口清单和补充建议。当准备 CONSTRAINT 验收前使用。
overdesign-detect
检测设计文档中的过度设计（实现细节、技术术语过多），生成过度设计清单和精简建议。当准备CONSTRAINT验收前使用，避免边界合规验收失败。
registry-sync-validator
审计Registry是否与设计artifacts保持一致，生成同步率报告和遗漏清单。当完成设计后、CONSTRAINT验收前使用，避免Registry不一致导致验收失败。
tech-selection-explain
将技术选型决策转换为业务语言解释，生成客户友好的技术说明。当ARCH中技术术语过多、需要向PM/客户解释时使用。
vs-coverage-check
检查每个US是否有对应的VS，生成覆盖率报告和修复建议。当设计文档创建后、CONSTRAINT验收前使用，避免US→VS覆盖率<100%导致验收失败。
constraints-generator
生成ExecSpecMasterConstraints_L*.md权威约束文件，定义Phase/SubPlan/Round命名规范、目录结构、环境策略和质量门禁阈值。当需要创建 ExecSpec Master Plan 的约束文档、定义命名规范、定义质量门禁、定义HITL检查点时使用。
dependency-graph-generator
生成GOAL/SubPlan依赖DAG和关键路径分析，并执行SubPlan划分。当需要分析技术依赖、业务依赖、识别关键路径、发现并行执行机会、执行SubPlan分配时使用。基于GOAL的dependencies字段和业务逻辑分析生成Mermaid依赖图和SubPlan划分方案。
environment-config-generator
生成多环境配置清单和dotenv模板文件，确保dev/test/staging/prod环境配置完整。当需要创建环境配置、生成.env.example模板、文档化测试框架setup、映射CI环境变量时使用。解决dotenv经常被忽视的痛点。
integration-window-planner
规划集成窗口位置和验证策略。当需要在Phase之间或SubPlan之间安排集成窗口、定义集成验证策略、生成集成清单（API契约/数据流/E2E测试）时使用。主要用于L2/L3项目。
progress-tracking
监控执行计划的进度和健康状态，跟踪 SubPlan 完成度和 Round 执行状态，识别阻塞点并同步 Dashboard。当需要检查执行进度、更新 Round 状态、记录阻塞项、生成进度报告、计算进度偏差、分析趋势、预测完成日期时使用。支持资源消耗跟踪、风险状态更新、燃尽图分析和利益相关者报告生成。
risk-buffer-calculator
计算每Phase风险缓冲百分比，基于复杂度、依赖和未知因素进行启发式分析。当需要风险评估、缓冲时间规划、资源预留时使用。主要用于L3项目的严格风险管理。
round-planning
规划Red/Green/Refactor Round节奏，估算Round数量和执行时间。当需要规划TDD周期、估算Round数、分配测试用例到Round、评估执行时长时使用。基于TS数量和复杂度进行启发式估算。
scaffold-analysis
识别项目技术栈、测试框架和环境依赖，为 Compile ExecSpec 提供基础上下文。当需要编译 ExecSpec 前，识别项目类型（Node/Python/Go）、测试框架（Jest/Pytest/RSpec）、环境变量依赖（dotenv/os.getenv）时使用。
code-quality
执行代码质量门禁检查（测试通过→覆盖率→Lint→GOAL追溯→可提交），验证单元测试覆盖率≥80%、集成测试通过率≥95%、代码规范零错误。当完成代码实现、准备提交代码、需要质量验证、进行提交前自检时使用。确保代码可合并。
code-review
执行代码审查流程（提交PR→自查→同行审查→反馈修改→合并），覆盖功能正确性、代码质量、测试完整性、安全合规四大维度。当提交Pull Request、进行结对编程、执行代码走查、需要知识共享时使用。支持L1/L2/L3三级审查深度。
refactoring
执行代码重构（识别坏味道→选择手法→小步修改→运行测试），在保持外部行为不变前提下改进内部结构。当TDD进入REFACTOR阶段、发现代码坏味道、需要消除重复代码、优化代码结构时使用。支持提取方法、类、参数对象等重构手法。
tdd-cycle
执行 TDD 红绿重构循环（RED→GREEN→REFACTOR→REPEAT），通过先写失败测试、最小代码实现、保持绿色重构的节奏驱动开发。当启动功能开发、需要测试驱动节奏、进行迭代编码、追求高测试覆盖率时使用。提供检查清单和节奏控制。
aictxt-manager
生成、维护、修剪AICTXT文档，保持在CRAFT大小限制内。当AICTXT创建和更新时使用。
bdd-scenario-quality-check
检查Given-When-Then格式规范性，发现场景缺口，提供丰富建议。当BDD场景编写完成后使用，确保场景质量符合CRAFT标准。
goal-granularity-check
确保GOAL粒度合理，不过粗或过细。当GOAL创建完成后使用，确保GOAL符合单一职责原则。
goal-sc-coverage-check
检查VS→GOAL→SC覆盖完整性，确保每个VS都有对应的GOAL和SC。当GOAL和SC创建完成后使用，避免覆盖缺口导致验收失败。
goal-traceability-validator
验证GOAL的source_vs追溯链完整性，确保每个GOAL都能追溯到原始VS。当GOAL创建完成后使用。
implementation-sequencer
验证代码构建顺序，分析依赖关键路径，建议Sprint划分和交付优先级。当STRUCT和GOAL确定后使用。
mock-contract-advisor
生成Mock/Stub契约检查清单，enforcing test_suites.md的Mock策略规则。当TS中Mock策略确定后使用。
performance-test-generator
基于NFR性能要求，生成性能测试场景和关键性能指标（KPI）。L3级别专用，当性能需求明确后使用。
project-structure-validator
压力测试STRUCT文件，验证模块化分解的可行性。当项目结构确定后使用，确保模块边界清晰。
registry-consistency-check
审计spec_artifacts_registry.md的Stage 3条目一致性，确保AICTXT/GOAL/SC等都已注册。当IMPLEMENTATION artifact创建完成后使用。
security-test-generator
基于NFR安全要求，生成STRIDE/OWASP威胁模型和测试场景。L3级别专用，当设计和需求确认后使用。
test-pyramid-advisor
分析unit/integration/e2e测试分配比例，建议60/30/10比例平衡。当AICTXT/测试策略确定后使用，优化测试执行效率和覆盖质量。
ac-to-examples
将抽象的Acceptance Criteria（Given-When-Then）转换为具体的数值示例和真实对话，让AC对PM/客户/测试人员更易懂。适合在AC编写完成后、准备测试或向客户展示时使用，当AC格式正确但过于抽象时。帮助不熟悉BDD的PM/BA/测试人员理解测试场景，让AC从抽象规则变成可直接用于手动测试的具体步骤。
acceptance-criteria
检查Acceptance Criteria格式和完整性，验证是否符合Given-When-Then结构、覆盖正常流程/边界条件/异常场景。适合在为User Story编写AC后、准备测试用例前使用，当需要验收AC质量时。帮助不熟悉BDD的PM/BA确保AC明确、可测试、覆盖完整，避免遗漏关键场景。
interview-to-us
将访谈记录、会议纪要、邮件沟通等非结构化内容快速转换为符合CRAFT标准的User Story草稿。适合在需求调研阶段使用，当有大量访谈笔记需要结构化时。帮助不会写US的PM/BA快速上手，从自然语言访谈记录自动提取As-Want-So结构，节省手动整理时间（1小时→10分钟）。
nfr-to-user-impact
将技术性的NFR（非功能需求）约束转换为用户能感知的影响描述，用业务语言解释技术约束的价值。适合在NFR定义完成后、需要向客户或管理层解释时使用，当NFR过于技术化时。帮助不熟悉技术术语的PM/客户/BA理解NFR的业务意义，让技术约束变得亲切易懂。
us-enrich-context
为精炼的User Story增加真实场景描述、用户心理和具体对话，让US对PM/客户更亲切易懂。适合在US初稿完成后、需要向客户展示理解或准备验收时使用，当US格式正确但缺乏场景感时。帮助不熟悉敏捷的PM/BA、需要对外沟通的团队，通过丰富的场景感让需求文档更容易被理解和接受。
us-readability-check
检查User Story是否对非技术人员友好，检测技术术语残留、过于精炼的表达、缺乏场景感等问题。适合在US初稿完成后、准备提交验收前使用，当需要质量检查时。帮助敏捷新手自我检查，知道自己写的US哪里需要改进，给出具体可操作的改进建议。
user-story-format
验证User Story格式和质量，检查是否符合As-I-Want-So三要素结构、角色明确、功能具体、价值清晰。适合在编写新US后、准备Sprint Planning前使用，当需要审核US质量时。帮助不熟悉敏捷的PM/BA识别格式问题、模糊角色、缺失价值等常见问题，确保US可理解、可排序、可开发。
embedded-thinking
提供嵌入式系统软硬件协同思考框架，涵盖硬件层、软件架构、资源约束、实时性、测试调试五大维度。当需要设计嵌入式应用、评审物联网系统、或需要全局视角审视 MCU/MPU 与软件配合时使用。支持裸机/RTOS 选型、功耗优化、内存预算、中断响应、OTA 升级等嵌入式特有场景决策。
microservice-thinking
提供微服务分布式架构思考框架，涵盖服务拆分、通信机制、基础设施、治理策略、可观测性五大维度。当需要设计微服务系统、评审分布式架构、或需要全局视角审视服务边界与协同时使用。支持 DDD 领域建模、同步/异步通信、API Gateway、服务网格、熔断降级等分布式系统关键决策。
mobile-app-thinking
提供移动应用全链路架构思考框架，涵盖技术选型、离线同步、平台适配、性能优化、发布流程五大维度。当需要设计移动 APP、评审客户端架构、或需要全局视角审视原生/跨平台方案时使用。支持 Native/React Native/Flutter、推送通知、数据同步、iOS/Android 双平台等移动端特有场景决策。
Page 1 of 2 · 51 results