ai-workflow-init 1.1.0 → 1.1.1

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

@@ -43,9 +43,8 @@ Then collect inputs (after Q&A):
 ## Step 2: Load Templates
 **Before creating docs, read the following files:**
 - `docs/ai/planning/feature-template.md` - Template structure to follow
-- `docs/ai/testing/feature-template.md` - Template structure for test plan skeleton
 
-These templates define the required structure and format. Use them as the baseline for creating feature docs.
+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.
@@ -55,11 +54,10 @@ 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:
+Create the following file automatically and populate initial content:
 - `docs/ai/planning/feature-{name}.md` - Use structure from `feature-template.md`
-- `docs/ai/testing/feature-{name}.md` - Use structure from testing `feature-template.md` (skeleton)
 
-Do NOT create the implementation file at this step.
+Do NOT create the implementation or testing files at this step.
 Notify the user when done.
 
 Produce a Markdown doc following the template structure:
@@ -69,3 +67,4 @@ Produce a Markdown doc following the template structure:
 
 ## Step 4: Next Actions
 Suggest running `execute-plan` to begin task execution.
+Note: Test documentation will be created separately using the `writing-test` command.

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

@@ -6,49 +6,211 @@ Use `docs/ai/testing/feature-{name}.md` as the source of truth.
 - 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.)
+- **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
 
 Always align test cases with acceptance criteria from the planning doc. If implementation notes are missing, treat planning as the single source of truth.
 
