plugins/projman/README.md

@@ -114,6 +114,17 @@ Check current sprint progress.
 
 **When to use:** Daily standup, progress check, deciding what to work on next
 
+### `/proposal-status`
+View proposal and implementation hierarchy.
+
+**What it does:**
+- Lists all change proposals from Gitea Wiki
+- Shows implementations under each proposal with status
+- Displays linked issues and lessons learned
+- Tree-style formatted output
+
+**When to use:** Review progress on multi-sprint features, track proposal lifecycle
+
 ### `/sprint-close`
 Complete sprint and capture lessons learned.
 
@@ -468,6 +479,7 @@ projman/
 │   ├── sprint-start.md
 │   ├── sprint-status.md
 │   ├── sprint-close.md
+│   ├── proposal-status.md
 │   ├── labels-sync.md
 │   ├── initial-setup.md
 │   ├── project-init.md

plugins/projman/agents/orchestrator.md

@@ -357,6 +357,11 @@ Let's capture lessons learned. I'll ask some questions:
 ```markdown
 # Sprint {N} - {Clear Title}
 
+## Metadata
+- **Implementation:** [Change VXX.X.X (Impl N)](wiki-link)
+- **Issues:** #XX, #XX
+- **Sprint:** Sprint N
+
 ## Context
 Brief background - what were you doing?
 
@@ -373,17 +378,94 @@ How can future sprints avoid this or optimize it?
 technology, component, issue-type, pattern
 ```
 
+**IMPORTANT:** Always include the Metadata section with implementation link for traceability.
+
 **D. Save to Gitea Wiki**
+
+Include the implementation reference in lesson content:
 ```
 create_lesson(
     title="Sprint 18 - Claude Code Infinite Loop on Validation Errors",
-    content="[Full lesson content]",
+    content="""
+# Sprint 18 - Claude Code Infinite Loop on Validation Errors
+
+## Metadata
+- **Implementation:** [Change V1.2.0 (Impl 1)](wiki-link)
+- **Issues:** #45, #46
+- **Sprint:** Sprint 18
+
+## Context
+[Lesson context...]
+
+## Problem
+[What went wrong...]
+
+## Solution
+[How it was solved...]
+
+## Prevention
+[How to avoid in future...]
+
+## Tags
+testing, claude-code, validation, python
+""",
     tags=["testing", "claude-code", "validation", "python"],
     category="sprints"
 )
 ```
 
