ai-workflow-init 1.3.1 → 2.0.0

package/.cursor/commands/create-plan.md

@@ -71,19 +71,56 @@ Auto-name feature:
 - Example: "Login Page (HTML/CSS)" → `feature-login-page`.
 - If a file with the same name already exists, append a numeric suffix: `feature-{name}-2`, `feature-{name}-3`, ...
 
-Create the following files automatically and populate initial content:
+### 3a: Generate Planning Doc
 
-- `docs/ai/planning/feature-{name}.md` - Use structure from `feature-template.md`
-- `docs/ai/implementation/feature-{name}.md` - Use structure from `docs/ai/implementation/feature-template.md` (read this template before writing)
-
-Notify the user when done.
+Produce a Markdown doc following `docs/ai/planning/feature-template.md`:
 
-Produce a Markdown doc following the template structure:
-
-- Match sections from `docs/ai/planning/feature-template.md`
+- Match sections from template
 - Fill in content from Q&A inputs
 - Ensure all required sections are present
 
+### 3b: Generate Implementation Doc with Phases
+
+Before creating implementation doc, read `docs/ai/implementation/feature-template.md` to understand phase structure.
+
+**Estimate phase scope**:
+- Count total tasks from planning doc
+- If tasks ≤ 5: use single phase named "Core Implementation"
+- If tasks 6–12: suggest 2–3 phases (group by feature area or dependency order)
+- If tasks > 12: suggest 3–5 phases; prioritize logical grouping
+
+**For each phase, generate**:
+- Phase name (descriptive, e.g., "Database Schema Setup", "API Endpoints", "UI Components")
+- Tasks list: `[ ] [ACTION] path/to/file — Summary`
+- Pseudo-code outline (show logic structure, not real code):
+  ```
+  Pseudo-code:
+  - [Step 1]: what will be done
+  - [Step 2]: validation or check
+  - [Step 3]: data storage/return
+  ```
+
+**Pseudo-code guidelines**:
+- Keep to 3–5 lines per task
+- Show inputs, key logic, outputs
+- Use natural language, not actual syntax
+- Example for "Create user endpoint":
+  ```
+  Pseudo-code:
+  - Parse username + password from request
+  - Validate password strength
+  - Hash password with bcrypt
+  - Store user in database
+  - Return success + user ID
+  ```
+
+Create the following files automatically:
+
+- `docs/ai/planning/feature-{name}.md` - Use structure from `feature-template.md`
+- `docs/ai/implementation/feature-{name}.md` - Use phase structure with pseudo-code per task
+
+Notify the user when done with summary: "Created plan with X phases: Phase 1 (name), Phase 2 (name), ..."
+
 ## Step 4: Next Actions
 
 Suggest running `execute-plan` to begin task execution. Implementation work will be driven from `docs/ai/implementation/feature-{name}.md` as the task source.

package/.cursor/commands/execute-plan.md

@@ -21,15 +21,39 @@ Execute the feature plan by implementing tasks from the implementation doc and p
 - Load implementation doc: `docs/ai/implementation/feature-{name}.md`.
 - **Load template:** Read `docs/ai/implementation/feature-template.md` to understand required structure.
 
+### 1a: Phase Progress Detection
+
+If implementation doc exists, scan for phase markers (`### Phase X:`):
+
+- **Count total phases** in the document
+- **Detect last completed phase**: Find the highest phase where ALL tasks (checkbox `[x]`) are marked complete
+- **Detect current phase**: Find the first phase with incomplete tasks (`[ ]` marks)
+- **Show summary to user**:
+
+  ```
+  Found 3 phases.
+  - Phase 1 (Database Setup): Complete [x]
+  - Phase 2 (API Endpoints): In Progress [2/4 tasks done]
+  - Phase 3 (Frontend): Not Started
+
+  Resuming Phase 2...
+  ```
+
+If no phases detected (old format):
+
+- Treat entire "Changes" section as single phase (backward compatible)
+
 ## Step 2: Build Task Queue
 
