@laxture/vibe-pm 0.1.0

package/dist/docs/template/large-refactor/flow.md

@@ -0,0 +1,242 @@
+# Large-Scale Refactoring
+
+**Template ID**: `large-refactor`
+**Category**: development
+**Description**: Large-scale code refactoring workflow (Impact assessment → Migration path → Compatibility verification → Integration)
+**Command**: `/pm-large-refactor`
+**Version**: 1.0.0
+
+---
+
+## Applicable Scenarios
+
+- Cross-module architecture adjustments
+- API signature changes
+- Data model migration
+- Refactoring affecting more than 5 files
+
+---
+
+## Input Requirements
+
+| Input Item | Required | Description |
+|--------|------|------|
+| Refactoring goal | Yes | Refactoring motivation, expected outcome |
+| Impact scope estimate | No | Rough estimate of affected files and modules |
+
+---
+
+## Default Deliverables
+
+- Impact scope assessment report
+- Migration path design document
+- Refactored code (with backward compatibility layer)
+- Migration tests
+- Compatibility verification report
+
+---
+
+## State Machine
+
+```mermaid
+stateDiagram-v2
+    [*] --> S1_理解意图: 触发
+    S1_理解意图 --> S2_探索代码
+    S2_探索代码 --> S3_标记影响与风险
+    S3_标记影响与风险 --> S4_渐进式访谈
+    S4_渐进式访谈 --> S4_渐进式访谈: 继续追问
+    S4_渐进式访谈 --> S3_标记影响与风险: 基于澄清答案重新分析
+    S3_标记影响与风险 --> S4_渐进式访谈: 发现新疑问
+    S3_标记影响与风险 --> S5_设计方案与迁移路径: 无更多疑问
+    S5_设计方案与迁移路径 --> S6_审查计划
+    S6_审查计划 --> S5_设计方案与迁移路径: 需修改
+    S6_审查计划 --> S7_编写代码: 通过
+    S7_编写代码 --> S8_编写迁移测试
+    S8_编写迁移测试 --> S9_运行测试修复
+    S9_运行测试修复 --> S9_运行测试修复: 测试失败
+    S9_运行测试修复 --> S10_兼容性验证: 全部通过
+    S10_兼容性验证 --> S11_自查
+    S11_自查 --> S12_用户验收: 通过
+    S11_自查 --> S7_编写代码: 需修复
+    S12_用户验收 --> S13_合流: 通过
+    S12_用户验收 --> S7_编写代码: 需修复
+    S13_合流 --> [*]
+
+    note right of S4_渐进式访谈: ⚠️ 需要用户介入
+    note right of S6_审查计划: ⚠️ 需要用户介入
+    note right of S12_用户验收: ⚠️ 需要用户介入
+```
+
+---
+
+## Task Steps
+
+### S1: Understand Refactoring Intent
+
+**Goal**: Accurately understand the refactoring objective, motivation, and expected outcome.
+
+1. Read the refactoring requirement description
+2. Extract core objectives — What to change? Why change? Expected outcome?
+3. Preliminary scope assessment
+
+**On completion**: Automatically proceed to S2
+
+---
+
+### S2: Explore Existing Code
+
+**Goal**: Gain a thorough understanding of the current state of the affected code.
+
+1. Search all reference points (functions, types, interfaces)
+2. Analyze call chains and dependency relationships
+3. Mark external interfaces that are depended upon
+
+**On completion**: Automatically proceed to S3
+
+---
+
+### S3: Mark Impact Scope and Risks
+
+**Goal**: Systematically assess the blast radius and risks of the refactoring.
+
+1. List all affected files and modules
+2. Assess the impact of breaking changes
+3. Mark high-risk areas (data migration, API compatibility)
+4. Sort by risk level
+5. **Re-analysis after interview**: After returning from S4, re-examine the S3 original marker list based on clarified answers:
+   - Do the clarified answers introduce new impact scopes or risk points?
+   - Are there new conflicts between the clarified conclusions and the existing architecture?
+   - Are there high-risk areas that were not previously marked?
+6. If new questions arise → compile a new question list and return to S4 to continue the interview; if no new questions → proceed to S5
+
+**On completion**: No new questions → automatically proceed to S5; new questions → return to S4
+
+---
+
+### S4: [Human-in-loop] Progressive Interview ⚠️
+
+> **⚠️ This step requires user intervention.** Ask only 1 question at a time.
+
+**Goal**: Clarify ambiguities in refactoring decisions.
+
+1. Use question / confirm to ask questions one at a time
+2. Cover: compatibility strategy, migration window, rollback plan
+
+**On completion**: User confirms "no more questions" → return to S3 for re-analysis
+
+---
+
+### S5: Design Solution and Migration Path
+
+**Goal**: Design a complete refactoring solution and migration plan.
+**Reference Regulation**: coding_style.md, constitution.md
+
+1. Design the new architecture / interfaces / data model
+2. Design the backward compatibility layer (e.g., Adapter / Facade)
+3. Design the migration path (incremental vs big bang)
+4. Mark the deprecation timeline
+
+**On completion**: Automatically proceed to S6
+
+---
+
+### S6: [Human-in-loop] Review Plan ⚠️
+
+**Goal**: User reviews the refactoring plan.
+
+1. Present: impact scope, migration path, compatibility strategy, risks
+2. Use the confirm tool to wait for review
+
+**On completion**: Approved → S7, needs revision → S5
+
+---
+
+### S7: Write Code (Maintaining Backward Compatibility)
+
+**Goal**: Implement the refactoring incrementally following the migration path.
+**Reference Regulation**: coding_style.md, constitution.md
+
+1. Build the compatibility layer first, then modify internal implementation
+2. Run build / type check after each change
+3. Mark deprecated APIs (@deprecated)
+
+**On completion**: Automatically proceed to S8
+
+---
+
+### S8: Write Migration Tests
+
+**Goal**: Write tests covering both old and new behavior.
+**Reference Regulation**: coding_style.md
+
+1. Retain regression tests for old APIs
+2. Add behavioral tests for new APIs
+3. Add compatibility layer tests
+
+**On completion**: Automatically proceed to S9
+
+---
+
+### S9: Run Tests and Fix
+
+**Goal**: All tests pass.
+
+1. Run all tests
+2. Fix failures
+3. Confirm no regressions
+
+**On completion**: All pass → S10
+
+---
+
+### S10: Compatibility Verification
+
+**Goal**: Verify backward compatibility.
+**Reference Regulation**: migration-checklist.md
+
+1. Run tests for callers of old APIs
+2. Verify data format compatibility
+3. Verify configuration file compatibility
+4. Check Deprecation Warning output
+
+**On completion**: Automatically proceed to S11
+
+---
+
+### S11: Self-Check
+
+**Goal**: Comprehensive self-check.
+**Reference Regulation**: checklist.md
+
+1. Is the migration path complete
+2. Does the compatibility layer cover all old APIs
+3. Do tests cover both old and new behavior
+4. Is documentation updated
+
+**On completion**: Pass → S12, needs fixes → S7
+
+---
+
+### S12: [Human-in-loop] User Acceptance ⚠️
+
+**Goal**: User confirms the refactoring results.
+
+1. Present the refactoring report (impact scope, migration path, compatibility)
+2. Use the confirm tool to wait for confirmation
+
+**On completion**: Approved → S13, needs fixes → S7
+
+---
+
+### S13: Integration
+
+**Goal**: Final verification, wrap up documentation, ask whether to commit.
+
+1. Run final build validation and tests
+2. Update Spec and Migration documentation
+3. Use the `question` tool to ask the user: "Execute `git commit`?"
+   - If user selects "Yes": execute `git add -A && git commit`, using the refactoring summary as the commit message
+   - If user selects "No": skip the commit
+   - ⚠️ User choice does not affect task completion
+
+**On completion**: Task ends

