القائمة
设计功能的技术实现方案。在功能需求（含验收标准）明确后使用，产出包含 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