aiwf 0.3.7 → 0.3.12

package/claude-code/aiwf/en/.claude/commands/aiwf/aiwf_commit.md

@@ -1,160 +0,0 @@
-# Analyze Changes and Create Logical Git Commits
-
-Follow these instructions from top to bottom.
-
-## Create a TODO with EXACTLY these 6 items
-
-1. Parse arguments and analyze git status
-2. Review changes and group by logical commits
-3. Propose commit structure and messages
-4. Check if user approval is necessary
-5. Execute approved commits
-6. Report commit results
-
----
-
-## 1 · Analyze git status and parse arguments
-
-- Run these commands in parallel for maximum efficiency: `git status`, `git diff --staged`, `git diff`
-- List all changed files with their folder structure to understand the scope
-
-### CRITICAL: Argument Interpretation Rules
-
-**Context Provided** (when <$ARGUMENTS> contains text):
-
-- If YOLO is part of the <$ARGUMENTS> it is meant to skip user Approval (see Step 4 on your Todo)
-- The other text in <$ARGUMENTS> represents a **task ID**, **sprint ID**, or other **contextual identifier** provided by the user
-- This is NOT a file path - it's a semantic context for filtering changes
-- **PRIMARY FOCUS**: Only commit files directly related to this context
-- **SECONDARY CONSIDERATION**: After handling the primary context, ask if user wants to commit other unrelated changes
-
-**Task ID Pattern** (e.g., T01_S02, TX03_S01, T003):
-
-- Sprint Tasks: `T<NN>_S<NN>` format (e.g., T01_S02, T03_S02)
-- Completed Sprint Tasks: `TX<NN>_S<NN>` format (e.g., TX01_S02, TX03_S01)
-- General Tasks: `T<NNN>` format (e.g., T001, T002)
-- Completed General Tasks: `TX<NNN>` format (e.g., TX001, TX002)
-- Search for this task ID in:
-  - `.aiwf/03_SPRINTS/` directory (for sprint tasks)
-  - `.aiwf/04_GENERAL_TASKS/` directory (for general tasks)
-  - Task metadata in files (look for `task_id: T01_S02` in frontmatter)
-  - Git diff content (to see if code comments or commits reference the task)
-- Identify ALL files that were modified as part of this task's implementation
-- This includes: source code, tests, configuration, and the task documentation file itself
-
-**Sprint ID Pattern** (e.g., S01, S02):
-
-- When only sprint ID is provided, commit all changes related to ANY task within that sprint
-- Search pattern: `T*_S<NN>` in the sprint directory
-- Example: "S02" would include changes for T01_S02, T02_S02, T03_S02, etc.
-
-**No Context Provided** (when <$ARGUMENTS> is empty):
-
-- Analyze all changes and group them logically
-- Propose separate commits for different logical units of work
-
-### Implementation Steps
-
-1. First, determine if <$ARGUMENTS> contains any text
-2. If yes, explicitly state: "Context provided: '$ARGUMENTS' - I will focus on changes related to this context"
-3. If it's a task ID pattern, find the task file and understand what was implemented
-4. Filter the changed files to only those related to the identified context
-5. If no files match the context, inform the user: "No changes found related to '$ARGUMENTS'"
-6. If unrelated changes exist, mention them but DO NOT include in initial commit proposal
-
-## 2 · Review changes and group by logical commits
-
-### PRIORITY: Context Filtering
-
-**If context provided in arguments**:
-
-1. **FILTER FIRST**: Separate changes into two groups:
-   - **Related to context**: Files that are part of the task/context implementation
-   - **Unrelated to context**: Everything else
-2. **FOCUS**: Only analyze the "related to context" group for the first commit
-3. **DEFER**: Keep the "unrelated" group for potential later commits (only if user requests)
-
-**Standard grouping logic** (for no-context or within-context grouping):
-
-- **Think about** which changes belong together logically:
-  - Task completion (group by task ID when applicable)
-  - Feature additions (group by feature scope)
-  - Configuration updates (group separately)
-  - Documentation updates (group by documentation type)
-  - Bug fixes (group by related functionality)
-- **Think carefully** to ensure each commit represents one logical change that can be understood and potentially reverted independently
-- Avoid mixing unrelated changes in the same commit
-- Consider dependencies between changes when ordering commits
-
-## 3 · Propose commit
-
-### Context-Aware Commit Proposal
-
-**When context was provided** (e.g., task ID):
-
-- **FIRST COMMIT**: Must contain ONLY files related to the provided context
-- State clearly: "This commit includes changes for $ARGUMENTS"
-- After this commit is done, then ask: "There are also unrelated changes in [list files]. Would you like me to create additional commits for these?"
-
-**When no context provided**:
-
-- Propose commits based on logical grouping of all changes
-
-For the next commit to create:
-
-- **Context**: If applicable, which task/context this commit addresses
-- **Files**: List the specific files to be included
-- **Commit message**: Use conventional commit format, be clear and concise
-  - **CRITICAL:** Must not contain any attribution to Claude, Anthropic, or AI assistance
-  - If task-related, include task ID in message (e.g., "feat(agents): implement T01_S02 coordinator agent" or "fix(api): resolve T003 authentication issue")
-  - **GitHub Issue Linking**: If task has a GitHub issue, include `fixes #123` or `relates to #456` in commit message
-- **Reasoning**: Brief explanation of why these changes belong together
-
-## 4 · Check if user approval is necessary
-
-If YOLO **IS** part of the <$ARGUMENTS> skip this and jump to next step.
-
-Otherwise ask the User for approval.
-
-- Show the complete commit plan including files and message
-- Wait for explicit user confirmation before proceeding
-- If user says no, ask what should be changed
-- If user wants to modify the commit message or scope, make adjustments
-
-## 5 · Execute approved commit and continue
-
-For the approved commit:
-
-- Stage the specified files with `git add`
-- **IMPORTANT:** We are using pre-commit hooks that will likely report shortcomings. You need to fix them. Don't skip validation unless there are open tasks adressing especially these problems.
-- **Create the commit** with the approved message
-- Verify commit was created successfully
-- **GitHub Issue Update (if applicable):**
-  - If task has a linked GitHub issue
-  - Add commit link comment to issue:
-    ```bash
-    gh issue comment {issue_number} --body "🔗 Commit: {commit_sha} - {commit_message}"
-    ```
-- **IMPORTANT:** If there are more commits remaining, return to step 3 for the next commit
-- Only proceed to step 6 when all commits are completed
-
-## 6 · Report commit results
-
-Provide summary:
-
-- **Commits Created**: List each commit with SHA and message
-- **Files Committed**: Total count of files committed
-- **Remaining Changes**: Any uncommitted changes still pending
-- **Repository Status**: Current git status after commits
-
-## 7 · Generate Changelog (Optional)
-
-After successful commits:
-
-- Ask user: "Commits completed successfully. Would you like to update the Changelog? (y/n)"
-- If yes, execute: `/project:aiwf:changelog`
-- This will:
-  - Analyze recent commit history
-  - Generate or update CHANGELOG.md
-  - Categorize changes by type (feat, fix, docs, etc.)
-  - Include the commits just created