-**E. Git Operations**
+**E. Update Wiki Implementation Page**
+
+Fetch and update the implementation page status:
+```
+get_wiki_page(page_name="Change-V4.1.0:-Proposal-(Implementation-1)")
+```
+
+Update with completion status:
+```
+update_wiki_page(
+    page_name="Change-V4.1.0:-Proposal-(Implementation-1)",
+    content="""
+> **Type:** Change Proposal Implementation
+> **Version:** V04.1.0
+> **Status:** Implemented ✅
+> **Date:** 2026-01-26
+> **Completed:** 2026-01-28
+> **Origin:** [Proposal](wiki-link)
+> **Sprint:** Sprint 17
+
+# Implementation Details
+[Original content...]
+
+## Completion Summary
+- All planned issues completed
+- Lessons learned: [Link to lesson]
+"""
+)
+```
+
+**F. Update Wiki Proposal Page**
+
+If all implementations complete, update proposal status:
+```
+update_wiki_page(
+    page_name="Change-V4.1.0:-Proposal",
+    content="""
+> **Type:** Change Proposal
+> **Version:** V04.1.0
+> **Status:** Implemented ✅
+> **Date:** 2026-01-26
+
+# Feature Title
+[Original content...]
+
+## Implementations
+- [Implementation 1](link) - ✅ Completed (Sprint 17)
+"""
+)
+```
+
+**G. Git Operations**
 
 Offer to handle git cleanup:
 ```
@@ -418,7 +500,9 @@ Would you like me to handle git operations?
 **Lessons Learned Tools (Gitea Wiki):**
 - `search_lessons(query, tags, limit)` - Find relevant past lessons
 - `create_lesson(title, content, tags, category)` - Save new lesson
-- `get_wiki_page(page_name)` - Fetch specific pages
+- `get_wiki_page(page_name)` - Fetch implementation/proposal pages
+- `update_wiki_page(page_name, content)` - Update implementation/proposal status
+- `list_wiki_pages()` - List all wiki pages
 
 **Validation Tools:**
 - `get_branch_protection(branch)` - Check merge rules
@@ -455,6 +539,8 @@ Would you like me to handle git operations?
 8. **Auto-check subtasks** - Mark issue subtasks complete on close
 9. **Track meticulously** - Update issues immediately, document blockers
 10. **Capture lessons** - At sprint close, interview thoroughly
+11. **Update wiki status** - At sprint close, update implementation and proposal pages
+12. **Link lessons to wiki** - Include lesson links in implementation completion summary
 
 ## Your Mission
 

plugins/projman/agents/planner.md

@@ -122,23 +122,34 @@ get_labels(repo="owner/repo")
 - Use `create_label` to create them
 - Report which labels were created
 
-### 4. docs/changes/ Folder Check
+### 4. Input Source Detection
 
-Verify the project has a `docs/changes/` folder for sprint input files.
+Detect where the planning input is coming from:
 
-**If folder exists:**
+| Source | Detection | Action |
-- Check for relevant change files for current sprint
+|--------|-----------|--------|
-- Reference these files during planning
+| **Local file** | `docs/changes/*.md` exists | Parse frontmatter, migrate to wiki, delete local |
+| **Existing wiki** | `Change VXX.X.X: Proposal` exists | Use as-is, create new implementation page |
+| **Conversation** | Neither file nor wiki exists | Create wiki from discussion context |
 
-**If folder does NOT exist:**
+**Input File Format** (if using local file):
-- Prompt user: "Your project doesn't have a `docs/changes/` folder. This folder stores sprint planning inputs and decisions. Would you like me to create it?"
+```yaml
-- If user agrees, create the folder structure
+---
+version: "4.1.0"        # or "sprint-17" for internal work
+title: "Feature Name"
+plugin: plugin-name     # optional
+type: feature           # feature | bugfix | refactor | infra
+---
 
-**If sprint starts with discussion but no input file:**
+# Feature Description
-- Capture the discussion outputs
+[Free-form content...]
-- Create a change file: `docs/changes/sprint-XX-description.md`
+```
-- Structure the file to meet Claude Code standards (concise, focused, actionable)
+
-- Then proceed with sprint planning using that file
+**Detection Steps:**
+1. Check for `docs/changes/*.md` files with valid frontmatter
+2. Use `list_wiki_pages()` to check for existing proposal
+3. If neither found, use conversation context
+4. If ambiguous (multiple sources), ask user which to use
 
 ## Your Responsibilities
 
@@ -161,7 +172,30 @@ Great! Let me ask a few questions to understand the scope:
 5. Should this integrate with existing systems?
 ```
 
-### 2. Search Relevant Lessons Learned
+### 2. Detect Input Source
+
+Before proceeding, identify where the planning input is:
+
+```
+# Check for local files
+ls docs/changes/*.md
+
+# Check for existing wiki proposal
+list_wiki_pages() → filter for "Change V" prefix
+```
+
+**Report to user:**
+```
+Input source detected:
+✓ Found: docs/changes/v4.1.0-wiki-planning.md
+  - Version: 4.1.0
+  - Title: Wiki-Based Planning Workflow
+  - Type: feature
+
+I'll use this as the planning input. Proceed? (y/n)
+```
+
+### 3. Search Relevant Lessons Learned
 
 **ALWAYS search for past lessons** before planning:
 
@@ -192,7 +226,59 @@ I searched previous sprint lessons and found these relevant insights:
 I'll keep these in mind while planning this sprint.
 ```
 
-### 3. Architecture Analysis
+### 4. Create Wiki Proposal and Implementation Pages
+
+After detecting input and searching lessons, create the wiki structure:
+
+**Create/Update Proposal Page:**
+```
+# If no proposal exists for this version:
+create_wiki_page(
+    title="Change V4.1.0: Proposal",
+    content="""
+> **Type:** Change Proposal
+> **Version:** V04.1.0
+> **Plugin:** projman
+> **Status:** In Progress
+> **Date:** 2026-01-26
+
+# Feature Title
+
+[Content migrated from input source]
+
+## Implementations
+- [Implementation 1](link) - Current sprint
+"""
+)
+```
+
+**Create Implementation Page:**
+```
+create_wiki_page(
+    title="Change V4.1.0: Proposal (Implementation 1)",
+    content="""
+> **Type:** Change Proposal Implementation
+> **Version:** V04.1.0
+> **Status:** In Progress
+> **Date:** 2026-01-26
+> **Origin:** [Proposal](wiki-link)
+> **Sprint:** Sprint 17
+
+# Implementation Details
+
+[Technical details, scope, approach]
+"""
+)
+```
+
+**Update Proposal with Implementation Link:**
+- Add link to new implementation in the Implementations section
+
+**Cleanup Local File:**
+- If input came from `docs/changes/*.md`, delete the file
+- Wiki is now the single source of truth
+
+### 5. Architecture Analysis
 
 Think through the technical approach:
 
@@ -204,7 +290,7 @@ Think through the technical approach:
 - What's the data flow?
 - What are potential risks?
 
-### 4. Create Gitea Issues with Proper Naming
+### 6. Create Gitea Issues with Wiki Reference
 
 **Issue Title Format (MANDATORY):**
 ```
@@ -233,17 +319,29 @@ Think through the technical approach:
 
 **If a task is too large, break it down into smaller tasks.**
 
-Use the `create_issue` and `suggest_labels` MCP tools:
+**IMPORTANT: Include wiki implementation reference in issue body:**
 
 ```
 create_issue(
     title="[Sprint 17] feat: Implement JWT token generation",
-    body="## Description\n\n...\n\n## Acceptance Criteria\n\n...",
+    body="""## Description
+
+[Description here]
+
+## Implementation
+
+**Wiki:** [Change V4.1.0 (Implementation 1)](https://gitea.example.com/org/repo/wiki/Change-V4.1.0%3A-Proposal-(Implementation-1))
+
+## Acceptance Criteria
+
+- [ ] Criteria 1
+- [ ] Criteria 2
+""",
     labels=["Type/Feature", "Priority/High", "Component/Auth", "Tech/Python"]
 )
 ```
 
-### 5. Set Up Dependencies
+### 7. Set Up Dependencies
 
 After creating issues, establish dependencies using native Gitea dependencies:
 
@@ -256,7 +354,7 @@ create_issue_dependency(
 
 This creates a relationship where issue #46 depends on #45 completing first.
 
-### 6. Create or Select Milestone
+### 8. Create or Select Milestone
 
 Use milestones to group sprint issues:
 
@@ -270,7 +368,7 @@ create_milestone(
 
 Then assign issues to the milestone when creating them.
 
-### 7. Generate Planning Document
+### 9. Generate Planning Document
 
 Summarize the sprint plan:
 
@@ -338,11 +436,13 @@ Sprint 17 - User Authentication (Due: 2025-02-01)
 - `create_issue_dependency(issue_number, depends_on)` - Create dependency
 - `get_execution_order(issue_numbers)` - Get parallel execution order
 
-**Lessons Learned Tools (Gitea Wiki):**
+**Lessons Learned & Wiki Tools:**
 - `search_lessons(query, tags, limit)` - Search lessons learned
 - `create_lesson(title, content, tags, category)` - Create lesson
 - `list_wiki_pages()` - List wiki pages
 - `get_wiki_page(page_name)` - Get wiki page content
+- `create_wiki_page(title, content)` - Create new wiki page (proposals, implementations)
+- `update_wiki_page(page_name, content)` - Update wiki page content
 
 ## Communication Style
 
@@ -370,11 +470,14 @@ Sprint 17 - User Authentication (Due: 2025-02-01)
 2. **Always check branch first** - No planning on production!
 3. **Always validate repo is under organization** - Fail fast if not
 4. **Always validate labels exist** - Create missing ones
-5. **Always check for docs/changes/ folder** - Create if missing
+5. **Always detect input source** - Check file, wiki, or use conversation
-6. **Always search lessons learned** - Prevent repeated mistakes
+6. **Always create wiki proposal and implementation** - Before creating issues
-7. **Always use proper naming** - `[Sprint XX] <type>: <description>`
+7. **Always search lessons learned** - Prevent repeated mistakes
-8. **Always set up dependencies** - Use native Gitea dependencies
+8. **Always use proper naming** - `[Sprint XX] <type>: <description>`
-9. **Always use suggest_labels** - Don't guess labels
+9. **Always include wiki reference** - Add implementation link to issues
-10. **Always think through architecture** - Consider edge cases
+10. **Always set up dependencies** - Use native Gitea dependencies
+11. **Always use suggest_labels** - Don't guess labels
+12. **Always think through architecture** - Consider edge cases
+13. **Always cleanup local files** - Delete after migrating to wiki
 
 You are the thoughtful planner who ensures sprints are well-prepared, architecturally sound, and learn from past experiences. Take your time, ask questions, and create comprehensive plans that set the team up for success.

plugins/projman/commands/proposal-status.md

@@ -0,0 +1,121 @@
+---
+description: View proposal and implementation hierarchy with status tracking
+---
+
+# Proposal Status
+
+View the status of all change proposals and their implementations in the Gitea Wiki.
+
+## Overview
+
+This command provides a tree view of:
+- All change proposals (`Change VXX.X.X: Proposal`)
+- Their implementations (`Change VXX.X.X: Proposal (Implementation N)`)
+- Linked issues and lessons learned
+
+## Workflow
+
+1. **Fetch All Wiki Pages**
+   - Use `list_wiki_pages()` to get all wiki pages
+   - Filter for pages matching `Change V*: Proposal*` pattern
+
+2. **Parse Proposal Structure**
+   - Group implementations under their parent proposals
+   - Extract status from page metadata (In Progress, Implemented, Abandoned)
+
+3. **Fetch Linked Artifacts**
+   - For each implementation, search for issues referencing it
+   - Search lessons learned that link to the implementation
+
+4. **Display Tree View**
+   ```
+   Change V04.1.0: Proposal [In Progress]
+   ├── Implementation 1 [In Progress] - 2026-01-26
+   │   ├── Issues: #161, #162, #163, #164
+   │   └── Lessons: (pending)
+   └── Implementation 2 [Not Started]
+
+   Change V04.0.0: Proposal [Implemented]
+   └── Implementation 1 [Implemented] - 2026-01-20
+       ├── Issues: #150, #151
+       └── Lessons: v4.0.0-impl-1-lessons
+   ```
+
+## MCP Tools Used
+
+- `list_wiki_pages()` - List all wiki pages
+- `get_wiki_page(page_name)` - Get page content for status extraction
+- `list_issues(state, labels)` - Find linked issues
+- `search_lessons(query, tags)` - Find linked lessons
+
+## Status Definitions
+
+| Status | Meaning |
+|--------|---------|
+| **Pending** | Proposal created but no implementation started |
+| **In Progress** | At least one implementation is active |
+| **Implemented** | All planned implementations complete |
+| **Abandoned** | Proposal was cancelled or superseded |
+
+## Filtering Options
+
+The command accepts optional filters:
+
+```
+/proposal-status                    # Show all proposals
+/proposal-status --version V04.1.0  # Show specific version
+/proposal-status --status "In Progress"  # Filter by status
+```
+
+## Example Output
+
+```
+Proposal Status Report
+======================
+
+Change V04.1.0: Wiki-Based Planning Workflow [In Progress]
+├── Implementation 1 [In Progress] - Started: 2026-01-26
+│   ├── Issues: #161 (closed), #162 (closed), #163 (closed), #164 (open)
+│   └── Lessons: (pending - sprint not closed)
+│
+└── (No additional implementations planned)
+
+Change V04.0.0: MCP Server Consolidation [Implemented]
+├── Implementation 1 [Implemented] - 2026-01-15 to 2026-01-20
+│   ├── Issues: #150 (closed), #151 (closed), #152 (closed)
+│   └── Lessons:
+│       • Sprint 15 - MCP Server Symlink Best Practices
+│       • Sprint 15 - Venv Path Resolution in Plugins
+│
+└── (Complete)
+
+Change V03.2.0: Label Taxonomy Sync [Implemented]
+└── Implementation 1 [Implemented] - 2026-01-10 to 2026-01-12
+    ├── Issues: #140 (closed), #141 (closed)
+    └── Lessons:
+        • Sprint 14 - Organization vs Repository Labels
+
+Summary:
+- Total Proposals: 3
+- In Progress: 1
+- Implemented: 2
+- Pending: 0
+```
+
+## Implementation Notes
+
+**Page Name Parsing:**
+- Proposals: `Change VXX.X.X: Proposal` or `Change Sprint-NN: Proposal`
+- Implementations: `Change VXX.X.X: Proposal (Implementation N)`
+
+**Status Extraction:**
+- Parse the `> **Status:**` line from page metadata
+- Default to "Unknown" if not found
+
+**Issue Linking:**
+- Search for issues containing wiki link in body
+- Or search for issues with `[Sprint XX]` prefix matching implementation
+
+**Lesson Linking:**
+- Search lessons with implementation link in metadata
+- Or search by version/sprint tags

plugins/projman/commands/sprint-close.md

@@ -41,13 +41,26 @@ The orchestrator agent will guide you through:
    - Create lessons in project wiki under `lessons-learned/sprints/`
    - Make lessons searchable for future sprints
 
-5. **Git Operations**
+5. **Update Wiki Implementation Page**
+   - Use `get_wiki_page` to fetch the current implementation page
+   - Update status from "In Progress" to "Implemented" (or "Partial"/"Failed")
+   - Add completion date
+   - Link to lessons learned created in step 4
+   - Use `update_wiki_page` to save changes
+
+6. **Update Wiki Proposal Page**
+   - Check if all implementations for this proposal are complete
+   - If all complete: Update proposal status to "Implemented"
+   - If partial: Keep status as "In Progress", note completed implementations
+   - Add summary of what was accomplished
+
+7. **Git Operations**
    - Commit any remaining work
    - Merge feature branches if needed
    - Clean up merged branches
    - Tag sprint completion
 
-6. **Close Milestone**
+8. **Close Milestone**
    - Use `update_milestone` to close the sprint milestone
    - Document final completion status
 
@@ -66,7 +79,8 @@ The orchestrator agent will guide you through:
 - `create_lesson` - Create lessons learned entry
 - `search_lessons` - Check for similar existing lessons
 - `list_wiki_pages` - Check existing lessons learned
-- `get_wiki_page` - Read existing lessons
+- `get_wiki_page` - Read existing lessons or implementation pages
+- `update_wiki_page` - Update implementation/proposal status
 
 ## Lesson Structure
 
@@ -75,6 +89,11 @@ Lessons should follow this structure:
 ```markdown
 # Sprint X - [Lesson Title]
 
+## Metadata
+- **Implementation:** [Change VXX.X.X (Impl N)](wiki-link)
+- **Issues:** #45, #46, #47
+- **Sprint:** Sprint X
+
 ## Context
 [What were you trying to do? What was the sprint goal?]
 
@@ -91,12 +110,19 @@ Lessons should follow this structure:
 [Comma-separated tags for search: technology, component, type]
 ```
 
+**IMPORTANT:** Always include the Implementation link in the Metadata section. This enables bidirectional traceability between lessons and the work that generated them.
+
 ## Example Lessons Learned
 
 **Example 1: Technical Gotcha**
 ```markdown
 # Sprint 16 - Claude Code Infinite Loop on Validation Errors
 
+## Metadata
+- **Implementation:** [Change V1.2.0 (Impl 1)](https://gitea.example.com/org/repo/wiki/Change-V1.2.0%3A-Proposal-(Implementation-1))
+- **Issues:** #45, #46
+- **Sprint:** Sprint 16
+
 ## Context
 Implementing input validation for authentication API endpoints.
 
@@ -123,6 +149,11 @@ testing, claude-code, validation, python, pytest, debugging
 ```markdown
 # Sprint 14 - Extracting Services Too Early
 
+## Metadata
+- **Implementation:** [Change V2.0.0 (Impl 1)](https://gitea.example.com/org/repo/wiki/Change-V2.0.0%3A-Proposal-(Implementation-1))
+- **Issues:** #32, #33, #34
+- **Sprint:** Sprint 14
+
 ## Context
 Planning to extract Intuit Engine service from monolith.
 

plugins/projman/commands/sprint-plan.md

@@ -47,15 +47,34 @@ Verify all required labels exist using `get_labels`:
 
 **If labels are missing:** Use `create_label` to create them.
 
-### 4. docs/changes/ Folder Check
+### 4. Input Source Detection
 
-Verify the project has a `docs/changes/` folder for sprint input files.
+The planner supports flexible input sources for sprint planning:
 
-**If folder does NOT exist:** Prompt user to create it.
+| Source | Detection | Action |
+|--------|-----------|--------|
+| **Local file** | `docs/changes/*.md` exists | Parse frontmatter, migrate to wiki, delete local |
+| **Existing wiki** | `Change VXX.X.X: Proposal` exists | Use as-is, create new implementation page |
+| **Conversation** | Neither file nor wiki exists | Create wiki from discussion context |
 
-**If sprint starts with discussion but no input file:**
+**Input File Format** (if using local file):
-- Capture the discussion outputs
+```yaml
-- Create a change file: `docs/changes/sprint-XX-description.md`
+---
+version: "4.1.0"        # or "sprint-17" for internal work
+title: "Feature Name"
+plugin: plugin-name     # optional
+type: feature           # feature | bugfix | refactor | infra
+---
+
+# Feature Description
+[Free-form content...]
+```
+
+**Detection Logic:**
+1. Check for `docs/changes/*.md` files
+2. Check for existing wiki proposal matching version
+3. If neither found, use conversation context
+4. If ambiguous, ask user which input to use
 
 ## Planning Workflow
 
@@ -66,36 +85,56 @@ The planner agent will:
    - Understand scope, priorities, and constraints
    - Never rush - take time to understand requirements fully
 
-2. **Search Relevant Lessons Learned**
+2. **Detect Input Source**
+   - Check for `docs/changes/*.md` files
+   - Check for existing wiki proposal by version
+   - If neither: use conversation context
+   - Ask user if multiple sources found
+
+3. **Search Relevant Lessons Learned**
    - Use the `search_lessons` MCP tool to find past experiences
    - Search by keywords and tags relevant to the sprint work
    - Review patterns and preventable mistakes from previous sprints
 
-3. **Architecture Analysis**
+4. **Create/Update Wiki Proposal**
+   - If local file: migrate content to wiki, create proposal page
+   - If conversation: create proposal from discussion
+   - If existing wiki: skip creation, use as-is
+   - **Page naming:** `Change VXX.X.X: Proposal` or `Change Sprint-NN: Proposal`
+
+5. **Create Wiki Implementation Page**
+   - Create `Change VXX.X.X: Proposal (Implementation N)`
+   - Include tags: Type, Version, Status=In Progress, Date, Origin
+   - Update proposal page with link to this implementation
+   - This page tracks THIS sprint's work on the proposal
+
+6. **Architecture Analysis**
    - Think through technical approach and edge cases
    - Identify architectural decisions needed
    - Consider dependencies and integration points
    - Review existing codebase architecture
 
-4. **Create Gitea Issues**
+7. **Create Gitea Issues**
    - Use the `create_issue` MCP tool for each planned task
    - Apply appropriate labels using `suggest_labels` tool
    - **Issue Title Format (MANDATORY):** `[Sprint XX] <type>: <description>`
+   - **Include wiki reference:** `Implementation: [Change VXX.X.X (Impl N)](wiki-link)`
    - Include acceptance criteria and technical notes
 
-5. **Set Up Dependencies**
+8. **Set Up Dependencies**
    - Use `create_issue_dependency` to establish task dependencies
    - This enables parallel execution planning
 
-6. **Create or Select Milestone**
+9. **Create or Select Milestone**
    - Use `create_milestone` to group sprint issues
    - Assign issues to the milestone
 
-7. **Generate Planning Document**
+10. **Cleanup & Summary**
-   - Summarize architectural decisions
+    - Delete local input file (wiki is now source of truth)
-   - List created issues with labels
+    - Summarize architectural decisions
-   - Document dependency graph
+    - List created issues with labels
-   - Provide sprint overview
+    - Document dependency graph
+    - Provide sprint overview with wiki links
 
 ## Issue Title Format (MANDATORY)
 
@@ -152,6 +191,8 @@ The planner agent will:
 - `search_lessons` - Search lessons learned from previous sprints
 - `list_wiki_pages` - List wiki pages
 - `get_wiki_page` - Fetch specific documentation page
+- `create_wiki_page` - Create new wiki page (proposals, implementations)
+- `update_wiki_page` - Update wiki page content
 
 ## Label Taxonomy
 
@@ -181,16 +222,17 @@ The planner agent is thoughtful and methodical:
 User: I want to plan a sprint for user authentication
 Planner: Great! Let me first run pre-planning validations...
 
-[Checks branch, repo org, labels, docs/changes folder]
+[Checks branch, repo org, labels]
+All validations passed.
 
-All validations passed. Now let me ask a few questions:
+[Checks for input sources]
+Found: docs/changes/v1.2.0-user-authentication.md
+
+I'll use this file as the planning input. Let me ask a few questions:
 
 1. What authentication method are you planning? (JWT, OAuth, session-based?)
 2. Are there any specific security requirements or compliance needs?
 3. Should this integrate with existing user management?
-4. What's the priority level for this sprint?
-
-Let me also search for relevant lessons learned about authentication...
 
 [Uses search_lessons to find past authentication work]
 
@@ -198,22 +240,23 @@ Based on previous experience, I found these relevant lessons:
 - Sprint 12: JWT token expiration handling edge cases
 - Sprint 8: OAuth integration pitfalls with third-party providers
 
-Now, let me analyze the architecture...
+[Creates wiki proposal and implementation pages]
+✓ Created: "Change V1.2.0: Proposal" (wiki)
+✓ Created: "Change V1.2.0: Proposal (Implementation 1)" (wiki)
+✓ Deleted: docs/changes/v1.2.0-user-authentication.md (migrated to wiki)
 
-[Creates issues with appropriate labels and dependencies]
+Now, let me analyze the architecture and create issues...
+
+[Creates issues with wiki references]
 
 Created 5 issues for the authentication sprint:
 - Issue #45: [Sprint 17] feat: Implement JWT token generation
   Labels: Type/Feature, Priority/High, Component/Auth, Tech/Python
-  Dependencies: None
+  Implementation: [Change V1.2.0 (Impl 1)](wiki-link)
 
 - Issue #46: [Sprint 17] feat: Build user login endpoint
   Labels: Type/Feature, Priority/High, Component/API, Tech/FastAPI
-  Dependencies: #45
+  Implementation: [Change V1.2.0 (Impl 1)](wiki-link)
-
-- Issue #47: [Sprint 17] feat: Create user registration form
-  Labels: Type/Feature, Priority/Medium, Component/Frontend, Tech/Vue
-  Dependencies: #46
 
 Dependency Graph:
 #45 -> #46 -> #47
@@ -222,20 +265,28 @@ Dependency Graph:
       #48
 
 Milestone: Sprint 17 - User Authentication (Due: 2025-02-01)
+Wiki: https://gitea.example.com/org/repo/wiki/Change-V1.2.0%3A-Proposal
 ```
 
 ## Getting Started
 
 Invoke the planner agent by providing your sprint goals. The agent will guide you through the planning process.
 
+**Input Options:**
+1. Create `docs/changes/vX.Y.Z-feature-name.md` with frontmatter before running
+2. Create wiki proposal page manually, then run `/sprint-plan`
+3. Just start a conversation - the planner will capture context and create wiki pages
+
 **Example:**
 > "I want to plan a sprint for extracting the Intuit Engine service from the monolith"
 
 The planner will then:
 1. Run pre-planning validations
-2. Ask clarifying questions
+2. Detect input source (file, wiki, or conversation)
-3. Search lessons learned
+3. Ask clarifying questions
-4. Create issues with proper naming and labels
+4. Search lessons learned
-5. Set up dependencies
+5. Create wiki proposal and implementation pages
-6. Create milestone
+6. Create issues with wiki references
-7. Generate planning summary
+7. Set up dependencies
+8. Create milestone
+9. Cleanup and generate planning summary