ai-workflow-init 1.2.3 → 1.3.0

package/.cursor/commands/check-implementation.md

@@ -1,5 +1,9 @@
 Compare current implementation against planning and implementation notes.
 
+## Workflow Alignment
+- Provide brief status updates (1–3 sentences) before/after important actions.
+- Provide a high-signal summary at completion highlighting key mismatches and next steps.
+
 1) Ask me for:
 - Feature name (if not provided)
 - Then locate docs by feature name:

package/.cursor/commands/code-review.md

@@ -1,5 +1,9 @@
 You are helping me perform a local code review **before** I push changes. This review is restricted to standards conformance only.
 
+## Workflow Alignment
+- Provide brief status updates (1–3 sentences) before/after important actions.
+- Provide a high-signal summary at completion highlighting key findings and impact.
+
 ## Step 1: Gather Context (minimal)
 - Ask for feature name if not provided (must be kebab-case).
 - Then locate and read:
@@ -14,6 +18,15 @@ You are helping me perform a local code review **before** I push changes. This r
 - **Do NOT** provide design opinions, performance guesses, or alternative architectures.
 - **Do NOT** infer requirements beyond what standards explicitly state.
 
+### Automated Checks (recommended)
+- Detect tools from project config and run non-interactive checks:
+  - JS/TS: `npx eslint .` (or `pnpm eslint .`), consider `--max-warnings=0`; type checks with `npx tsc --noEmit`
+  - Python: `ruff .` or `flake8 .`; type checks with `mypy .` or `pyright`
+  - Go: `golangci-lint run` or `go vet ./...`
+  - Rust: `cargo clippy -- -D warnings`
+  - Java: `./gradlew check` or `mvn -q -DskipTests=false -Dspotbugs.failOnError=true verify`
+- Use results to focus the review; still report only clear violations per standards.
+
 ## Step 3: File-by-File Review (standards violations only)
 For every relevant file, report ONLY standards violations per the two docs above. Do not assess broader design or run git commands.
 

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

@@ -1,11 +1,19 @@
-
 ## Goal
-Generate a planning doc at `docs/ai/planning/feature-{name}.md` using the template, with minimal, actionable content aligned to the 4-phase workflow.
+
+Generate a planning doc at `docs/ai/planning/feature-{name}.md` using the template, with minimal, actionable content aligned to the 4-phase workflow. Also initialize the implementation doc at `docs/ai/implementation/feature-{name}.md` based on the implementation template.
+
+## Workflow Alignment
+
+- Provide brief status updates (1–3 sentences) before/after important actions.
+- For medium/large tasks, create todos (≤14 words, verb-led). Keep only one `in_progress` item.
+- Update todos immediately after progress; mark completed upon finish.
 
 ## Step 1: Clarify Scope (Focused Q&A Guidelines)
+
 Purpose: the agent MUST generate a short, numbered Q&A for the user to clarify scope; keep it relevant, avoid off-topic, and do not build a static question bank.
 
 Principles:
+
 - Quickly classify context: a) Micro-UI, b) Page/Flow, c) Service/API/Data, d) Cross-cutting.
 - Ask only what is missing to produce Goal, Tasks, Risks, and DoD. Keep to 3–7 questions.
 - Do not re-ask what the user already stated; if ambiguous, confirm briefly (yes/no or single choice).
@@ -13,58 +21,75 @@ Principles:
 - Answers may be a/b/c or free text; the agent is not required to present fixed option lists.
 
 Output format for Q&A:
+
 - Number questions sequentially starting at 1 (e.g., "1.", "2.").
 - Under each question, provide 2–4 suggested options labeled with lowercase letters + ")" (e.g., "a)", "b)").
 - Keep options short (≤7 words) and add an "other" when useful.
 - Example:
   1. UI library?
-     a) TailwindCSS  b) Bootstrap  c) SCSS  d) Other
+     a) TailwindCSS b) Bootstrap c) SCSS d) Other
 
 Scope checklist to cover (ask only missing items, based on context):
