Preamble (run first)
echo "📊 正在检查前置文档..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
echo "✅ PRD文档 - 已找到"
else
echo "⏳ PRD文档 - 未找到"
fi
if [ -f "docs/02-方案设计/原型设计方案.md" ]; then
echo "✅ 原型设计方案 - 已找到"
else
echo "⏳ 原型设计方案 - 未找到"
fi
Write-time boundaries
When only discussing, do not write files; startup checks do not create directories. When the user requests saving artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmation,only immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md; installing this skill alone also follows this paragraph.
Cross-Agent interaction rules
When the process requires interaction with the user:
- If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
- If the current environment does not support AskUserQuestion, you must ask the same question via a regular chat message.
- Ask only one question at a time.
- After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
- Do not generate documents or write to docs before the user answers.
- Existing docs files cannot substitute for the user's answer in this round.
Execution flow
Step 1: Determine the scope of technical alignment
Use AskUserQuestion to ask:
What kind of technical alignment support do you need?
A) Overall technical solution (tech stack, architecture, third-party services) B) Feature feasibility assessment (assess the difficulty of feature implementation) C) Interface design (API interface planning) D) Performance and scalability (performance requirements, scaling solutions) E) Other (please enter manually)
💡 Tip: Product planning → overall solution, feature design → feasibility assessment, technical review → interface design
Record to variable TECH_SCOPE
Step 2: Read prerequisite data
Required documents: PRD product requirements document, prototype design plan (one of them is required) Optional documents: MVP plan, requirements research report
If the PRD does not exist:
⚠️ PRD document not found
You can choose: A) Run /pm-docs to generate a PRD B) Use the MVP plan as input C) Enter feature requirements manually (quick mode)
Step 3: Extract key requirements
Extract from the PRD: feature list, non-functional requirements (performance/security/compatibility), data requirements Extract from the prototype design: interaction flow, page complexity
Step 4: Technical solution design
4.1 Tech stack recommendation
Based on the product requirements, the following tech stacks are recommended:
Frontend: Option A React+TS+Ant Design / Option B Vue3+TS+Element Plus / Option C Mini Program native Backend: Option A Java+Spring Boot+MySQL / Option B Node.js+Express+MongoDB / Option C Python+Django+PG / Option D Go+Gin+MySQL
Basis for selection: team proficiency, project scale, performance requirements, development cycle
A) Use the recommended solution B) Needs adjustment C) There are existing tech stack constraints
4.2 Architecture design
📐 Recommended architecture solution:
- Frontend layer → Access layer (Nginx) → Application service layer → Data layer
- Core modules: user service, business service, data service
A) The architecture is reasonable, continue B) Needs adjustment C) I have other ideas
Step 5: Feature Feasibility Assessment
5.1 Feature-by-Feature Analysis
Submit the following assessment for each core feature:
📋 {Feature Name}
- Technical Implementation: Frontend solution, backend solution, data storage, third-party dependencies
- Difficulty: ⭐Easy / ⭐⭐Medium / ⭐⭐⭐Complex
- Risk: {Risk Point}
- Suggested Timeline: {Estimated Time}
A) Continue to the next assessment B) This feature needs adjustment C) View all assessment results
5.2 High-Risk Feature Identification
⚠️ High-Risk Feature Summary: List risk items and mitigation plans (alternatives/phased approach/introduce third party)
A) Accept the recommended plan B) Needs further discussion C) Adjust feature requirements to reduce risk
Step 6: API Design
6.1 Core API Planning
🔌 Core API Endpoints:
User Module：POST /api/auth/login, POST /api/auth/register, GET/PUT /api/user/profile Business Module：GET /api/products, GET /api/products/{id}, POST /api/cart, POST /api/orders
Do you need a detailed design for a specific API?
A) Need detailed design B) Already sufficient C) Export in Swagger format
6.2 Detailed API Design (Optional)
Provide detailed design for key APIs: request method, path, request headers, request parameters (JSON Schema), response parameters, error codes
Step 7: Third-Party Service Assessment
7.1 Service Recommendations
🔧 Third-party services: Payment (Alipay/WeChat), SMS (Alibaba Cloud/Tencent Cloud), Maps (Amap/Baidu), Storage (OSS/COS), Push (JPush/Getui)
7.2 Cost Estimation
💰 Cost reference: payment processing fee 0.6-1%, SMS 0.03-0.05 yuan/message, storage {unit price}/GB/month
Subagent Parallel Analysis (New in v2.0)
Before Step 4 (Technical Solution Design), the main agent can dispatch subagents to execute independent analysis tasks in parallel:
使用 Agent 工具并行派发：
Agent 1: 技术栈调研
- 调研各技术栈的社区活跃度、生态成熟度、人才市场
- 输出：技术栈对比报告（JSON）
Agent 2: 成本预估
- 估算开发成本、第三方服务费用、运维成本
- 输出：成本预估明细（JSON）
Agent 3: 风险分析
- 识别技术风险、替代方案、降级策略
- 输出：风险评估矩阵（JSON）
主 agent 等待所有 subagent 完成，整合结果用于技术方案设计。
Version Comparison (v1 vs v2)
| Dimension | v1 (Serial) | v2 (Subagent Parallel) |
|---|---|---|
| Tech Stack Research | Manual analysis by main agent | Parallel research by subagents |
| Cost Estimation | Manual calculation | Automatic calculation by subagents |
| Risk Analysis | Assessed one by one | Parallel assessment by subagents |
| Token Usage | Analysis details occupy the main context | Independent context for subagents |
| Execution Efficiency | Linear sequence | 3x parallel speedup |
Step 8: Output the Technical Integration Plan
Use the Write tool to create docs/02-方案设计/技术对接方案.md。
Refer to the references/output-template.md template and fill in the user input data. Document structure:
- Technical Overview - Product background, technical goals
- Tech Stack Selection - Frontend, backend, development tools
- System Architecture - Overall architecture, core modules
- Feature Feasibility Assessment - Feature list and difficulty, high-risk analysis
- API Design - Specifications, core APIs, detailed design
- Database Design - Core table structure, indexes
- Third-party services - Service list, cost estimates
- Non-functional requirements - Performance, security, availability
- Deployment plan - Deployment architecture, CI/CD
- Project risks and mitigation
- Development schedule recommendations - Phase breakdown, staffing requirements
Fallback mechanism
Scenario: No prerequisite documents
If neither the PRD nor the prototype exists, provide a quick mode for manually entering the feature list.
Notes
- Tech stack recommendations should take into account the team's existing technical expertise
- API design follows RESTful conventions
- Third-party service costs need to be estimated based on actual usage
- For the complete output template, see
references/output-template.md
Output quality comparison
✅ Good example：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad example：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
Common pitfalls / Red Flags — STOP
Stop immediately and backtrack if any of the following occurs:
| Pitfall | Correct approach |
|---|---|
| Drawing conclusions using "should", "probably", "seems" | Must be based on actual data and verification |
| Claiming completion without running checks | Verify first, then state |
| Skipping key steps due to time pressure | No exceptions; the tighter the time, the stricter you must be |
| The thought "it should be fine this time" | Re-verify every time |
Output quality check / Verification Checklist
- Prerequisite dependencies are satisfied (input documents/data have been collected)
- All core steps have been executed
- Output document has been generated to
docs/directory - Every judgment is supported by data/evidence
- 2-3 follow-up skills have been recommended
⚠️ If any item fails → complete it before marking as done.