-## Step 2: Scope (simple tests only)
-- Focus on pure functions, small utilities, and isolated component logic.
-- Test edge cases and logic branches.
-- **Do NOT** write complex rendering tests, E2E flows, or integration tests requiring heavy setup.
-- Keep tests simple and fast to run via command line.
-
-## Step 3: Generate Unit Tests
-- List scenarios: happy path, edge cases, error cases.
-- Propose concrete test cases/snippets per main function/module.
-- Ensure tests are deterministic (avoid external IO when possible).
-- Focus on logic validation, not complex UI rendering or user flows.
-
-## Step 4: Placement & Commands
-- Place tests per `PROJECT_STRUCTURE.md`:
-  - Colocated `*.spec.*` files with source, or
-  - Under `__tests__/` mirroring source structure
-- Provide run commands consistent with project:
-  - Example: `npm test -- --run <pattern>` or language-specific runner
-  - Ensure tests can be run individually for quick iteration
-- Keep each test file small and focused.
-
-## Step 5: Coverage Strategy (lightweight)
-- Suggest coverage command if available (e.g., `npm test -- --coverage`).
-- Default targets (adjust if project-specific):
-  - Lines: 80%
-  - Branches: 70%
-- Highlight files still lacking coverage for critical paths.
-
-## Step 6: Update Testing Doc
-- Use structure from `docs/ai/testing/feature-template.md` to populate `docs/ai/testing/feature-{name}.md`.
-- Fill cases/snippets/coverage notes following the template sections:
-  - `## Unit Tests`
-  - `## Integration Tests`
-  - `## Manual Checklist`
-  - `## Coverage Targets`
-- Keep the document brief and actionable.
-- Include run commands for quick verification.
-- Ensure all required sections from template are present.
+## Step 2: Scope (logic and component tests only)
+- **Focus on:**
+  - Pure function logic: test with various input parameters (happy path, edge cases, invalid inputs)
+  - Component logic: test component behavior with different props/parameters (without complex rendering)
+  - Utility functions: test return values, error handling, boundary conditions
+  - Parameter variations: systematically test different combinations of parameters
+  - Edge cases: null, undefined, empty values, boundary values
+  - Error handling: invalid inputs, exceptions, error messages
+  - Type safety: type mismatches, missing properties, contract violations
+  - Property-based testing: mathematical properties (commutativity, associativity, idempotency)
+- **DO NOT write:**
+  - Integration tests between multiple modules/services (requires heavy setup)
+  - Complex UI rendering tests requiring heavy DOM setup
+  - E2E flows or end-to-end user journey tests
+  - Tests requiring external API calls, database connections, or network mocking
+  - Performance/load testing
+- Keep tests simple, fast, and deterministic.
+
+## Step 3: Analyze Code to Test
+Read implementation files from `docs/ai/implementation/feature-{name}.md` or scan source code files:
+- Identify all functions/components that need testing:
+  - List each function with its signature (parameters, return type, exceptions)
+  - List each component with its props interface
+  - List each class with its methods and properties
+- For each function/component, identify:
+  - Input parameter types and possible values
+  - Expected outputs for different inputs
+  - Edge cases (null, undefined, empty, boundaries, min/max values)
+  - Error cases (invalid inputs, exceptions, error messages)
+  - Control flow branches (if/else, switch cases, loops)
+  - Mathematical properties (if applicable): commutativity, associativity, idempotency, invariants
+
+## Step 4: Generate Test Code (automatic)
+For each function/component identified:
+
+1. **Create test file** according to `PROJECT_STRUCTURE.md`:
+   - Colocated `*.spec.*` or `*.test.*` files with source, OR
+   - Under `__tests__/` or `tests/` mirroring source structure
+   - Follow naming conventions from `CODE_CONVENTIONS.md`
+
+2. **Write complete test code** with:
+   - Test framework setup (imports, describe blocks, test utilities)
+   - Multiple test cases per function/component:
+     - **Happy path**: normal parameters → expected output
+     - **Edge cases**: empty/null/undefined inputs, boundary values (min/max, 0, -1, empty strings/arrays)
+     - **Parameter combinations**: systematically test different combinations of parameters (cartesian product when practical)
+     - **Error cases**: invalid inputs, exceptions, error messages
+     - **Type safety**: wrong types, missing properties, extra properties
+     - **Property-based**: verify mathematical properties if applicable
+   - Clear, descriptive test names describing what is being tested
+   - Assertions using appropriate test framework syntax
+
+3. **Focus on logic testing:**
+   - For functions: test return values, side effects (if any), error handling
+   - For components: test output/logic with different props (avoid complex rendering - use lightweight snapshots or logic checks)
+   - For classes: test methods independently with various inputs
+   - Test parameter combinations systematically
+
+4. **Generate edge cases systematically:**
+   - For each parameter, generate: null, undefined, empty, zero, negative, max/min values
+   - Test type mismatches: wrong types, missing required properties
+   - Test boundary conditions: off-by-one errors, overflow/underflow
+
+5. **Property-based testing (when applicable):**
+   - Identify mathematical/algorithmic properties
+   - Generate property-based tests: commutativity, associativity, idempotency, invariants
+   - Test with random inputs following constraints
+
+**Example test structure:**
+```javascript
+import { describe, it, expect } from 'vitest';
+import { functionToTest } from './source-file';
+
+describe('functionToTest', () => {
+  it('should return correct value with normal parameters', () => {
+    // Test with standard inputs
+  });
+  
+  it('should handle edge case with empty input', () => {
+    // Test boundary
+  });
+  
+  it('should handle null input', () => {
+    // Test null handling
+  });
+  
+  it('should handle different parameter combinations', () => {
+    // Test various param combinations
+  });
+  
+  it('should throw error with invalid input', () => {
+    // Test error handling
+  });
+  
+  it('should maintain idempotency property', () => {
+    // Property-based test
+  });
+});
+```
+
+## 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
+
+2. **Capture and display output** in terminal with detailed logging:
+   - Show test execution progress (which tests are running)
+   - Show test results (pass/fail) for each test case with execution time
+   - Show test summary (total tests, passed, failed, skipped)
+   - Show any error messages, stack traces, or assertion failures for failures
+   - Show coverage report if available (lines, branches, functions coverage)
+   - Format output clearly for readability
+
+3. **Log format example:**
+   ```
+   === Running tests for feature: {name} ===
+   
+   RUN  test-file-1.spec.js
+     ✓ should handle normal case (2ms)
+     ✓ should handle edge case (1ms)
+     ✗ should handle invalid input (3ms)
+       
+       Error: Expected error to be thrown
+       at test-file-1.spec.js:25
+       
+     ✓ should handle parameter combinations (5ms)
+     ✓ should maintain property (1ms)
+   
+   Test Files:  1 passed | 0 failed | 1 total
+   Tests:       4 passed | 1 failed | 5 total
+   Time:        0.012s
+   
+   Coverage:
+   - Lines: 82% (lines covered / total lines)
+   - Branches: 75% (branches covered / total branches)
+   - Functions: 90% (functions covered / total functions)
+   ```
+
+4. **If tests fail:**
+   - Analyze failure reason from logs
+   - Fix test code or implementation as needed
+   - Re-run tests until all pass
+   - Update implementation doc if code changes were needed
+
+## Step 6: Coverage Gap Analysis (automatic)
+After initial test generation and execution:
+
+1. **Analyze coverage report:**
+   - Identify untested branches/conditions
+   - Identify untested lines/paths
+   - Identify untested functions/methods
+
+2. **Generate additional tests automatically:**
+   - For each uncovered branch: create test case
+   - For each uncovered line: ensure it's reachable by existing tests or add new test
+   - For each uncovered function: create test cases
+
+3. **Re-run tests and verify coverage:**
+   - Execute tests again with coverage
+   - Verify coverage targets are met (default: 80% lines, 70% branches)
+   - Continue generating tests until targets are met or all practical cases are covered
+
+## Step 7: Update Testing Doc
+Use structure from `docs/ai/testing/feature-template.md` to populate `docs/ai/testing/feature-{name}.md`.
+
+Fill with:
+- **Test Files Created**: List all test files generated with paths
+- **Test Cases Summary**: Brief summary of what was tested (function/component + key scenarios)
+  - Happy path scenarios
+  - Edge cases covered
+  - Parameter variations tested
+  - Error scenarios handled
+  - Property-based tests (if any)
+- **Run Command**: Command to execute tests
+- **Last Run Results**: Summary of test execution
+  - Total/passed/failed count
+  - Coverage percentages (lines, branches, functions)
+  - Any notable findings or issues
+- **Coverage Targets**: Coverage goals and current status
+
+Ensure all required sections from template are present. Keep the document brief and actionable.
+
+## Step 8: Verify Tests Pass
+- Ensure all generated tests pass successfully
+- Ensure coverage targets are met (default: 80% lines, 70% branches)
+- If any test fails, debug and fix issues
+- Update implementation doc if code changes were needed
+- Re-run tests to confirm fixes
 
 ## Notes
