@laxture/vibe-pm 0.1.0

package/dist/docs/template/bug-fix/flow.md

@@ -0,0 +1,189 @@
+# Bug Fix
+
+**Template ID**: `bug-fix`
+**Category**: maintenance
+**Description**: Standardized bug fix workflow (root cause analysis → fix → regression → acceptance)
+**Command**: `/pm-bug-fix`
+**Version**: 1.0.0
+
+---
+
+## Applicable Scenarios
+
+- Bug fixes in production or development environments
+- Non-trivial fixes requiring root cause analysis
+
+---
+
+## Input Requirements
+
+| Input | Required | Description |
+|--------|------|------|
+| Bug Description | Yes | Symptoms, reproduction steps, impact scope |
+| Related Code/Logs | No | Information to help locate the issue |
+
+---
+
+## Default Deliverables
+
+- Root cause analysis report
+- Fix code + regression tests
+- Delivery report
+
+---
+
+## State Machine
+
+```mermaid
+stateDiagram-v2
+    [*] --> S1_UnderstandingBug: Trigger
+    S1_UnderstandingBug --> S2_RootCauseAnalysis
+    S2_RootCauseAnalysis --> S3_ReviewPlan
+    S3_ReviewPlan --> S2_RootCauseAnalysis: Needs revision
+    S3_ReviewPlan --> S4_WriteFix: Approved
+    S4_WriteFix --> S5_WriteTests
+    S5_WriteTests --> S6_RegressionVerification
+    S6_RegressionVerification --> S7_SelfCheck
+    S7_SelfCheck --> S8_UserAcceptance: Pass
+    S7_SelfCheck --> S4_WriteFix: Needs fix
+    S8_UserAcceptance --> S9_Merge: Pass
+    S8_UserAcceptance --> S4_WriteFix: Needs fix
+    S9_Merge --> [*]
+
+    note right of S3_ReviewPlan: ⚠️ Human-in-loop
+    note right of S8_UserAcceptance: ⚠️ Human-in-loop
+```
+
+---
+
+## Task Steps
+
+### S1: Understand the Bug
+
+**Goal**: Accurately understand the bug symptoms, reproduction conditions, and impact scope.
+
+1. Read the bug description, logs, and screenshots
+2. Confirm reproduction steps
+3. If the description is unclear, use the `question` tool to ask for clarification
+4. Assess impact scope (functionality, data, security)
+
+**On completion**: Automatically advance to S2
+
+---
+
+### S2: Root Cause Analysis
+
+**Goal**: Identify the root cause and propose a fix plan.
+
+1. Read relevant source code
+2. Trace the call chain
+3. Analyze and identify the root cause
+4. Analyze test case coverage:
+   - Search for existing test cases related to the affected code (`{affected_module}_test.go`)
+   - Determine whether existing tests cover this abnormal path:
+     - If **covered**, explain why the existing tests did not catch this bug (assertions not precise enough? mock data too ideal? tests skipped?)
+     - If **not covered**, describe which test scenario is missing
+   - Determine whether new or modified test cases are needed after the fix
+5. Propose a fix plan: follow the project constitution's "Code Quality First" principle — strive for elegance, directness, and readable, maintainable code
+
+```markdown
+## Root Cause Analysis
+
+- **Symptom**: {what the user observed}
+- **Trigger Condition**: {under what conditions it triggers}
+- **Root Cause**: {code-level reason for the failure, citing specific file and line numbers}
+- **Impact Scope**: {which features / which users are affected}
+
+
+```
+
+**On completion**: Automatically advance to S3
+
+---
+
+### S3: [Human-in-loop] Review Fix Plan ⚠️
+
+**Goal**: User reviews the fix plan.
+
+1. Present: root cause, fix plan, alternatives, risk assessment
+2. Use the `confirm` tool to wait for confirmation
+
+**On completion**: Approved → S4, Needs revision → S2
+
+---
+
+### S4: Write the Fix
+
+**Goal**: Write the fix according to the approved plan.
+**Referenced Regulation**: coding_style.md
+
+1. Minimal fix — only change the root cause code
+2. Do not introduce unrelated refactoring
+3. Run project build / type check to verify
+
+**On completion**: Automatically advance to S5
+
+---
+
+### S5: Write Tests
+
+**Goal**: Write regression tests to prevent recurrence.
+**Referenced Regulation**: coding_style.md
+
+1. Cover the reproduction scenario
+2. Cover edge cases
+3. Cover related functionality (prevent side effects)
+
+**On completion**: Automatically advance to S6
+
+---
+
+### S6: Regression Verification
+
+**Goal**: Confirm the fix is effective and there is no regression.
+
+1. Run all tests
+2. Verify the original bug scenario no longer reproduces
+3. Check that related functionality works correctly
+
+**On completion**: Automatically advance to S7
+
+---
+
+### S7: Self-Check
+
+**Goal**: Thoroughly self-review fix quality.
+**Referenced Regulation**: checklist.md
+
+1. Does the fix comply with the code quality first principle?
+2. Do all tests pass?
+3. Have any new issues been introduced?
+4. Does documentation need updating?
+
+**On completion**: Pass → S8, Needs fix → S4
+
+---
+
+### S8: [Human-in-loop] User Acceptance ⚠️
+
+**Goal**: User confirms the fix result.
+
+1. Present the fix report (root cause, changes, test results)
+2. Use the `confirm` tool to wait for confirmation
+
+**On completion**: Approved → S9, Needs fix → S4
+
+---
+
+### S9: Merge
+
+**Goal**: Final verification, wrap-up documentation, ask whether to commit.
+
+1. Run final build check and tests
+2. Update Spec and Plan documents (if needed)
+3. Use the `question` tool to ask the user: "Execute `git commit`?"
+   - If the user selects "Yes": run `git add -A && git commit`, using the fix summary as the commit message
+   - If the user selects "No": skip commit
+   - ⚠️ User selection does not affect task completion
+
+**On completion**: Task ends