package/dist/docs/template/large-refactor/regulations/migration-checklist.md

@@ -0,0 +1,28 @@
+# Large-Scale Refactoring Compatibility Checklist
+
+## Interface Compatibility
+
+- [ ] All legacy APIs remain available (via Adapter / Facade / @deprecated marks)
+- [ ] No data loss or format errors when legacy APIs call new APIs
+- [ ] Deprecation warnings output correctly (if enabled)
+- [ ] New API behavior matches legacy API documentation (or docs have been updated)
+
+## Data Compatibility
+
+- [ ] Legacy data formats can be read normally
+- [ ] New and old data formats can be converted bidirectionally
+- [ ] Database migration scripts are reversible
+- [ ] Config file format is compatible (or migration tool provided)
+
+## Test Coverage
+
+- [ ] All legacy API regression tests pass
+- [ ] New API behavior tests pass
+- [ ] Compatibility layer tests pass (legacy→new call path)
+- [ ] Edge case tests pass (empty data, extreme values, concurrency)
+
+## Migration Path
+
+- [ ] Migration docs updated (steps, timeline, rollback plan)
+- [ ] Callers notified (if external modules or teams are involved)
+- [ ] Deprecation milestones marked (version number + estimated removal date)

package/dist/docs/template/research/flow.md