package/claude-code/aiwf/en/.claude/commands/aiwf/aiwf_create_feature_ledger.md

@@ -1,54 +0,0 @@
-# Create Feature Ledger
-
-Create a new Feature Ledger to track feature development.
-
-```bash
-cd .aiwf && node ../claude-code/aiwf/en/commands/feature-ledger.js create "$@"
-```
-
-## Description
-
-Feature Ledger is a system for systematically tracking and managing each feature development in your project. Use this command when you start developing a new feature.
-
-### 🎯 Key Features
-- Automatic Feature ID assignment (FL001, FL002...)
-- Standardized directory structure creation
-- Automatic Feature index updates
-- Git branch creation guidance
-
-### 📝 Usage
-```bash
-# Interactive mode (recommended)
-/project:aiwf:create_feature_ledger
-
-# Direct name specification
-/project:aiwf:create_feature_ledger user_authentication
-/project:aiwf:create_feature_ledger "Dashboard Redesign"
-```
-
-### 📂 Creation Location
-- `.aiwf/06_FEATURE_LEDGERS/active/FL###_feature_name.md`
-- Automatic index file update
-
-### ✅ Creation Process
-1. Check next available Feature ID
-2. Receive Feature metadata input
-3. Create Feature file
-4. Update index
-5. Provide Git branch creation guidance
-
-## Example Output
-```
-🎯 Feature Ledger created successfully!
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Feature ID: FL001
-Title: User Authentication System
-Status: active
-Priority: high
-Category: feature
-
-📁 File location: .aiwf/06_FEATURE_LEDGERS/active/FL001_user_authentication.md
-
-💡 Next steps:
-git checkout -b feature/FL001-user-authentication
-```