package/dist/docs/template/constitution-template.md

@@ -0,0 +1,119 @@
+# {PROJECT_NAME} Project Constitution
+
+**Version**: 1.0.0 | **Ratified**: {DATE} | **Last Amended**: {DATE}
+
+---
+
+## Core Principles
+
+### I. Flow + Spec + Test-Driven Development
+
+All three are indispensable:
+
+- **Flow** — Ensures team alignment. Structured step transitions eliminate ambiguity, giving every participant a shared understanding of "what to do and where we are."
+- **Spec** — Captures technical decisions. Solidifies architecture choices, interface contracts, and boundary conditions into documents, preventing information loss from word-of-mouth.
+- **Test** — Guarantees delivery quality. Defines "done" in verifiable terms, so regressions are caught immediately.
+
+Execution:
+
+- All changes require a written plan and my confirmation before implementation.
+- Use `/pm-{flow}` commands to start tasks (e.g., `/pm-bug-fix`, `/pm-research`); the plugin manages step transitions.
+- After each code change, ensure the corresponding Spec document is updated.
+
+### II. Type Safety (NON-NEGOTIABLE)
+
+- When using strongly-typed languages, type escape mechanisms are forbidden.
+- Interfaces defined at the consumer side; accept interfaces, return concrete types.
+- All errors must be handled explicitly (propagate / wrap / handle / terminate).
+
+### III. Verification Mandatory
+
+All code changes must pass three layers of verification:
+
+1. **LSP Diagnostics**: `lsp_diagnostics` on changed files must have zero errors.
+2. **Build**: Project build command must exit with code 0.
+3. **Tests**: Test suite must pass fully (or pre-existing failures explicitly noted).
+
+**Forbidden**: Skipping tests, deleting failing tests to "pass", or claiming "it should work" without verification.
+
+### IV. Mermaid Diagrams Preferred
+
+All architecture, flow, state, and sequence diagrams **must use Mermaid**.
+
+- **Forbidden**: ASCII art diagrams.
+- Supported: `graph`, `sequenceDiagram`, `stateDiagram`, `classDiagram`, `flowchart`, etc.
+- If Mermaid cannot express something (e.g., complex UI layouts), text descriptions are allowed as an exception.
+
+### V. Code Quality First
+
+Every code change should strive for elegance and go straight to the heart of the problem. Code must be readable and maintainable.
+
+- Readers matter more than writers — write once, read a hundred times.
+- Clean up code smells as you go — if you see room for improvement nearby, improve it.
+- Abstraction must have clear benefit — abstract for readability, testability, reusability.
+- Naming is documentation — express intent through clear naming.
+- Don't add error handling for "impossible" scenarios — only validate at system boundaries (user input, external APIs).
+
+### VI. Language Principle
+
+- Code comments and identifiers use the interactive language.
+- Logs use English (for tool compatibility).
+
+### VII. Respect External Changes
+
+1. If you detect code modified externally (by tools or user), ask the user how to handle it (keep or revert) before overwriting.
+2. If the user explicitly states "I manually modified the code", you must first read and understand the purpose. Without explicit consent, never modify or revert refactored code.
+3. If external changes introduce verifiable issues (test failures, type errors), ask for consent before adjusting.
+
+### VIII. Rational Pushback
+
+If the user's request is unreasonable or technically infeasible, you must firmly explain:
+
+- What is unreasonable.
+- Why it cannot be done.
+- Suggested alternatives.
+
+Never flatter or forcefully execute unreasonable demands.
+
+### IX. Failure Transparency
+
+If you attempt a solution and it fails, or roll back after multiple attempts, you must clearly state:
+
+- What approach was attempted.
+- Why it failed.
+- Current code state (whether rolled back to safe state).
+
+Never pretend a problem is solved or obscure failure with vague language.
+
+---
+
+## Additional Constraints
+
+### Directory Constraints
+
+```
+/docs/flow/         — Flow definitions (do not modify casually; changes follow process)
+/docs/regulation/   — Constitution, coding style, checklists, dictionary
+/docs/spec/         — Program specifications
+/docs/plan/         — Task plans
+```
+
+### Zero Tolerance
+
+| Violation | Handling |
+|-----------|----------|
+| Type escape (`any` / `@ts-ignore`) | Must rewrite |
+| Skipping requirement clarification and implementing directly | Revert all changes |
+| Deleting failing tests to "pass" | Restore tests + fix root cause |
+| Mixing refactoring into bug fixes | Split into separate tasks |
+| Overwriting user refactored code without consent | Revert + understand intent first |
+| Forcefully executing known-infeasible requests | Revert + explain why infeasible |
+| Pretending problems are solved after failure | Clearly state real status + roll back |
+
+---
+
+## Rule Change Management
+
+### Conflict Resolution
+
+Constitution overrides specific rules; specific rules override verbal conventions.

