Menü
将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
对已实现代码进行纯静态忠实度审查，验证实现是否忠于 PRD、ADR、System Design 与 05_TASKS.md 的既有契约，并识别契约漂移、任务漂移、测试漂移与回流遗漏，作为 challenge 的实现侧证据层。
Generate a persistent .nexus-map/ knowledge base that lets any AI session instantly understand a codebase's architecture, systems, dependencies, and change hotspots. Use when starting work on an unfamiliar repository, onboarding with AI-assisted context, preparing for a major refactoring initiative, or enabling reliable cold-start AI sessions across a team. Produces INDEX.md, systems.md, concept_model.json, git_forensics.md and more. Requires shell execution and Python 4.10+. For ad-hoc file queries or instant impact analysis during active development, use nexus-query instead.
使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。
评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
识别项目中的独立系统，定义系统边界。产出系统架构总览，为后续系统设计奠定基础。
为单个系统设计详细的技术文档。负责架构图、接口设计、数据模型、Trade-offs讨论等。
| name | spec-writer |
| description | 将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。 |
“软件开发最难的部分，不是如何实现，而是精确定义到底要实现什么。”
你的任务是消灭歧义。
references/prd_template.md，然后创建 .specflow/v{N}/01_PRD.md。[ASSUMPTION]。在创建 PRD 之前，你必须：
在创建 PRD 之后，你必须：
5. 执行“10 维歧义扫描”，修复或标记所有 Partial / Missing 项。
6. 验证每条 User Story 都具备：优先级 / 独立可测 / 涉及系统 / 边界情况。
7. 确保 [NEEDS CLARIFICATION] 标签数量 ≤ 3（硬限制）。若超出，则采用合理默认值并加 [ASSUMPTION] 标签。
.specflow/v{N}/01_PRD.mdreferences/prd_template.md：产品需求文档模板。起草 PRD 后，你必须从以下 10 个维度系统性扫描全文。这一步是为了用可重复、可穷尽的方法替代随意的“还有问题吗？”。
对每个维度，标记状态：Clear ✅ / Partial ⚠️ / Missing ❌
| # | 维度 | 检查内容 | 状态 |
|---|---|---|---|
| 1 | 功能范围与行为 | 核心目标 / 成功标准 / 明确排除项 / 用户角色区分 | |
| 2 | 领域与数据模型 | 实体、属性、关系 / 唯一性规则 / 生命周期与状态转换 / 数据规模假设 | |
| 3 | 交互与 UX 流程 | 关键用户路径 / 错误、空状态、加载状态 / 无障碍与 i18n | |
| 4 | 非功能质量 | 性能 / 可扩展性 / 可靠性 / 可观测性 / 安全与隐私 / 合规 | |
| 5 | 集成与外部依赖 | 外部服务失败模式 / 导入导出格式 / 协议版本假设 | |
| 6 | 边界情况与失败场景 | 负向场景 / 限流 / 并发冲突处理 | |
| 7 | 约束与权衡 | 技术约束 / 显式权衡记录 / 被否决的备选架构 | |
| 8 | 术语一致性 | 标准术语表 / 同义词在全文中的统一 | |
| 9 | 完成信号 | 验收标准是否可测 / DoD 是否可量化 | |
| 10 | 占位符与模糊词 | TODO 标记 / 未量化形容词（快、可扩展、安全、直观、健壮） |
规则：
Partial 或 Missing 项，按 影响 × 不确定性 排序，选取前 5 个向用户追问[NEEDS CLARIFICATION] 标签数量硬限制 ≤ 3；若仍超出，则采用合理默认值并加 [ASSUMPTION: ...]PRD 中的每条 User Story，在 PRD 被视为完成前，都必须通过以下检查：
| 检查项 | 要求 |
|---|---|
| 唯一 ID | 必须带 [REQ-XXX] 以便追踪 |
| 优先级 | 标记为 P0 / P1 / P2，且 P0 必须排前 |
| 独立可测 | 说明该故事如何独立演示和验证 |
| 涉及系统 | 列出具体系统 ID（必须与 02_ARCHITECTURE_OVERVIEW.md 对齐） |
| 验收标准 | 至少 1 条 Given-When-Then + 至少 1 个错误场景 |
| 边界情况 | 至少识别 1 个边界条件 |
| 无模糊感觉词 | 不允许出现未量化形容词（如快 → <100ms p99，可扩展 → 支持 N 用户） |
| 用户价值 | 用一句话描述对终端用户的价值 |
若任一 User Story 未通过检查，必须先修复，再交付 PRD。