package/claude-code/aiwf/en/.claude/commands/aiwf/aiwf_create_general_task.md

@@ -1,147 +0,0 @@
-# Create General Task - Top-Down Execution
-
-Creates a new general task in `.aiwf/04_GENERAL_TASKS/` following project documentation standards.
-
-## Create a TODO with EXACTLY these 10 Items
-
-1. Parse task arguments and determine task ID
-2. Load project context and documentation requirements
-3. Verify task doesn't duplicate existing work
-4. Research codebase for implementation context
-5. Create task file using standard template
-6. Fill in task details with proper context
-7. Add technical guidance and codebase references
-8. Update project manifest with new task
-9. Validate task alignment with architecture
-10. Perform final quality check and report
-
-## DETAILS on every TODO item
-
-### 1. Parse task arguments and determine task ID
-
-The argument format is: `<Task Title or Description>`
-
-- If arguments are empty, prompt user for task details
-- Generate sequential task ID by examining existing tasks in `.aiwf/04_GENERAL_TASKS/`
-- Find highest task number (T###) and increment by 1
-- Format: `T###_<Task_Title_Snake_Case>.md`
-- **IMPORTANT:** Task IDs must be sequential with no gaps
-
-### 2. Load project context and documentation requirements
-
-Use PARALLEL SUBAGENTS to READ and UNDERSTAND the project's context:
-
-- READ `.aiwf/00_PROJECT_MANIFEST.md` - Get current project state
-- READ `.aiwf/01_PROJECT_DOCS/ARCHITECTURE.md` - Understand system constraints
-- READ `.aiwf/01_PROJECT_DOCS/LONG_TERM_VISION.md` - Understand future direction
-- READ latest files in `.aiwf/10_STATE_OF_PROJECT/` - Review current state
-- SCAN `.aiwf/05_ARCHITECTURE_DECISIONS/` for relevant ADRs
-- **IMPORTANT:** General tasks must align with documented architecture
-
-### 3. Verify task doesn't duplicate existing work
-
-**SEARCH** comprehensively for potential duplicates:
-
-- Check all files in `.aiwf/04_GENERAL_TASKS/`
-- Search sprint tasks in `.aiwf/03_SPRINTS/*/T*.md`
-- Look for similar functionality in completed milestones
-- **CRITICAL:** If duplicate found, stop and report to user with file reference
-
-### 4. Research codebase for implementation context
-
-Based on the task description, use PARALLEL SUBAGENTS to:
-
-- SEARCH for existing patterns similar to what the task requires
-- IDENTIFY key interfaces, classes, or modules that will be affected
-- FIND examples of similar implementations in the codebase
-- LOCATE relevant test patterns and existing test files
-- DISCOVER error handling and logging patterns used
-- MAP OUT integration points with existing code
-- **DOCUMENT** all findings for inclusion in task
-
-### 5. Create task file using standard template
-
-**USE** the task template in `.aiwf/99_TEMPLATES/task_template.md` as base structure:
-
-- Copy template structure exactly
-- Place file in `.aiwf/04_GENERAL_TASKS/T###_<Title>.md`
-- Include timestamp: Execute `date '+%Y-%m-%d %H:%M:%S'` for creation time
-- **IMPORTANT:** Follow template structure precisely - no deviations
-
-### 6. Fill in task details with proper context
-
-Populate the task file with:
-
-- **Title**: Clear, actionable task name
-- **Context**: Link to architecture docs and project state
-- **Requirements**: Specific, measurable outcomes
-- **Acceptance Criteria**: Clear definition of done
-- **Dependencies**: Reference relevant sprints/milestones
-- **Implementation Notes**: Technical approach aligned with architecture
-- **CRITICAL:** All content must reference existing documentation
-
-### 7. Add technical guidance and codebase references
-
-**Technical Guidance section:**
-
-- Key interfaces and integration points discovered in step 4
-- Specific imports and module references from codebase
-- Existing patterns to follow (with file references)
-- Database models or API contracts to work with
-- Error handling approach used in similar code
-- Testing patterns found in the codebase
-
-**Implementation Notes section:**
-
-- Step-by-step implementation approach based on research
-- Key architectural decisions to respect (reference ADRs)
-- Specific files and functions to modify or extend
-- Testing approach based on existing test patterns
-- Performance considerations if relevant
-
-**IMPORTANT:** Do NOT include code examples. Provide structural guidance and file references only.
-
-### 8. Update project manifest with new task
-
-**UPDATE** `.aiwf/00_PROJECT_MANIFEST.md`:
-
-- Add task to "## General Tasks" section
-- Format: `- [ ] T###: [Task Title] - Status: Not Started`
-- Maintain alphabetical/numerical ordering
-- Link to task file: `[T###](04_GENERAL_TASKS/T###_Title.md)`
-- **IMPORTANT:** Preserve all existing content
-
-### 9. Validate task alignment with architecture
-
-**VERIFY** task compliance:
-
-- Check task doesn't contradict architecture principles
-- Ensure implementation approach uses established patterns
-- Validate dependencies exist and are correct
-- Confirm task scope is appropriate (not too broad/narrow)
-- Technical guidance aligns with existing codebase patterns
-- **CRITICAL:** Documentation is source of truth - any deviation needs justification
-
-### 10. Perform final quality check and report
-
-**QUALITY CHECK**:
-
-- Task file follows template completely
-- All sections properly filled including new technical guidance
-- References to documentation and codebase are valid
-- Task ID is sequential and unique
-- Manifest updated correctly
-- Technical guidance references actual files and patterns
-- No scope creep or architecture violations
-
-**OUTPUT FORMAT**:
-
-```markdown
-✅ **Created**: T###\_<Title>.md
-📋 **Type**: General Task
-🎯 **Purpose**: [One-line summary]
-📚 **References**: [Key documentation links]
-🔧 **Key Integration Points**: [Main files/modules to modify]
-🧪 **Test Approach**: [Testing pattern to follow]
-⏭️ **Next Step**: Review task details and run `/do_task T###` to begin
-```

package/claude-code/aiwf/en/.claude/commands/aiwf/aiwf_create_milestone_plan.md

@@ -1,194 +0,0 @@
-# Create Milestone Plan - Top-Down Execution
-
-Creates a new milestone with proper structure, documentation, and project integration through an interactive, adaptive process.
-
-## Create a TODO with EXACTLY these 8 items
-
-1. Parse arguments and analyze project context
-2. Interactive milestone scoping and definition
-3. Determine milestone structure and naming
-4. Create milestone directory and meta file
-5. Guide supporting documentation creation
-6. Update project manifest with milestone
-7. Validate milestone coherence and alignment
-8. Report milestone creation and next steps
-
----
-
-## 1 · Parse arguments and analyze project context
-
-**CRITICAL:** You are given additional Arguments: <$ARGUMENTS>
-
-**USE PARALLEL SUBAGENTS** to do these tasks:
-
-- Parse arguments for suggested milestone name/focus (defaults to interactive creation)
-- Read `.aiwf/00_PROJECT_MANIFEST.md` to understand current project state
-- Scan `.aiwf/02_REQUIREMENTS/` to identify existing milestones and numbering
-- Read `.aiwf/01_PROJECT_DOCS/ARCHITECTURE.md` to understand project scope
-- Check latest project review in `.aiwf/10_STATE_OF_PROJECT/` for current status
-- **IMPORTANT:** Understand project phase and what logical next milestone should be
-
-## 2 · Interactive milestone scoping and definition
-
-**Conversational milestone definition:**
-
-If arguments provided:
-
-- "I see you want to create a milestone for: [arguments]"
-- "Let me understand the scope better..."
-
-If no arguments:
-
-- "Let's define your next milestone based on the current project state"
-- "I see you're currently on [current milestone] - what should we focus on next?"
-
-**Interactive questions (adapt based on context):**
-
-- "What's the main goal of this milestone?"
-- "What key deliverables should be completed?"
-- "Are there any specific technical challenges or requirements?"
-- "How does this milestone advance the project toward its long-term vision?"
-- "What would 'done' look like for this milestone?"
-
-**Keep conversational and adaptive** - don't interrogate, just gather what's needed
-
-## 3 · Determine milestone structure and naming
-
-**Generate milestone details:**
-
-- Determine next milestone number (M##) by scanning existing milestones
-- Create descriptive milestone name from user input
-- Format: `M##_Milestone_Name_Snake_Case`
-- **CRITICAL:** Ensure no duplicate milestone numbers
-- Validate naming follows AIWF conventions (underscores, no spaces)
-
-**Confirm with user:**
-
-- "I'll create milestone: M##\_[Name] - does this sound right?"
-- Allow user to adjust name or numbering if needed
-
-## 4 · Create milestone directory and meta file
-
-**Create milestone structure:**
-
-- Create directory: `.aiwf/02_REQUIREMENTS/M##_Milestone_Name/`
-- Copy template from `.aiwf/99_TEMPLATES/milestone_meta_template.md`
-- Create milestone meta file: `M##_milestone_meta.md`
-
-**Populate milestone meta file:**
-
-- Fill in YAML frontmatter:
-  - `milestone_id: M##`
-  - `title: [Milestone Name]`
-  - `status: pending`
-  - `last_updated: [current timestamp YYYY-MM-DD HH:MM]`
-- Convert user input into structured sections:
-  - **Goals**: Clear objectives from user discussion
-  - **Key Documents**: Placeholder for PRD and SPECS files
-  - **Definition of Done**: Specific, measurable criteria from user input
-  - **Notes/Context**: Additional context from user discussion
-
-## 5 · Guide supporting documentation creation
-
-**Interactive document planning:**
-
-Based on milestone scope, suggest needed documents:
-
-- "For this milestone, you'll likely need:"
-- "□ PRD\_[Milestone_Name].md - Product requirements"
-- "□ SPECS\_[Technical_Area].md - Technical specifications"
-- "□ Any domain-specific documentation"
-
-**Ask user:**
-
-- "Would you like me to create starter templates for these documents now?"
-- "Or would you prefer to create them manually as needed?"
-
-**If user wants templates created:**
-
-- Create basic PRD template with milestone-specific sections
-- Create SPECS template if technical milestone
-- Include proper cross-references between documents
-- **IMPORTANT:** Don't over-engineer - create useful starting points
-
-**If user prefers manual:**
-
-- Note in milestone meta what documents are expected
-- Provide guidance on when/how to create them
-
-## 6 · Update project manifest with milestone
-
-**UPDATE** `.aiwf/00_PROJECT_MANIFEST.md`:
-
-- Add milestone to milestones section:
-  - Format: `- [ ] M##: [Milestone Name] - Status: Planning`
-  - Link: `[M##](02_REQUIREMENTS/M##_Milestone_Name/M##_milestone_meta.md)`
-- Update project metadata:
-  - Set `current_milestone` if this is the active milestone
-  - Update `highest_milestone` number
-  - Update `last_updated` timestamp
-- **IMPORTANT:** Preserve all existing content and formatting
-
-## 7 · Validate milestone coherence and alignment
-
-**VERIFY** milestone quality:
-
-- Check milestone aligns with project architecture and vision
-- Ensure Definition of Done is specific and measurable
-- Validate milestone scope is appropriate (not too broad/narrow)
-- Confirm milestone advances project toward stated goals
-- Check milestone numbering and naming follows conventions
-- Verify all created files follow template structure
-- **CRITICAL:** Milestone should be independently valuable and achievable
-
-**THINK ABOUT**:
-
-- Does this milestone make sense given the current project state?
-- Are the goals realistic and well-scoped?
-- Is the Definition of Done clear enough to know when it's complete?
-- Does this milestone set up future milestones logically?
-
-## 8 · Report milestone creation and next steps
-
-**OUTPUT FORMAT**:
-
-```markdown
-✅ **Milestone Created**: M##\_[Milestone_Name]
-
-📋 **Milestone Details**:
-
-- ID: M##
-- Title: [Milestone Name]
-- Status: Planning
-- Focus: [One-line summary of main goal]
-
-📚 **Created Documents**:
-
-- Milestone meta: `02_REQUIREMENTS/M##_[Name]/M##_milestone_meta.md`
-- [Any additional documents created]
-
-🎯 **Definition of Done**:
-
-- [Key DoD criteria from milestone]
-
-📈 **Project Impact**:
-
-- Updates project from M[previous] to M##
-- Advances toward: [project vision alignment]
-
-⏭️ **Recommended Next Steps**:
-
-- Review milestone details: `02_REQUIREMENTS/M##_[Name]/M##_milestone_meta.md`
-- Create supporting documentation as planned
-- Break down into sprints: `/project:aiwf:create_sprints_from_milestone M##`
-- Update with specific requirements as they become clear
-
-🎯 **Ready for Development**: Use `/project:aiwf:create_sprints_from_milestone M##` when ready to start implementation planning
-```
-
-**IMPORTANT NOTES**:
-
-- Keep milestone scope focused and achievable
-- Definition of Done should be measurable
-- Supporting documents can be created as needed
-- Milestone planning is iterative - refine as you learn more