-- Parse tasks (checkboxes `[ ]`, `[x]`) from the implementation doc:
-  - Primary source: `## Changes` section with `[ ] [ACTION] ...` entries.
+- Parse tasks (checkboxes `[ ]`, `[x]`) from **current phase only** (from phase detection in Step 1a):
+  - Primary source: Tasks under `### Phase X:` with `[ ] [ACTION] ...` entries (incomplete only).
   - For `[MODIFIED]` files, parse sub-bullets representing distinct logic items with line ranges.
-  - Optionally include other `[ ]` sections (e.g., `## Follow-ups`) if designated in-scope.
+  - **Skip completed phases** entirely (do not re-execute)
 - Build prioritized task queue (top-to-bottom unless dependencies block).
 - Identify blocked tasks and note reasons.
 
+Note: Do not include Follow-ups section unless explicitly in current phase.
+
 ## Step 3: Implement Iteratively (per task)
 
 For each task in queue:
@@ -92,14 +116,37 @@ After completing Step 4 for each task batch:
   - Go/Rust/Java: rely on compiler/type system via build step
 - Parallelize lint and type-check when safe; fix issues (up to 3 attempts) before proceeding.
 
-## Step 6: Next Actions
+## Step 6: Phase Completion Check (NEW)
+
+After completing all tasks in current phase:
+
+1. **Mark phase complete** in implementation doc (optional visual marker)
+2. **Check remaining phases**:
+   - If more incomplete phases exist:
+     ```
+     ✓ Phase 2 complete!
+     Ready for Phase 3 (Frontend)?
+     Run: /execute-plan
+     ```
+   - If this is final phase:
+     ```
+     ✓ All phases complete!
+     Ready for code review?
+     Run: /code-review
+     ```
 
-After completing tasks:
+## Step 7: Next Actions
+
+After all phases complete:
 
 - Suggest running `code-review` to verify against standards
 - Suggest running `writing-test` if edge cases need coverage
 - Suggest running `check-implementation` to validate alignment with implementation entries
 
+If phases remain:
+
+- User runs `/execute-plan` again; Phase detection (Step 1a) will resume correctly
+
 ## Notes
 
 - Keep code changes minimal and focused on implementation tasks

package/.cursor/commands/modify-plan.md

