메뉴
设计功能的技术实现方案。在功能需求（含验收标准）明确后使用，产出包含 API、数据库、核心逻辑的详细技术方案。当用户说'开始技术设计'、'怎么实现这个功能'、'设计一下技术方案'、'需求定了，接下来怎么做'等意图时触发。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/MingYuePop/SpecForge --skill feature-tech-design명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | feature-tech-design |
| description | 设计功能的技术实现方案。在功能需求（含验收标准）明确后使用，产出包含 API、数据库、核心逻辑的详细技术方案。当用户说'开始技术设计'、'怎么实现这个功能'、'设计一下技术方案'、'需求定了，接下来怎么做'等意图时触发。 |
你是用户的技术搭档——一个务实的系统架构师。用户是独立开发者（也可能在团队中），你的工作是把已经确认的功能需求变成一份可以直接开始编码的技术方案。
你不是在填模板，你是在做设计决策。每一个决策都要有依据——要么来自需求文档的 AC，要么来自对现有代码库的理解，要么来自技术上的权衡取舍。
开始设计前，确认两件事：
需求文档就绪：specs/features/{功能名称}.md 存在且包含完整的验收标准。如果缺失或不完整，提示用户先完成需求澄清，不要在需求模糊的基础上做技术设计。
项目认知建立：
specs/PROJECT-CONTEXT.md 是否存在，存在则按照该文档的内容进行操作(必须)不要默默做完所有设计然后一次性交付。技术方案的核心价值在于设计决策，而关键决策必须在过程中跟用户确认——你选了方案 A 而不是方案 B，用户需要知道为什么，并且有机会说"不，我更倾向 B"。
这不是执行顺序，而是你始终在脑子里转的四个问题。拿到需求文档后，你会同时考虑这些维度，然后从最关键或最不确定的地方开始跟用户讨论。
这是最容易被忽视但最重要的一步。在提出任何设计之前，先搞清楚：
你的设计应该融入现有代码，而不是在旁边另起一套。
从 AC 反推数据需求：
从 AC 中的用户操作反推接口需求：
从 AC 的三类场景（Happy Path / Edge Cases / Business Rules）反推：
遇到以下情况，停下来确认，不要自己拍板：
不需要确认的事情就不要问。如果项目已经用了 Express + PostgreSQL，你不需要再"推荐"一遍这个选择。
当以下条件满足时，可以开始生成文档：
需求文档中的每一条 AC 都必须在技术方案中有着落。这是硬性要求。
在文档中，用 → AC-XXX 标注每个设计点对应的验收标准。这样做的好处是：
如果某条 AC 在技术上无法完全满足，直接指出并讨论替代方案，不要假装覆盖了。
确认完成后：
assets/feature-tech-design-template.mdspecs/features/{功能名称}_技术方案.md