package/dist/docs/template/design-spec/flow.md

@@ -0,0 +1,194 @@
+# Spec Design
+
+**Template ID**: `design-spec`
+**Category**: design
+**Description**: Progressive design workflow from requirements to Spec documents (understand / explore / interview / design / review, 6 steps)
+**Command**: `/pm-design-spec`
+**Version**: 1.0.0
+
+---
+
+## Applicable Scenarios
+
+- Designing a Spec document for a new feature from scratch
+- Translating vague requirements into structured design specifications
+- Complex design tasks requiring multiple rounds of user interviews to clarify
+
+**Not applicable**: Incremental modifications to an existing Spec (use spec-driven-dev); pure code research (use research).
+
+---
+
+## Input Requirements
+
+| Input Item | Required | Description |
+|------------|----------|-------------|
+| Requirement Description | Yes | Feature concept, problem statement, goal summary |
+| Constraints | No | Known technical/business constraints |
+
+---
+
+## Default Deliverables Checklist
+
+- Spec document (format reference: `docs/template/spec-template.md`)
+- Research notes or decision records if necessary
+
+---
+
+## State Machine
+
+```mermaid
+stateDiagram-v2
+    [*] --> S1_Understand_Requirements
+    S1_Understand_Requirements --> S2_Explore_Known_Facts
+    S2_Explore_Known_Facts --> S3_Identify_Gaps_and_Contradictions
+    S3_Identify_Gaps_and_Contradictions --> S4_Progressive_Interview
+    S4_Progressive_Interview --> S4_Progressive_Interview: Continue follow-up
+    S4_Progressive_Interview --> S3_Identify_Gaps_and_Contradictions: Re-analyze based on clarified answers
+    S3_Identify_Gaps_and_Contradictions --> S4_Progressive_Interview: New questions discovered
+    S3_Identify_Gaps_and_Contradictions --> S5_Design_Phase: No further questions
+    S5_Design_Phase --> S6_User_Review_Output
+    S6_User_Review_Output --> S5_Design_Phase: Revisions needed
+    S6_User_Review_Output --> [*]: Approved
+
+    note right of S4_Progressive_Interview
+        ⚠️ Requires user intervention
+    end note
+
+    note right of S6_User_Review_Output
+        ⚠️ Requires user intervention
+    end note
+```
+
+---
+
+## Task Steps
+
+### S1: Understand Requirements
+
+**Goal**: Accurately understand the core intent and expected output of the user's input.
+
+1. Read the user-provided requirement description section by section
+2. Extract the core intent — what problem to solve? What goal to achieve?
+3. Preliminarily identify what is already clear in the requirements and what remains vague
+4. Confirm the output scope — is it a complete Feature Spec, system design, or a design for a specific module?
+
+**Upon completion**: Automatically proceed to S2
+
+---
+
+### S2: Explore Known Facts
+
+**Goal**: Search for internal and external project-related information to establish the knowledge baseline needed for design.
+
+1. Search for existing relevant documents, code, and specs within the project (using explore agent in parallel)
+2. Search for external references — best practices, open-source implementations, technical documentation (using librarian agent)
+3. Record key findings:
+   - Constraints and capability boundaries of the existing system
+   - Reusable modules or interfaces
+   - Known technical limitations or dependencies
+4. Summarize findings and establish a knowledge baseline — serving as the foundation of "known facts" for subsequent design
+
+**Reference tools**: explore / librarian Agent (in parallel as needed)
+
+**Upon completion**: Automatically proceed to S3
+
+---
+
+### S3: Identify Gaps and Contradictions
+
+**Goal**: Systematically identify all vague, missing, or conflicting design points.
+
+1. Cross-reference the input requirements with the S2 knowledge baseline to flag three categories of issues:
+   - **Missing items**: Core parts that are completely absent from the design
+   - **Ambiguous items**: Content with insufficient specificity or inherent ambiguity
+   - **Contradictory items**: Areas where the requirement intent conflicts with known facts
+2. Sort by impact — prioritize blocking issues (gaps that will affect subsequent design decisions first)
+3. Prepare a per-question interview list for S4 — each question should be focused and answerable
+4. **Post-interview re-analysis**: After returning from S4, re-examine the original S3 flagged list based on the clarified answers:
+   - Do the clarified answers introduce new ambiguities?
+   - Do the clarified conclusions conflict with the existing knowledge baseline?
+   - Are there newly discovered missing items that were previously unnoticed?
+5. If new questions are discovered → organize a new question list and return to S4 to continue interviewing; if no new questions → proceed to S5
+
+**Upon completion**: No new questions → automatically proceed to S5; new questions exist → return to S4
+
+---
+
+### S4: [Human-in-loop] Progressive Interview ⚠️
+
+> **⚠️ This step requires user intervention.** Use `question` / `confirm` blocking tools to ask the user — only 1 question at a time.
+
+**Goal**: Clarify all ambiguous and contradictory points through per-question interviewing.
+
+1. Use `question` / `confirm` blocking tools to issue questions — only 1 question at a time
+2. Wait for the user's reply before asking the next question
+3. If the user's answer leads to a new direction, follow up deeply before returning to the original route
+4. Loop until the user confirms "there are no other questions that need clarification"
+5. Before concluding the interview, estimate the Spec coverage scope based on the clarified requirements:
+   - If the scope is clearly too large (involving 3 or more independent modules/subsystems), suggest adopting a decomposed design
+   - Use the `question` tool to ask the user: "This Spec has a relatively large scope (involving {N} modules). Would you like to adopt a decomposed design — producing one overview Spec + multiple detailed design Specs for independent features?"
+   - If the user agrees → mark "S5 will use decomposed design"; if they disagree → proceed with the conventional single-document design
+6. **Never** batch multiple questions in plain text
+
+**Upon completion**: User confirms "no further follow-up" → return to S3 for re-analysis
+
+---
+
+### S5: Design Phase
+
+**Goal**: Based on the clarified requirements, produce a structured Spec document.
+
+1. Consolidate all information from S1–S4:
+   - Clear requirement background and goals
+   - Key decisions and clarification results from user interviews
+   - Technical constraints and known facts collected in S2
+2. Populate each section following the organizational structure of `docs/template/spec-template.md`:
+   - Requirement background
+   - Use cases and user stories (annotated with priority P1/P2/P3)
+   - Design points (domain model, critical paths, conditional branches, interface design, configurable items)
+   - Edge cases and error scenarios
+   - Constraints and limitations (technical constraints, business constraints, known risks, scope of impact)
+3. If the user chose decomposed design in S4:
+   - Produce an overview Spec (master Spec), where "Design Points" only describes the module layering architecture and inter-module interfaces
+   - Produce independent detailed design Specs (full sections) for each independent feature
+   - Save sub-Specs to the `/docs/spec/{parent-feature}/` directory, with file naming `spec-{feature-name}.md`
+   - Use a "Decomposition Index" table in the master Spec to reference each detailed design Spec
+4. Output the Spec document(s):
+   - Conventional design → `/docs/spec/{feature-name}.md`
+   - Decomposed design → master Spec saved as `/docs/spec/{feature-name}/spec-{feature-name}.md`, sub-Specs saved to the same directory
+5. For sections not applicable to the current design, mark "Not Applicable" while retaining the skeleton
+6. Note any open items still pending decision in the design (if any)
+
+**Reference document**: `docs/template/spec-template.md`
+
+**Upon completion**: Automatically proceed to S6
+
+---
+
+### S6: [Human-in-loop] User Review Output ⚠️
+
+> **⚠️ This step requires user intervention.** The user reviews the Spec document and confirms it to complete.
+
+**Goal**: The user reviews the Spec document and confirms that the design meets the requirements.
+
+1. Present a Spec document summary — core design decisions, key user stories, major constraints and risks
+2. Use the `confirm` tool to wait for the user's overall review approval of the Spec
+3. After approval, use the `question` tool to ask the user: "Run `git commit`?"
+   - If the user selects "Yes": execute `git add -A && git commit`, using the summary of this Spec design as the commit message
+   - If the user selects "No": skip the commit
+   - ⚠️ The user's choice does not affect task completion
+
+> ⚠️ **Important**: Spec design ends at S6. The deliverable of this workflow is the Spec document — it does **not** enter code implementation. For subsequent implementation, start an independent task via `/pm-spec-driven-dev` or `/pm-new-feature`. To decompose the Spec into a step-by-step plan, use `/pm-plan`.
+
+**State transitions**:
+- User approves → merge and end
+- User requests modifications → return to S5
+
+**Upon completion**: Task ends
+
+---
+
+> **Design Principles**:
+> - **Precision over quantity**: The Spec only contains confirmed information; uncertain items are marked as "Pending Decision"
+> - **LLM-driven transitions**: The model decides state transitions based on user feedback
+> - **Human-machine collaboration at key nodes**: S4 Progressive Interview + S6 Review Output, two user checkpoints

