aiwf 0.1.0 → 0.3.1

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

@@ -0,0 +1,82 @@
+# Generate Changelog from Git Commit History
+
+Analyzes git commit history to generate a structured changelog.
+
+## Work Steps
+
+### 1. Analyze Git History
+- Analyze recent commits to understand changes
+- Check tag information (if available)
+- Parse conventional commit format from commit messages
+
+### 2. Categorize Changes
+Classify commits into the following categories:
+- ✨ Features (feat)
+- 🐛 Bug Fixes (fix)
+- 📝 Documentation (docs)
+- 🎨 Code Style (style)
+- ♻️ Refactoring (refactor)
+- ⚡ Performance (perf)
+- ✅ Tests (test)
+- 🔧 Build/Config (build, chore)
+
+### 3. Generate Changelog
+- Create or update CHANGELOG.md file
+- Organize sections by version (based on tags)
+- Group changes by category
+- Display with commit SHA
+
+### 4. Usage
+```bash
+# Basic execution (full history)
+/project:aiwf:changelog
+
+# Specify commit range
+/project:aiwf:changelog v1.0.0..HEAD
+
+# Recent commits with count
+/project:aiwf:changelog -n 50
+```
+
+### 5. Example Output
+```markdown
+# Changelog
+
+## [Unreleased]
+
+### ✨ Features
+- feat(auth): add social login functionality (abc1234)
+- feat(api): implement RESTful API v2 (def5678)
+
+### 🐛 Bug Fixes
+- fix(ui): correct mobile responsive layout (ghi9012)
+
+### 📝 Documentation
+- docs(readme): update installation guide (jkl3456)
+```
+
+## Implementation Details
+
+1. Parse Git Log:
+```bash
+git log --pretty=format:"%h|%s|%an|%ad" --date=short
+```
+
+2. Conventional Commit Pattern Matching:
+```regex
+^(feat|fix|docs|style|refactor|perf|test|build|chore)(\(.+\))?:\s+(.+)$
+```
+
+3. Utilize Tag Information:
+```bash
+git describe --tags --abbrev=0
+```
+
+4. Apply changelog template and generate file
+
+5. Merge appropriately if existing CHANGELOG.md exists
+
+## Notes
+- Commits not following Conventional Commit format are classified as "Other Changes"
+- Merge commits are excluded by default
+- Generated changelog can be manually edited after review

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

@@ -0,0 +1,88 @@
+# Code Review - Top-Down Execution
+
+Use the following instructions from top to bottom to execute a Code Review.
+
+## Create a TODO with EXACTLY these 6 Items
+
+1. Analyze the Scope given
+2. Find code changes within Scope
+3. Find relevant Specification and Documentation
+4. Compare code changes against Documentation and Requirements
+5. Analyze possible differences
+6. Provide PASS/FAIL verdict with details
+
+Follow step by step and adhere closely to the following instructions for each step.
+
+## DETAILS on every TODO item
+
+### 1. Analyze the Scope given
+
+check: <$ARGUMENTS>
+
+If empty, use default, otherwise interpret <$ARGUMENTS> to identify the scope of the Review. Only continue if you can find meaningful changes to review.
+
+**CONTEXT:** Before reviewing code changes:
+
+- Read `.aiwf/00_PROJECT_MANIFEST.md` to understand current sprint and milestone context
+- Use the manifest to identify which sprint is active and what work is in scope
+- Only evaluate against requirements appropriate for the current sprint's deliverables
+
+### 2. Find code changes within Scope
+
+With the identified Scope use `git diff` (on default: `git diff HEAD~1`) to find code changes.
+
+### 3. Find relevant Specifications and Documentation
+
+- FIND the Task, Sprint and Milestone involved in the work that was done and output your findings
+- Navigate to `.aiwf/03_SPRINTS/` to find the current sprint directory
+- READ the sprint meta file to understand sprint objectives and deliverables
+- If a specific task is in scope, find and READ the task file in the sprint directory
+- IDENTIFY related requirements in `.aiwf/02_REQUIREMENTS/` for the current milestone
+- READ involved Documents especially in `.aiwf/01_PROJECT_DOCS/` and `.aiwf/02_REQUIREMENTS/`
+- **IMPORTANT:** Focus on current sprint deliverables, not future milestone features
+
+### 4. Compare code changes against Documentation and Requirements
+
+- Use DEEP THINKING to compare changes against found Requirements and Specs.
+- Compare especially these things:
+  - **Data models / schemas** — fields, types, constraints, relationships.
+  - **APIs / interfaces** — endpoints, params, return shapes, status codes, errors.
+  - **Config / environment** — keys, defaults, required/optional.
+  - **Behaviour** — business rules, side-effects, error handling.
+  - **Quality** — naming, formatting, tests, linter status.
+
+**IMPORTANT**:
+
+- Deviations from the Specs is not allowed. Not even small ones. Be very picky here!
+- If in doubt call a **FAIL** and ask the User.
+- Zero tolerance on not following the Specs and Documentation.
+
+### 5. Analyze the differences
+
+- Analyze any difference found
+- Give every issue a Severity Score
+- Severity ranges from 1 (low) to 10 (high)
+- Remember List of issues and Scores for output
+
+### 6. Provide PASS/FAIL verdict with details
+
+- Call a **FAIL** on any differences found.
+  - Zero Tolerance - even on well meant additions.
+  - Leave it on the user to decide if small changes are allowed.
+- Only **PASS** if no discrepancy appeared.
+
+#### IMPORTANT: Output Format
+
+- Output the results of your review to the task's **## Output Log** section in the task file
+- Find the task file in `.aiwf/03_SPRINTS/` or `.aiwf/04_GENERAL_TASKS/` based on the scope
+- Append the review results to the existing Output Log with timestamp
+- Output Format:
+  ```
+  [YYYY-MM-DD HH:MM]: Code Review - PASS/FAIL
+  Result: **FAIL/PASS** Your final decision on if it's a PASS or a FAIL.
+  **Scope:** Inform the user about the review scope.
+  **Findings:** Detailed list with all Issues found and Severity Score.
+  **Summary:** Short summary on what is wrong or not.
+  **Recommendation:** Your personal recommendation on further steps.
+  ```
+- Also output a brief result summary to the console for immediate feedback

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

@@ -0,0 +1,160 @@
+# 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_general_task.md

@@ -0,0 +1,147 @@
+# 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

@@ -0,0 +1,194 @@
+# 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