@@ -0,0 +1,190 @@
+## Goal
+
+Modify a feature plan after partial/full implementation. Support reverting to a previous git state or applying new requirement changes with both code and documentation sync.
+
+## Prerequisites
+
+- Feature name (kebab-case, e.g., `user-authentication`)
+- Planning doc exists: `docs/ai/planning/feature-{name}.md`
+- Implementation doc exists: `docs/ai/implementation/feature-{name}.md`
+- Git repo initialized (for tracking code state)
+
+## Workflow Alignment
+
+- Provide brief status updates (1–3 sentences) before/after important actions.
+- Update both planning and implementation docs when making changes.
+- Do NOT auto-commit; user reviews all changes before pushing.
+
+## Step 1: Load Current State
+
+Ask for feature name (must be kebab-case).
+
+Load and summarize:
+
+1. **Planning doc**: Current goal, scope, tasks overview
+2. **Implementation doc**: Current phases, completion status, files affected
+
+Display summary:
+
+```
+Feature: user-authentication
+Plan: Create user login + registration endpoints
+
+Implementation Progress:
+- Phase 1 (Database): Complete [x]
+  Files: src/db/schema.ts
+- Phase 2 (API Endpoints): In Progress [3/4]
+  Files: src/api/users.ts, src/api/auth.ts
+- Phase 3 (Frontend): Not Started [ ]
+  Files: src/components/Login.tsx
+
+Total files touched: 4
+```
+
+## Step 2: Scope of Change (Q&A)
+
+Ask user what's changing:
+
+**1. Type of modification:**
+   a) Modify goal/scope (entire plan changes)
+   b) Modify specific phase(s) (tactical change)
+   c) Revert to previous approach (manual revert)
+   d) Other (describe)
+
+**2a. If modifying goal/scope:**
+   - What's the new goal/scope?
+   - How does it impact existing tasks?
+
+**2b. If modifying specific phase(s):**
+   - Which phase(s)? (list by name)
+   - What requirement/approach is changing?
+
+**2c. If reverting approach:**
+   - Which phase to revert?
+   - Or revert all code changes after phase X?
+
+## Step 3: Apply Changes
+
+### Option A: Revert to Previous Approach (Manual)
+
+If user selects revert:
+
+1. **Identify affected files & changes**:
+   - Parse implementation doc; list all files modified in affected phase(s)
+   - Show file list that needs reverting:
+     ```
+     Files to revert (manual):
+     - src/api/users.ts (lines 45–120)
+     - src/db/schema.ts (lines 10–30)
+     - tests/api.test.ts (delete entire file)
+     ```
+
+2. **Manual revert guidance**:
+   - For MODIFIED files: show current state vs. target state (code snippets/line ranges)
+   - For DELETED files: ask user to delete manually
+   - Ask: "Ready to manually revert these files?"
+
+3. **If user confirms**:
+   - User manually reverts files (copy-paste old code back, undo in IDE, etc.)
+   - Update implementation doc:
+     - Mark affected phases/tasks `[ ]` (reset to pending)
+     - Add "Modification History" entry:
+       ```
+       ## Modification History
+
+       ### Revert [Date]: {Reason}
+       - **Reverted phases**: Phase X, Y
+       - **Reason**: [user provided]
+       - **Files manually reverted**: [list]
+       - **Affected tasks reset**: [ ] Task 1, [ ] Task 2, ...
+       ```
+
+4. **Result**: Docs updated; tasks reset; ready to re-implement with new approach
+
+### Option B: Apply New Changes
+
+If user selects new approach:
+
+1. **Update planning doc**:
+   - Modify goal/scope section if changed
+   - Update affected task(s) with new approach
+   - Add "Modification History" section:
+     ```
+     ## Modification History
+
+     ### Change [Date]: {Title}
+     - **Previous approach**: [original details]
+     - **New approach**: [new details]
+     - **Reason**: [user provided]
+     - **Affected phases**: Phase X, Y
+     ```
+
+2. **Update implementation doc**:
+   - For affected phases:
+     - Modify pseudo-code to match new approach
+     - Reset incomplete tasks `[ ]` (if approach changed significantly)
+   - Keep completed tasks as-is (do not re-implement)
+   - Update "Changes" section with new structure (files/logic outline)
+
+3. **Show git impact**:
+   - Highlight files that may need re-editing
+   - Ask: "Ready to re-implement with new approach?" (yes/no)
+
+## Step 4: Confirmation & Audit Trail
+
+Before finalizing, show:
+
+1. **Updated planning doc** snippet (modified sections)
+2. **Updated implementation doc** snippet (phase changes, pseudo-code)
+3. **Files affected** (files that will be changed)
+
+Ask: **"Apply changes and update docs?"** (yes/no)
+
+If **yes**:
+- Save updated docs
+- If revert: User manually reverts files (code state updated)
+- If new approach: docs updated; ready for re-implementation
+
+If **no**:
+- Rollback changes to docs
+- Discard any temporary changes
+
+## Step 5: Next Actions
+
+**After manual revert**:
+- "Docs updated. Affected tasks reset to `[ ]`. Run `/execute-plan` to re-implement Phase X with new approach."
+
+**After apply new approach**:
+- If only pseudo-code/docs changed (no code revert needed): "Continue current phase with `/execute-plan`."
+- If code changes needed (revert old approach + implement new): "Manually update code files first, then run `/execute-plan`."
+- "When done, run `/code-review` to validate standards."
+
+## Important Notes
+
+- **Manual revert**: User manually reverts code files (no git reset); AI guides the process
+- **Multi-feature safe**: Works when implementing multiple features simultaneously (selective revert possible)
+- **Backward compatible**: Works with both phase-based and non-phase-based implementation docs
+- **Audit trail**: "Modification History" section preserves decision rationale and affected files
+- **Idempotent**: Safe to re-run; modification history accumulates
+- **Safe defaults**: Asks confirmation before any changes; user always has final say
+
+## Example Flow
+
+```
+User: I want to modify plan
+Agent: Load state, show summary
+
+User: Revert Phase 2 (API Endpoints) - use different auth approach
+Agent: Identify affected files (src/api/users.ts, src/api/auth.ts)
+        Show current state vs. target state (pseudo-code + old implementation)
+        Ask: Ready to manually revert these files?
+
+User: Yes, I'll manually revert
+Agent: (User manually copies old code back or undoes changes in IDE)
+       Update implementation doc:
+       - Mark Phase 2 tasks [ ] (reset)
+       - Add Modification History: Phase 2 reverted, reason: better auth strategy
+
+Agent: Phase 2 reset. Ready to re-implement with new auth approach?
+       Run: /execute-plan
+```