-1) Problem & Users: the core problem and target user groups.
-2) In-scope vs Out-of-scope: what is included and excluded (e.g., MVP, no i18n, no payments).
-3) Acceptance Criteria (GWT): 2–3 key Given–When–Then scenarios.
-4) Constraints & Dependencies: technical constraints, libraries, real API vs mock, deadlines, external deps.
-5) Risks & Assumptions: known risks and key assumptions.
-6) Tasks Overview: 3–7 high-level work items.
-7) Definition of Done: completion criteria (build/test/docs/review).
+
+1. Problem & Users: the core problem and target user groups.
+2. In-scope vs Out-of-scope: what is included and excluded (e.g., MVP, no i18n, no payments).
+3. Acceptance Criteria (GWT): 2–3 key Given–When–Then scenarios.
+4. Constraints & Dependencies: technical constraints, libraries, real API vs mock, deadlines, external deps.
+5. Risks & Assumptions: known risks and key assumptions.
+6. Tasks Overview: 3–7 high-level work items.
+7. Definition of Done: completion criteria (build/test/docs/review).
 
 Adaptive behavior:
+
 - Always reduce questions to what is necessary; once Goal/Tasks/Risks/DoD can be written, stop asking.
 - Prioritize clarifying scope and acceptance criteria before implementation details.
 - If the user already specified items (framework, API/Mock, deadlines, etc.), confirm briefly only.
 
 Then collect inputs (after Q&A):
+
 - Feature name (kebab-case, e.g., `user-authentication`)
 - Short goal and scope
 - High-level tasks overview (3–7 items)
 - Definition of Done (build/test/review/docs)
 
 ## Step 2: Load Templates
+
 **Before creating docs, read the following files:**
+
 - `docs/ai/planning/feature-template.md` - Template structure to follow
+- `docs/ai/implementation/feature-template.md` - Template structure to follow for the implementation doc
 
 This template defines the required structure and format. Use it as the baseline for creating the planning doc.
 
 ## Step 3: Draft the Plan (auto-generate)
+
 Using the Q&A results and templates, immediately generate the plan without asking for confirmation.
 
 Auto-name feature:
+
 - Derive `feature-{name}` from user prompt + Q&A (kebab-case, concise, specific).
 - 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 file automatically and populate initial content:
+Create the following files automatically and populate initial content:
+
 - `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)
 
-Do NOT create the implementation or testing files at this step.
 Notify the user when done.
 
 Produce a Markdown doc following the template structure:
+
 - Match sections from `docs/ai/planning/feature-template.md`
 - Fill in content from Q&A inputs
 - Ensure all required sections are present
 
 ## Step 4: Next Actions
-Suggest running `execute-plan` to begin task execution.
+
+Suggest running `execute-plan` to begin task execution. Implementation work will be driven from `docs/ai/implementation/feature-{name}.md` as the task source.
 Note: Test documentation will be created separately using the `writing-test` command.
+
+## Notes
+
+- This command creates the planning doc and initializes the implementation doc; it does not modify unrelated existing files.
+- Idempotent: safe to re-run; auto-appends numeric suffix if files exist.

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

@@ -1,72 +1,109 @@
 ## Goal
-Execute the feature plan by implementing tasks and persisting notes to docs.
+
+Execute the feature plan by implementing tasks from the implementation doc and persisting notes to docs.
+
+## Workflow Alignment
+
+- Provide brief status updates (1–3 sentences) before each operation.
+- For medium/large tasks, create todos (≤14 words, verb-led). Keep only one `in_progress` item.
+- Update todos immediately after progress; mark completed upon finish.
+- Perform edits via file editing tools, not by printing code for copy-paste.
 
 ### 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`
+- Planning doc exists: `docs/ai/planning/feature-{name}.md` (reference only; tasks are driven by implementation doc)
 
 ## Step 1: Gather Context
+
 - Ask for feature name if not provided (must be kebab-case).
