在 .NET 项目中编码前做架构感知规划…

适用于 .NET 项目中用户要求 plan/think through/design this/how should I approach，或需要 3 步以上、涉及架构决策、跨多层改动或影响多个调用方的非平凡任务，在编码前产出并确认结构化实现计划。

适用场景

解决思路

1. 在写代码前进入结构化规划模式，先考虑项目架构再产出实现计划，不要直接跳到代码。
2. 识别项目当前架构；如果项目尚未建立架构，则推荐一个合适架构。
3. 将任务映射到受影响的层、模块和边界。
4. 产出带清晰步骤的编号实现计划。
5. 在写任何代码前迭代计划，直到计划足够可靠。
6. 把计划当作活文档：实现过程中如果走偏，停止并重新规划，而不是继续硬推有问题的方案。
7. 检查 docs/specs/ 中是否有覆盖该任务的已批准 spec。
8. 如果存在已批准 spec，以它为唯一事实来源：把它的验收标准映射到计划步骤，然后跳到 Step 2。
9. 如果功能值得写 spec（大到无法用一句话描述）且没有 spec，先推荐 /spec，而不是基于假设进行规划。
10. 如果没有 spec 且功能不够大到需要 spec，用聚焦问题澄清用户想构建什么。
11. 不要假设用户未说明的需求。
12. 使用 architecture-advisor skill 判断项目架构。
13. 检查已有架构标记（文件夹结构、项目引用、模式）。
14. 如果没有建立架构，运行 architecture questionnaire。
15. 加载对应的架构专用 skill（vertical-slice、clean-architecture、ddd）。
16. 识别任务触及的每一层、模块和边界。
17. 确定哪些项目/文件夹会有新建或修改的文件。
18. 检查是否存在横切关注点（认证、缓存、校验、日志）。
19. 确定哪些现有代码会受影响；使用 find_references 和 find_callers MCP 工具评估影响范围（blast radius）。
20. 确定是否需要数据库迁移。
21. 按以下结构输出编号计划：## Plan: [Task Title]；**Architecture:** [Detected architecture]；**Affected layers:** [List]；**Estimated steps:** [Count]；### Steps；1. [Step] -- [Which file/layer] -- [Why this order]；...；### Open Questions；- [Anything that needs user input before proceeding]；### Risks；- [Potential issues and mitigations]。
22. 展示计划并询问：“Does this plan look right, or should I adjust anything?”
23. 根据用户反馈修订计划，直到用户确认。
24. 只有用户确认计划后，才进入实现。
25. 计划批准后，可执行 /scaffold 生成文件。
26. 实现计划后，可执行 /verify 运行验证。

适用边界 · 注意事项

• 单文件修改、简单 bug 修复、拼写错误修正、配置微调等琐碎任务不适用。
• 功能大到无法用一句话描述且没有 spec 时，不要直接规划，应先写 /spec。