@@ -0,0 +1,161 @@
+# Research Task
+
+**Template ID**: `research`
+**Category**: research
+**Description**: Research workflow for organizing requirements, design documents, and analysis
+**Command**: `/pm-research`
+**Version**: 1.0.0
+
+---
+
+## Applicable Scenarios
+
+- Organizing requirements, maintaining documentation
+- Research analysis, investigating open-ended questions
+- Designing and writing Spec documents, technical proposals
+
+**Not applicable**: Code implementation, bug fixes.
+
+---
+
+## Input Requirements
+
+| Input Item | Required | Description |
+|------------|----------|-------------|
+| Requirement description / draft / initial idea | Yes | Describe the problem to solve or the goal to achieve |
+
+If the input does not meet requirements, guide the user to supplement before continuing.
+
+---
+
+## Default Deliverables
+
+- Research report / Spec document / Technical proposal
+- If a planning phase is involved, output the plan document to `/docs/plan/[plan]_*.md`
+
+---
+
+## State Machine
+
+```mermaid
+stateDiagram-v2
+    [*] --> S1_Understand_Intent
+    S1_Understand_Intent --> S2_Explore_Known_Facts
+    S2_Explore_Known_Facts --> S3_Mark_Gaps_and_Conflicts
+    S3_Mark_Gaps_and_Conflicts --> S4_Progressive_Interview
+    S4_Progressive_Interview --> S4_Progressive_Interview: Continue probing
+    S4_Progressive_Interview --> S3_Mark_Gaps_and_Conflicts: Re-analyze based on clarified answers
+    S3_Mark_Gaps_and_Conflicts --> S4_Progressive_Interview: New questions found
+    S3_Mark_Gaps_and_Conflicts --> S5_Execution_Phase: No more questions
+    S5_Execution_Phase --> S6_User_Review
+    S6_User_Review --> S5_Execution_Phase: Revisions needed
+    S6_User_Review --> [*]: Approved
+
+    note right of S4_Progressive_Interview
+        ⚠️ Requires user intervention
+    end note
+
+    note right of S6_User_Review
+        ⚠️ Requires user intervention
+    end note
+```
+
+---
+
+## Task Steps
+
+### S1: Understand Input Intent
+
+**Goal**: Accurately understand the core intent of the user's input.
+
+1. Read the user-provided description paragraph by paragraph
+2. Extract the core intent — what problem to solve? What goal to achieve?
+3. Identify covered information and preliminary gaps
+
+**After completion**: Automatically proceed to S2
+
+---
+
+### S2: Explore Related Known Facts
+
+**Goal**: Search for relevant internal and external information to establish a knowledge baseline.
+
+1. Search for existing relevant documents and code within the project
+2. Search for external reference materials (documentation, best practices, open-source implementations)
+3. Document key findings and constraints
+4. Summarize findings to establish a knowledge baseline
+
+**Referenced tools**: explore / librarian Agent (parallel on demand)
+
+**After completion**: Automatically proceed to S3
+
+---
+
+### S3: Mark Information Gaps and Contradictions
+
+**Goal**: Systematically identify all vague, missing, and conflicting areas.
+
+1. Compare input intent with known facts, and mark:
+   - **Missing items**: Key parts of the design that are completely blank
+   - **Vague items**: Descriptions that are not specific enough or contain ambiguity
+   - **Conflicting items**: Places where design intent conflicts with known facts
+2. Prioritize by impact — blocking issues first
+3. Prepare a question-by-question interview list for S4
+4. **Post-interview re-analysis**: After returning from S4, based on clarified answers, re-examine the original S3 marker list:
+   - Do the clarified answers introduce new ambiguities?
+   - Do the clarified conclusions conflict with the existing knowledge baseline?
+   - Are there previously undiscovered missing items?
+5. If new questions found → organize new question list, return to S4 for further interview; if no new questions → proceed to S5
+
+**After completion**: No new questions → automatically proceed to S5; new questions → return to S4
+
+---
+
+### S4: [Human-in-loop] Progressive Interview ⚠️
+
+> **⚠️ This step requires user intervention.** Use `question` / `confirm` blocking tools to ask the user — only one question at a time.
+
+**Goal**: Clarify all vague points and contradictions through sequential questioning.
+
+1. Use `question` / `confirm` blocking tools to ask questions — only one question at a time
+2. Wait for the user's response before asking the next one
+3. If the user's answer leads to a new direction, follow up deeply before returning to the original path
+4. Loop until the user confirms "no further questions need clarification"
+5. **Never** batch multiple questions in plain text
+
+**After completion**: User confirms "no further questions" → return to S3 for re-analysis
+
+---
+
+### S5: Execution Phase
+
+**Goal**: Design the solution based on clarified requirements, execute according to plan, and produce final deliverables.
+
+1. Outline the complete design — modules, interfaces, data flow, edge-case handling
+2. Break down tasks into independently executable and verifiable subtasks, noting dependencies and parallelization opportunities
+3. Execute subtasks in the planned order to produce the final deliverable (research report / Spec document / technical proposal)
+4. Mark tasks with `[P]` for parallel processing; update progress after completing each subtask
+5. Consolidate all outputs and prepare for user review
+
+**After completion**: Automatically proceed to S6
+
+---
+
+### S6: [Human-in-loop] User Review Output ⚠️
+
+> **⚠️ This step requires user intervention.** The user reviews the final output and confirms before merging.
+
+**Goal**: User reviews the final research output and confirms that deliverables meet requirements.
+
+1. Present a summary of the final output (key content and conclusions of the report / Spec / proposal)
+2. Use the `confirm` tool to wait for user review and approval
+3. After approval, use the `question` tool to ask the user: "Execute `git commit`?"
+   - If the user selects "Yes": run `git add -A && git commit`, using the research summary as the commit message
+   - If the user selects "No": skip the commit
+   - ⚠️ The user's choice does not affect task completion
+
+**State transitions**:
+- User approves → merge and end
+- User requests revisions → return to S5
+
+**After completion**: Task ends