-- Load plan: `docs/ai/planning/feature-{name}.md`.
+- Load implementation doc: `docs/ai/implementation/feature-{name}.md`.
 - **Load template:** Read `docs/ai/implementation/feature-template.md` to understand required structure.
-- Ensure implementation doc exists or will be created: `docs/ai/implementation/feature-{name}.md`.
 
 ## Step 2: Build Task Queue
-- Parse tasks (checkboxes `[ ]`, `[x]`) from the plan.
+
+- Parse tasks (checkboxes `[ ]`, `[x]`) from the implementation doc:
+  - Primary source: `## Changes` section with `[ ] [ACTION] ...` entries.
+  - 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.
 - Build prioritized task queue (top-to-bottom unless dependencies block).
 - Identify blocked tasks and note reasons.
 
 ## Step 3: Implement Iteratively (per task)
+
 For each task in queue:
-1. Plan minimal change set:
+
+1. **Status update**: Brief note (1–3 sentences) on what will be done.
+2. Plan minimal change set:
    - Identify files/regions to modify
-   - Map changes to acceptance criteria from plan
-2. Implement changes:
-   - Write/edit code according to the plan
+   - Map changes to acceptance criteria from plan (reference if needed)
+3. Implement changes:
+   - Write/edit code according to the implementation doc entries (`[ACTION]` items)
    - Keep changes minimal and incremental
-   - Avoid speculative changes beyond plan scope
-3. Quick validation:
+   - Avoid speculative changes beyond implementation scope
+4. Quick validation:
    - Run build/compile if available
    - Run fast unit/smoke tests if available
    - Fix immediate issues before proceeding
-4. Persist notes to implementation doc:
+5. Persist notes to implementation doc:
    - File: `docs/ai/implementation/feature-{name}.md`
-   - Append entry per completed task:
-     - Files touched: `path/to/file.ext` (lines: x–y)
-     - Approach/pattern used: brief description
-     - Edge cases handled: list if any
-     - Risks/notes: any concerns
-5. Update planning doc:
-   - Mark completed tasks `[x]` with brief note
+   - Update the relevant `[ ]` entry to `[x]` when completed
+   - For `MODIFIED` files with sub-bullets, mark each completed sub-bullet `[x]`
+   - Include line ranges and concise summaries as per template
+6. Update implementation doc:
+   - Mark completed tasks `[x]` with brief notes
    - Mark blocked tasks with reason
+   - Do not mirror completion state in the planning doc
 
 ## Step 4: Implementation Doc Structure
+
 **Before creating the implementation doc, ensure you have read:**
+
 - `docs/ai/implementation/feature-template.md` - Template structure to follow
 
-If creating implementation doc for first task:
+If creating implementation doc for the first task (should already exist from create-plan):
+
 - Use the structure from `feature-template.md` exactly
-- Create `docs/ai/implementation/feature-{name}.md` with:
+- Ensure these sections exist:
   - `# Implementation Notes: {Feature Name}`
   - `## Summary` - Brief description of overall approach
-  - `## Changes` - Per-task entries with file paths, line ranges, approach
+  - `## Changes` — Use `[ ] [ACTION] ...` format with allowed actions ADDED | MODIFIED | DELETED | RENAMED
+    - For MODIFIED, use sub-bullets with line ranges and per-logic summaries
   - `## Edge Cases` - List of handled edge cases
   - `## Follow-ups` - TODOs or deferred work
-- Follow the template format strictly
+  - `## Execution Discipline`
 
 ## Step 5: Quality Checks
+
 After completing Step 4 for each task batch:
-- Run linting on changed files (e.g., `eslint` if JavaScript/TypeScript project).
-- Run type checks if applicable (e.g., `tsc --noEmit`).
-- Fix issues (up to 3 attempts) before proceeding to the next task.
+
+- Detect available tools from project config (e.g., `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, build files) and run the appropriate non-interactive checks.
+- Linting on changed files (prefer non-interactive):
+  - JavaScript/TypeScript: `npx eslint .` or `pnpm eslint .` (add `--max-warnings=0` if desired)
+  - Python: `ruff .` or `flake8 .`
+  - Go: `golangci-lint run` or `go vet ./...`
+  - Rust: `cargo clippy -- -D warnings`
+  - Java: `./gradlew check` or `mvn -q -DskipTests=false -Dspotbugs.failOnError=true verify`
+  - Scope to changed files when possible for speed
+- Type checks (non-emitting where applicable):
+  - TypeScript: `npx tsc --noEmit`
+  - Python: `mypy .` (if configured) or `pyright` if present
+  - 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
+
 After completing tasks:
+
 - 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 plan
+- Suggest running `check-implementation` to validate alignment with implementation entries
 
 ## Notes
-- Keep code changes minimal and focused on plan tasks
-- Document all changes in implementation doc for later review/refactor
-- Avoid implementing features not in the plan
+
+- Keep code changes minimal and focused on implementation tasks
+- Document all changes in the implementation doc; use checkboxes to track progress
+- Avoid implementing features not in the implementation doc scope
+- Modifies source code per implementation scope; updates `docs/ai/implementation/feature-{name}.md`. Does not modify unrelated files.
+- Idempotent: safe to re-run; updates checkboxes deterministically.

package/.cursor/commands/generate-standards.md

@@ -1,19 +1,36 @@
 ## Goal
+
 Generate or update `docs/ai/project/CODE_CONVENTIONS.md` and `PROJECT_STRUCTURE.md` from the current codebase with brief Q&A refinement.
 
-## Step 1: Clarify Scope (3–6 questions max)
+## Step 1: Detect Project Context
+
+Detect project languages/frameworks/libraries from repository metadata:
+
+- Analyze `package.json`, `pyproject.toml`, lockfiles, config files
+- Identify primary languages (JavaScript/TypeScript, Python, etc.)
+- Identify frameworks (React, Vue, Angular, etc.)
+- Identify libraries and tooling (ESLint, Prettier, testing frameworks, etc.)
+- Note any build tools or bundlers in use
+
+**Output**: The detected project context will be written to `CODE_CONVENTIONS.md` as the foundation for code conventions.
+
+## Step 2: Clarify Scope (3–6 questions max)
+
 Quick classification and targeted questions:
+
 - Languages/frameworks detected: confirm correct? (a/b/other)
-- Import/style tools in use: (a) ESLint/Prettier  (b) Other formatter  (c) None
-- Test placement preference: (a) Colocated `*.spec.*`  (b) `__tests__/` directory  (c) Other
-- Error handling strategy: (a) Exceptions/try-catch  (b) Result types  (c) Other
-- Module organization: (a) By feature  (b) By layer  (c) Mixed
+- Import/style tools in use: (a) ESLint/Prettier (b) Other formatter (c) None
+- Test placement preference: (a) Colocated `*.spec.*` (b) `__tests__/` directory (c) Other
+- Error handling strategy: (a) Exceptions/try-catch (b) Result types (c) Other
+- Module organization: (a) By feature (b) By layer (c) Mixed
 - Any performance/security constraints to encode? (yes/no, brief)
 
 Keep questions short and single-purpose. Stop once sufficient info gathered.
 
-## Step 2: Auto-Discovery
+## Step 3: Auto-Discovery
+
 Analyze repository to infer:
+
 - Dominant naming patterns:
   - Variables/functions: camelCase/PascalCase/snake_case
   - Classes/types: PascalCase
@@ -33,16 +50,26 @@ Analyze repository to infer:
   - Strategy patterns
   - Other architectural patterns
 
-## Step 3: Draft Standards
+## Step 4: Draft Standards
+
 Generate two documents (with template preload):
 
 ### CODE_CONVENTIONS.md
-- Template preload (in order, if present):
-  1) `docs/ai/project/template-convention/common.md` — always preload first.
-  2) `docs/ai/project/template-convention/javascript.md` — preload if the repository primarily uses JavaScript/TypeScript.
-  3) `docs/ai/project/template-convention/react.md` — preload if the repository uses React (detect via dependencies like `react`, file patterns like `.jsx/.tsx`, or imports from `react`).
-  
-  These templates take precedence and should appear at the top of the generated document, followed by auto-discovered rules.
+
+- Template preload (flexible matching based on detected project context):
+
+  1. Read all files in `docs/ai/project/template-convention/` directory
+  2. For each template file, determine if it matches the detected project context:
+     - Match by language (e.g., `javascript.md`, `typescript.md`, `python.md`)
+     - Match by framework (e.g., `react.md`, `vue.md`, `angular.md`)
+     - Match by common patterns (e.g., `common.md` — always include if present)
+  3. Load and merge all matching templates in a logical order:
+     - `common.md` first (if present)
+     - Language-specific templates (e.g., `javascript.md`, `typescript.md`)
+     - Framework-specific templates (e.g., `react.md`, `vue.md`)
+     - Other relevant templates based on detected tooling/patterns
+  4. These templates take precedence and should appear at the top of the generated document, followed by auto-discovered rules from codebase analysis.
+
 - Naming conventions (variables, functions, classes, constants)
 - Import order and grouping
 - Formatting tools (ESLint/Prettier/etc.) if detected
@@ -53,6 +80,7 @@ Generate two documents (with template preload):
 - Async/await patterns if applicable
 
 ### PROJECT_STRUCTURE.md
+
 - Folder layout summary:
   - `src/`: source code organization
   - `docs/ai/**`: documentation structure
@@ -61,7 +89,8 @@ Generate two documents (with template preload):
 - Test placement and naming conventions
 - Config/secrets handling summary
 
-## Step 4: Persist (Update-in-place, Non-destructive)
+## Step 5: Persist (Update-in-place, Non-destructive)
+
 - Target files:
   - `docs/ai/project/CODE_CONVENTIONS.md`
   - `docs/ai/project/PROJECT_STRUCTURE.md`
@@ -69,12 +98,15 @@ Generate two documents (with template preload):
 - Do NOT blindly overwrite entire files. Update only the managed blocks using markers:
 
 ### Managed Block Markers
+
 Use these exact markers to wrap generated content:
+
 ```
 <!-- GENERATED: CODE_CONVENTIONS:START -->
 ... generated content ...
 <!-- GENERATED: CODE_CONVENTIONS:END -->
 ```
+
 ```
 <!-- GENERATED: PROJECT_STRUCTURE:START -->
 ... generated content ...
@@ -82,25 +114,29 @@ Use these exact markers to wrap generated content:
 ```
 
 ### Update Rules
-1) If the target file exists and contains the corresponding markers, replace only the content between START/END with the newly generated content.
-2) If the file exists but does not contain markers, append a new managed block to the end of the file (preserve all existing manual content).
-3) If the file does not exist, create it with the header note and a single managed block.
-4) Never modify content outside the managed blocks.
+
+1. If the target file exists and contains the corresponding markers, replace only the content between START/END with the newly generated content.
+2. If the file exists but does not contain markers, append a new managed block to the end of the file (preserve all existing manual content).
+3. If the file does not exist, create it with the header note and a single managed block.
+4. Never modify content outside the managed blocks.
 
 ### Generated Content Order (for CODE_CONVENTIONS)
-- Merge templates in preload order (when present):
-  1) `docs/ai/project/template-convention/common.md`
-  2) `docs/ai/project/template-convention/javascript.md` (when JS/TS detected)
-  3) `docs/ai/project/template-convention/react.md` (when React is detected)
-  4) `docs/ai/project/template-convention/typescript.md.md` (when TS is detected)
-- After the merged templates, append auto-discovered rules from the codebase analysis.
-
-## Step 5: Next Actions
+
+1. **Project Context Section**: Write the detected project context from Step 1 (languages, frameworks, libraries, tooling)
+2. **Template Rules Section**: Merge all matching templates from `docs/ai/project/template-convention/` directory:
+   - Read all files in the directory
+   - Filter templates that match the detected project context (by language, framework, or common patterns)
+   - Merge in logical order: common → language → framework → tooling-specific
+3. **Auto-Discovered Rules Section**: Append auto-discovered rules from codebase analysis (Step 3)
+4. **Project-Specific Rules Section**: Include any project-specific conventions from Q&A (Step 2)
+
+## Step 6: Next Actions
+
 - Suggest running `code-review` to validate new standards are being followed
 - Inform user they can manually edit these files anytime
 
 ## Notes
+
 - Focus on patterns actually present in codebase, not ideal patterns
 - Keep generated docs concise and actionable
 - User can refine standards manually after generation
-

package/.cursor/commands/init-chat.md

@@ -1,30 +1,33 @@
 ## Goal
+
 Initialize a new chat by loading and aligning to `AGENTS.md` so the AI agent consistently follows project rules (workflow, tooling, communication, language mirroring) from the first message.
 
 ## What this command does
+
 1. Read `AGENTS.md` and extract the actionable rules.
 2. Summarize responsibilities and constraints the agent must follow in this session.
 3. Confirm language-mirroring: respond in the user's chat language; default to English if the user's language is unclear or ambiguous.
 4. Acknowledge the 4-phase workflow and TODO discipline for future commands.
 
 ## Steps
-1) Open and read `AGENTS.md` (project root).
-2) Detect project languages/frameworks/libraries from repository metadata (e.g., `package.json`, `pyproject.toml`, lockfiles, config files). Update `docs/ai/project/CODE_CONVENTIONS.md` to include any missing key coding conventions (only important items like React, TypeScript, TailwindCSS, etc.).
-3) Read files in `docs/ai/project/` to understand project context and standards.
-4) Produce a short confirmation in the chat including:
+
+1. Open and read `AGENTS.md` (project root).
+2. Read `docs/ai/project/CODE_CONVENTIONS.md` and `docs/ai/project/PROJECT_STRUCTURE.md` if they exist in the repository.
+3. Produce a short confirmation in the chat including:
    - Workflow alignment: Plan → Implement → Test → Review
    - Tooling strategy: semantic search first; parallelize independent steps
    - Communication: minimal Markdown; status updates; high-signal summaries; mirror user language (default English if unclear)
    - Code presentation: code references for existing code; fenced blocks for new code
    - TODO policy: create/update todos; keep only one `in_progress`
-5) If any section is missing or unclear, ask a single concise clarification question; otherwise proceed silently in future commands.
+4. If any section is missing or unclear, ask a single concise clarification question; otherwise proceed silently in future commands.
 
 ## Output format (concise)
+
 - Use the language of the triggering user message (mirror). If ambiguous, use English.
 - One short paragraph confirming alignment + a 4–6 bullet checklist of the above items.
 - No code unless strictly needed.
 
 ## Notes
-- This command is idempotent—safe to re-run at the start of any chat.
-- It does not modify files; it only sets expectations for subsequent commands.
 
+- This command is idempotent—safe to re-run at the start of any chat.
+- It does not modify existing files; it only sets expectations for subsequent commands.

package/.cursor/commands/writing-test.md

@@ -1,12 +1,18 @@
 Use `docs/ai/testing/feature-{name}.md` as the source of truth.
 
+## Workflow Alignment
+- Provide brief status updates (1–3 sentences) before/after important actions.
+- For medium/large tasks, create todos (≤14 words, verb-led). Keep only one `in_progress` item.
+- Update todos immediately after progress; mark completed upon finish.
+- Default to parallel execution for independent operations; use sequential steps only when dependencies exist.
+
 ## Step 1: Gather Context (minimal)
 - Ask for feature name if not provided (must be kebab-case).
 - **Load template:** Read `docs/ai/testing/feature-template.md` to understand required structure.
 - Then locate docs by convention:
   - Planning: `docs/ai/planning/feature-{name}.md`
   - Implementation (optional): `docs/ai/implementation/feature-{name}.md`
-- **Detect test framework:** Check `package.json` and project structure to identify test framework (Vitest, Jest, Mocha, pytest, etc.)
+- **Detect test framework:** Check `package.json` and project structure to identify test framework (Vitest, Jest, Mocha, pytest, etc.). Auto-detect from `package.json` first; if no test runner found, create skeleton test and report missing runner.
 - **Load standards:** Read `docs/ai/project/PROJECT_STRUCTURE.md` for test file placement rules
 - **Load conventions:** Read `docs/ai/project/CODE_CONVENTIONS.md` for coding standards
 
@@ -115,12 +121,12 @@ describe('functionToTest', () => {
 ## Step 5: Run Tests with Logging (automatic)
 After generating test code:
 
-1. **Execute test command** based on detected framework:
-   - Vitest: `npm test` or `npx vitest run`
-   - Jest: `npm test` or `npx jest`
-   - Mocha: `npm test` or `npx mocha`
-   - pytest: `pytest` or `python -m pytest`
-   - Other: detect from `package.json` scripts
+1. **Execute test command** based on detected framework (use non-interactive flags):
+   - Vitest: `npm test` or `npx vitest run --run`
+   - Jest: `npm test` or `npx jest --ci`
+   - Mocha: `npm test` or `npx mocha --reporter spec`
+   - pytest: `pytest` or `python -m pytest -v`
+   - Other: detect from `package.json` scripts, add `--no-interactive` or equivalent flags
 
 2. **Capture and display output** in terminal with detailed logging:
    - Show test execution progress (which tests are running)
@@ -214,3 +220,5 @@ Ensure all required sections from template are present. Keep the document brief
 - Test execution must show clear, detailed logging in terminal
 - AI excels at: edge case generation, parameter combinations, property-based testing, coverage analysis
 - Keep tests deterministic (avoid external dependencies, random values without seeds, time-dependent logic)
+- Creates test files only; does not edit non-test source files.
+- Idempotent: safe to re-run; appends entries or updates test doc deterministically.

package/cli.js

@@ -1,48 +1,98 @@
 #!/usr/bin/env node
 
-const { execSync } = require('child_process');
-const { existsSync, mkdirSync } = require('fs');
+const { execSync } = require("child_process");
+const { existsSync, mkdirSync } = require("fs");
+const readline = require("readline");
 
 // Repo workflow gốc của bạn
-const REPO = 'phananhtuan09/ai-agent-workflow';
-const RAW_BASE = 'https://raw.githubusercontent.com/phananhtuan09/ai-agent-workflow/main';
+const REPO = "phananhtuan09/ai-agent-workflow";
+const RAW_BASE =
+  "https://raw.githubusercontent.com/phananhtuan09/ai-agent-workflow/main";
 
 // In ra helper log
 function step(msg) {
-  console.log('\x1b[36m%s\x1b[0m', msg); // cyan
+  console.log("\x1b[36m%s\x1b[0m", msg); // cyan
 }
 
 function run(cmd) {
   try {
-    execSync(cmd, { stdio: 'inherit' });
+    execSync(cmd, { stdio: "inherit" });
   } catch (e) {
-    console.error('❌ Failed:', cmd);
+    console.error("❌ Failed:", cmd);
     process.exit(1);
   }
 }
 
-// Kiểm tra và tạo folder nếu chưa có
-if (!existsSync('docs/ai')) {
-  mkdirSync('docs/ai', { recursive: true });
-}
-if (!existsSync('.cursor/commands')) {
-  mkdirSync('.cursor/commands', { recursive: true });
+// Hỏi user chọn IDE
+const rl = readline.createInterface({
+  input: process.stdin,
+  output: process.stdout,
+});
+
+function askIDE() {
+  return new Promise((resolve) => {
+    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");
+
+    rl.question("\nEnter your choice (1-3): ", (answer) => {
+      rl.close();
+      resolve(answer.trim());
+    });
+  });
 }
 
-step('🚚 Downloading workflow template (docs/ai)...');
-run(`npx degit ${REPO}/docs/ai docs/ai --force`);
+async function main() {
+  const choice = await askIDE();
+  const installCursor = ["1", "3"].includes(choice);
+  const installCopilot = ["2", "3"].includes(choice);
+
+  if (!["1", "2", "3"].includes(choice)) {
+    console.error("❌ Invalid choice. Please enter 1, 2, or 3.");
+    process.exit(1);
+  }
+
+  // Kiểm tra và tạo folder nếu chưa có
+  if (!existsSync("docs/ai")) {
+    mkdirSync("docs/ai", { recursive: true });
+  }
 
-step('🚚 Downloading agent commands (.cursor/commands)...');
-run(`npx degit ${REPO}/.cursor/commands .cursor/commands --force`);
+  step("🚚 Downloading workflow template (docs/ai)...");
+  run(`npx degit ${REPO}/docs/ai docs/ai --force`);
+
+  // Clone Cursor commands
+  if (installCursor) {
+    if (!existsSync(".cursor/commands")) {
+      mkdirSync(".cursor/commands", { recursive: true });
+    }
+    step("🚚 Downloading Cursor agent commands (.cursor/commands)...");
+    run(`npx degit ${REPO}/.cursor/commands .cursor/commands --force`);
+  }
+
+  // Clone GitHub Copilot commands (nếu có folder khác)
+  if (installCopilot) {
+    if (!existsSync(".copilot/commands")) {
+      mkdirSync(".copilot/commands", { recursive: true });
+    }
+    step("🚚 Downloading GitHub Copilot agent commands (.copilot/commands)...");
+    run(`npx degit ${REPO}/.copilot/commands .copilot/commands --force`);
+  }
+
+  step("🚚 Downloading AGENTS.md ...");
+  try {
+    run(`curl -fsSL ${RAW_BASE}/AGENTS.md -o AGENTS.md`);
+  } catch (_) {
+    // Fallback cho môi trường không có curl
+    run(`wget -qO AGENTS.md ${RAW_BASE}/AGENTS.md`);
+  }
 
-step('🚚 Downloading AGENTS.md ...');
-// degit không hỗ trợ tải 1 file đơn lẻ -> dùng raw github
-try {
-  run(`curl -fsSL ${RAW_BASE}/AGENTS.md -o AGENTS.md`);
-} catch (_) {
-  // Fallback cho môi trường không có curl
-  run(`wget -qO AGENTS.md ${RAW_BASE}/AGENTS.md`);
+  step(
+    "✅ All AI workflow docs and selected command templates have been copied!"
+  );
+  console.log(
+    "\n🌱 You can now use your AI workflow! Edit docs/ai/ and AGENTS.md as needed.\n"
+  );
 }
 
-step('✅ All AI workflow docs, command templates, and AGENTS.md have been copied!');
-console.log('\n🌱 You can now use your AI workflow! Edit docs/ai/ and AGENTS.md as needed.\n');
+main();

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

@@ -3,19 +3,29 @@
 Note: All content in this document must be written in English.
 
 ## Summary
+
 - Short description of the solution approach
 
 ## Changes
-- File: path/to/file1 (lines: x–y) — solution/ API/ pattern
-- File: path/to/file2 (lines: a–b) — change summary
+
+- [ ] [ACTION] path/to/file (lines: x–y) — Summary of change
+- [ ] [ACTION] path/to/file (lines: a–b) — Summary of change
+
+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.
 
 ## Edge Cases
+
 - List of handled edge cases
 
 ## Follow-ups
+
 - TODOs or deferred work
 
 ## Execution Discipline
+
 - Before each edit, provide a short status update describing the next action (1–3 sentences).
 - Perform edits via file editing tools; avoid printing large code blocks for copy-paste.
 - After each batch of edits, run linter/type/build on changed files; auto-fix issues (up to 3 attempts) before requesting review.

package/package.json

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