package/cli.js

@@ -171,9 +171,10 @@ function askIDE() {
     console.log("\n🤖 Which AI tool(s) do you want to setup?");
     console.log("1. Cursor");
     console.log("2. GitHub Copilot");
-    console.log("3. Both");
+    console.log("3. Claude Code");
+    console.log("4. All");
 
-    rl.question("\nEnter your choice (1-3): ", (answer) => {
+    rl.question("\nEnter your choice (1-4): ", (answer) => {
       rl.close();
       resolve(answer.trim());
     });
@@ -182,11 +183,12 @@ function askIDE() {
 
 async function main() {
   const choice = await askIDE();
-  const installCursor = ["1", "3"].includes(choice);
-  const installCopilot = ["2", "3"].includes(choice);
+  const installCursor = ["1", "4"].includes(choice);
+  const installCopilot = ["2", "4"].includes(choice);
+  const installClaudeCode = ["3", "4"].includes(choice);
 
-  if (!["1", "2", "3"].includes(choice)) {
-    console.error("❌ Invalid choice. Please enter 1, 2, or 3.");
+  if (!["1", "2", "3", "4"].includes(choice)) {
+    console.error("❌ Invalid choice. Please enter 1, 2, 3, or 4.");
     process.exit(1);
   }
 
@@ -212,6 +214,15 @@ async function main() {
     run(`npx degit ${REPO}/.github/prompts .github/prompts --force`);
   }
 
+  // Clone Claude Code commands (luôn ghi đè)
+  if (installClaudeCode) {
+    if (!existsSync(".claude/commands")) {
+      mkdirSync(".claude/commands", { recursive: true });
+    }
+    step("🚚 Downloading Claude Code commands (.claude/commands)...");
+    run(`npx degit ${REPO}/.claude/commands .claude/commands --force`);
+  }
+
   // Clone Cursor prompts (luôn ghi đè)
   if (installCursor) {
     if (!existsSync(".cursor/prompts")) {

package/docs/ai/implementation/feature-template.md

@@ -8,13 +8,35 @@ Note: All content in this document must be written in English.
 
 ## Changes
 
+### Phase 1: [Phase Name]
+
 - [ ] [ACTION] path/to/file (lines: x–y) — Summary of change
+  ```
+  Pseudo-code:
+  - function/logic outline
+  - key variables/state
+  ```
 - [ ] [ACTION] path/to/file (lines: a–b) — Summary of change
+  ```
+  Pseudo-code:
+  - logic structure
+  ```
+
+### Phase 2: [Phase Name]
+
+- [ ] [ACTION] path/to/file — Summary of change
+  ```
+  Pseudo-code:
+  - ...
+  ```
 
 Notes:
 
 - ACTION must be one of: ADDED | MODIFIED | DELETED | RENAMED
 - For MODIFIED files, use sub-bullets for each distinct logic change and include line ranges.
+- Pseudo-code shows logic structure and key steps, not actual implementation code.
+- Each phase groups related tasks; phases execute sequentially.
+- Use only one phase for small features (≤ 5 tasks); use multiple phases for larger features.
 
 ## Edge Cases
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-workflow-init",
-  "version": "1.3.1",
+  "version": "2.0.0",
   "description": "Initialize AI workflow docs & commands into any repo with one command",
   "bin": {
     "ai-workflow-init": "./cli.js"