package/dist/docs/template/side-job/flow.md

@@ -0,0 +1,147 @@
+# Quick Turnaround Tasks
+
+**Template ID**: `side-job`
+**Category**: side-job
+**Description**: Quick turnaround task flow — LLM must confirm the plan with the user before execution
+**Command**: `/pm-side-job`
+**Version**: 1.0.0
+
+---
+
+## Applicable Scenarios
+
+- Independent small tasks with clear intent that don't require deep research
+- One-off modifications, config adjustments, small-scale refactoring, script writing, etc.
+- Users expect the LLM to think through a plan and get confirmation before taking action
+
+**Not applicable**: Complex architecture design, bug fixes requiring root cause analysis, large-scale refactoring.
+
+---
+
+## Input Requirements
+
+| Input Item | Required | Description |
+|------------|----------|-------------|
+| Task Description | Yes | What to do, and the expected outcome |
+
+If the input does not meet requirements, guide the user to supplement before continuing.
+
+---
+
+## Default Deliverables
+
+- Complete the task described by the user
+- If code changes are involved, pass LSP diagnostics and build verification
+
+---
+
+## State Machine
+
+```mermaid
+stateDiagram-v2
+    [*] --> S1_UnderstandIntent: Trigger
+    S1_UnderstandIntent --> S2_ConfirmPlan
+    S2_ConfirmPlan --> S1_UnderstandIntent: User requests revision
+    S2_ConfirmPlan --> S1_UnderstandIntent: Plan is infeasible, needs re-analysis
+    S2_ConfirmPlan --> S3_Execute: User confirms approval
+    S3_Execute --> S4_AcceptanceIntegration
+    S4_AcceptanceIntegration --> S3_Execute: Modifications needed
+    S4_AcceptanceIntegration --> [*]: Passed
+
+    note right of S2_ConfirmPlan
+        ⚠️ Requires user intervention
+    end note
+
+    note right of S4_AcceptanceIntegration
+        ⚠️ Requires user intervention
+    end note
+```
+
+---
+
+## Task Steps
+
+### S1: Understand Intent
+
+**Goal**: Accurately understand what the user wants to do, and analyze feasible approaches.
+
+1. Read the user's description, extract the core task and constraints
+2. Read relevant source code and documentation as needed (using the read tool directly)
+3. Search for related files within the project to understand existing patterns (using explore agent for parallel searches)
+4. If the description is unclear or information is insufficient, use the `question` / `confirm` tools to follow up
+5. Consider 2-3 feasible approaches, evaluate each in terms of scope of changes, risk, and impact
+6. Select the recommended approach, ready to present in S2
+
+**Note**: **Do not** edit, create, or delete any files during this step.
+
+**On completion**: Automatically proceed to S2
+
+---
+
+### S2: [Human-in-loop] Confirm Execution Plan ⚠️
+
+> **⚠️ This step requires user intervention.** The LLM presents the execution plan and uses the `confirm` / `question` tools to wait for the user's **explicit confirmation** before proceeding.
+
+**Goal**: Present the execution plan to the user and obtain explicit confirmation.
+
+1. Call `pm_task_set_step(step="S2")` to declare entry into this step
+2. Present the execution plan, including at minimum:
+   - **Task Understanding**: A one-sentence summary of what to do
+   - **Execution Steps**: Which specific files to modify, what changes to make (order and dependencies)
+   - **Scope of Impact**: Modules or features that may be affected
+   - **Risk Points**: Areas to watch out for (if any)
+3. ⚠️ Use the `confirm` / `question` tools to wait for the user's explicit confirmation:
+   - **Must** receive a **strongly affirmative** instruction such as "confirmed / agree / approved / no problem / OK / go ahead / LGTM" before proceeding
+   - Vague or weakly affirmative language ("looks doable", "give it a try", "mm", "should be fine") is treated as **unconfirmed** — must follow up with the user for a clear stance
+   - User silence is treated as **unconfirmed** — do not proceed on your own
+4. **Strictly prohibited** from performing any code modifications, file edits, or todo creation before receiving explicit confirmation
+5. If the user requests plan adjustments → return to S1 for re-analysis (or revise in place at this step and re-confirm)
+
+**State transitions**:
+- User explicitly confirms → S3
+- User requests revisions → return to S1 (re-analyze the plan)
+- Plan adjusted with simple changes and re-confirmed → stay at S2 to continue confirmation
+
+**On completion**: User explicitly confirms → proceed to S3
+
+---
+
+### S3: Execute
+
+**Goal**: Execute the task according to the confirmed plan.
+
+1. Call `pm_task_set_step(step="S3")` to declare entry into this step
+2. Create a todo list (if the task involves multiple sub-steps)
+3. Strictly follow the plan confirmed in S2:
+   - Only modify files listed in the plan
+   - Do not introduce changes outside the plan
+   - Follow the project constitution's "Code Quality First" principle
+4. Update todo status upon completing each sub-step
+5. After completion, run project build / type check / LSP diagnostics for verification
+
+**On completion**: Automatically proceed to S4
+
+---
+
+### S4: [Human-in-loop] Acceptance & Integration ⚠️
+
+> **⚠️ This step requires user intervention.** The user reviews the execution results and confirms integration.
+
+**Goal**: User accepts the final deliverable and confirms completion.
+
+1. Call `pm_task_set_step(step="S4")` to declare entry into this step
+2. Present an execution summary:
+   - Which files were modified
+   - What changes were made (diff summary)
+   - Verification results (build / type check / LSP diagnostics passed or not)
+3. Use the `confirm` / `question` tools to wait for the user's acceptance confirmation
+4. After acceptance, use the `question` tool to ask the user: "Proceed with `git commit`?"
+   - If the user chooses "Yes": run `git add -A && git commit`, using the task summary as the commit message
+   - If the user chooses "No": skip the commit
+   - ⚠️ The user's choice does not affect task completion
+
+**State transitions**:
+- User approves → integration complete
+- User requests modifications → return to S3
+
+**On completion**: Call `pm_task_close()` to end the task and trigger analysis