-- Tests should be simple enough to run quickly and verify logic correctness.
-- Avoid complex test setup or mocking unless necessary.
-- Focus on catching logic errors and edge cases, not testing frameworks or flows.
+- Tests should be simple enough to run quickly and verify logic correctness
+- Focus on catching logic errors and edge cases through systematic parameter variation
+- Avoid complex test setup or mocking unless necessary for logic isolation
+- All tests must be automatically runnable via command line
+- 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)

package/docs/ai/testing/README.md

@@ -7,36 +7,77 @@ description: Feature test plans and testing guidelines
 # Testing Documentation
 
 ## Purpose
-This directory contains test plans for individual features. These docs focus on simple, fast-running tests to verify logic correctness.
+This directory contains test plans for individual features. These docs focus on simple, fast-running tests to verify logic correctness. Tests are automatically generated and executed by AI agents.
 
 ## Testing Workflow
 
 ### Creating Test Plans
-Use the `writing-test` command to generate test plans:
+Use the `writing-test` command to generate test plans and test code:
 - Command: `.cursor/commands/writing-test.md`
 - Output: `docs/ai/testing/feature-{name}.md`
 - Template: `docs/ai/testing/feature-template.md`
 
+### Automatic Test Generation
+The `writing-test` command automatically:
+1. **Analyzes code** from implementation notes or source files
+2. **Generates test code** with comprehensive test cases:
+   - Happy path scenarios
+   - Edge cases (null, undefined, empty, boundaries)
+   - Parameter combinations
+   - Error handling
+   - Type safety checks
+   - Property-based tests (when applicable)
+3. **Runs tests** automatically with detailed logging
+4. **Analyzes coverage** and generates additional tests to fill gaps
+5. **Updates test documentation** with results and coverage
+
 ### Test Plan Structure
 Each test plan follows the template structure:
-- **Unit Tests**: Simple test cases for functions/components
+- **Test Files Created**: List of all generated test files
+- **Unit Tests**: Test cases organized by function/component
   - Happy path scenarios
-  - Edge cases
+  - Edge cases (null, undefined, empty, boundaries)
+  - Parameter variations
   - Error cases
-- **Integration Tests**: Simple component interaction tests (if needed)
-- **Manual Checklist**: Steps for manual verification
-- **Coverage Targets**: Coverage goals and gaps
+  - Type safety checks
+  - Property-based tests
+- **Run Command**: Command to execute tests
+- **Last Run Results**: Test execution summary with coverage
+- **Coverage Targets**: Coverage goals and current status
 
 ### Testing Philosophy
-- **Focus**: Pure functions, small utilities, isolated component logic
+- **Focus**: Pure functions, small utilities, isolated component logic, parameter variations
 - **Speed**: Tests must run quickly via command line
 - **Simplicity**: Avoid complex rendering tests, E2E flows, or heavy setup
