多智能体预调研提示词实战用并行 Discovery 为 Feature Forge 需求规格工作坊注入技术证据【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills导读在 Feature Forge 需求规格工作坊开始之前如果团队对代码库、安全约束和 API 现状一无所知访谈很容易变成一轮又一轮的探索式提问既浪费时间又依赖猜测。本仓库 docs/prompts/discovery-for-feature-forge.md 提供了一份可直接复用的多智能体预调研提示词在访谈前并行启动多个 Task 子智能体各自调用对应技能architecture-designer、security-reviewer、api-designer 等收集技术证据再综合为结构化摘要、提炼关键决策并启动 Feature Forge 访谈。读完本文你将掌握这套提示词的完整结构、按功能类型裁剪智能体组合的方法以及它背后的 ReAct 思维链设计原理并能直接替换功能描述后投入实战。一、为什么需要预调研而非直接访谈Feature Forge 的核心工作流本身分为五个阶段Discover用AskUserQuestions理解目标、Interview系统性提问、Document编写 EARS 格式需求、Validate评审验收标准、Plan生成实现清单——参见 skills/feature-forge/SKILL.md。问题在于当新功能跨越多个领域认证、数据库、UI、外部服务时访谈者对被调研代码库的理解是空白的。此时启动访谈只能提出泛泛的问题无法围绕现有的用户模型怎么设计的当前项目的 API 遵循什么分页约定文件上传有哪些历史安全坑展开有依据的追问。预调研提示词正是为此设计它把探索从访谈阶段前置到访谈之前让子智能体并行收集技术事实访谈只聚焦决策与取舍。这与 Feature Forge 官方参考文档 skills/feature-forge/references/pre-discovery-subagents.md 中描述的前置加载技术上下文模式完全一致——其适用条件包括功能触及 3 个以上系统层、代码库陌生或文档不足、需要先拿到具体技术事实再提问、干系人时间有限需要减少来回沟通。二、提示词全文与逐段拆解以下为仓库中该文档的核心提示词可直接复制使用I need to define a new feature: [FEATURE DESCRIPTION]. Before we start the Feature Forge specification workshop, run parallel discovery across the relevant domains to build technical context. Launch the following Task subagents concurrently — each should invoke its respective skill and return a focused summary: 1. Architecture Discovery — Launch a Task subagent (general-purpose) that invokes the architecture-designer skill to: - Identify which system components this feature touches - Map integration points and data flows - Flag architectural constraints or trade-offs - Recommend patterns that fit the existing system 2. Security Discovery — Launch a Task subagent (general-purpose) that invokes the security-reviewer skill to: - Identify authentication and authorization requirements - Flag data sensitivity concerns (PII, PCI, GDPR) - Surface OWASP-relevant risks for this feature type - Recommend security patterns and controls 3. Codebase Discovery — Launch a Task subagent (Explore) to: - Search for existing patterns, components, or utilities related to this feature - Identify code conventions and abstractions already in use - Find similar features that can serve as implementation templates - Note relevant test patterns and coverage expectations 4. API/Integration Discovery — Launch a Task subagent (general-purpose) that invokes the api-designer skill to: - Propose API surface area (endpoints, methods, payloads) - Identify existing API patterns to follow for consistency - Flag external service dependencies and rate limits - Recommend versioning and backwards-compatibility approach Wait for all subagents to complete, then: 1. Synthesize — Combine the findings into a structured discovery summary with sections for: Architecture, Security, Codebase Patterns, and API Surface. 2. Identify Decisions — List the key decisions that emerged from discovery (e.g., sync vs async processing, new table vs extend existing). Present these as AskUserQuestions with structured options. 3. Launch Feature Forge — With the discovery context and user decisions in hand, invoke the feature-forge skill to begin the specification workshop. The interview should reference discovery findings rather than re-asking questions the subagents already answered.2.1 四路并行的 Discovery 分工提示词定义了四条平行的探索轨道每条轨道对应一个子智能体与一项仓库技能轨道子智能体类型调用技能交付物Architecture Discoverygeneral-purposearchitecture-designer组件影响面、集成点与数据流、架构约束与取舍、适配现有系统的模式建议Security Discoverygeneral-purposesecurity-reviewer认证/授权需求、数据敏感性PII/PCI/GDPR、OWASP 相关风险、安全模式与控制建议Codebase DiscoveryExplore无需技能纯代码检索现有模式/组件/工具、编码约定与抽象、可复用的相似功能模板、测试模式API/Integration Discoverygeneral-purposeapi-designerAPI 表面积端点/方法/负载、需遵循的现有 API 约定、外部服务依赖与限流、版本化与向后兼容策略值得注意的细节Codebase Discovery 使用 Explore 类型的子智能体而非 general-purpose因为它的任务是纯粹的文件系统检索搜索现有模式、约定、模板不需要额外的专家技能层而另外三条轨道都明确要求调用各自技能让架构、安全、API 领域的专家知识进入收集环节。2.2 子智能体技能在仓库中的实际能力提示词引用的三个技能在本仓库中均有完整实现可以从 skills/architecture-designer/SKILL.md、skills/security-reviewer/SKILL.md、skills/api-designer/SKILL.md 中印证各自的必做/必不做约束与输出模板architecture-designer以主架构师视角工作核心工作流是理解需求 → 匹配模式 → 设计显式记录取舍并产出图表→ 用 ADR 记录关键决策 → 干系人评审。它强制要求把技术决策写成 ADR如ADR-001: Use PostgreSQL for Order Storage包含 Status / Context / Decision / Alternatives Considered / Consequences / Trade-offs 六段结构并强制评估权衡而非只讲好处——这与预调研中Flag architectural constraints or trade-offs的要求一一对应。security-reviewer其工作流是 Scope → Scan → Review → Test and classify → Report。预调研阶段子智能体需要产出的是认证授权需求、数据敏感性、OWASP 风险对应它的 Scope 与 Review 阶段而其 MUST DO 中的Check authentication/authorization first先检查认证/授权正是 Security Discovery 轨道的第一项任务。技能自带的 OWASP Top 10、CWE、CVSS 等知识参考域为风险标注提供了标准术语支撑。api-designer其工作流覆盖建模资源 → 设计端点 → 制定契约 → Mock 验证 → 规划演进。预调研要求propose API surface area对应资源建模与端点设计、flag rate limits对应其 MUST NOT DO 中的Omit rate limiting considerations、recommend versioning对应其Version APIs with clear deprecation policies约束。该技能还内置了 OpenAPI 3.1 可复制的端点模板与 RFC 7807 Problem Details 错误响应格式可作为 API Surface 结论的落地骨架。2.3 汇合后的三步收尾提示词明确要求等待所有子智能体完成后再执行三步Synthesize把四路结果合并为结构化的 discovery summary固定包含 Architecture、Security、Codebase Patterns、API Surface 四个小节Identify Decisions列出从 discovery 中涌现的关键决策如同步 vs 异步处理新建表 vs 扩展现有表并用AskUserQuestions以结构化选项呈现给用户——这正是 Feature Forge 的 MUST DO 约束UseAskUserQuestionstool for structured elicitation的体现Launch Feature Forge带着 discovery 上下文与用户决策调用feature-forge技能启动工作坊且访谈必须引用已有发现不再重新问子智能体已经回答过的问题。三、用法基本调用与智能体裁剪3.1 基本调用把[FEATURE DESCRIPTION]替换为功能一句话描述即可。原文档给出的示例I need to define a new feature: user-facing data export that supports CSV and JSON formats with scheduled recurring exports. Before we start the Feature Forge specification workshop, run parallel discovery...替换后四路子智能体将围绕数据导出 CSV/JSON 定时重复导出并行展开架构轨道分析导出任务对现有服务、存储、调度器的影响安全轨道排查数据导出涉及的权限与敏感数据很可能命中 GDPR 的 data portability 需求代码库轨道检索项目里已有的导出工具类或相似实现API 轨道设计导出端点、格式参数与调度接口。3.2 按功能类型裁剪智能体组合并非每个功能都需要全部四条轨道。原文档给出了推荐裁剪表可直接套用功能类型推荐子智能体组合新 UI 功能Codebase Architecture新 API 端点API/Integration Security Codebase数据管道Architecture Security Codebase认证/权限Security Architecture Codebase全栈功能全部四个子智能体这条表的背后逻辑是按功能触碰的领域决定探索深度纯 UI 功能主要依赖代码库检索与架构影响分析无需展开安全与 API 设计而认证/权限功能是安全高风险区Security 必须参与。该思路与 skills/feature-forge/references/pre-discovery-subagents.md 中的When NOT to Use一致——若功能被严格限定在单一领域、或团队已有深度代码库认知、或需求纯属业务/UX 层面可以完全跳过预调研。3.3 预期的输出流程原文档用流程图描绘了从用户输入到最终规格文档的完整链路User provides feature description │ ├─→ [Parallel] Architecture Discovery ──→ Component map, constraints ├─→ [Parallel] Security Discovery ──────→ Auth reqs, data sensitivity ├─→ [Parallel] Codebase Discovery ──────→ Existing patterns, templates └─→ [Parallel] API Discovery ───────────→ Endpoint design, integrations │ ▼ Synthesized Discovery Summary │ ▼ AskUserQuestions: Key decisions from discovery │ ▼ Feature Forge Interview (informed by discovery context) │ ▼ EARS Specification Document终点产物是 EARS 格式的规格文档其结构在 skills/feature-forge/references/specification-template.md 中有完整定义Overview、Functional RequirementsEARS 格式、Non-Functional Requirements、Acceptance CriteriaGiven/When/Then、Error Handling 表、Implementation TODO 清单、Out of Scope、Open Questions。功能需求句式的语法细节Ubiquitous / Event-driven / State-driven / Conditional / Optional 五种模式可参考 skills/feature-forge/references/ears-syntax.md验收标准的 INVEST 标准与错误场景写法可参考 skills/feature-forge/references/acceptance-criteria.md。四、设计原理ReAct × 思维链 × 结构化启发原文档明确指出这份提示词应用了提示工程中经典的ReAct Chain-of-Thought模式ReActReasoning Acting每个子智能体都是推理-行动链上的一环——它调用技能Action、收集发现Observation、再向前传递结果Feed forward。四路子智能体互为对方的观察源最终汇入主智能体的推理过程。Chain-of-ThoughtSynthesize 步骤强制在主智能体进入 Feature Forge 访谈之前显式推理发现之间如何关联。这一步等价于思维链中的中间推理步骤避免拿到零散素材就直接提问的跳跃。结构化启发Structured Elicitation关键决策以AskUserQuestions的形式、携带由技术证据推导出的选项浮出水面而不是空泛地让用户拍脑袋。例如同步 vs 异步这类决策在被子智能体确认数据量级和外部服务限流之后选项就有了依据。这种设计的工程价值在于并行执行降低了总延迟四条轨道并发运行而不是针对每个领域按顺序向用户追问一轮从而压缩了整个 pre-workshop 阶段的时间成本。从实现层面看Feature Forge 的 Interview 阶段同样内置了多智能体预发现模式——skills/feature-forge/references/interview-questions.md 的Multi-Agent Pre-Discovery一节给出了同构的并行模式general-purpose 子智能体调用 architecture-designer / security-reviewerExplore 子智能体检索代码库并提供了 PM Hat 与 Dev Hat 两套提问框架PM Hat 关注问题、用户、价值、范围、成功指标、优先级Dev Hat 关注集成、安全、性能、边界情况、数据、依赖。预调研的输出恰好填充了 Dev Hat 的大部分问题空间。五、落地建议与工作流衔接把预调研提示词当作模板而不是脚本优先按 3.2 节的裁剪表删除无关轨道若功能横跨 3 个以上系统层且代码库陌生可进一步参考 skills/feature-forge/references/pre-discovery-subagents.md 中的用户头像上传示例Architecture 分析用户模型与存储、Security 排查文件上传风险、Framework Expert 查项目端点与存储方式细化每个子智能体的任务描述。定义好聚焦摘要的边界提示词要求每个子智能体return a focused summary避免探索结果变成长篇报告这能显著降低合成阶段的处理负担。与项目 Discovery 阶段的关系本仓库的工作流中还存在独立的 docs/workflow/discovery-phase.md 研究阶段discovery:create→discovery:synthesize→discovery:approve面向访谈中浮现的、需要人类调研用户访谈、竞品分析、技术 spike才能回答的未知项。两者互补本文的提示词解决的是访谈前的代码库技术证据前置而 Discovery 阶段解决的是访谈后仍存疑的业务与技术未知项最终都汇入规格文档与工单创建。从结果反推规格文档Synthesize 生成的 discovery summaryArchitecture / Security / Codebase Patterns / API Surface应当被 Feature Forge 访谈消费而不是存档——访谈中的 Dev Hat 提问集成、安全、性能、边界、数据、依赖可以直接引用其中的证据使最终产出的 EARS 规格文档 skills/feature-forge/references/specification-template.md 中每条功能需求都有代码库或安全分析背书。六、结语多智能体预调研提示词的核心价值在于把猜测替换为证据在 Feature Forge 工作坊开始前通过并行子智能体把架构影响、安全约束、代码库现状和 API 设计一次摸清让访谈专注于真正需要人来拍板的决策点。这套模式融合了 ReAct 的行动-观察循环、思维链的显式综合与AskUserQuestions的结构化启发并且与仓库中 architecture-designer、security-reviewer、api-designer 三个技能的约束和输出模板形成了完整的证据链。直接复制提示词、替换功能描述、按功能类型裁剪轨道即可在当前项目中立即投入使用。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
多智能体预调研提示词实战：用并行 Discovery 为 Feature Forge 需求规格工作坊注入技术证据
多智能体预调研提示词实战用并行 Discovery 为 Feature Forge 需求规格工作坊注入技术证据【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills导读在 Feature Forge 需求规格工作坊开始之前如果团队对代码库、安全约束和 API 现状一无所知访谈很容易变成一轮又一轮的探索式提问既浪费时间又依赖猜测。本仓库 docs/prompts/discovery-for-feature-forge.md 提供了一份可直接复用的多智能体预调研提示词在访谈前并行启动多个 Task 子智能体各自调用对应技能architecture-designer、security-reviewer、api-designer 等收集技术证据再综合为结构化摘要、提炼关键决策并启动 Feature Forge 访谈。读完本文你将掌握这套提示词的完整结构、按功能类型裁剪智能体组合的方法以及它背后的 ReAct 思维链设计原理并能直接替换功能描述后投入实战。一、为什么需要预调研而非直接访谈Feature Forge 的核心工作流本身分为五个阶段Discover用AskUserQuestions理解目标、Interview系统性提问、Document编写 EARS 格式需求、Validate评审验收标准、Plan生成实现清单——参见 skills/feature-forge/SKILL.md。问题在于当新功能跨越多个领域认证、数据库、UI、外部服务时访谈者对被调研代码库的理解是空白的。此时启动访谈只能提出泛泛的问题无法围绕现有的用户模型怎么设计的当前项目的 API 遵循什么分页约定文件上传有哪些历史安全坑展开有依据的追问。预调研提示词正是为此设计它把探索从访谈阶段前置到访谈之前让子智能体并行收集技术事实访谈只聚焦决策与取舍。这与 Feature Forge 官方参考文档 skills/feature-forge/references/pre-discovery-subagents.md 中描述的前置加载技术上下文模式完全一致——其适用条件包括功能触及 3 个以上系统层、代码库陌生或文档不足、需要先拿到具体技术事实再提问、干系人时间有限需要减少来回沟通。二、提示词全文与逐段拆解以下为仓库中该文档的核心提示词可直接复制使用I need to define a new feature: [FEATURE DESCRIPTION]. Before we start the Feature Forge specification workshop, run parallel discovery across the relevant domains to build technical context. Launch the following Task subagents concurrently — each should invoke its respective skill and return a focused summary: 1. Architecture Discovery — Launch a Task subagent (general-purpose) that invokes the architecture-designer skill to: - Identify which system components this feature touches - Map integration points and data flows - Flag architectural constraints or trade-offs - Recommend patterns that fit the existing system 2. Security Discovery — Launch a Task subagent (general-purpose) that invokes the security-reviewer skill to: - Identify authentication and authorization requirements - Flag data sensitivity concerns (PII, PCI, GDPR) - Surface OWASP-relevant risks for this feature type - Recommend security patterns and controls 3. Codebase Discovery — Launch a Task subagent (Explore) to: - Search for existing patterns, components, or utilities related to this feature - Identify code conventions and abstractions already in use - Find similar features that can serve as implementation templates - Note relevant test patterns and coverage expectations 4. API/Integration Discovery — Launch a Task subagent (general-purpose) that invokes the api-designer skill to: - Propose API surface area (endpoints, methods, payloads) - Identify existing API patterns to follow for consistency - Flag external service dependencies and rate limits - Recommend versioning and backwards-compatibility approach Wait for all subagents to complete, then: 1. Synthesize — Combine the findings into a structured discovery summary with sections for: Architecture, Security, Codebase Patterns, and API Surface. 2. Identify Decisions — List the key decisions that emerged from discovery (e.g., sync vs async processing, new table vs extend existing). Present these as AskUserQuestions with structured options. 3. Launch Feature Forge — With the discovery context and user decisions in hand, invoke the feature-forge skill to begin the specification workshop. The interview should reference discovery findings rather than re-asking questions the subagents already answered.2.1 四路并行的 Discovery 分工提示词定义了四条平行的探索轨道每条轨道对应一个子智能体与一项仓库技能轨道子智能体类型调用技能交付物Architecture Discoverygeneral-purposearchitecture-designer组件影响面、集成点与数据流、架构约束与取舍、适配现有系统的模式建议Security Discoverygeneral-purposesecurity-reviewer认证/授权需求、数据敏感性PII/PCI/GDPR、OWASP 相关风险、安全模式与控制建议Codebase DiscoveryExplore无需技能纯代码检索现有模式/组件/工具、编码约定与抽象、可复用的相似功能模板、测试模式API/Integration Discoverygeneral-purposeapi-designerAPI 表面积端点/方法/负载、需遵循的现有 API 约定、外部服务依赖与限流、版本化与向后兼容策略值得注意的细节Codebase Discovery 使用 Explore 类型的子智能体而非 general-purpose因为它的任务是纯粹的文件系统检索搜索现有模式、约定、模板不需要额外的专家技能层而另外三条轨道都明确要求调用各自技能让架构、安全、API 领域的专家知识进入收集环节。2.2 子智能体技能在仓库中的实际能力提示词引用的三个技能在本仓库中均有完整实现可以从 skills/architecture-designer/SKILL.md、skills/security-reviewer/SKILL.md、skills/api-designer/SKILL.md 中印证各自的必做/必不做约束与输出模板architecture-designer以主架构师视角工作核心工作流是理解需求 → 匹配模式 → 设计显式记录取舍并产出图表→ 用 ADR 记录关键决策 → 干系人评审。它强制要求把技术决策写成 ADR如ADR-001: Use PostgreSQL for Order Storage包含 Status / Context / Decision / Alternatives Considered / Consequences / Trade-offs 六段结构并强制评估权衡而非只讲好处——这与预调研中Flag architectural constraints or trade-offs的要求一一对应。security-reviewer其工作流是 Scope → Scan → Review → Test and classify → Report。预调研阶段子智能体需要产出的是认证授权需求、数据敏感性、OWASP 风险对应它的 Scope 与 Review 阶段而其 MUST DO 中的Check authentication/authorization first先检查认证/授权正是 Security Discovery 轨道的第一项任务。技能自带的 OWASP Top 10、CWE、CVSS 等知识参考域为风险标注提供了标准术语支撑。api-designer其工作流覆盖建模资源 → 设计端点 → 制定契约 → Mock 验证 → 规划演进。预调研要求propose API surface area对应资源建模与端点设计、flag rate limits对应其 MUST NOT DO 中的Omit rate limiting considerations、recommend versioning对应其Version APIs with clear deprecation policies约束。该技能还内置了 OpenAPI 3.1 可复制的端点模板与 RFC 7807 Problem Details 错误响应格式可作为 API Surface 结论的落地骨架。2.3 汇合后的三步收尾提示词明确要求等待所有子智能体完成后再执行三步Synthesize把四路结果合并为结构化的 discovery summary固定包含 Architecture、Security、Codebase Patterns、API Surface 四个小节Identify Decisions列出从 discovery 中涌现的关键决策如同步 vs 异步处理新建表 vs 扩展现有表并用AskUserQuestions以结构化选项呈现给用户——这正是 Feature Forge 的 MUST DO 约束UseAskUserQuestionstool for structured elicitation的体现Launch Feature Forge带着 discovery 上下文与用户决策调用feature-forge技能启动工作坊且访谈必须引用已有发现不再重新问子智能体已经回答过的问题。三、用法基本调用与智能体裁剪3.1 基本调用把[FEATURE DESCRIPTION]替换为功能一句话描述即可。原文档给出的示例I need to define a new feature: user-facing data export that supports CSV and JSON formats with scheduled recurring exports. Before we start the Feature Forge specification workshop, run parallel discovery...替换后四路子智能体将围绕数据导出 CSV/JSON 定时重复导出并行展开架构轨道分析导出任务对现有服务、存储、调度器的影响安全轨道排查数据导出涉及的权限与敏感数据很可能命中 GDPR 的 data portability 需求代码库轨道检索项目里已有的导出工具类或相似实现API 轨道设计导出端点、格式参数与调度接口。3.2 按功能类型裁剪智能体组合并非每个功能都需要全部四条轨道。原文档给出了推荐裁剪表可直接套用功能类型推荐子智能体组合新 UI 功能Codebase Architecture新 API 端点API/Integration Security Codebase数据管道Architecture Security Codebase认证/权限Security Architecture Codebase全栈功能全部四个子智能体这条表的背后逻辑是按功能触碰的领域决定探索深度纯 UI 功能主要依赖代码库检索与架构影响分析无需展开安全与 API 设计而认证/权限功能是安全高风险区Security 必须参与。该思路与 skills/feature-forge/references/pre-discovery-subagents.md 中的When NOT to Use一致——若功能被严格限定在单一领域、或团队已有深度代码库认知、或需求纯属业务/UX 层面可以完全跳过预调研。3.3 预期的输出流程原文档用流程图描绘了从用户输入到最终规格文档的完整链路User provides feature description │ ├─→ [Parallel] Architecture Discovery ──→ Component map, constraints ├─→ [Parallel] Security Discovery ──────→ Auth reqs, data sensitivity ├─→ [Parallel] Codebase Discovery ──────→ Existing patterns, templates └─→ [Parallel] API Discovery ───────────→ Endpoint design, integrations │ ▼ Synthesized Discovery Summary │ ▼ AskUserQuestions: Key decisions from discovery │ ▼ Feature Forge Interview (informed by discovery context) │ ▼ EARS Specification Document终点产物是 EARS 格式的规格文档其结构在 skills/feature-forge/references/specification-template.md 中有完整定义Overview、Functional RequirementsEARS 格式、Non-Functional Requirements、Acceptance CriteriaGiven/When/Then、Error Handling 表、Implementation TODO 清单、Out of Scope、Open Questions。功能需求句式的语法细节Ubiquitous / Event-driven / State-driven / Conditional / Optional 五种模式可参考 skills/feature-forge/references/ears-syntax.md验收标准的 INVEST 标准与错误场景写法可参考 skills/feature-forge/references/acceptance-criteria.md。四、设计原理ReAct × 思维链 × 结构化启发原文档明确指出这份提示词应用了提示工程中经典的ReAct Chain-of-Thought模式ReActReasoning Acting每个子智能体都是推理-行动链上的一环——它调用技能Action、收集发现Observation、再向前传递结果Feed forward。四路子智能体互为对方的观察源最终汇入主智能体的推理过程。Chain-of-ThoughtSynthesize 步骤强制在主智能体进入 Feature Forge 访谈之前显式推理发现之间如何关联。这一步等价于思维链中的中间推理步骤避免拿到零散素材就直接提问的跳跃。结构化启发Structured Elicitation关键决策以AskUserQuestions的形式、携带由技术证据推导出的选项浮出水面而不是空泛地让用户拍脑袋。例如同步 vs 异步这类决策在被子智能体确认数据量级和外部服务限流之后选项就有了依据。这种设计的工程价值在于并行执行降低了总延迟四条轨道并发运行而不是针对每个领域按顺序向用户追问一轮从而压缩了整个 pre-workshop 阶段的时间成本。从实现层面看Feature Forge 的 Interview 阶段同样内置了多智能体预发现模式——skills/feature-forge/references/interview-questions.md 的Multi-Agent Pre-Discovery一节给出了同构的并行模式general-purpose 子智能体调用 architecture-designer / security-reviewerExplore 子智能体检索代码库并提供了 PM Hat 与 Dev Hat 两套提问框架PM Hat 关注问题、用户、价值、范围、成功指标、优先级Dev Hat 关注集成、安全、性能、边界情况、数据、依赖。预调研的输出恰好填充了 Dev Hat 的大部分问题空间。五、落地建议与工作流衔接把预调研提示词当作模板而不是脚本优先按 3.2 节的裁剪表删除无关轨道若功能横跨 3 个以上系统层且代码库陌生可进一步参考 skills/feature-forge/references/pre-discovery-subagents.md 中的用户头像上传示例Architecture 分析用户模型与存储、Security 排查文件上传风险、Framework Expert 查项目端点与存储方式细化每个子智能体的任务描述。定义好聚焦摘要的边界提示词要求每个子智能体return a focused summary避免探索结果变成长篇报告这能显著降低合成阶段的处理负担。与项目 Discovery 阶段的关系本仓库的工作流中还存在独立的 docs/workflow/discovery-phase.md 研究阶段discovery:create→discovery:synthesize→discovery:approve面向访谈中浮现的、需要人类调研用户访谈、竞品分析、技术 spike才能回答的未知项。两者互补本文的提示词解决的是访谈前的代码库技术证据前置而 Discovery 阶段解决的是访谈后仍存疑的业务与技术未知项最终都汇入规格文档与工单创建。从结果反推规格文档Synthesize 生成的 discovery summaryArchitecture / Security / Codebase Patterns / API Surface应当被 Feature Forge 访谈消费而不是存档——访谈中的 Dev Hat 提问集成、安全、性能、边界、数据、依赖可以直接引用其中的证据使最终产出的 EARS 规格文档 skills/feature-forge/references/specification-template.md 中每条功能需求都有代码库或安全分析背书。六、结语多智能体预调研提示词的核心价值在于把猜测替换为证据在 Feature Forge 工作坊开始前通过并行子智能体把架构影响、安全约束、代码库现状和 API 设计一次摸清让访谈专注于真正需要人来拍板的决策点。这套模式融合了 ReAct 的行动-观察循环、思维链的显式综合与AskUserQuestions的结构化启发并且与仓库中 architecture-designer、security-reviewer、api-designer 三个技能的约束和输出模板形成了完整的证据链。直接复制提示词、替换功能描述、按功能类型裁剪轨道即可在当前项目中立即投入使用。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考