pm-feature

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

Boundaries when writing

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 confirmationonly 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 normal 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 replace the user's answer in this round.

Execution flow

Step 1: Select the feature(s) to decompose

Which feature would you like to decompose?

A) Decompose all core features (based on the PRD feature list) B) Decompose a single feature (please specify the feature name) C) Decompose all features of a certain module D) Other (please enter manually)

💡 Tip: Development preparation → decompose all, technical review → decompose a single complex feature, project scheduling → decompose a certain module

Record to variable FEATURE_SCOPE

Step 2: Read prerequisite data

Required documents: PRD product requirements document, prototype design plan (one of them is required) Optional documents: technical integration plan, MVP plan

If the PRD does not exist:

⚠️ PRD document not found

A) Run /pm-docs to generate a PRD B) Use the MVP plan as input C) Manually enter feature requirements (quick mode)

Step 3: Feature list extraction

Extract the feature module division, feature requirements list, and priorities from the PRD. Extract page features, interaction features, and state features from the prototype design.

📋 The following feature list was identified based on the PRD:

User module: user registration, login, personal information management Business module: product browsing, search, shopping cart, order management

Decompose all features?

A) Yes, decompose all B) Decompose only some C) Need to adjust the feature list

Step 4: Feature decomposition (feature by feature)

Use the decomposition template for each feature:

4.1 Basic feature information

📝 {Feature name} Feature description: {extracted from PRD} Priority：P0/P1/P2 User value: {what user problem it solves}

4.2 User scenario analysis

🎯 Motivation for use: A) Complete a core task B) Solve a specific problem C) Satisfy an emotional need Usage scenario: A) Daily high frequency B) Low frequency but important C) Occasional scenario

4.3 Feature flow decomposition

Main flow: Preconditions → Operation step sequence (6-12 steps) → Post-operations Branch flows: For each exception scenario: Trigger condition → System handling → User feedback → Follow-up operations

4.4 UI Element Breakdown

🎨 Page structure: Top/main/bottom elements Interactive elements: Input fields (validation rules), buttons (states), lists (pagination) State display: Loading state/empty state/error state

4.5 Data Logic Breakdown

💾 Input data: Field name/type/required/validation rules Data processing: Storage location/update logic/deletion strategy Data validation: Format validation/business validation/permission validation

4.6 Exception Handling

Handling solutions for frontend exceptions (network/validation/timeout) and backend exceptions (parameter/business/system) + boundary conditions

4.7 Technical Implementation Key Points

🔧 Frontend implementation: Component selection, state management, performance optimization Backend implementation: API design, database operations, caching strategy Third-party dependencies: {service name} - {purpose}

4.8 Testing Key Points

Functional testing (normal/abnormal/boundary), performance testing, security testing, compatibility testing

Step 5: Output the feature breakdown document

Use the Write tool to create docs/02-方案设计/功能细节拆解.md。

Refer to the references/output-template.md template, document structure:

Feature list overview - Module division, dependency relationships
Feature breakdown for each module - Complete breakdown of each feature (basic information/scenarios/flows/UI/data/exceptions/technology/testing/schedule)
Appendix - Development task list, technical risk identification

Subagent parallel breakdown (optional)

If there are a large number of features (>5), the Agent tool can be used for parallel breakdown:

Agent 1: 拆解用户模块的所有功能
Agent 2: 拆解业务模块的所有功能
Agent 3: 拆解订单模块的所有功能

每个 subagent 按拆解模板输出到文档对应章节
主 agent 等待所有完成，整合输出最终文档

Fallback mechanism

Scenario: No prerequisite document

Provide a quick mode where the user manually inputs the feature name and description, and the AI automatically breaks it down according to the template.

Notes

The core breakdown template contains 8 dimensions: Basic information → Scenarios → Flows → UI → Data → Exceptions → Technology → Testing
After each feature breakdown is completed, record the development schedule (frontend/backend/third-party/testing)
For the complete output template, see references/output-template.md
For a large number of features, subagents can be used for parallel breakdown to improve efficiency

Output Quality Comparison

✅ Good example：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad example：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

Common Misconceptions / Red Flags — STOP

Stop immediately and backtrack if any of the following occur:

Misconception	Correct approach
Using "should", "probably", "seems" to draw conclusions	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 "this time it should be fine"	Re-verify every time

Recommended next steps

Suggested actions:

/pm-user-story - Break down features into specific user stories
/pm-journey - Draw a user journey map to verify feature coverage
/pm-mvp - Re-examine the MVP scope based on the feature breakdown

Output Quality Check / Verification Checklist

Prerequisite dependencies are satisfied (input documents/data have been collected)
All core steps have been executed
Output documents have been generated to docs/ directory
Every judgment is supported by data/evidence
2-3 follow-up skills have been recommended

⚠️ If any item is not passed → complete it before marking as done.