package/dist/docs/template/dictionary-template.md

@@ -0,0 +1,40 @@
+# 术语字典
+
+本项目使用以下术语。代码中的标识符使用英文，文档和沟通中可混用。
+
+---
+
+## 核心概念
+
+| 中文 | 英文 | 说明 |
+|------|------|------|
+| 流程 | Flow | 一个完整的任务执行流程，定义在 /docs/flow/ 中 |
+| 步骤 | Step | 流程中的一个阶段，如 S1, S2, ... |
+| 任务 | Task | 在某流程下启动的一次具体执行 |
+| 行为准则 | Regulation | 项目中的规则文档，包括宪法、编码风格等 |
+| 宪法 | Constitution | 始终加载的最高原则 |
+| 字典 | Dictionary | 术语对照表（即本文件） |
+
+## 任务模型
+
+| 中文 | 英文 | 说明 |
+|------|------|------|
+| 规格说明 | Spec | 定义"做什么"（WHAT）的文档 |
+| 任务计划 | Plan | 定义"怎么做"（HOW）的文档 |
+| 任务状态 | Task State | 当前"做到哪了"（WHERE）的状态记录 |
+
+## 流程相关
+
+| 中文 | 英文 | 说明 |
+|------|------|------|
+| 状态机 | FSM / State Machine | 用 Mermaid 定义步骤流转逻辑 |
+| 人机协作 | Human-in-loop | 需要用户介入的步骤 |
+| 步骤流转 | Step Transition | 从一个步骤推进到下一个步骤 |
+| 上下文注入 | Context Injection | 通过文件引用标签向对话注入内容 |
+
+## 通用术语
+
+| 中文 | 英文 | 说明 |
+|------|------|------|
+| 会话 | Session | 一次对话 |
+| 插件 | Plugin | 扩展模块 |