chore: release v4.1.0

Problem: Version workflow was documented but not enforced in sprint-close.
After completing sprints, CHANGELOG wasn't updated and releases weren't created.

Solution:
- Add "Update CHANGELOG" as mandatory step 7 in sprint-close
- Add "Version Check" as step 8 with /suggest-version and release.sh
- Update orchestrator agent with CHANGELOG and version reminders
- Add V04.1.0 wiki workflow changes to CHANGELOG [Unreleased]
- Document MCP bug #160 in Known Issues

This ensures versioning workflow is part of the sprint close process,
not just documented in CLAUDE.md.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

.claude-plugin/marketplace.json

@@ -6,12 +6,12 @@
   },
   "metadata": {
     "description": "Project management plugins with Gitea and NetBox integrations",
-    "version": "4.0.0"
+    "version": "4.1.0"
   },
   "plugins": [
     {
       "name": "projman",
-      "version": "3.1.0",
+      "version": "3.2.0",
       "description": "Sprint planning and project management with Gitea integration",
       "source": "./plugins/projman",
       "author": {

CHANGELOG.md

@@ -4,6 +4,39 @@ All notable changes to the Leo Claude Marketplace will be documented in this fil
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
+## [Unreleased]
+
+---
+
+## [4.1.0] - 2026-01-26
+
+### Added
+- **projman:** Wiki-based planning workflow enhancement (V04.1.0)
+  - Flexible input source detection in `/sprint-plan` (file, wiki, or conversation)
+  - Wiki proposal and implementation page creation during sprint planning
+  - Wiki reference linking in created issues
+  - Wiki status updates in `/sprint-close` (Implemented/Partial/Failed)
+  - Metadata section in lessons learned with implementation link for traceability
+  - New `/proposal-status` command for viewing proposal/implementation tree
+- **projman:** `/suggest-version` command - Analyzes CHANGELOG and recommends semantic version bump
+- **projman:** SessionStart hook now suggests sprint planning when open issues exist without milestone
+- **projman:** SessionStart hook now warns about unreleased CHANGELOG entries
+
+### Changed
+- **doc-guardian:** Hook now tracks documentation dependencies and queues specific files needing updates
+  - Outputs which specific docs need updating (e.g., "commands changed → update needed: docs/COMMANDS-CHEATSHEET.md README.md")
+  - Maintains queue file (`.doc-guardian-queue`) for batch processing
+- **docs:** COMMANDS-CHEATSHEET.md updated with data-platform plugin (7 commands + hook)
+
+### Fixed
+- Documentation drift: COMMANDS-CHEATSHEET.md was missing data-platform plugin added in v4.0.0
+- Proactive sprint planning: projman now suggests `/sprint-plan` at session start when unplanned issues exist
+
+### Known Issues
+- **MCP Bug #160:** `update_wiki_page` tool renames pages to "unnamed" when page_name contains URL-encoded characters (`:` → `%3A`). Workaround: use `create_wiki_page` to overwrite instead.
+
+---
+
 ## [4.0.0] - 2026-01-25
 
 ### Added

CLAUDE.md

@@ -50,7 +50,7 @@ See `docs/DEBUGGING-CHECKLIST.md` for details on cache timing.
 ## Project Overview
 
 **Repository:** leo-claude-mktplace
-**Version:** 3.1.2
+**Version:** 4.0.0
 **Status:** Production Ready
 
 A plugin marketplace for Claude Code containing:
@@ -65,6 +65,7 @@ A plugin marketplace for Claude Code containing:
 | `code-sentinel` | Security scanning and code refactoring tools | 1.0.0 |
 | `claude-config-maintainer` | CLAUDE.md optimization and maintenance | 1.0.0 |
 | `cmdb-assistant` | NetBox CMDB integration for infrastructure management | 1.0.0 |
+| `data-platform` | pandas, PostgreSQL, and dbt integration for data engineering | 1.0.0 |
 | `project-hygiene` | Post-task cleanup automation via hooks | 0.1.0 |
 
 ## Quick Start
@@ -84,10 +85,12 @@ A plugin marketplace for Claude Code containing:
 | **Setup** | `/initial-setup`, `/project-init`, `/project-sync` |
 | **Sprint** | `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close` |
 | **Quality** | `/review`, `/test-check`, `/test-gen` |
+| **Versioning** | `/suggest-version` |
 | **PR Review** | `/pr-review:initial-setup`, `/pr-review:project-init` |
 | **Docs** | `/doc-audit`, `/doc-sync` |
 | **Security** | `/security-scan`, `/refactor`, `/refactor-dry` |
 | **Config** | `/config-analyze`, `/config-optimize` |
+| **Data** | `/ingest`, `/profile`, `/schema`, `/explain`, `/lineage`, `/run` |
 | **Debug** | `/debug-report`, `/debug-review` |
 
 ## Repository Structure
@@ -104,8 +107,8 @@ leo-claude-mktplace/
 │   │   ├── .claude-plugin/plugin.json
 │   │   ├── .mcp.json
 │   │   ├── mcp-servers/gitea -> ../../../mcp-servers/gitea  # SYMLINK
-│   │   ├── commands/             # 13 commands (incl. setup, debug)
+│   │   ├── commands/             # 14 commands (incl. setup, debug, suggest-version)
-│   │   ├── hooks/                # SessionStart mismatch detection
+│   │   ├── hooks/                # SessionStart: mismatch detection + sprint suggestions
 │   │   ├── agents/               # 4 agents
 │   │   └── skills/label-taxonomy/
 │   ├── git-flow/                 # Git workflow automation
@@ -119,10 +122,17 @@ leo-claude-mktplace/
 │   │   ├── commands/             # 6 commands (incl. setup)
 │   │   ├── hooks/                # SessionStart mismatch detection
 │   │   └── agents/               # 5 agents
-│   ├── clarity-assist/           # Prompt optimization (NEW v3.0.0)
+│   ├── clarity-assist/           # Prompt optimization
 │   │   ├── .claude-plugin/plugin.json
 │   │   ├── commands/             # 2 commands
 │   │   └── agents/
+│   ├── data-platform/            # Data engineering (NEW v4.0.0)
+│   │   ├── .claude-plugin/plugin.json
+│   │   ├── .mcp.json
+│   │   ├── mcp-servers/          # pandas, postgresql, dbt MCPs
+│   │   ├── commands/             # 7 commands
+│   │   ├── hooks/                # SessionStart PostgreSQL check
+│   │   └── agents/               # 2 agents
 │   ├── doc-guardian/             # Documentation drift detection
 │   ├── code-sentinel/            # Security scanning & refactoring
 │   ├── claude-config-maintainer/
@@ -153,6 +163,14 @@ leo-claude-mktplace/
 - **MCP server venv path**: `${CLAUDE_PLUGIN_ROOT}/mcp-servers/{name}/.venv/bin/python`
 - **CLI tools forbidden** - Use MCP tools exclusively (never `tea`, `gh`, etc.)
 
+#### ⚠️ plugin.json Format Rules (CRITICAL)
+- **Hooks in separate file** - Use `hooks/hooks.json` (auto-discovered), NOT inline in plugin.json
+- **NEVER reference hooks** - Don't add `"hooks": "..."` field to plugin.json at all
+- **Agents auto-discover** - NEVER add `"agents": ["./agents/"]` - .md files found automatically
+- **Always validate** - Run `./scripts/validate-marketplace.sh` before committing
+- **Working examples:** projman, pr-review, claude-config-maintainer all use `hooks/hooks.json`
+- See lesson: `lessons/patterns/plugin-manifest-validation---hooks-and-agents-format-requirements`
+
 ### Hooks (Valid Events Only)
 `PreToolUse`, `PostToolUse`, `UserPromptSubmit`, `SessionStart`, `SessionEnd`, `Notification`, `Stop`, `SubagentStop`, `PreCompact`
 

README.md

@@ -1,4 +1,4 @@
-# Leo Claude Marketplace - v4.0.0
+# Leo Claude Marketplace - v4.1.0
 
 A collection of Claude Code plugins for project management, infrastructure automation, and development workflows.
 

docs/COMMANDS-CHEATSHEET.md

@@ -22,6 +22,7 @@ Quick reference for all commands in the Leo Claude Marketplace.
 | **projman** | `/test-gen` | | X | Generate comprehensive tests for specified code |
 | **projman** | `/debug-report` | | X | Run diagnostics and create structured issue in marketplace |
 | **projman** | `/debug-review` | | X | Investigate diagnostic issues and propose fixes with approval gates |
+| **projman** | `/suggest-version` | | X | Analyze CHANGELOG and recommend semantic version bump |
 | **git-flow** | `/commit` | | X | Create commit with auto-generated conventional message |
 | **git-flow** | `/commit-push` | | X | Commit and push to remote in one operation |
 | **git-flow** | `/commit-merge` | | X | Commit current changes, then merge into target branch |
@@ -55,6 +56,14 @@ Quick reference for all commands in the Leo Claude Marketplace.
 | **cmdb-assistant** | `/cmdb-ip` | | X | Manage IP addresses and prefixes |
 | **cmdb-assistant** | `/cmdb-site` | | X | Manage sites, locations, racks, and regions |
 | **project-hygiene** | *PostToolUse hook* | X | | Removes temp files, warns about unexpected root files |
+| **data-platform** | `/ingest` | | X | Load data from CSV, Parquet, JSON into DataFrame |
+| **data-platform** | `/profile` | | X | Generate data profiling report with statistics |
+| **data-platform** | `/schema` | | X | Explore database schemas, tables, columns |
+| **data-platform** | `/explain` | | X | Explain query execution plan |
+| **data-platform** | `/lineage` | | X | Show dbt model lineage and dependencies |
+| **data-platform** | `/run` | | X | Run dbt models with validation |
+| **data-platform** | `/initial-setup` | | X | Setup wizard for data-platform MCP servers |
+| **data-platform** | *SessionStart hook* | X | | Checks PostgreSQL connection (non-blocking warning) |
 
 ---
 
@@ -62,12 +71,13 @@ Quick reference for all commands in the Leo Claude Marketplace.
 
 | Category | Plugins | Primary Use |
 |----------|---------|-------------|
-| **Setup** | projman, pr-review, cmdb-assistant | `/initial-setup`, `/project-init` |
+| **Setup** | projman, pr-review, cmdb-assistant, data-platform | `/initial-setup`, `/project-init` |
 | **Task Planning** | projman, clarity-assist | Sprint management, requirement clarification |
 | **Code Quality** | code-sentinel, pr-review | Security scanning, PR reviews |
 | **Documentation** | doc-guardian, claude-config-maintainer | Doc sync, CLAUDE.md maintenance |
 | **Git Operations** | git-flow | Commits, branches, workflow automation |
 | **Infrastructure** | cmdb-assistant | NetBox CMDB management |
+| **Data Engineering** | data-platform | pandas, PostgreSQL, dbt operations |
 | **Maintenance** | project-hygiene | Automatic cleanup |
 
 ---
@@ -76,11 +86,12 @@ Quick reference for all commands in the Leo Claude Marketplace.
 
 | Plugin | Hook Event | Behavior |
 |--------|------------|----------|
-| **projman** | SessionStart | Checks git remote vs .env; warns if mismatch detected |
+| **projman** | SessionStart | Checks git remote vs .env; warns if mismatch detected; suggests sprint planning if issues exist |
 | **pr-review** | SessionStart | Checks git remote vs .env; warns if mismatch detected |
-| **doc-guardian** | PostToolUse (Write/Edit) | Silently tracks documentation drift |
+| **doc-guardian** | PostToolUse (Write/Edit) | Tracks documentation drift; auto-updates dependent docs |
 | **code-sentinel** | PreToolUse (Write/Edit) | Scans for security issues; blocks critical vulnerabilities |
 | **project-hygiene** | PostToolUse (Write/Edit) | Cleans temp files, warns about misplaced files |
+| **data-platform** | SessionStart | Checks PostgreSQL connection; non-blocking warning if unavailable |
 
 ---
 
@@ -162,6 +173,19 @@ Managing infrastructure with CMDB:
 4. /cmdb-site view Y         # Check site info
 ```
 
+### Example 6b: Data Engineering Workflow
+
+Working with data pipelines:
+
+```
+1. /ingest file.csv          # Load data into DataFrame
+2. /profile                  # Generate data profiling report
+3. /schema                   # Explore database schemas
+4. /lineage model_name       # View dbt model dependencies
+5. /run model_name           # Execute dbt models
+6. /explain "SELECT ..."     # Analyze query execution plan
+```
+
 ### Example 7: First-Time Setup (New Machine)
 
 Setting up the marketplace for the first time:
@@ -209,9 +233,10 @@ Some plugins require MCP server connectivity:
 | projman | Gitea | Issues, PRs, wiki, labels, milestones |
 | pr-review | Gitea | PR operations and reviews |
 | cmdb-assistant | NetBox | Infrastructure CMDB |
+| data-platform | pandas, PostgreSQL, dbt | DataFrames, database queries, dbt builds |
 
-Ensure credentials are configured in `~/.config/claude/gitea.env` or `~/.config/claude/netbox.env`.
+Ensure credentials are configured in `~/.config/claude/gitea.env`, `~/.config/claude/netbox.env`, or `~/.config/claude/postgres.env`.
 
 ---
 
-*Last Updated: 2026-01-22*
+*Last Updated: 2026-01-25*

plugins/data-platform/.claude-plugin/plugin.json

@@ -18,8 +18,6 @@
     "etl",
     "dataframe"
   ],
-  "hooks": "hooks/hooks.json",
   "commands": ["./commands/"],
-  "agents": ["./agents/"],
   "mcpServers": ["./.mcp.json"]
 }

plugins/doc-guardian/hooks/notify.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # doc-guardian notification hook
-# Outputs a single notification for config file changes, nothing otherwise
+# Tracks documentation dependencies and queues updates
 # This is a command hook - guaranteed not to block workflow
 
 # Read tool input from stdin (JSON with file_path)
@@ -14,10 +14,45 @@ if [ -z "$FILE_PATH" ]; then
     exit 0
 fi
 
-# Check if file is in a config directory (commands/, agents/, skills/, hooks/)
+# Define documentation dependency mappings
-if echo "$FILE_PATH" | grep -qE '/(commands|agents|skills|hooks)/'; then
+# When these directories change, these docs need updating
-    echo "[doc-guardian] Config file modified. Run /doc-sync when ready."
+declare -A DOC_DEPS
+DOC_DEPS["commands"]="docs/COMMANDS-CHEATSHEET.md README.md"
+DOC_DEPS["agents"]="README.md CLAUDE.md"
+DOC_DEPS["hooks"]="docs/COMMANDS-CHEATSHEET.md README.md"
+DOC_DEPS["skills"]="README.md"
+DOC_DEPS[".claude-plugin"]="CLAUDE.md .claude-plugin/marketplace.json"
+DOC_DEPS["mcp-servers"]="docs/COMMANDS-CHEATSHEET.md CLAUDE.md"
+
+# Check which config directory was modified
+MODIFIED_TYPE=""
+for dir in commands agents hooks skills .claude-plugin mcp-servers; do
+    if echo "$FILE_PATH" | grep -qE "/${dir}/|^${dir}/"; then
+        MODIFIED_TYPE="$dir"
+        break
+    fi
+done
+
+# Exit silently if not a tracked config directory
+if [ -z "$MODIFIED_TYPE" ]; then
+    exit 0
 fi
 
-# Exit silently for all other files (no output = no blocking)
+# Get the dependent docs
+DEPENDENT_DOCS="${DOC_DEPS[$MODIFIED_TYPE]}"
+
+# Queue file for tracking pending updates
+QUEUE_FILE="${CLAUDE_PROJECT_ROOT:-.}/.doc-guardian-queue"
+
+# Add to queue (create if doesn't exist, append if does)
+{
+    echo "$(date +%Y-%m-%dT%H:%M:%S) | $MODIFIED_TYPE | $FILE_PATH | $DEPENDENT_DOCS"
+} >> "$QUEUE_FILE" 2>/dev/null || true
+
+# Count pending updates
+PENDING_COUNT=$(wc -l < "$QUEUE_FILE" 2>/dev/null | tr -d ' ' || echo "1")
+
+# Output notification with specific docs that need updating
+echo "[doc-guardian] $MODIFIED_TYPE changed → update needed: $DEPENDENT_DOCS (${PENDING_COUNT} pending)"
+
 exit 0

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,131 @@ 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. Update CHANGELOG (MANDATORY)**
+
+Add all sprint changes to `[Unreleased]` section:
+```markdown
+## [Unreleased]
+
+### Added
+- **projman:** New feature description
+- **plugin-name:** Another feature
+
+### Changed
+- **projman:** Modified behavior
+
+### Fixed
+- **plugin-name:** Bug fix description
+```
+
+**IMPORTANT:** Never skip this step. Every sprint must update CHANGELOG.
+
+**H. Version Check**
+
+Run `/suggest-version` to analyze CHANGELOG and recommend version bump:
+```
+/suggest-version
+```
+
+If release is warranted:
+```bash
+./scripts/release.sh X.Y.Z
+```
+
+This ensures version numbers stay in sync:
+- README.md title
+- .claude-plugin/marketplace.json
+- Git tags
+- CHANGELOG.md section header
+
+**I. Git Operations**
 
 Offer to handle git cleanup:
 ```
@@ -418,7 +537,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 +576,10 @@ 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
+13. **Update CHANGELOG** - MANDATORY at sprint close, never skip
+14. **Run suggest-version** - Check if release is needed after CHANGELOG update
 
 ## 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,36 @@ 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**
-   - Commit any remaining work
+   - 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. **Update CHANGELOG** (MANDATORY)
+   - Add all sprint changes to `[Unreleased]` section in CHANGELOG.md
+   - Categorize: Added, Changed, Fixed, Removed, Deprecated
+   - Include plugin prefix (e.g., `- **projman:** New feature`)
+
+8. **Version Check**
+   - Run `/suggest-version` to analyze changes and recommend version bump
+   - If release warranted: run `./scripts/release.sh X.Y.Z`
+   - Ensures version numbers stay in sync across files
+
+9. **Git Operations**
+   - Commit any remaining work (including CHANGELOG updates)
    - Merge feature branches if needed
    - Clean up merged branches
-   - Tag sprint completion
+   - Tag sprint completion (if release created)
 
-6. **Close Milestone**
+10. **Close Milestone**
    - Use `update_milestone` to close the sprint milestone
    - Document final completion status
 
@@ -66,7 +89,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 +99,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 +120,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 +159,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

plugins/projman/commands/suggest-version.md

@@ -0,0 +1,78 @@
+# /suggest-version
+
+Analyze CHANGELOG.md and suggest appropriate semantic version bump.
+
+## Behavior
+
+1. **Read current state**:
+   - Read `CHANGELOG.md` to find current version and [Unreleased] content
+   - Read `.claude-plugin/marketplace.json` for current marketplace version
+   - Check individual plugin versions in `plugins/*/. claude-plugin/plugin.json`
+
+2. **Analyze [Unreleased] section**:
+   - Extract all entries under `### Added`, `### Changed`, `### Fixed`, `### Removed`, `### Deprecated`
+   - Categorize changes by impact
+
+3. **Apply SemVer rules**:
+
+   | Change Type | Version Bump | Indicators |
+   |-------------|--------------|------------|
+   | **MAJOR** (X.0.0) | Breaking changes | `### Removed`, `### Changed` with "BREAKING:", renamed/removed APIs |
+   | **MINOR** (x.Y.0) | New features, backwards compatible | `### Added` with new commands/plugins/features |
+   | **PATCH** (x.y.Z) | Bug fixes only | `### Fixed` only, `### Changed` for non-breaking tweaks |
+
+4. **Output recommendation**:
+   ```
+   ## Version Analysis
+
+   **Current version:** X.Y.Z
+   **[Unreleased] summary:**
+   - Added: N entries (new features/plugins)
+   - Changed: N entries (M breaking)
+   - Fixed: N entries
+   - Removed: N entries
+
+   **Recommendation:** MINOR bump → X.(Y+1).0
+   **Reason:** New features added without breaking changes
+
+   **To release:** ./scripts/release.sh X.Y.Z
+   ```
+
+5. **Check version sync**:
+   - Compare marketplace version with individual plugin versions
+   - Warn if plugins are out of sync (e.g., marketplace 4.0.0 but projman 3.1.0)
+
+## Examples
+
+**Output when MINOR bump needed:**
+```
+## Version Analysis
+
+**Current version:** 4.0.0
+**[Unreleased] summary:**
+- Added: 3 entries (new command, hook improvement, workflow example)
+- Changed: 1 entry (0 breaking)
+- Fixed: 2 entries
+
+**Recommendation:** MINOR bump → 4.1.0
+**Reason:** New features (Added section) without breaking changes
+
+**To release:** ./scripts/release.sh 4.1.0
+```
+
+**Output when nothing to release:**
+```
+## Version Analysis
+
+**Current version:** 4.0.0
+**[Unreleased] summary:** Empty - no pending changes
+
+**Recommendation:** No release needed
+```
+
+## Integration
+
+This command helps maintain proper versioning workflow:
+- Run after completing a sprint to determine version bump
+- Run before `/sprint-close` to ensure version is updated
+- Integrates with `./scripts/release.sh` for actual release execution

plugins/projman/hooks/startup-check.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # projman startup check hook
-# Checks for common issues at session start
+# Checks for common issues AND suggests sprint planning proactively
 # All output MUST have [projman] prefix
 
 PREFIX="[projman]"
@@ -26,5 +26,41 @@ if [[ -f ".env" ]]; then
     fi
 fi
 
-# All checks passed - say nothing
+# Check for open issues (suggests sprint planning)
+# Only if .env exists with valid GITEA config
+if [[ -f ".env" ]]; then
+    GITEA_API_URL=$(grep -E "^GITEA_API_URL=" ~/.config/claude/gitea.env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
+    GITEA_API_TOKEN=$(grep -E "^GITEA_API_TOKEN=" ~/.config/claude/gitea.env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
+    GITEA_REPO=$(grep -E "^GITEA_REPO=" .env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
+
+    if [[ -n "$GITEA_API_URL" && -n "$GITEA_API_TOKEN" && -n "$GITEA_REPO" ]]; then
+        # Quick check for open issues without milestone (unplanned work)
+        OPEN_ISSUES=$(curl -s -m 5 \
+            -H "Authorization: token $GITEA_API_TOKEN" \
+            "${GITEA_API_URL}/repos/${GITEA_REPO}/issues?state=open&milestone=none&limit=1" 2>/dev/null | \
+            grep -c '"number"' || echo "0")
+
+        if [[ "$OPEN_ISSUES" -gt 0 ]]; then
+            # Count total unplanned issues
+            TOTAL_UNPLANNED=$(curl -s -m 5 \
+                -H "Authorization: token $GITEA_API_TOKEN" \
+                "${GITEA_API_URL}/repos/${GITEA_REPO}/issues?state=open&milestone=none" 2>/dev/null | \
+                grep -c '"number"' || echo "?")
+            echo "$PREFIX ${TOTAL_UNPLANNED} open issues without milestone - consider /sprint-plan"
+        fi
+    fi
+fi
+
+# Check for CHANGELOG.md [Unreleased] content (version management)
+if [[ -f "CHANGELOG.md" ]]; then
+    # Check if there's content under [Unreleased] that hasn't been released
+    UNRELEASED_CONTENT=$(sed -n '/## \[Unreleased\]/,/## \[/p' CHANGELOG.md 2>/dev/null | grep -E '^### (Added|Changed|Fixed|Removed|Deprecated)' | head -1 || true)
+    if [[ -n "$UNRELEASED_CONTENT" ]]; then
+        UNRELEASED_LINES=$(sed -n '/## \[Unreleased\]/,/## \[/p' CHANGELOG.md 2>/dev/null | grep -E '^- ' | wc -l | tr -d ' ')
+        if [[ "$UNRELEASED_LINES" -gt 0 ]]; then
+            echo "$PREFIX ${UNRELEASED_LINES} unreleased changes in CHANGELOG - consider version bump"
+        fi
+    fi
+fi
+
 exit 0