-- **Purpose**: Catch logic errors and edge cases, not test frameworks
+- **Purpose**: Catch logic errors and edge cases through systematic testing
+- **Automation**: AI agents excel at generating comprehensive test cases and running them automatically
+
+### Test Types (AI Agent Strengths)
+AI agents excel at automatically generating:
+1. **Logic Testing**: Function behavior with various parameters
+2. **Edge Cases**: Null, undefined, empty, boundary values systematically
+3. **Parameter Combinations**: Cartesian products and systematic variations
+4. **Error Handling**: Invalid inputs, exceptions, error messages
+5. **Type Safety**: Type mismatches, missing properties, contract violations
+6. **Property-Based Testing**: Mathematical properties (commutativity, associativity, idempotency)
+7. **Coverage Analysis**: Identifying and filling coverage gaps
+8. **Regression Testing**: Test generation from code changes and bug reports
+
+### Test Types (Not in Scope)
+The workflow focuses on simple, fast tests. Complex tests should be handled separately:
+- Integration tests between multiple services (requires heavy setup)
+- Complex UI rendering tests (requires heavy DOM setup)
+- E2E flows or end-to-end user journey tests
+- Performance/load testing
+- Tests requiring external API calls or database connections
 
 ### Coverage Targets
 Default targets (adjust if project-specific):
 - Lines: 80%
 - Branches: 70%
+- Functions: 90%
+
+Coverage is automatically analyzed and gaps are filled by generating additional tests.
 
 ## Template Reference
 See `feature-template.md` for the exact structure required for test plans.
@@ -48,4 +89,4 @@ See `feature-template.md` for the exact structure required for test plans.
 
 ---
 
-**Note**: For complex E2E tests, performance testing, or bug tracking strategies, document these separately or in project-level documentation.
+**Note**: For complex E2E tests, performance testing, or bug tracking strategies, document these separately or in project-level documentation. The `writing-test` command focuses on automated, logic-focused testing that AI agents excel at.

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

@@ -1,16 +1,48 @@
 # Test Plan: {Feature Name}
 
+## Test Files Created
+- `path/to/test-file.spec.js` - Tests for [component/function]
+- `path/to/another-test.spec.js` - Tests for [component/function]
+
 ## Unit Tests
-- Case 1: ...
-- Case 2: ...
-- Edge: ...
 
-## Integration Tests
-- Main flow: ...
-- Failure modes: ...
+### Function/Component Name
+- ✓ Happy path: normal parameters → expected output
+- ✓ Edge case: empty/null input → handled correctly  
+- ✓ Edge case: boundary values (min/max, 0, -1) → handled correctly
+- ✓ Parameter variation: [param1]=X, [param2]=Y → output Z
+- ✓ Error case: invalid input → throws/returns error
+- ✓ Type safety: wrong type input → handled correctly
+- ✓ Property-based: [property] maintained → verified
+
+### Another Function/Component
+- [Similar test cases...]
 
-## Manual Checklist
-- Steps for manual verification
+## Run Command
+```bash
+npm test
+# or
+npx vitest run
+# or language-specific command
+```
+
+## Last Run Results
+- Total: 15 tests
+- Passed: 14
+- Failed: 1
+- Skipped: 0
+- Coverage:
+  - Lines: 82% (123/150)
+  - Branches: 75% (30/40)
+  - Functions: 90% (18/20)
 
 ## Coverage Targets
-- Coverage goals and remaining gaps
+- Target: 80% (lines), 70% (branches)
+- Current: 82% (lines), 75% (branches)
+- Status: ✓ Targets met
+
+## Notes
+- All tests run automatically via command line
+- Test results logged to terminal with detailed output
+- Focus on logic testing, edge cases, and parameter variations
+- No complex integration or UI rendering tests

package/package.json

@@ -1,11 +1,11 @@
 {
   "name": "ai-workflow-init",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "Initialize AI workflow docs & commands into any repo with one command",
   "bin": {
     "ai-workflow-init": "./cli.js"
   },
-  "author": "your-name",
+  "author": "tuanpa",
   "license": "MIT",
   "repository": {
     "type": "git",
@@ -24,5 +24,18 @@
   },
   "engines": {
     "node": ">=14"
-  }
+  },
+  "scripts": {
+    "release": "node scripts/release.js",
+    "release:patch": "node scripts/release.js patch",
+    "release:minor": "node scripts/release.js minor",
+    "release:major": "node scripts/release.js major"
+  },
+  "files": [
+    "cli.js",
+    "docs/",
+    ".cursor/",
+    "AGENTS.md",
+    "README.md"
+  ]
 }

package/.npmignore

@@ -1,2 +0,0 @@
-node_modules
-.git