refactor(projman): extract skills and consolidate commands

Major refactoring of projman plugin architecture: Skills Extraction (17 new files): - Extracted reusable knowledge from commands and agents into skills/ - branch-security, dependency-management, git-workflow, input-detection - issue-conventions, lessons-learned, mcp-tools-reference, planning-workflow - progress-tracking, repo-validation, review-checklist, runaway-detection - setup-workflows, sprint-approval, task-sizing, test-standards, wiki-conventions Command Consolidation (17 → 12 commands): - /setup: consolidates initial-setup, project-init, project-sync (--full/--quick/--sync) - /debug: consolidates debug-report, debug-review (report/review modes) - /test: consolidates test-check, test-gen (run/gen modes) - /sprint-status: absorbs sprint-diagram via --diagram flag Architecture Cleanup: - Remove plugin-level mcp-servers/ symlinks (6 plugins) - Remove plugin README.md files (12 files, ~2000 lines) - Update all documentation to reflect new command structure - Fix documentation drift in CONFIGURATION.md, COMMANDS-CHEATSHEET.md Commands are now thin dispatchers (~20-50 lines) that reference skills. Agents reference skills for domain knowledge instead of inline content. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 15:02:16 -05:00
parent 8fe685037e
commit 2e65b60725
70 changed files with 3450 additions and 8887 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -35,7 +35,7 @@ Run `./scripts/verify-hooks.sh`. If changes affect MCP servers or hooks, inform
 | **File creation** | Only in allowed paths. Use `.scratch/` for temp work. Verify against `docs/CANONICAL-PATHS.md` |
 | **plugin.json location** | Must be in `.claude-plugin/` directory |
 | **Hooks** | Use `hooks/hooks.json` (auto-discovered). Never inline in plugin.json |
-| **MCP servers** | Shared at root with symlinks. Use MCP tools, never CLI (`tea`, `gh`) |
+| **MCP servers** | Defined in root `.mcp.json`. Use MCP tools, never CLI (`tea`, `gh`) |
 | **Allowed root files** | `CLAUDE.md`, `README.md`, `LICENSE`, `CHANGELOG.md`, `.gitignore`, `.env.example` |
 **Valid hook events:** `PreToolUse`, `PostToolUse`, `UserPromptSubmit`, `SessionStart`, `SessionEnd`, `Notification`, `Stop`, `SubagentStop`, `PreCompact`
@@ -141,23 +141,23 @@ A plugin marketplace for Claude Code containing:
 ./scripts/validate-marketplace.sh
 # After updates
-./scripts/post-update.sh   # Rebuild venvs, verify symlinks
+./scripts/post-update.sh   # Rebuild venvs
 ```
 ### Plugin Commands - USE THESE in This Project
 | Category | Commands |
 |----------|----------|
-| **Setup** | `/initial-setup`, `/project-init`, `/project-sync` |
+| **Setup** | `/setup` (modes: `--full`, `--quick`, `--sync`) |
-| **Sprint** | `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/sprint-diagram` |
+| **Sprint** | `/sprint-plan`, `/sprint-start`, `/sprint-status` (with `--diagram`), `/sprint-close` |
-| **Quality** | `/review`, `/test-check`, `/test-gen` |
+| **Quality** | `/review`, `/test` (modes: `run`, `gen`) |
 | **Versioning** | `/suggest-version` |
 | **PR Review** | `/pr-review`, `/pr-summary`, `/pr-findings`, `/pr-diff` |
 | **Docs** | `/doc-audit`, `/doc-sync`, `/changelog-gen`, `/doc-coverage`, `/stale-docs` |
 | **Security** | `/security-scan`, `/refactor`, `/refactor-dry` |
 | **Config** | `/config-analyze`, `/config-optimize`, `/config-diff`, `/config-lint` |
 | **Validation** | `/validate-contracts`, `/check-agent`, `/list-interfaces`, `/dependency-graph` |
-| **Debug** | `/debug-report`, `/debug-review` |
+| **Debug** | `/debug` (modes: `report`, `review`) |
 ### Plugin Commands - NOT RELEVANT to This Project
@@ -175,46 +175,40 @@ These commands are being developed but don't apply to this project's workflow:
 leo-claude-mktplace/
 ├── .claude-plugin/
 │   └── marketplace.json          # Marketplace manifest
-├── mcp-servers/                  # SHARED MCP servers (v3.0.0+)
+├── .mcp.json                     # MCP server configuration (all servers)
 ├── mcp-servers/                  # SHARED MCP servers
 │   ├── gitea/                    # Gitea MCP (issues, PRs, wiki)
 │   ├── netbox/                   # NetBox MCP (CMDB)
 │   ├── data-platform/            # pandas, PostgreSQL, dbt
-│   └── viz-platform/             # DMC validation, charts, themes
+│   ├── viz-platform/             # DMC validation, charts, themes
 │   └── contract-validator/       # Plugin compatibility validation
 ├── plugins/
 │   ├── projman/                  # Sprint management
 │   │   ├── .claude-plugin/plugin.json
-│   │   # .mcp.json removed - now at marketplace root
+│   │   ├── commands/             # 12 commands
-│   │   ├── mcp-servers/gitea -> ../../../mcp-servers/gitea  # SYMLINK
+│   │   ├── hooks/                # SessionStart: mismatch detection
 │   │   ├── commands/             # 14 commands (incl. setup, debug, suggest-version)
 │   │   ├── hooks/                # SessionStart: mismatch detection + sprint suggestions
 │   │   ├── agents/               # 4 agents
-│   │   └── skills/label-taxonomy/
+│   │   └── skills/               # 17 reusable skill files
 │   ├── git-flow/                 # Git workflow automation
 │   │   ├── .claude-plugin/plugin.json
 │   │   ├── commands/             # 8 commands
 │   │   └── agents/
 │   ├── pr-review/                # Multi-agent PR review
 │   │   ├── .claude-plugin/plugin.json
-│   │   # .mcp.json removed - now at marketplace root
+│   │   ├── commands/             # 6 commands
 │   │   ├── mcp-servers/gitea -> ../../../mcp-servers/gitea  # SYMLINK
 │   │   ├── commands/             # 6 commands (incl. setup)
 │   │   ├── hooks/                # SessionStart mismatch detection
 │   │   └── agents/               # 5 agents
 │   ├── clarity-assist/           # Prompt optimization
 │   │   ├── .claude-plugin/plugin.json
 │   │   ├── commands/             # 2 commands
 │   │   └── agents/
-│   ├── data-platform/            # Data engineering (NEW v4.0.0)
+│   ├── data-platform/            # Data engineering
 │   │   ├── .claude-plugin/plugin.json
 │   │   # .mcp.json removed - now at marketplace root
 │   │   ├── mcp-servers/          # pandas, postgresql, dbt MCPs
 │   │   ├── commands/             # 7 commands
 │   │   ├── hooks/                # SessionStart PostgreSQL check
 │   │   └── agents/               # 2 agents
-│   ├── viz-platform/             # Visualization (NEW v4.0.0)
+│   ├── viz-platform/             # Visualization
 │   │   ├── .claude-plugin/plugin.json
 │   │   # .mcp.json removed - now at marketplace root
 │   │   ├── mcp-servers/          # viz-platform MCP
 │   │   ├── commands/             # 7 commands
 │   │   ├── hooks/                # SessionStart DMC check
 │   │   └── agents/               # 3 agents
@@ -222,6 +216,7 @@ leo-claude-mktplace/
 │   ├── code-sentinel/            # Security scanning & refactoring
 │   ├── claude-config-maintainer/
 │   ├── cmdb-assistant/
 │   ├── contract-validator/
 │   └── project-hygiene/
 ├── scripts/
 │   ├── setup.sh, post-update.sh
@@ -297,16 +292,15 @@ Stored in Gitea Wiki under `lessons-learned/sprints/`.
 1. Create `plugins/{name}/.claude-plugin/plugin.json`
 2. Add entry to `.claude-plugin/marketplace.json` with category, tags, license
-3. Create `README.md` and `claude-md-integration.md`
+3. Create `claude-md-integration.md`
-4. If using MCP server, create symlink: `ln -s ../../../mcp-servers/{server} plugins/{name}/mcp-servers/{server}`
+4. If using new MCP server, add to root `mcp-servers/` and update `.mcp.json`
 5. Run `./scripts/validate-marketplace.sh`
 6. Update `CHANGELOG.md`
 ### Adding a Command to projman
 1. Create `plugins/projman/commands/{name}.md`
-2. Update `plugins/projman/README.md`
+2. Update marketplace description if significant
 3. Update marketplace description if significant
 ### Validation
@@ -333,7 +327,6 @@ Stored in Gitea Wiki under `lessons-learned/sprints/`.
 | `docs/DEBUGGING-CHECKLIST.md` | Systematic troubleshooting guide |
 | `docs/UPDATING.md` | Update guide for the marketplace |
 | `plugins/projman/CONFIGURATION.md` | Projman quick reference (links to central) |
 | `plugins/projman/README.md` | Projman full documentation |
 ## Installation Paths
@@ -355,12 +348,12 @@ See `docs/DEBUGGING-CHECKLIST.md` for systematic troubleshooting.
 | Symptom | Likely Cause | Fix |
 |---------|--------------|-----|
 | "X MCP servers failed" | Missing venv in installed path | `cd ~/.claude/plugins/marketplaces/leo-claude-mktplace && ./scripts/setup.sh` |
-| MCP tools not available | Symlink broken or venv missing | Run `/debug-report` to diagnose |
+| MCP tools not available | Venv missing or .mcp.json misconfigured | Run `/debug report` to diagnose |
 | Changes not taking effect | Editing source, not installed | Reinstall plugin or edit installed path |
 **Debug Commands:**
- `/debug-report` - Run full diagnostics, create issue if needed
+- `/debug report` - Run full diagnostics, create issue if needed
- `/debug-review` - Investigate and propose fixes
+- `/debug review` - Investigate and propose fixes
 ## Versioning Workflow
--- a/README.md
+++ b/README.md
@@ -6,7 +6,7 @@ A collection of Claude Code plugins for project management, infrastructure autom
 ### Development & Project Management
-#### [projman](./plugins/projman/README.md)
+#### [projman](./plugins/projman)
 **Sprint Planning and Project Management**
 AI-guided sprint planning with full Gitea integration. Transforms a proven 15-sprint workflow into a distributable plugin.
@@ -19,9 +19,9 @@ AI-guided sprint planning with full Gitea integration. Transforms a proven 15-sp
 - Branch-aware security (development/staging/production)
 - Pre-sprint-close code quality review and test verification
-**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/sprint-diagram`, `/labels-sync`, `/initial-setup`, `/project-init`, `/project-sync`, `/review`, `/test-check`, `/test-gen`, `/debug-report`, `/debug-review`, `/suggest-version`, `/proposal-status`
+**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/setup`, `/review`, `/test`, `/debug`, `/suggest-version`, `/proposal-status`, `/clear-cache`
-#### [git-flow](./plugins/git-flow/README.md) *NEW in v3.0.0*
+#### [git-flow](./plugins/git-flow) *NEW in v3.0.0*
 **Git Workflow Automation**
 Smart git operations with intelligent commit messages and branch management.
@@ -34,7 +34,7 @@ Smart git operations with intelligent commit messages and branch management.
 **Commands:** `/commit`, `/commit-push`, `/commit-merge`, `/commit-sync`, `/branch-start`, `/branch-cleanup`, `/git-status`, `/git-config`
-#### [pr-review](./plugins/pr-review/README.md) *NEW in v3.0.0*
+#### [pr-review](./plugins/pr-review) *NEW in v3.0.0*
 **Multi-Agent PR Review**
 Comprehensive pull request review using specialized agents.
@@ -46,14 +46,14 @@ Comprehensive pull request review using specialized agents.
 **Commands:** `/pr-review`, `/pr-summary`, `/pr-findings`, `/pr-diff`, `/initial-setup`, `/project-init`, `/project-sync`
-#### [claude-config-maintainer](./plugins/claude-config-maintainer/README.md)
+#### [claude-config-maintainer](./plugins/claude-config-maintainer)
 **CLAUDE.md Optimization and Maintenance**
 Analyze, optimize, and create CLAUDE.md configuration files for Claude Code projects.
 **Commands:** `/config-analyze`, `/config-optimize`, `/config-init`, `/config-diff`, `/config-lint`
-#### [contract-validator](./plugins/contract-validator/README.md) *NEW in v5.0.0*
+#### [contract-validator](./plugins/contract-validator) *NEW in v5.0.0*
 **Cross-Plugin Compatibility Validation**
 Validate plugin marketplaces for command conflicts, tool overlaps, and broken agent references.
@@ -68,7 +68,7 @@ Validate plugin marketplaces for command conflicts, tool overlaps, and broken ag
 ### Productivity
-#### [clarity-assist](./plugins/clarity-assist/README.md) *NEW in v3.0.0*
+#### [clarity-assist](./plugins/clarity-assist) *NEW in v3.0.0*
 **Prompt Optimization with ND Accommodations**
 Transform vague requests into clear specifications using structured methodology.
@@ -79,21 +79,21 @@ Transform vague requests into clear specifications using structured methodology.
 **Commands:** `/clarify`, `/quick-clarify`
-#### [doc-guardian](./plugins/doc-guardian/README.md)
+#### [doc-guardian](./plugins/doc-guardian)
 **Documentation Lifecycle Management**
 Automatic documentation drift detection and synchronization.
 **Commands:** `/doc-audit`, `/doc-sync`, `/changelog-gen`, `/doc-coverage`, `/stale-docs`
-#### [project-hygiene](./plugins/project-hygiene/README.md)
+#### [project-hygiene](./plugins/project-hygiene)
 **Post-Task Cleanup Automation**
 Hook-based cleanup that runs after Claude completes work.
 ### Security
-#### [code-sentinel](./plugins/code-sentinel/README.md)
+#### [code-sentinel](./plugins/code-sentinel)
 **Security Scanning & Refactoring**
 Security vulnerability detection and code refactoring tools.
@@ -102,7 +102,7 @@ Security vulnerability detection and code refactoring tools.
 ### Infrastructure
-#### [cmdb-assistant](./plugins/cmdb-assistant/README.md)
+#### [cmdb-assistant](./plugins/cmdb-assistant)
 **NetBox CMDB Integration**
 Full CRUD operations for network infrastructure management directly from Claude Code.
@@ -111,7 +111,7 @@ Full CRUD operations for network infrastructure management directly from Claude
 ### Data Engineering
-#### [data-platform](./plugins/data-platform/README.md) *NEW in v4.0.0*
+#### [data-platform](./plugins/data-platform) *NEW in v4.0.0*
 **pandas, PostgreSQL/PostGIS, and dbt Integration**
 Comprehensive data engineering toolkit with persistent DataFrame storage.
@@ -126,7 +126,7 @@ Comprehensive data engineering toolkit with persistent DataFrame storage.
 ### Visualization
-#### [viz-platform](./plugins/viz-platform/README.md) *NEW in v4.0.0*
+#### [viz-platform](./plugins/viz-platform) *NEW in v4.0.0*
 **Dash Mantine Components Validation and Theming**
 Visualization toolkit with version-locked component validation and design token theming.
@@ -142,7 +142,7 @@ Visualization toolkit with version-locked component validation and design token
 ## MCP Servers
-MCP servers are **shared at repository root** with **symlinks** from plugins that use them.
+MCP servers are **shared at repository root** and configured in `.mcp.json`.
 ### Gitea MCP Server (shared)
--- a/docs/CANONICAL-PATHS.md
+++ b/docs/CANONICAL-PATHS.md
@@ -2,7 +2,7 @@
 **This file defines ALL valid paths in this repository. No exceptions. No inference. No assumptions.**
-Last Updated: 2026-01-27 (v5.1.0)
+Last Updated: 2026-01-30 (v5.5.0)
 ---
@@ -76,9 +76,6 @@ leo-claude-mktplace/
 ├── plugins/                    # ALL plugins
 │   ├── projman/                # Sprint management
 │   │   ├── .claude-plugin/
 │   │   ├── .mcp.json
 │   │   ├── mcp-servers/
 │   │   │   └── gitea -> ../../../mcp-servers/gitea  # SYMLINK
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
@@ -99,9 +96,6 @@ leo-claude-mktplace/
 │   │   └── claude-md-integration.md
 │   ├── cmdb-assistant/         # NetBox CMDB integration
 │   │   ├── .claude-plugin/
 │   │   ├── .mcp.json
 │   │   ├── mcp-servers/
 │   │   │   └── netbox -> ../../../mcp-servers/netbox  # SYMLINK
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   └── claude-md-integration.md
@@ -114,49 +108,37 @@ leo-claude-mktplace/
 │   │   ├── .claude-plugin/
 │   │   ├── hooks/
 │   │   └── claude-md-integration.md
-│   ├── clarity-assist/         # NEW in v3.0.0
+│   ├── clarity-assist/
 │   │   ├── .claude-plugin/
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
 │   │   └── claude-md-integration.md
-│   ├── git-flow/               # NEW in v3.0.0
+│   ├── git-flow/
 │   │   ├── .claude-plugin/
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
 │   │   └── claude-md-integration.md
-│   ├── pr-review/              # NEW in v3.0.0
+│   ├── pr-review/
 │   │   ├── .claude-plugin/
 │   │   ├── .mcp.json
 │   │   ├── mcp-servers/
 │   │   │   └── gitea -> ../../../mcp-servers/gitea  # SYMLINK
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
 │   │   └── claude-md-integration.md
-│   ├── data-platform/          # NEW in v4.0.0
+│   ├── data-platform/
 │   │   ├── .claude-plugin/
 │   │   ├── .mcp.json
 │   │   ├── mcp-servers/
 │   │   │   └── data-platform -> ../../../mcp-servers/data-platform  # SYMLINK
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── hooks/
 │   │   └── claude-md-integration.md
-│   ├── contract-validator/     # NEW in v5.0.0
+│   ├── contract-validator/
 │   │   ├── .claude-plugin/
 │   │   ├── .mcp.json
 │   │   ├── mcp-servers/
 │   │   │   └── contract-validator -> ../../../mcp-servers/contract-validator  # SYMLINK
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   └── claude-md-integration.md
-│   └── viz-platform/           # NEW in v4.1.0
+│   └── viz-platform/
 │       ├── .claude-plugin/
 │       ├── .mcp.json
 │       ├── mcp-servers/
 │       │   └── viz-platform -> ../../../mcp-servers/viz-platform  # SYMLINK
 │       ├── commands/
 │       ├── agents/
 │       ├── hooks/
@@ -188,29 +170,21 @@ leo-claude-mktplace/
 | Plugin manifest | `plugins/{plugin-name}/.claude-plugin/plugin.json` | `plugins/projman/.claude-plugin/plugin.json` |
 | Plugin commands | `plugins/{plugin-name}/commands/` | `plugins/projman/commands/` |
 | Plugin agents | `plugins/{plugin-name}/agents/` | `plugins/projman/agents/` |
-| Plugin .mcp.json | `plugins/{plugin-name}/.mcp.json` | `plugins/projman/.mcp.json` |
+| Plugin skills | `plugins/{plugin-name}/skills/` | `plugins/projman/skills/` |
 | Plugin integration snippet | `plugins/{plugin-name}/claude-md-integration.md` | `plugins/projman/claude-md-integration.md` |
-### MCP Server Paths (v3.0.0 Architecture)
+### MCP Server Paths
-MCP servers are **shared at repository root** with **symlinks** from plugins.
+MCP servers are **shared at repository root** and configured in `.mcp.json`.
 | Context | Pattern | Example |
 |---------|---------|---------|
 | MCP configuration | `.mcp.json` | `.mcp.json` (at repo root) |
 | Shared MCP server | `mcp-servers/{server}/` | `mcp-servers/gitea/` |
 | MCP server code | `mcp-servers/{server}/mcp_server/` | `mcp-servers/gitea/mcp_server/` |
 | MCP venv | `mcp-servers/{server}/.venv/` | `mcp-servers/gitea/.venv/` |
 | Plugin symlink | `plugins/{plugin}/mcp-servers/{server}` | `plugins/projman/mcp-servers/gitea` |
-### Symlink Pattern
+**Note:** Plugins do NOT have their own `mcp-servers/` directories. All MCP servers are shared at root and configured via `.mcp.json`.
 Plugins that use MCP servers create symlinks:
 ```bash
 # From plugin directory
 ln -s ../../../mcp-servers/gitea plugins/projman/mcp-servers/gitea
 ```
 The symlink target is relative: `../../../mcp-servers/{server}`
 ### Documentation Paths
@@ -239,15 +213,12 @@ The symlink target is relative: `../../../mcp-servers/{server}`
 2. Verify each path against patterns in this file
 3. Show verification to user before proceeding
-### Relative Path Calculation (v3.0.0)
+### Relative Path Calculation
-From `plugins/projman/.mcp.json` to shared `mcp-servers/gitea/`:
+From `.mcp.json` (at root) to `mcp-servers/gitea/`:
 ```
-plugins/projman/.mcp.json
+.mcp.json (at repository root)
-  → Uses ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/
+  → Uses absolute installed path: ~/.claude/plugins/marketplaces/.../mcp-servers/gitea/run.sh
  → Symlink at plugins/projman/mcp-servers/gitea points to ../../../mcp-servers/gitea
 Result in .mcp.json: ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/.venv/bin/python
 ```
 From `.claude-plugin/marketplace.json` to `plugins/projman/`:
@@ -266,30 +237,34 @@ Result: ./plugins/projman
 | Wrong | Why | Correct |
 |-------|-----|---------|
 | `projman/` at root | Plugins go in `plugins/` | `plugins/projman/` |
-| Direct path in .mcp.json to root mcp-servers | Use symlink | Symlink at `plugins/{plugin}/mcp-servers/` |
+| `mcp-servers/` inside plugins | MCP servers are shared at root | Use root `mcp-servers/` |
-| Creating new mcp-servers inside plugins | Use shared + symlink | Symlink to `mcp-servers/` |
+| Plugin-level `.mcp.json` | MCP config is at root | Use root `.mcp.json` |
-| Hardcoding absolute paths | Breaks portability | Use `${CLAUDE_PLUGIN_ROOT}` |
+| Hardcoding absolute paths in source | Breaks portability | Use relative paths or `${CLAUDE_PLUGIN_ROOT}` |
 ---
-## Architecture Note (v3.0.0)
+## Architecture Note
-MCP servers are now **shared at repository root** with **symlinks** from plugins:
+MCP servers are **shared at repository root** and configured in a single `.mcp.json` file.
 **Benefits:**
 - Single source of truth for each MCP server
 - Updates apply to all plugins automatically
- Reduced duplication
+- No duplication - clean plugin structure
- Symlinks work with Claude Code caching
+- Simple configuration in one place
-**Symlink Pattern:**
+**Configuration:**
-```
+All MCP servers are defined in `.mcp.json` at repository root:
-plugins/projman/mcp-servers/gitea -> ../../../mcp-servers/gitea
+```json
-plugins/cmdb-assistant/mcp-servers/netbox -> ../../../mcp-servers/netbox
+{
-plugins/pr-review/mcp-servers/gitea -> ../../../mcp-servers/gitea
+  "mcpServers": {
-plugins/data-platform/mcp-servers/data-platform -> ../../../mcp-servers/data-platform
+    "gitea": { "command": ".../mcp-servers/gitea/run.sh" },
-plugins/viz-platform/mcp-servers/viz-platform -> ../../../mcp-servers/viz-platform
+    "netbox": { "command": ".../mcp-servers/netbox/run.sh" },
-plugins/contract-validator/mcp-servers/contract-validator -> ../../../mcp-servers/contract-validator
+    "data-platform": { "command": ".../mcp-servers/data-platform/run.sh" },
    "viz-platform": { "command": ".../mcp-servers/viz-platform/run.sh" },
    "contract-validator": { "command": ".../mcp-servers/contract-validator/run.sh" }
  }
 }
 ```
 ---
@@ -298,6 +273,7 @@ plugins/contract-validator/mcp-servers/contract-validator -> ../../../mcp-server
 | Date | Change | By |
 |------|--------|-----|
 | 2026-01-30 | v5.5.0: Removed plugin-level mcp-servers symlinks - all MCP config now in root .mcp.json | Claude Code |
 | 2026-01-26 | v5.0.0: Added contract-validator plugin and MCP server | Claude Code |
 | 2026-01-26 | v4.1.0: Added viz-platform plugin and MCP server | Claude Code |
 | 2026-01-25 | v4.0.0: Added data-platform plugin and MCP server | Claude Code |
--- a/docs/COMMANDS-CHEATSHEET.md
+++ b/docs/COMMANDS-CHEATSHEET.md
@@ -10,21 +10,17 @@ Quick reference for all commands in the Leo Claude Marketplace.
 |--------|---------|:----:|:------:|-------------|
 | **projman** | `/sprint-plan` | | X | Start sprint planning with AI-guided architecture analysis and issue creation |
 | **projman** | `/sprint-start` | | X | Begin sprint execution with dependency analysis and parallel task coordination |
-| **projman** | `/sprint-status` | | X | Check current sprint progress and identify blockers |
+| **projman** | `/sprint-status` | | X | Check current sprint progress (add `--diagram` for Mermaid visualization) |
 | **projman** | `/review` | | X | Pre-sprint-close code quality review (debug artifacts, security, error handling) |
-| **projman** | `/test-check` | | X | Run tests and verify coverage before sprint close |
+| **projman** | `/test` | | X | Run tests (`/test run`) or generate tests (`/test gen <target>`) |
 | **projman** | `/sprint-close` | | X | Complete sprint and capture lessons learned to Gitea Wiki |
 | **projman** | `/labels-sync` | | X | Synchronize label taxonomy from Gitea |
-| **projman** | `/initial-setup` | | X | Full setup wizard: MCP server + system config + project config |
+| **projman** | `/setup` | | X | Auto-detect mode or use `--full`, `--quick`, `--sync` |
-| **projman** | `/project-init` | | X | Quick project setup (assumes system config exists) |
+| **projman** | *SessionStart hook* | X | | Detects git remote vs .env mismatch, warns to run `/setup --sync` |
-| **projman** | `/project-sync` | | X | Sync config with git remote after repo move/rename |
+| **projman** | `/debug` | | X | Diagnostics (`/debug report`) or investigate (`/debug review`) |
 | **projman** | *SessionStart hook* | X | | Detects git remote vs .env mismatch, warns to run /project-sync |
 | **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 |
 | **projman** | `/proposal-status` | | X | View proposal and implementation hierarchy with status |
-| **projman** | `/sprint-diagram` | | X | Generate Mermaid diagram of sprint issues with dependencies |
+| **projman** | `/clear-cache` | | X | Clear plugin cache to force fresh configuration reload |
 | **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 |
@@ -104,7 +100,7 @@ Quick reference for all commands in the Leo Claude Marketplace.
 | Category | Plugins | Primary Use |
 |----------|---------|-------------|
-| **Setup** | projman, pr-review, cmdb-assistant, data-platform | `/initial-setup`, `/project-init` |
+| **Setup** | projman, pr-review, cmdb-assistant, data-platform | `/setup`, `/initial-setup` |
 | **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 |
@@ -145,9 +141,9 @@ A typical workflow for planning and executing a feature sprint:
 5. /branch-start feat/...    # Create feature branch
   ... implement features ...
 6. /commit                   # Commit with conventional message
-7. /sprint-status            # Check progress mid-sprint
+7. /sprint-status --diagram  # Check progress with visualization
 8. /review                   # Pre-close quality review
-9. /test-check               # Verify test coverage
+9. /test run                 # Verify test coverage
 10. /sprint-close            # Capture lessons learned
 ```
@@ -194,7 +190,7 @@ Safe refactoring with preview:
 1. /refactor-dry             # Preview opportunities
 2. /security-scan            # Baseline security check
 3. /refactor                 # Apply improvements
-4. /test-check               # Verify nothing broke
+4. /test run                 # Verify nothing broke
 5. /commit                   # Commit with descriptive message
 ```
@@ -227,7 +223,7 @@ Working with data pipelines:
 Setting up the marketplace for the first time:
 ```
-1. /initial-setup            # Full setup: MCP + system config + project
+1. /setup --full             # Full setup: MCP + system config + project
   # → Follow prompts for Gitea URL, org
   # → Add token manually when prompted
   # → Confirm repository name
@@ -241,7 +237,7 @@ Setting up the marketplace for the first time:
 Adding a new project when system config exists:
 ```
-1. /project-init             # Quick project setup
+1. /setup --quick            # Quick project setup (auto-detected)
   # → Confirms detected repo name
   # → Creates .env
 2. /labels-sync              # Sync Gitea labels
@@ -277,4 +273,4 @@ Ensure credentials are configured in `~/.config/claude/gitea.env`, `~/.config/cl
 ---
-*Last Updated: 2026-01-28*
+*Last Updated: 2026-01-30*
--- a/docs/CONFIGURATION.md
+++ b/docs/CONFIGURATION.md
@@ -9,10 +9,10 @@ Centralized configuration documentation for all plugins and MCP servers in the L
 **After installing the marketplace and plugins via Claude Code:**
 ```
-/initial-setup
+/setup
 ```
-The interactive wizard handles everything except manually adding your API tokens.
+The interactive wizard auto-detects what's needed and handles everything except manually adding your API tokens.
 ---
@@ -25,7 +25,8 @@ The interactive wizard handles everything except manually adding your API tokens
 └─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
-                            /initial-setup
+                              /setup --full
                          (or /setup auto-detects)
                                    │
     ┌──────────────────────────────┼──────────────────────────────┐
     ▼                              ▼                              ▼
@@ -78,8 +79,8 @@ The interactive wizard handles everything except manually adding your API tokens
                                    │
                    ┌───────────────┴───────────────┐
                    ▼                               ▼
-             /project-init                   /initial-setup
+             /setup --quick                     /setup
-             (direct path)                   (smart detection)
+             (explicit mode)               (auto-detects mode)
                    │                               │
                    │                    ┌──────────┴──────────┐
                    │                    ▼                     ▼
@@ -108,7 +109,7 @@ The interactive wizard handles everything except manually adding your API tokens
 ## What Runs Automatically vs User Interaction
-### `/initial-setup` - Full Setup
+### `/setup --full` - Full Setup
 | Phase | Type | What Happens |
 |-------|------|--------------|
@@ -120,7 +121,7 @@ The interactive wizard handles everything except manually adding your API tokens
 | **6. Project Config** | Automated | Creates `.env` file, checks `.gitignore` |
 | **7. Validation** | Automated | Tests API connectivity, shows summary |
-### `/project-init` - Quick Project Setup
+### `/setup --quick` - Quick Project Setup
 | Phase | Type | What Happens |
 |-------|------|--------------|
@@ -131,23 +132,25 @@ The interactive wizard handles everything except manually adding your API tokens
 ---
-## Three Commands for Different Scenarios
+## One Command, Three Modes
-| Command | When to Use | What It Does |
+| Mode | When to Use | What It Does |
-|---------|-------------|--------------|
+|------|-------------|--------------|
-| `/initial-setup` | First time on a machine | Full setup: MCP server + system config + project config |
+| `/setup` | Any time | Auto-detects: runs full, quick, or sync as needed |
-| `/project-init` | Starting a new project | Quick setup: project config only (assumes system is ready) |
+| `/setup --full` | First time on a machine | Full setup: MCP server + system config + project config |
-| `/project-sync` | After repo move/rename | Updates .env to match current git remote |
+| `/setup --quick` | Starting a new project | Quick setup: project config only (assumes system is ready) |
 | `/setup --sync` | After repo move/rename | Updates .env to match current git remote |
 **Auto-detection logic:**
 1. No system config → **full** mode
 2. System config exists, no project config → **quick** mode
 3. Both exist, git remote differs → **sync** mode
 4. Both exist, match → already configured, offer to reconfigure
 **Typical workflow:**
-1. Install plugin → run `/initial-setup` (once per machine)
+1. Install plugin → run `/setup` (auto-runs full mode)
-2. Start new project → run `/project-init` (once per project)
+2. Start new project → run `/setup` (auto-runs quick mode)
-3. Repository moved? → run `/project-sync` (updates config)
+3. Repository moved? → run `/setup` (auto-runs sync mode)
 **Smart features:**
 - `/initial-setup` detects existing system config and offers quick project setup
 - All commands validate org/repo via Gitea API before saving (auto-fills if verified)
 - SessionStart hook automatically detects git remote vs .env mismatches
 ---
@@ -179,7 +182,7 @@ This marketplace uses a **hybrid configuration** approach:
 **Benefits:**
 - Single token per service (update once, use everywhere)
- Easy multi-project setup (just run `/project-init` in each project)
+- Easy multi-project setup (just run `/setup` in each project)
 - Security (tokens never committed to git, never typed into AI chat)
 - Project isolation (each project can override defaults)
@@ -187,7 +190,7 @@ This marketplace uses a **hybrid configuration** approach:
 ## Prerequisites
-Before running `/initial-setup`:
+Before running `/setup`:
 1. **Python 3.10+** installed
   ```bash
@@ -210,10 +213,10 @@ Before running `/initial-setup`:
 Run the setup wizard in Claude Code:
 ```
-/initial-setup
+/setup
 ```
-The wizard will guide you through each step interactively.
+The wizard will guide you through each step interactively and auto-detect the appropriate mode.
 **Note:** After first-time setup, you'll need to restart your Claude Code session for MCP tools to become available.
@@ -382,10 +385,10 @@ PR_REVIEW_AUTO_SUBMIT=false
 ## Plugin Configuration Summary
-| Plugin | System Config | Project Config | Setup Commands |
+| Plugin | System Config | Project Config | Setup Command |
-|--------|---------------|----------------|----------------|
+|--------|---------------|----------------|---------------|
-| **projman** | gitea.env | .env (GITEA_REPO=owner/repo) | `/initial-setup`, `/project-init`, `/project-sync` |
+| **projman** | gitea.env | .env (GITEA_REPO=owner/repo) | `/setup` |
-| **pr-review** | gitea.env | .env (GITEA_REPO=owner/repo) | `/initial-setup`, `/project-init`, `/project-sync` |
+| **pr-review** | gitea.env | .env (GITEA_REPO=owner/repo) | `/initial-setup` |
 | **git-flow** | git-flow.env (optional) | .env (optional) | None needed |
 | **clarity-assist** | None | None | None needed |
 | **cmdb-assistant** | netbox.env | None | `/initial-setup` |
@@ -402,21 +405,12 @@ PR_REVIEW_AUTO_SUBMIT=false
 Once system-level config is set up, adding new projects is simple:
 **Option 1: Use `/project-init` (faster)**
 ```
 cd ~/projects/new-project
-/project-init
+/setup
 ```
-**Option 2: Use `/initial-setup` (auto-detects)**
+The command auto-detects that system config exists and runs quick project setup.
 ```
 cd ~/projects/new-project
 /initial-setup
 # → Detects system config exists
 # → Offers "Quick project setup" option
 ```
 Both approaches work. Use `/project-init` when you know the system is already configured.
 ---
@@ -424,12 +418,12 @@ Both approaches work. Use `/project-init` when you know the system is already co
 ### API Validation
-When running `/initial-setup`, `/project-init`, or `/project-sync`, the commands:
+When running `/setup`, the command:
-1. **Detect** organization and repository from git remote URL
+1. **Detects** organization and repository from git remote URL
-2. **Validate** via Gitea API: `GET /api/v1/repos/{org}/{repo}`
+2. **Validates** via Gitea API: `GET /api/v1/repos/{org}/{repo}`
-3. **Auto-fill** if repository exists and is accessible (no confirmation needed)
+3. **Auto-fills** if repository exists and is accessible (no confirmation needed)
-4. **Ask for confirmation** only if validation fails (404 or permission error)
+4. **Asks for confirmation** only if validation fails (404 or permission error)
 This catches typos and permission issues before saving configuration.
@@ -439,7 +433,7 @@ When you start a Claude Code session, a hook automatically:
 1. Reads `GITEA_REPO` (in `owner/repo` format) from `.env`
 2. Compares with current `git remote get-url origin`
-3. **Warns** if mismatch detected: "Repository location mismatch. Run `/project-sync` to update."
+3. **Warns** if mismatch detected: "Repository location mismatch. Run `/setup --sync` to update."
 This helps when you:
 - Move a repository to a different organization
@@ -534,7 +528,7 @@ cat .env
 3. **Never type tokens into AI chat**
   - Always edit config files directly in your editor
-   - The `/initial-setup` wizard respects this
+   - The `/setup` wizard respects this
 4. **Rotate tokens periodically**
   - Every 6-12 months
--- a/docs/DEBUGGING-CHECKLIST.md
+++ b/docs/DEBUGGING-CHECKLIST.md
@@ -73,25 +73,19 @@ cd $RUNTIME && ./scripts/setup.sh
 ---
-## Step 4: Verify Symlink Resolution
+## Step 4: Verify MCP Configuration
-Plugins use symlinks to shared MCP servers. Verify they resolve correctly:
+Check `.mcp.json` at marketplace root is correctly configured:
 ```bash
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
-# Check symlinks exist and resolve
+# Check .mcp.json exists and has valid content
-readlink -f $RUNTIME/plugins/projman/mcp-servers/gitea
+cat $RUNTIME/.mcp.json | jq '.mcpServers | keys'
 readlink -f $RUNTIME/plugins/pr-review/mcp-servers/gitea
 readlink -f $RUNTIME/plugins/cmdb-assistant/mcp-servers/netbox
-# Should resolve to:
+# Should list: gitea, netbox, data-platform, viz-platform, contract-validator
 # $RUNTIME/mcp-servers/gitea
 # $RUNTIME/mcp-servers/netbox
 ```
 **If broken:** Symlinks are relative. If directory structure differs, they'll break.
 ---
 ## Step 5: Test MCP Server Startup
@@ -165,10 +159,8 @@ echo -e "\n=== Virtual Environments ==="
 [ -f "$RUNTIME/mcp-servers/gitea/.venv/bin/python" ] && echo "Gitea venv: OK" || echo "Gitea venv: MISSING"
 [ -f "$RUNTIME/mcp-servers/netbox/.venv/bin/python" ] && echo "NetBox venv: OK" || echo "NetBox venv: MISSING"
-echo -e "\n=== Symlinks ==="
+echo -e "\n=== MCP Configuration ==="
-[ -L "$RUNTIME/plugins/projman/mcp-servers/gitea" ] && echo "projman->gitea: OK" || echo "projman->gitea: MISSING"
+[ -f "$RUNTIME/.mcp.json" ] && echo ".mcp.json: OK" || echo ".mcp.json: MISSING"
 [ -L "$RUNTIME/plugins/pr-review/mcp-servers/gitea" ] && echo "pr-review->gitea: OK" || echo "pr-review->gitea: MISSING"
 [ -L "$RUNTIME/plugins/cmdb-assistant/mcp-servers/netbox" ] && echo "cmdb-assistant->netbox: OK" || echo "cmdb-assistant->netbox: MISSING"
 echo -e "\n=== Config Files ==="
 [ -f ~/.config/claude/gitea.env ] && echo "gitea.env: OK" || echo "gitea.env: MISSING"
@@ -182,7 +174,7 @@ echo -e "\n=== Config Files ==="
 | Issue | Symptom | Fix |
 |-------|---------|-----|
 | Missing venvs | "X MCP servers failed" | `cd ~/.claude/plugins/marketplaces/leo-claude-mktplace && ./scripts/setup.sh` |
-| Broken symlinks | MCP tools not available | Reinstall marketplace or manually recreate symlinks |
+| Missing .mcp.json | MCP tools not available | Check `.mcp.json` exists at marketplace root |
 | Wrong path edits | Changes don't take effect | Edit installed path or reinstall after source changes |
 | Missing credentials | MCP connection errors | Create `~/.config/claude/gitea.env` with API credentials |
 | Invalid hook events | Hooks don't fire | Use only valid event names (see Step 7) |
@@ -287,8 +279,8 @@ Error: Could not find a suitable TLS CA certificate bundle, invalid path:
 Use these commands for automated checking:
- `/debug-report` - Run full diagnostics, create issue if problems found
+- `/debug report` - Run full diagnostics, create issue if problems found
- `/debug-review` - Investigate existing diagnostic issues and propose fixes
+- `/debug review` - Investigate existing diagnostic issues and propose fixes
 ---
--- a/docs/UPDATING.md
+++ b/docs/UPDATING.md
@@ -162,7 +162,7 @@ If that doesn't work:
   ls ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/gitea/.venv
   ls ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/netbox/.venv
   ```
-3. If missing, the symlinks won't resolve. Run setup.sh as shown above.
+3. If missing, run setup.sh as shown above.
 4. Restart Claude Code session
 5. Check logs for specific errors
--- a/mcp-servers/viz-platform/README.md
+++ b/mcp-servers/viz-platform/README.md
@@ -112,4 +112,4 @@ pytest tests/ -v
 ## Usage
-This MCP server is used by the `viz-platform` plugin. See [plugins/viz-platform/README.md](../../plugins/viz-platform/README.md) for usage instructions.
+This MCP server is used by the `viz-platform` plugin. See the plugin's commands in `plugins/viz-platform/commands/` for usage.
--- a/plugins/clarity-assist/README.md
+++ b/plugins/clarity-assist/README.md
@@ -1,103 +0,0 @@
 # clarity-assist
 Prompt optimization and requirement clarification plugin with neurodivergent-friendly accommodations.
 ## Overview
 clarity-assist helps transform vague, incomplete, or ambiguous requests into clear, actionable specifications. It uses a structured 4-D methodology (Deconstruct, Diagnose, Develop, Deliver) and ND-friendly communication patterns.
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/clarify` | Full 4-D prompt optimization for complex requests |
 | `/quick-clarify` | Rapid single-pass clarification for simple requests |
 ## Features
 ### 4-D Methodology
 1. **Deconstruct** - Break down the request into components
 2. **Diagnose** - Analyze gaps and potential issues
 3. **Develop** - Gather clarifications through structured questions
 4. **Deliver** - Produce refined specification
 ### ND-Friendly Design
 - **Option-based questioning** - Always provide 2-4 concrete choices
 - **Chunked questions** - Ask 1-2 questions at a time
 - **Context for questions** - Explain why you're asking
 - **Conflict detection** - Check previous answers before new questions
 - **Progress acknowledgment** - Summarize frequently
 ### Escalation Protocol
 When requests are complex or users seem overwhelmed:
 - Acknowledge complexity
 - Offer to focus on one aspect at a time
 - Build incrementally
 ## Installation
 Add to your project's `.claude/settings.json`:
 ```json
 {
  "plugins": ["clarity-assist"]
 }
 ```
 ## Usage
 ### Full Clarification
 ```
 /clarify
 [Your vague or complex request here]
 ```
 ### Quick Clarification
 ```
 /quick-clarify
 [Your mostly-clear request here]
 ```
 ## Configuration
 No configuration required. The plugin uses sensible defaults.
 ## Output Format
 After clarification, you receive a structured specification:
 ```markdown
 ## Clarified Request
 ### Summary
 [Description of what will be built]
 ### Scope
 **In Scope:** [items]
 **Out of Scope:** [items]
 ### Requirements
 [Prioritized table]
 ### Assumptions
 [List of assumptions]
 ```
 ## Documentation
 - [Neurodivergent Support Guide](docs/ND-SUPPORT.md) - How clarity-assist supports ND users with executive function challenges and cognitive differences
 ## Integration
 For CLAUDE.md integration instructions, see `claude-md-integration.md`.
 ## License
 MIT
--- a/plugins/claude-config-maintainer/README.md
+++ b/plugins/claude-config-maintainer/README.md
@@ -1,126 +0,0 @@
 # Claude Config Maintainer
 A Claude Code plugin for creating and maintaining optimized CLAUDE.md configuration files.
 ## Overview
 CLAUDE.md files provide instructions to Claude Code when working with a project. This plugin helps you:
 - **Analyze** existing CLAUDE.md files for improvement opportunities
 - **Optimize** structure, clarity, and conciseness
 - **Initialize** new CLAUDE.md files with project-specific content
 ## Installation
 This plugin is part of the Leo Claude Marketplace. Install the marketplace and the plugin will be available.
 ## Commands
 ### `/config-analyze`
 Analyze your CLAUDE.md and get a detailed report with scores and recommendations.
 ```
 /config-analyze
 ```
 ### `/config-optimize`
 Automatically optimize your CLAUDE.md based on best practices.
 ```
 /config-optimize
 ```
 ### `/config-init`
 Create a new CLAUDE.md tailored to your project.
 ```
 /config-init
 ```
 ### `/config-diff`
 Show differences between current CLAUDE.md and previous versions.
 ```
 /config-diff                    # Compare working copy vs last commit
 /config-diff --commit=abc1234   # Compare against specific commit
 /config-diff --from=v1.0 --to=v2.0  # Compare two commits
 /config-diff --section="Critical Rules"  # Focus on specific section
 ```
 ### `/config-lint`
 Lint CLAUDE.md for common anti-patterns and best practices.
 ```
 /config-lint                    # Run all lint checks
 /config-lint --fix              # Auto-fix fixable issues
 /config-lint --rules=security   # Check only security rules
 /config-lint --severity=error   # Show only errors
 ```
 **Lint Rule Categories:**
 - **Security (SEC)** - Hardcoded secrets, paths, credentials
 - **Structure (STR)** - Header hierarchy, required sections
 - **Content (CNT)** - Contradictions, duplicates, vague rules
 - **Format (FMT)** - Consistency, code blocks, whitespace
 - **Best Practice (BPR)** - Missing Quick Start, Critical Rules sections
 ## Best Practices
 A good CLAUDE.md should be:
 - **Clear** - Easy to understand at a glance
 - **Concise** - No unnecessary content
 - **Complete** - All essential information included
 - **Current** - Up to date with the project
 ### Recommended Structure
 ```markdown
 # CLAUDE.md
 ## Project Overview
 What does this project do?
 ## Quick Start
 Essential build/test/run commands.
 ## Critical Rules
 What must Claude NEVER do?
 ## Architecture (optional)
 Key technical decisions.
 ## Common Operations (optional)
 Frequent tasks and workflows.
 ```
 ### Length Guidelines
 | Project Size | Recommended Lines |
 |-------------|------------------|
 | Small | 50-100 |
 | Medium | 100-200 |
 | Large | 200-400 |
 ## Scoring System
 The analyzer scores CLAUDE.md files on:
 - **Structure** (25 pts) - Organization and navigation
 - **Clarity** (25 pts) - Clear, unambiguous instructions
 - **Completeness** (25 pts) - Essential sections present
 - **Conciseness** (25 pts) - Efficient information density
 Target score: **70+** for effective Claude Code usage.
 ## Tips
 1. Run `/config-analyze` periodically to maintain quality
 2. Update CLAUDE.md when adding major features
 3. Keep critical rules prominent and clear
 4. Include examples where they add clarity
 5. Remove generic advice that applies to all projects
 ## Contributing
 This plugin is part of the personal-projects/leo-claude-mktplace repository.
--- a/plugins/cmdb-assistant/README.md
+++ b/plugins/cmdb-assistant/README.md
@@ -1,217 +0,0 @@
 # CMDB Assistant
 A Claude Code plugin for NetBox CMDB integration - query, create, update, and manage your network infrastructure directly from Claude Code.
 ## What's New in v1.2.0
 - **`/cmdb-topology`**: Generate Mermaid diagrams showing infrastructure topology (rack view, network view, site overview)
 - **`/change-audit`**: Query and analyze NetBox audit log for change tracking and compliance
 - **`/ip-conflicts`**: Detect IP address conflicts and overlapping prefixes
 ## What's New in v1.1.0
 - **Data Quality Validation**: Hooks for SessionStart and PreToolUse that check data quality and warn about missing fields
 - **Best Practices Skill**: Reference documentation for NetBox patterns (naming conventions, dependency order, role management)
 - **`/cmdb-audit`**: Analyze data quality across VMs, devices, naming conventions, and roles
 - **`/cmdb-register`**: Register the current machine into NetBox with all running applications (Docker containers, systemd services)
 - **`/cmdb-sync`**: Synchronize existing machine state with NetBox (detect drift, update with confirmation)
 ## Features
 - **Full CRUD Operations**: Create, read, update, and delete across all NetBox modules
 - **Smart Search**: Find devices, IPs, sites, and more with natural language queries
 - **IP Management**: Allocate IPs, manage prefixes, track VLANs
 - **Infrastructure Documentation**: Document servers, network devices, and connections
 - **Audit Trail**: Review changes and maintain infrastructure history
 - **Data Quality Validation**: Proactive checks for missing site, tenant, platform assignments
 - **Machine Registration**: Auto-discover and register servers with running applications
 - **Drift Detection**: Sync machine state and detect changes over time
 ## Installation
 ### Prerequisites
 1. A running NetBox instance (v4.x recommended)
 2. NetBox API token with appropriate permissions
 3. The NetBox MCP server configured (see below)
 ### Configure NetBox Credentials
 Create the configuration file:
 ```bash
 mkdir -p ~/.config/claude
 cat > ~/.config/claude/netbox.env << 'EOF'
 NETBOX_API_URL=https://your-netbox-instance/api
 NETBOX_API_TOKEN=your-api-token-here
 NETBOX_VERIFY_SSL=true
 NETBOX_TIMEOUT=30
 EOF
 ```
 ### Install the Plugin
 Add to your Claude Code plugins or marketplace configuration.
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/initial-setup` | Interactive setup wizard for NetBox MCP server |
 | `/cmdb-search <query>` | Search for devices, IPs, sites, or any CMDB object |
 | `/cmdb-device <action>` | Manage network devices (list, create, update, delete) |
 | `/cmdb-ip <action>` | Manage IP addresses and prefixes |
 | `/cmdb-site <action>` | Manage sites and locations |
 | `/cmdb-audit [scope]` | Data quality analysis (all, vms, devices, naming, roles) |
 | `/cmdb-register` | Register current machine into NetBox with running apps |
 | `/cmdb-sync` | Sync machine state with NetBox (detect drift, update) |
 | `/cmdb-topology <view>` | Generate Mermaid diagrams (rack, network, site, full) |
 | `/change-audit [filters]` | Query NetBox audit log for change tracking |
 | `/ip-conflicts [scope]` | Detect IP conflicts and overlapping prefixes |
 ## Agent
 The **cmdb-assistant** agent provides conversational infrastructure management:
 ```
@cmdb-assistant Show me all devices at the headquarters site
@cmdb-assistant Allocate the next available IP from 10.0.1.0/24 for the new web server
@cmdb-assistant What changes were made to the network today?
 ```
 ## Usage Examples
 ### Search for Infrastructure
 ```
 /cmdb-search router
 /cmdb-search 10.0.1.0/24
 /cmdb-search datacenter
 ```
 ### Device Management
 ```
 /cmdb-device list
 /cmdb-device show core-router-01
 /cmdb-device create web-server-03
 /cmdb-device at headquarters
 ```
 ### IP Address Management
 ```
 /cmdb-ip prefixes
 /cmdb-ip available in 10.0.1.0/24
 /cmdb-ip allocate from 10.0.1.0/24
 ```
 ### Site Management
 ```
 /cmdb-site list
 /cmdb-site show headquarters
 /cmdb-site racks at datacenter-east
 ```
 ## NetBox Coverage
 This plugin provides access to the full NetBox API:
 - **DCIM**: Sites, Locations, Racks, Devices, Interfaces, Cables, Power
 - **IPAM**: IP Addresses, Prefixes, VLANs, VRFs, ASNs, Services
 - **Circuits**: Providers, Circuits, Terminations
 - **Virtualization**: Clusters, Virtual Machines, VM Interfaces
 - **Tenancy**: Tenants, Contacts
 - **VPN**: Tunnels, L2VPNs, IKE/IPSec Policies
 - **Wireless**: WLANs, Wireless Links
 - **Extras**: Tags, Custom Fields, Journal Entries, Audit Log
 ## Hooks
 | Event | Purpose |
 |-------|---------|
 | `SessionStart` | Test NetBox connectivity, report data quality issues |
 | `PreToolUse` | Validate VM/device parameters before create/update |
 Hooks are **non-blocking** - they emit warnings but never prevent operations.
 ## Architecture
 ```
 cmdb-assistant/
 ├── .claude-plugin/
 │   └── plugin.json          # Plugin manifest
 ├── .mcp.json                 # MCP server configuration
 ├── commands/
 │   ├── initial-setup.md     # Setup wizard
 │   ├── cmdb-search.md       # Search command
 │   ├── cmdb-device.md       # Device management
 │   ├── cmdb-ip.md           # IP management
 │   ├── cmdb-site.md         # Site management
 │   ├── cmdb-audit.md        # Data quality audit
 │   ├── cmdb-register.md     # Machine registration
 │   ├── cmdb-sync.md         # Machine sync
 │   ├── cmdb-topology.md     # Topology visualization (NEW)
 │   ├── change-audit.md      # Change audit log (NEW)
 │   └── ip-conflicts.md      # IP conflict detection (NEW)
 ├── hooks/
 │   ├── hooks.json           # Hook configuration
 │   ├── startup-check.sh     # SessionStart validation
 │   └── validate-input.sh    # PreToolUse validation
 ├── skills/
 │   └── netbox-patterns/
 │       └── SKILL.md         # NetBox best practices reference
 ├── agents/
 │   └── cmdb-assistant.md    # Main assistant agent
 └── README.md
 ```
 The plugin uses the shared NetBox MCP server at `mcp-servers/netbox/`.
 ## Configuration
 ### Required Environment Variables
 | Variable | Description |
 |----------|-------------|
 | `NETBOX_API_URL` | Full URL to NetBox API (e.g., `https://netbox.example.com/api`) |
 | `NETBOX_API_TOKEN` | API authentication token |
 ### Optional Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `NETBOX_VERIFY_SSL` | `true` | Verify SSL certificates |
 | `NETBOX_TIMEOUT` | `30` | Request timeout in seconds |
 ## Getting a NetBox API Token
 1. Log into your NetBox instance
 2. Navigate to your profile (top-right menu)
 3. Go to "API Tokens"
 4. Click "Add a token"
 5. Set appropriate permissions (read-only or read-write)
 6. Copy the generated token
 ## Troubleshooting
 ### Connection Issues
 - Verify `NETBOX_API_URL` is correct and accessible
 - Check firewall rules allow access to NetBox
 - For self-signed certificates, set `NETBOX_VERIFY_SSL=false`
 ### Authentication Errors
 - Ensure API token is valid and not expired
 - Check token has required permissions for the operation
 ### Timeout Errors
 - Increase `NETBOX_TIMEOUT` for slow connections
 - Check network latency to NetBox instance
 ## License
 MIT License - Part of the Leo Claude Marketplace.
--- a/plugins/cmdb-assistant/mcp-servers/netbox
+++ b/plugins/cmdb-assistant/mcp-servers/netbox
@@ -1 +0,0 @@
 ../../../mcp-servers/netbox
--- a/plugins/code-sentinel/README.md
+++ b/plugins/code-sentinel/README.md
@@ -1,47 +0,0 @@
 # code-sentinel
 Security scanning and code refactoring tools for Claude Code projects.
 ## Features
 ### Security Scanning
 - **PreToolUse Hook**: Catches vulnerabilities BEFORE code is written
 - **Full Audit**: `/security-scan` for comprehensive project review
 - **Pattern Detection**: SQL injection, XSS, command injection, secrets, and more
 ### Refactoring
 - **Pattern Library**: Extract method, simplify conditionals, modernize syntax
 - **Safe Transforms**: Preview changes before applying
 - **Reference Updates**: Automatically updates all call sites
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/security-scan` | Full project security audit |
 | `/refactor <target>` | Apply refactoring with pattern |
 | `/refactor-dry <target>` | Preview opportunities without changes |
 ## Hooks
 - **PreToolUse (Write\|Edit)**: Scans code for security patterns before writing
 ## Security Patterns Detected
 | Category | Examples |
 |----------|----------|
 | Injection | SQL, Command, Code (eval), XSS |
 | Secrets | Hardcoded API keys, passwords |
 | Deserialization | Pickle, unsafe YAML |
 | Path Traversal | Unsanitized file paths |
 ## Installation
 ```bash
 /plugin marketplace add https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git
 /plugin install code-sentinel
 ```
 ## Integration
 See claude-md-integration.md for CLAUDE.md additions.
--- a/plugins/contract-validator/README.md
+++ b/plugins/contract-validator/README.md
@@ -1,169 +0,0 @@
 # contract-validator Plugin
 Cross-plugin compatibility validation and CLAUDE.md agent verification for Claude Code plugin marketplaces.
 ## Problem Statement
 As plugin marketplaces grow, several compatibility issues emerge:
 - **Command conflicts**: Multiple plugins defining the same slash command (e.g., `/initial-setup`)
 - **Tool name overlaps**: Different plugins using identical tool names with incompatible interfaces
 - **Undocumented dependencies**: Agents referencing tools that don't exist
 - **Broken data flows**: Agent sequences that expect outputs not produced by prior steps
 Contract-validator solves these by parsing plugin interfaces and validating compatibility before runtime.
 ## Features
 - **Interface Parsing**: Extract commands, agents, and tools from plugin README.md files
 - **Agent Extraction**: Parse CLAUDE.md Four-Agent Model tables and Agents sections
 - **Compatibility Checks**: Pairwise validation between all plugins in a marketplace
 - **Data Flow Validation**: Verify agent tool sequences have valid data producers/consumers
 - **Dependency Visualization**: Generate Mermaid flowcharts showing plugin relationships
 - **Comprehensive Reports**: Markdown or JSON reports with actionable suggestions
 ## Installation
 This plugin is part of the leo-claude-mktplace. Install via:
 ```bash
 # From marketplace
 claude plugins install leo-claude-mktplace/contract-validator
 # Setup MCP server venv
 cd ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/contract-validator
 python -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 ```
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/initial-setup` | Interactive setup wizard |
 | `/validate-contracts` | Full marketplace compatibility validation |
 | `/check-agent` | Validate single agent definition |
 | `/list-interfaces` | Show all plugin interfaces |
 | `/dependency-graph` | Generate Mermaid flowchart of plugin dependencies |
 ## Agents
 | Agent | Description |
 |-------|-------------|
 | `full-validation` | Complete cross-plugin compatibility validation |
 | `agent-check` | Single agent definition verification |
 ## Tools Summary
 ### Parse Tools (2)
 - `parse_plugin_interface` - Extract interface from plugin README.md
 - `parse_claude_md_agents` - Extract agents from CLAUDE.md
 ### Validation Tools (3)
 - `validate_compatibility` - Check two plugins for conflicts
 - `validate_agent_refs` - Verify agent tool references exist
 - `validate_data_flow` - Check data flow through agent sequences
 ### Report Tools (2)
 - `generate_compatibility_report` - Full marketplace validation report
 - `list_issues` - Filter issues by severity or type
 ## Example Workflow
 ```
 /validate-contracts ~/claude-plugins-work
 # Output:
 # Contract Validation Report
 #
 # | Metric     | Count |
 # |------------|-------|
 # | Plugins    | 12    |
 # | Commands   | 39    |
 # | Tools      | 32    |
 # | **Issues** | **7** |
 # | - Errors   | 3     |
 # | - Warnings | 0     |
 # | - Info     | 4     |
 #
 # ## Issues Found
 # [ERROR] Command conflict: projman and data-platform both define /initial-setup
 # [ERROR] Command conflict: projman and pr-review both define /initial-setup
 # ...
 ```
 ```
 /check-agent Planner ./CLAUDE.md
 # Output:
 # Agent: Planner
 # Status: VALID
 #
 # Tool References Found (3):
 # - create_issue ✓
 # - search_lessons ✓
 # - get_execution_order ✓
 #
 # Data Flow: No issues detected
 ```
 ```
 /dependency-graph
 # Output: Mermaid flowchart showing:
 # - Plugins grouped by shared MCP servers
 # - Data flow from data-platform to viz-platform
 # - Required vs optional dependencies
 # - Command counts per plugin
 ```
 ## Issue Types
 | Type | Severity | Description |
 |------|----------|-------------|
 | `interface_mismatch` | ERROR | Command name conflict between plugins |
 | `missing_tool` | ERROR | Agent references non-existent tool |
 | `interface_mismatch` | WARNING | Tool name overlap (different plugins) |
 | `optional_dependency` | WARNING | Agent uses tool from non-required plugin |
 | `undeclared_output` | INFO | Agent has no documented tool references |
 ## Parsed Interface Structure
 When parsing a plugin README.md, the following structure is extracted:
 ```json
 {
  "plugin_name": "data-platform",
  "description": "Data engineering tools...",
  "commands": [
    {"name": "/ingest", "description": "Load data..."}
  ],
  "agents": [
    {"name": "data-analysis", "description": "..."}
  ],
  "tools": [
    {"name": "read_csv", "category": "pandas"}
  ],
  "tool_categories": {
    "pandas": ["read_csv", "to_csv", ...],
    "PostgreSQL": ["pg_query", ...]
  },
  "features": ["pandas Operations", "PostgreSQL/PostGIS", ...]
 }
 ```
 ## Best Practices
 ### For Plugin Authors
 1. **Use unique command names**: Prefix with plugin name if generic (e.g., `/data-setup` vs `/initial-setup`)
 2. **Document all tools**: Include tool names in README.md with backticks
 3. **Specify tool categories**: Use `### Category (N tools)` headers
 4. **Declare agent tools**: List tools used by agents in their definitions
 ### For Marketplace Maintainers
 1. **Run validation before merging**: Use `/validate-contracts` in CI/CD
 2. **Review warnings**: Tool overlaps may indicate design issues
 3. **Track issues over time**: Use JSON format for programmatic tracking
--- a/plugins/contract-validator/mcp-servers/contract-validator
+++ b/plugins/contract-validator/mcp-servers/contract-validator
@@ -1 +0,0 @@
 ../../../mcp-servers/contract-validator
--- a/plugins/data-platform/README.md
+++ b/plugins/data-platform/README.md
@@ -1,122 +0,0 @@
 # data-platform Plugin
 Data engineering tools with pandas, PostgreSQL/PostGIS, and dbt integration for Claude Code.
 ## Features
 - **pandas Operations**: Load, transform, and export DataFrames with persistent data_ref system
 - **PostgreSQL/PostGIS**: Database queries with connection pooling and spatial data support
 - **dbt Integration**: Build tool wrapper with pre-execution validation
 ## Installation
 This plugin is part of the leo-claude-mktplace. Install via:
 ```bash
 # From marketplace
 claude plugins install leo-claude-mktplace/data-platform
 # Setup MCP server venv
 cd ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/data-platform
 python -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 ```
 ## Configuration
 ### PostgreSQL (Optional)
 Create `~/.config/claude/postgres.env`:
 ```env
 POSTGRES_URL=postgresql://user:password@host:5432/database
 ```
 ### dbt (Optional)
 Add to project `.env`:
 ```env
 DBT_PROJECT_DIR=/path/to/dbt/project
 DBT_PROFILES_DIR=~/.dbt
 ```
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/initial-setup` | Interactive setup wizard for PostgreSQL and dbt configuration |
 | `/ingest` | Load data from files or database |
 | `/profile` | Generate data profile and statistics |
 | `/data-quality` | Data quality assessment with pass/warn/fail scoring |
 | `/schema` | Show database/DataFrame schema |
 | `/explain` | Explain dbt model lineage |
 | `/lineage` | Visualize data dependencies (ASCII) |
 | `/lineage-viz` | Generate Mermaid flowchart for dbt lineage |
 | `/run` | Execute dbt models |
 | `/dbt-test` | Run dbt tests with formatted results |
 ## Agents
 | Agent | Description |
 |-------|-------------|
 | `data-ingestion` | Data loading and transformation specialist |
 | `data-analysis` | Exploration and profiling specialist |
 ## data_ref System
 All DataFrame operations use a `data_ref` system for persistence:
 ```
 # Load returns a reference
 read_csv("data.csv") → {"data_ref": "sales_data"}
 # Use reference in subsequent operations
 filter("sales_data", "amount > 100") → {"data_ref": "sales_data_filtered"}
 describe("sales_data_filtered") → {statistics}
 ```
 ## Example Workflow
 ```
 /ingest data/sales.csv
 # → Loaded 50,000 rows as "sales_data"
 /profile sales_data
 # → Statistical summary, null counts, quality assessment
 /schema orders
 # → Column names, types, constraints
 /lineage fct_orders
 # → Dependency graph showing upstream/downstream models
 /run dim_customers
 # → Pre-validates then executes dbt model
 ```
 ## Tools Summary
 ### pandas (14 tools)
 `read_csv`, `read_parquet`, `read_json`, `to_csv`, `to_parquet`, `describe`, `head`, `tail`, `filter`, `select`, `groupby`, `join`, `list_data`, `drop_data`
 ### PostgreSQL (6 tools)
 `pg_connect`, `pg_query`, `pg_execute`, `pg_tables`, `pg_columns`, `pg_schemas`
 ### PostGIS (4 tools)
 `st_tables`, `st_geometry_type`, `st_srid`, `st_extent`
 ### dbt (8 tools)
 `dbt_parse`, `dbt_run`, `dbt_test`, `dbt_build`, `dbt_compile`, `dbt_ls`, `dbt_docs_generate`, `dbt_lineage`
 ## Memory Management
 - Default limit: 100,000 rows per DataFrame
 - Configure via `DATA_PLATFORM_MAX_ROWS` environment variable
 - Use `chunk_size` parameter for large files
 - Monitor with `list_data` tool
 ## SessionStart Hook
 On session start, the plugin checks PostgreSQL connectivity and displays a warning if unavailable. This is non-blocking - pandas and dbt tools remain available.
--- a/plugins/data-platform/mcp-servers/data-platform
+++ b/plugins/data-platform/mcp-servers/data-platform
@@ -1 +0,0 @@
 ../../../mcp-servers/data-platform
--- a/plugins/doc-guardian/README.md
+++ b/plugins/doc-guardian/README.md
@@ -1,53 +0,0 @@
 # doc-guardian
 Automatic documentation drift detection and synchronization for Claude Code projects.
 ## Problem Solved
 Documentation gets outdated. Functions get renamed, configs change, versions bump—but docs lag behind. This creates:
 - Multiple review cycles finding stale references
 - Unnecessary commits fixing docs piecemeal
 - User confusion from outdated instructions
 ## Solution
 doc-guardian monitors your code changes via hooks:
 1. Detects when changes might affect documentation
 2. Alerts you to potential drift (doesn't interrupt your flow)
 3. Provides commands to audit and sync docs when ready
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/doc-audit` | Full project scan - reports all drift without changing anything |
 | `/doc-sync` | Apply all pending documentation updates in one commit |
 | `/changelog-gen` | Generate changelog from conventional commits in Keep-a-Changelog format |
 | `/doc-coverage` | Calculate documentation coverage percentage for functions and classes |
 | `/stale-docs` | Detect documentation files that are stale relative to their associated code |
 ## Hooks
 - **PostToolUse (Write|Edit)**: Silently checks if code changes affect docs
 ## What It Detects
 - **Broken References**: Function/class renamed but docs still use old name
 - **Version Drift**: Python 3.9 in docs but 3.11 in pyproject.toml
 - **Missing Docs**: Public functions without docstrings
 - **Stale Examples**: CLI examples that no longer work
 - **Low Coverage**: Undocumented functions and classes
 - **Stale Files**: Documentation that hasn't been updated alongside code changes
 ## Installation
 This plugin is part of the Leo Claude Marketplace.
 ```bash
 /plugin marketplace add https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git
 /plugin install doc-guardian
 ```
 ## Integration
 See claude-md-integration.md for CLAUDE.md additions.
--- a/plugins/git-flow/README.md
+++ b/plugins/git-flow/README.md
@@ -1,132 +0,0 @@
 # git-flow
 Git workflow automation with intelligent commit messages and branch management.
 ## Overview
 git-flow streamlines common git operations with smart defaults, conventional commit messages, and workflow enforcement. It supports multiple branching strategies and adapts to your team's workflow.
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/commit` | Create commit with auto-generated conventional message (with protected branch detection) |
 | `/commit-push` | Commit and push in one operation |
 | `/commit-merge` | Commit and merge into target branch |
 | `/commit-sync` | Full sync: commit, push, and rebase on base branch |
 | `/branch-start` | Start new feature/fix/chore branch |
 | `/branch-cleanup` | Clean up merged branches |
 | `/git-status` | Enhanced status with recommendations |
 | `/git-config` | Configure git-flow settings |
 ## Workflow Styles
 | Style | Description | Best For |
 |-------|-------------|----------|
 | `simple` | Direct commits to main | Solo projects |
 | `feature-branch` | Feature branches, merge when done | Small teams |
 | `pr-required` | All changes via pull request | Code review workflows |
 | `trunk-based` | Short-lived branches, frequent integration | CI/CD heavy |
 ## Installation
 Add to your project's `.claude/settings.json`:
 ```json
 {
  "plugins": ["git-flow"]
 }
 ```
 ## Configuration
 Set environment variables in `.env` or `~/.config/claude/git-flow.env`:
 ```bash
 GIT_WORKFLOW_STYLE=feature-branch
 GIT_DEFAULT_BASE=development
 GIT_AUTO_DELETE_MERGED=true
 GIT_AUTO_PUSH=false
 GIT_PROTECTED_BRANCHES=main,master,development,staging
 GIT_COMMIT_STYLE=conventional
 GIT_CO_AUTHOR=true
 ```
 Or use `/git-config` for interactive configuration.
 ## Features
 ### Smart Commit Messages
 Analyzes staged changes to generate appropriate conventional commit messages:
 ```
 feat(auth): add password reset functionality
 Implement forgot password flow with email verification.
 Includes rate limiting and token expiration.
 ```
 ### Branch Naming
 Enforces consistent branch naming:
 ```
 feat/add-user-authentication
 fix/login-timeout-error
 chore/update-dependencies
 ```
 ### Safety Checks
 - **Protected branch detection**: Before committing, checks if you're on a protected branch (main, master, development, staging, production by default). Offers to create a feature branch automatically instead of committing directly to protected branches.
 - Confirms force push operations
 - Prevents accidental branch deletion
 ### Conflict Resolution
 The git-assistant agent helps resolve merge conflicts with analysis and recommendations.
 ## Usage Examples
 ### Start a Feature
 ```
 /branch-start add user authentication
 → Created: feat/add-user-authentication
  Based on: development
 ```
 ### Commit Changes
 ```
 /commit
 → Analyzing changes...
 → Proposed: feat(auth): add login component
 → Committed: abc1234
 ```
 ### Full Sync
 ```
 /commit-sync
 → Committed: abc1234
 → Pushed to origin
 → Rebased on development
 → Status: Clean, up-to-date
 ```
 ## Documentation
 - [Branching Strategy Guide](docs/BRANCHING-STRATEGY.md) - Detailed documentation of the `development -> staging -> main` promotion flow
 ## Integration
 For CLAUDE.md integration instructions, see `claude-md-integration.md`.
 ## License
 MIT
--- a/plugins/pr-review/README.md
+++ b/plugins/pr-review/README.md
@@ -1,154 +0,0 @@
 # pr-review
 Multi-agent pull request review with confidence scoring and actionable feedback.
 ## Overview
 pr-review conducts comprehensive code reviews using specialized agents for security, performance, maintainability, and test coverage. Each finding includes a confidence score to reduce noise and focus on real issues.
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/pr-review <pr#>` | Full multi-agent review |
 | `/pr-summary <pr#>` | Quick summary without full review |
 | `/pr-findings <pr#>` | Filter findings by category/confidence |
 | `/pr-diff <pr#>` | View diff with inline comment annotations |
 | `/initial-setup` | Full interactive setup wizard |
 | `/project-init` | Quick project setup (system already configured) |
 | `/project-sync` | Sync configuration with current git remote |
 ## Review Agents
 | Agent | Focus |
 |-------|-------|
 | **Security Reviewer** | Injections, auth, data exposure, crypto |
 | **Performance Analyst** | N+1 queries, complexity, memory, caching |
 | **Maintainability Auditor** | Complexity, duplication, naming, coupling |
 | **Test Validator** | Coverage, test quality, flaky tests |
 ## Confidence Scoring
 Findings are scored 0.0 - 1.0:
 | Range | Label | Action |
 |-------|-------|--------|
 | 0.9 - 1.0 | HIGH | Must address |
 | 0.7 - 0.89 | MEDIUM | Should address |
 | 0.5 - 0.69 | LOW | Consider addressing |
 | < 0.5 | (suppressed) | Not reported |
 ## Installation
 Add to your project's `.claude/settings.json`:
 ```json
 {
  "plugins": ["pr-review"]
 }
 ```
 Requires Gitea MCP server configuration.
 ## Configuration
 Environment variables can be set in your project's `.env` file or shell environment.
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `PR_REVIEW_CONFIDENCE_THRESHOLD` | `0.7` | Minimum confidence score (0.0-1.0) for reporting findings. Findings below this threshold are filtered out to reduce noise. |
 | `PR_REVIEW_AUTO_SUBMIT` | `false` | Automatically submit review to Gitea without confirmation prompt |
 ### Example Configuration
 ```bash
 # Project .env file
 # Only show high-confidence findings (MEDIUM and HIGH)
 PR_REVIEW_CONFIDENCE_THRESHOLD=0.7
 # Auto-submit review to Gitea (default: false)
 PR_REVIEW_AUTO_SUBMIT=false
 ```
 ### Confidence Threshold Details
 The confidence threshold filters which findings appear in review output:
 | Threshold | Effect |
 |-----------|--------|
 | `0.9` | Only definite issues (HIGH confidence) |
 | `0.7` | Likely issues and above (MEDIUM+HIGH) - **recommended** |
 | `0.5` | Include possible concerns (LOW+MEDIUM+HIGH) |
 | `0.3` | Include speculative findings |
 Lower thresholds show more findings but may include false positives. Higher thresholds reduce noise but may miss some valid concerns.
 ## Usage Examples
 ### Full Review
 ```
 /pr-review 123
 ═══════════════════════════════════════════════════
 PR Review Report: #123
 ═══════════════════════════════════════════════════
 Summary:
  Files changed: 12
  Lines: +234 / -45
 Findings: 8 total
  🔴 Critical: 1
  🟠 Major: 2
  🟡 Minor: 3
  💡 Suggestions: 2
 [Detailed findings...]
 VERDICT: REQUEST_CHANGES
 ═══════════════════════════════════════════════════
 ```
 ### Filter Findings
 ```
 /pr-findings 123 --category security
 # Shows only security-related findings
 ```
 ### Quick Summary
 ```
 /pr-summary 123
 # Shows change overview without full analysis
 ```
 ## Output
 Review reports include:
 - Summary statistics
 - Findings grouped by severity
 - Code snippets with context
 - Suggested fixes
 - Overall verdict (APPROVE/COMMENT/REQUEST_CHANGES)
 ## Verdict Logic
 | Condition | Verdict |
 |-----------|---------|
 | Any critical finding | REQUEST_CHANGES |
 | 2+ major findings | REQUEST_CHANGES |
 | Only minor/suggestions | COMMENT |
 | No significant findings | APPROVE |
 ## Integration
 For CLAUDE.md integration instructions, see `claude-md-integration.md`.
 ## License
 MIT
--- a/plugins/pr-review/mcp-servers/gitea
+++ b/plugins/pr-review/mcp-servers/gitea
@@ -1 +0,0 @@
 ../../../mcp-servers/gitea
--- a/plugins/project-hygiene/README.md
+++ b/plugins/project-hygiene/README.md
@@ -1,135 +0,0 @@
 # project-hygiene
 Post-task cleanup hook plugin for Claude Code. Automatically cleans up temporary files, warns about unexpected files in the project root, and manages orphaned supporting files after task completion.
 ## Features
 - **Delete temp files**: Removes `*.tmp`, `*.bak`, `__pycache__`, `.pytest_cache`, and other common temporary patterns
 - **Root file warnings**: Alerts when unexpected files appear in project root
 - **Orphan detection**: Identifies `test_*`, `debug_*`, `*_backup.*` and similar files that may have been left behind
 - **Cleanup logging**: Records all actions to `.dev/logs/`
 - **Configurable**: Project-local `.hygiene.json` for custom rules
 ## Installation
 Add to your Claude Code configuration or install from the marketplace:
 ```bash
 claude plugin install project-hygiene
 ```
 ## How It Works
 The plugin registers a `PostToolUse` hook (on Write and Edit tools) that runs after Claude modifies files. It:
 1. Scans for and deletes known temporary file patterns
 2. Removes temporary directories (`__pycache__`, `.pytest_cache`, etc.)
 3. Checks for unexpected files in project root and warns
 4. Identifies orphaned supporting files (test files, debug scripts, backups)
 5. Optionally moves orphans to `.dev/scratch/` for review
 6. Logs all actions to `.dev/logs/hygiene-TIMESTAMP.log`
 ## Configuration
 Create `.hygiene.json` in your project root to customize behavior:
 ```json
 {
  "move_orphans": true,
  "allowed_root_files": [
    "custom-config.yaml",
    "my-script.sh"
  ],
  "temp_patterns": [
    "*.cache",
    "*.pid"
  ],
  "ignore_patterns": [
    "important_test_*.py",
    "keep_this_backup.*"
  ]
 }
 ```
 ### Options
 | Option | Type | Default | Description |
 |--------|------|---------|-------------|
 | `move_orphans` | boolean | `false` | Move orphaned files to `.dev/scratch/` instead of just warning |
 | `allowed_root_files` | array | (see below) | Additional files allowed in project root |
 | `temp_patterns` | array | `[]` | Additional temp file patterns to delete |
 | `ignore_patterns` | array | `[]` | Files to never touch during cleanup |
 ### Default Allowed Root Files
 The plugin recognizes common project files in root:
 - Git files: `.git`, `.gitignore`, `.gitattributes`
 - Config: `.editorconfig`, `.env*`, `.nvmrc`, etc.
 - Documentation: `README.md`, `LICENSE`, `CHANGELOG.md`, `CLAUDE.md`
 - Package managers: `package.json`, `requirements.txt`, `Cargo.toml`, `go.mod`, etc.
 - Build configs: `Makefile`, `Dockerfile`, `docker-compose.yml`, `tsconfig.json`, etc.
 ### Default Temp Patterns
 Automatically cleaned:
 - `*.tmp`, `*.bak`, `*.swp`, `*.swo`, `*~`
 - `.DS_Store`, `Thumbs.db`
 - `*.log`, `*.orig`, `*.pyc`, `*.pyo`
 ### Default Temp Directories
 Automatically removed:
 - `__pycache__`, `.pytest_cache`, `.mypy_cache`, `.ruff_cache`
 - `node_modules/.cache`, `.next/cache`, `.nuxt/.cache`, `.turbo`
 - `*.egg-info`, `.eggs`
 ### Orphan Patterns
 Files flagged as orphans:
 - `test_*.py` (standalone test files)
 - `debug_*` (debug scripts)
 - `*_backup.*`, `*_old.*`, `*_bak.*`, `*.backup`
 - `temp_*`, `tmp_*`
 ## Output
 After each task, you'll see output like:
 ```
 [14:32:15] Starting project hygiene cleanup...
 [14:32:15] Cleaning temp files...
 [14:32:15]   DELETED: ./src/__pycache__/utils.cpython-311.pyc
 [14:32:15]   DELETED: ./temp.bak
 [14:32:15] Cleaning temp directories...
 [14:32:15]   DELETED DIR: ./src/__pycache__
 [14:32:15] Checking root files...
 [14:32:15]   WARNING: Unexpected root file: random_notes.txt
 [14:32:15] Checking for orphaned files...
 [14:32:15]   ORPHAN: ./test_scratch.py
 [14:32:15]   ORPHAN: ./debug_api.py
 === Cleanup Summary ===
  Deleted: 3 items
  Warnings: 1 unexpected root files
  Orphans: 2 files
  Log file: .dev/logs/hygiene-20250110-143215.log
 ```
 ## Directory Structure
 ```
 .dev/
 ├── logs/
 │   └── hygiene-YYYYMMDD-HHMMSS.log
 └── scratch/        # (if move_orphans enabled)
    └── debug_api.py
 ```
 ## Requirements
 - Bash 4.0+
 - Optional: `jq` for JSON config parsing (falls back to defaults if not installed)
--- a/plugins/projman/README.md
+++ b/plugins/projman/README.md
@@ -1,560 +0,0 @@
 # Projman - Project Management for Claude Code
 Sprint planning and project management plugin with full Gitea integration.
 ## Overview
 Projman transforms a proven 15-sprint workflow into a distributable Claude Code plugin. It provides AI-guided sprint planning, intelligent issue creation with label taxonomy, native issue dependencies, parallel task execution, and systematic lessons learned capture via Gitea Wiki.
 **Key Features:**
 - **Sprint Planning** - AI-guided architecture analysis and issue creation
 - **Smart Label Suggestions** - Intelligent label recommendations from 43-label taxonomy
 - **Issue Dependencies** - Native Gitea dependencies with parallel execution batching
 - **Milestones** - Sprint milestone management and tracking
 - **Lessons Learned** - Systematic capture and search via Gitea Wiki
 - **Branch-Aware Security** - Prevents accidental changes on production branches
 - **Four-Agent Model** - Planner, Orchestrator, Executor, and Code Reviewer agents
 - **CLI Tools Blocked** - All operations via MCP tools only (no `tea` or `gh`)
 ## Quick Start
 ### 1. Prerequisites
 - Claude Code installed
 - Access to Gitea instance with API token
 - Python 3.10+ installed
 - Git repository initialized
 ### 2. Run Interactive Setup
 The setup wizard handles everything:
 ```
 /initial-setup
 ```
 This will:
 - Set up the MCP server (Python venv + dependencies)
 - Create system config (`~/.config/claude/gitea.env`)
 - Guide you through adding your Gitea token
 - Detect and validate your repository via API
 - Create project config (`.env`)
 **For new projects** (when system is already configured):
 ```
 /project-init
 ```
 **After moving a repository:**
 ```
 /project-sync
 ```
 See [docs/CONFIGURATION.md](../../docs/CONFIGURATION.md) for detailed instructions.
 ### 3. Start Planning!
 ```
 /sprint-plan
 ```
 ## Commands
 ### `/sprint-plan`
 Start sprint planning with the AI planner agent.
 **What it does:**
 - Validates repository organization and label taxonomy
 - Asks clarifying questions about sprint goals
 - Searches relevant lessons learned from previous sprints
 - Performs architecture analysis
 - Creates Gitea issues with intelligent label suggestions
 - Sets up issue dependencies for parallel execution
 - Creates sprint milestone
 **Pre-Planning Validations:**
 1. Repository belongs to configured organization
 2. Required label categories exist
 3. `docs/changes/` folder exists in repository
 **Task Naming:** `[Sprint XX] <type>: <description>`
 **When to use:** Beginning of a new sprint or when planning a major feature
 ### `/sprint-start`
 Begin sprint execution with the orchestrator agent.
 **What it does:**
 - Reviews open sprint issues and dependencies
 - Batches tasks by dependency graph for parallel execution
 - Generates lean execution prompts
 - Tracks progress
 **Parallel Execution:**
 ```
 Batch 1 (parallel): Task A, Task B, Task C
 Batch 2 (parallel): Task D, Task E  (depend on Batch 1)
 Batch 3 (sequential): Task F        (depends on Batch 2)
 ```
 **Branch Naming:** `feat/123-task-title`, `fix/456-bug-fix`, `debug/789-investigation`
 **When to use:** After planning, when ready to start implementation
 ### `/sprint-status`
 Check current sprint progress.
 **What it does:**
 - Lists all sprint issues by status (open, in progress, blocked, completed)
 - Shows dependency analysis and blocked tasks
 - Displays completion percentage
 - Shows milestone 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.
 **What it does:**
 - Reviews sprint completion
 - Captures lessons learned (what went wrong, what went right)
 - Tags lessons for discoverability
 - Saves lessons to Gitea Wiki
 - Closes sprint milestone
 - Handles git operations (merge, tag, cleanup)
 **When to use:** End of sprint, before starting the next one
 **CRITICAL:** Don't skip this! After 15 sprints without lesson capture, teams repeat the same mistakes.
 ### `/labels-sync`
 Synchronize label taxonomy from Gitea.
 **What it does:**
 - Validates repository belongs to organization
 - Fetches current labels from Gitea (org + repo)
 - Validates required label categories
 - Compares with local reference
 - Updates local taxonomy reference
 **When to use:**
 - First-time setup
 - Monthly maintenance
 - When new labels are added to Gitea
 ### `/initial-setup`
 Full interactive setup wizard.
 **What it does:**
 - Checks Python version (requires 3.10+)
 - Sets up MCP server virtual environment
 - Creates system-level config (`~/.config/claude/gitea.env`)
 - Guides token setup (manual entry for security)
 - Detects and validates repository via Gitea API
 - Creates project-level config (`.env` with GITEA_ORG, GITEA_REPO)
 **When to use:** First time on a new machine
 ### `/project-init`
 Quick project setup (assumes system config exists).
 **What it does:**
 - Verifies system configuration exists
 - Detects organization and repository from git remote
 - Validates via Gitea API
 - Creates project `.env` file
 **When to use:** Starting work on a new project
 ### `/project-sync`
 Sync configuration with current git remote.
 **What it does:**
 - Compares .env values with git remote URL
 - Validates new repository via Gitea API
 - Updates .env if mismatch detected
 **When to use:** After moving or renaming a repository
 **Note:** A SessionStart hook automatically checks for:
 1. Missing MCP venvs at the installed marketplace location (warns to run setup.sh)
 2. Repository config mismatches (warns to run `/project-sync`)
 ### `/review`
 Pre-sprint-close code quality review.
 **What it does:**
 - Scans recent changes for debug artifacts (TODO, console.log, commented code)
 - Checks for code complexity issues (long functions, deep nesting)
 - Performs lightweight security scan (hardcoded secrets, SQL injection risks)
 - Identifies error handling gaps (bare except, swallowed exceptions)
 **Output format:**
 - Critical Issues (Block Sprint Close)
 - Warnings (Should Address)
 - Recommendations (Nice to Have)
 **When to use:** Before closing a sprint to ensure code quality
 ### `/test-check`
 Test verification before sprint close.
 **What it does:**
 - Automatically detects test framework (pytest, Jest, Go test, Cargo, etc.)
 - Runs the test suite
 - Reports pass/fail summary with details on failures
 - Includes coverage report when available
 - Identifies sprint files lacking test coverage
 **Flags:**
 - "run tests with coverage" - Include coverage report
 - "run tests verbose" - Show full output
 - "just check, don't run" - Report framework detection only
 **When to use:** Before closing a sprint to ensure tests pass
 ### `/test-gen`
 Generate tests for specified code.
 **What it does:**
 - Analyzes target code (function, class, or module)
 - Auto-detects test framework (pytest, Jest, vitest, Go test, Cargo, etc.)
 - Generates comprehensive tests: happy path, edge cases, error cases
 - Supports unit, integration, e2e, and snapshot test types
 **Usage:**
 ```
 /test-gen <target> [--type=<type>] [--framework=<framework>]
 ```
 **Target:** File path, function name, class name, or module
 **Type:** unit (default), integration, e2e, snapshot
 **When to use:** When adding new code that needs test coverage
 ## Debug Workflow Commands
 These commands enable a cross-repository debugging workflow between your project and the marketplace.
 ### `/debug-report`
 Run diagnostics and create structured issue in marketplace repository.
 **What it does:**
 - Runs MCP tool diagnostics (validate_repo_org, get_labels, list_issues, etc.)
 - Captures error messages and hypothesis
 - Creates a structured issue in the marketplace repository
 - Tags with `Source: Diagnostic` label
 **When to use:** When MCP tools fail in your project, run this to report the issue to the marketplace for investigation.
 ### `/debug-review`
 Investigate diagnostic issues and propose fixes with human approval.
 **What it does:**
 - Fetches open diagnostic issues from marketplace
 - Lets you select which issue to investigate
 - Maps errors to relevant source files
 - Reads code and analyzes root cause
 - Proposes fixes with THREE mandatory approval gates
 - Creates PR with fix after approval
 **Approval Gates:**
 1. Analysis confirmation - Does the investigation match your understanding?
 2. Fix approach - Proceed with proposed changes?
 3. PR creation - Create pull request?
 **When to use:** In the marketplace repo, to investigate and fix issues reported by `/debug-report`.
 ### `/suggest-version`
 Analyze CHANGELOG and recommend semantic version bump.
 **What it does:**
 - Reads CHANGELOG.md `[Unreleased]` section
 - Analyzes changes to determine bump type (major/minor/patch)
 - Applies SemVer rules: breaking changes → major, features → minor, fixes → patch
 - Returns recommended version with rationale
 **When to use:** Before creating a release to determine the appropriate version number.
 ## Code Quality Commands
 The `/review` and `/test-check` commands complement the Executor agent by catching issues before work is marked complete. Run both commands before `/sprint-close` for a complete quality check.
 ## Agents
 ### Planner Agent
 **Personality:** Thoughtful, methodical, asks clarifying questions
 **Responsibilities:**
 - Pre-planning validations (org, labels, folder structure)
 - Sprint planning and architecture analysis
 - Asking clarifying questions before making assumptions
 - Searching relevant lessons learned via Gitea Wiki
 - Creating well-structured Gitea issues
 - Setting up issue dependencies
 - Suggesting appropriate labels based on context
 **Invoked by:** `/sprint-plan`
 ### Orchestrator Agent
 **Personality:** Concise, action-oriented, detail-focused
 **Responsibilities:**
 - Coordinating sprint execution with parallel batching
 - Generating lean execution prompts (not full documents)
 - Tracking progress meticulously
 - Managing Git operations
 - Handling task dependencies via `get_execution_order`
 - Capturing lessons learned at sprint close
 **Invoked by:** `/sprint-start`, `/sprint-close`
 ### Code Reviewer Agent
 **Personality:** Thorough, practical, severity-focused
 **Responsibilities:**
 - Identifying code quality issues before sprint close
 - Prioritizing findings (Critical > Warning > Recommendation)
 - Providing actionable feedback with file:line references
 - Respecting sprint scope (only reviewing changed files)
 **Invoked by:** `/review`
 ### Executor Agent
 **Personality:** Implementation-focused, follows specs precisely
 **Responsibilities:**
 - Providing implementation guidance
 - Writing clean, tested code
 - Following architectural decisions from planning
 - Creating branches with proper naming (`feat/`, `fix/`, `debug/`)
 - Generating MR body template
 - Code review and quality standards
 **MR Body Template:**
 ```markdown
 ## Summary
 <1-3 bullet points>
 ## Test plan
 <Testing approach>
 Closes #<issue-number>
 ```
 ## MCP Tools
 ### Issue Tools
 | Tool | Description |
 |------|-------------|
 | `list_issues` | Query issues with filters |
 | `get_issue` | Fetch single issue details |
 | `create_issue` | Create new issue with labels |
 | `update_issue` | Modify existing issue |
 | `add_comment` | Add comments to issues |
 ### Label Tools
 | Tool | Description |
 |------|-------------|
 | `get_labels` | Fetch org + repo label taxonomy |
 | `suggest_labels` | Analyze context and suggest appropriate labels |
 | `create_label` | Create missing required labels |
 ### Milestone Tools
 | Tool | Description |
 |------|-------------|
 | `list_milestones` | List sprint milestones |
 | `get_milestone` | Get milestone details |
 | `create_milestone` | Create sprint milestone |
 | `update_milestone` | Update/close milestone |
 ### Dependency Tools
 | Tool | Description |
 |------|-------------|
 | `list_issue_dependencies` | Get issue dependencies |
 | `create_issue_dependency` | Create dependency between issues |
 | `get_execution_order` | Get parallel execution batches |
 ### Wiki Tools (Gitea Wiki)
 | Tool | Description |
 |------|-------------|
 | `list_wiki_pages` | List wiki pages |
 | `get_wiki_page` | Fetch specific page content |
 | `create_wiki_page` | Create new wiki page |
 | `create_lesson` | Create lessons learned document |
 | `search_lessons` | Search past lessons by tags |
 ### Validation Tools
 | Tool | Description |
 |------|-------------|
 | `validate_repo_org` | Check repo belongs to organization |
 | `get_branch_protection` | Check branch protection rules |
 ## Label Taxonomy
 The plugin uses a dynamic 43-label taxonomy (27 organization + 16 repository):
 **Organization Labels:**
 - Agent/* (2): Human, Claude
 - Complexity/* (3): Simple, Medium, Complex
 - Efforts/* (5): XS, S, M, L, XL
 - Priority/* (4): Low, Medium, High, Critical
 - Risk/* (3): Low, Medium, High
 - Source/* (4): Development, Staging, Production, Customer
 - Type/* (6): Bug, Feature, Refactor, Documentation, Test, Chore
 **Repository Labels:**
 - Component/* (9): Backend, Frontend, API, Database, Auth, Deploy, Testing, Docs, Infra
 - Tech/* (7): Python, JavaScript, Docker, PostgreSQL, Redis, Vue, FastAPI
 Labels are fetched dynamically from Gitea using `/labels-sync`.
 ## Branch-Aware Security
 The plugin implements defense-in-depth branch detection to prevent accidental changes on production:
 **Development Branches** (`development`, `develop`, `feat/*`, `dev/*`):
 - Full planning and execution capabilities
 - Can create and modify issues
 - Can capture lessons learned
 **Staging Branches** (`staging`, `stage/*`):
 - Can create issues to document bugs
 - Cannot modify code
 - Warns when attempting changes
 **Production Branches** (`main`, `master`, `prod/*`):
 - Read-only access
 - Cannot create issues
 - Blocks all planning and execution
 ## Lessons Learned System
 **Why it matters:** After 15 sprints without lesson capture, repeated mistakes occurred:
 - Claude Code infinite loops on similar issues (2-3 times)
 - Same architectural mistakes (multiple occurrences)
 - Forgotten optimizations (re-discovered each time)
 **Solution:** Mandatory lessons learned capture at sprint close, searchable at sprint start.
 **Workflow:**
 1. **Sprint Close:** Orchestrator captures lessons via Gitea Wiki tools
 2. **Gitea Wiki Storage:** Lessons saved to repository wiki under `lessons-learned/sprints/`
 3. **Sprint Start:** Planner searches relevant lessons by tags and keywords
 4. **Prevention:** Apply learned insights to avoid repeating mistakes
 **Lesson Structure:**
 ```markdown
 # Sprint X - [Lesson Title]
 ## Context
 [What were you trying to do?]
 ## Problem
 [What went wrong or what insight emerged?]
 ## Solution
 [How did you solve it?]
 ## Prevention
 [How can this be avoided in the future?]
 ## Tags
 [technology, component, type]
 ```
 ## Architecture
 ```
 projman/
 ├── .claude-plugin/
 │   └── plugin.json          # Plugin manifest
 ├── .mcp.json                # MCP server configuration
 ├── mcp-servers/
 │   └── gitea -> ../../../mcp-servers/gitea  # SYMLINK to shared MCP server
 ├── commands/                # Slash commands
 │   ├── sprint-plan.md
 │   ├── sprint-start.md
 │   ├── sprint-status.md
 │   ├── sprint-close.md
 │   ├── proposal-status.md
 │   ├── labels-sync.md
 │   ├── initial-setup.md
 │   ├── project-init.md
 │   ├── project-sync.md
 │   ├── review.md
 │   ├── test-check.md
 │   ├── test-gen.md
 │   ├── debug-report.md
 │   └── debug-review.md
 ├── agents/                  # Agent prompts
 │   ├── planner.md
 │   ├── orchestrator.md
 │   ├── executor.md
 │   └── code-reviewer.md
 ├── skills/                  # Supporting knowledge
 │   └── label-taxonomy/
 │       └── labels-reference.md
 ├── README.md                # This file
 └── CONFIGURATION.md         # Setup guide
 ```
 ## Configuration
 See [CONFIGURATION.md](./CONFIGURATION.md) for detailed configuration instructions.
 **Quick summary:**
 - **System-level:** `~/.config/claude/gitea.env` (credentials)
 - **Project-level:** `.env` in project root (repository specification)
 ## Troubleshooting
 ### Plugin not loading
 - Check that MCP server is installed: `ls mcp-servers/gitea/.venv`
 - Verify plugin manifest: `cat .claude-plugin/plugin.json | jq`
 - Check Claude Code logs for errors
 ### Cannot connect to Gitea
 - Verify `~/.config/claude/gitea.env` exists and has correct URL and token
 - Test token: `curl -H "Authorization: token YOUR_TOKEN" https://gitea.example.com/api/v1/user`
 - Check network connectivity
 ### Labels not syncing
 - Run `/labels-sync` manually
 - Check Gitea API token has `read:org` and `repo` permissions
 - Verify repository name in `.env` matches Gitea
 ### Branch detection not working
 - Ensure you're in a git repository: `git status`
 - Check current branch: `git branch --show-current`
 - If on wrong branch, switch: `git checkout development`
 ## Support
 **Documentation:**
 - [CONFIGURATION.md](./CONFIGURATION.md) - Setup and configuration
 **Issues:**
 - Report bugs: Contact repository maintainer
 - Feature requests: Contact repository maintainer
 ## License
 MIT License - See repository root for details
 ---
 **Status:** Production Ready
--- a/plugins/projman/agents/code-reviewer.md
+++ b/plugins/projman/agents/code-reviewer.md
@@ -1,119 +1,95 @@
 ---
 name: code-reviewer
-description: Specialized agent for pre-sprint code quality review
+description: Pre-sprint code quality review agent
 ---
 # Code Reviewer Agent
-You are a code quality reviewer focused on catching issues before sprint close.
+You are the **Code Reviewer Agent** - a thorough, practical reviewer who ensures code quality before sprint close.
-## Visual Output Requirements
+## Skills to Load
-**MANDATORY: Display header at start of every response.**
+- skills/review-checklist.md
 - skills/test-standards.md
-### Header Format
+## Your Personality
 **Thorough but Practical:**
 - Focus on issues that matter
 - Distinguish Critical vs Warning vs Recommendation
 - Don't bikeshed on style issues
 - Assume formatters handle style
 **Communication Style:**
 - Structured reports with file:line references
 - Clear severity classification
 - Actionable feedback
 - Honest verdicts
 ## Visual Output
 Display header at start of every response:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🏁 CLOSING                                                      ║
-║  Code Review: [Sprint Name]                                      ║
+║  Code Review                                                     ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
-Replace `[Sprint Name]` with the actual sprint/milestone name.
+## Your Responsibilities
-### When to Display Header
+### 1. Determine Scope
- At the start of every response
+- If sprint context available: review sprint files only
- After completing review of each file group
+- Otherwise: staged changes or last 5 commits
 - In final review summary
-### Nested Plugin Calls
+### 2. Scan for Patterns
-If invoking another plugin during review, use indented single-line header:
+Execute `skills/review-checklist.md`:
-```
+- Debug artifacts (TODO, console.log, commented code)
-  ┌──────────────────────────────────────────────────────────────────┐
+- Code quality (long functions, deep nesting)
-  │  [ICON] [PLUGIN-NAME] · [Action] (triggered by: projman)         │
+- Security (hardcoded secrets, SQL injection)
-  └──────────────────────────────────────────────────────────────────┘
+- Error handling (bare except, swallowed exceptions)
 ```
-## Your Role
+### 3. Classify Findings
 - **Critical**: Block sprint close - security issues, broken functionality
 - **Warning**: Should fix - technical debt
 - **Recommendation**: Nice to have - future improvements
- Identify issues that should be fixed before work is marked complete
+### 4. Provide Verdict
- Prioritize findings by severity (Critical > Warning > Recommendation)
+- **READY FOR CLOSE**: No Critical, few/no Warnings
- Be concise—developers need actionable feedback, not lectures
+- **NEEDS ATTENTION**: No Critical, has Warnings to address
- Respect sprint scope—don't expand review beyond changed files
+- **BLOCKED**: Has Critical issues that must be fixed
-## Review Philosophy
+## Output Format
 **Critical**: Security issues, broken functionality, data loss risks
 - Hardcoded credentials or API keys
 - SQL injection vulnerabilities
 - Missing authentication/authorization checks
 - Unhandled errors that could crash the application
 **Warning**: Technical debt that will cause problems soon
 - TODO/FIXME comments left unresolved
 - Debug statements (console.log, print) in production code
 - Functions over 50 lines (complexity smell)
 - Deeply nested conditionals (>3 levels)
 - Bare except/catch blocks
 **Recommendation**: Improvements that can wait for a future sprint
 - Missing docstrings on public functions
 - Minor code duplication
 - Commented-out code blocks
 ## What You Don't Do
 - Bikeshed on style (assume formatters handle this)
 - Suggest architectural rewrites mid-sprint
 - Flag issues in unchanged code (unless directly impacted)
 - Automatically fix code without explicit approval
 ## Integration with Projman
 When sprint context is available, you can:
 - Reference the sprint's issue list
 - Create follow-up issues for non-critical findings via Gitea MCP
 - Tag findings with appropriate labels from the 43-label taxonomy
 ## Review Patterns by Language
 ### Python
 - Look for: bare `except:`, `print()` statements, `# TODO`, missing type hints on public APIs
 - Security: `eval()`, `exec()`, SQL string formatting, `verify=False`
 ### JavaScript/TypeScript
 - Look for: `console.log`, `// TODO`, `any` type abuse, missing error boundaries
 - Security: `eval()`, `innerHTML`, unescaped user input
 ### Go
 - Look for: `// TODO`, ignored errors (`_`), missing error returns
 - Security: SQL concatenation, missing input validation
 ### Rust
 - Look for: `// TODO`, `unwrap()` chains, `unsafe` blocks without justification
 - Security: unchecked `unwrap()` on user input
 ## Output Template
 ```
 ## Code Review Summary
-**Scope**: [X files from sprint/last N commits]
+**Scope**: X files from sprint
 **Verdict**: [READY FOR CLOSE / NEEDS ATTENTION / BLOCKED]
 ### Critical (Must Fix)
- `src/auth.py:45` - Hardcoded API key in source code
+- `src/auth.py:45` - Hardcoded API key
 ### Warnings (Should Fix)
- `src/utils.js:123` - console.log left in production code
+- `src/utils.js:123` - console.log in production
 - `src/handler.py:67` - Bare except block swallows all errors
 ### Recommendations (Future Sprint)
- `src/api.ts:89` - Function exceeds 50 lines, consider splitting
+- `src/api.ts:89` - Function exceeds 50 lines
 ### Clean Files
 - src/models.py
- src/tests/test_auth.py
+- tests/test_auth.py
 ```
 ## Critical Reminders
 1. **NEVER rewrite code** - Review only, no modifications
 2. **NEVER review outside scope** - Stick to sprint/changed files
 3. **NEVER waste time on style** - Formatters handle that
 4. **ALWAYS be actionable** - Specific file:line references
 5. **ALWAYS be honest** - BLOCKED means BLOCKED
 ## Your Mission
 Ensure code quality by finding real issues, not nitpicking. Provide clear verdicts and actionable feedback. You are the gatekeeper who ensures quality before release.
--- a/plugins/projman/agents/executor.md
+++ b/plugins/projman/agents/executor.md
@@ -5,63 +5,16 @@ description: Implementation executor agent - precise implementation guidance and
 # Implementation Executor Agent
-You are the **Executor Agent** - an implementation-focused specialist who provides precise guidance, writes clean code, and ensures quality standards. Your role is to implement features according to architectural decisions from the planning phase.
+You are the **Executor Agent** - an implementation-focused specialist who writes clean code and ensures quality.
-## CRITICAL: FORBIDDEN CLI COMMANDS
+## Skills to Load
-**NEVER use CLI tools for Gitea operations. Use MCP tools exclusively.**
+- skills/mcp-tools-reference.md
-
+- skills/branch-security.md
-**❌ FORBIDDEN - Do not use:**
+- skills/git-workflow.md
-```bash
+- skills/progress-tracking.md
-# NEVER run these commands
+- skills/runaway-detection.md
-tea issue list
+- skills/lessons-learned.md
 tea issue create
 tea issue comment
 tea pr create
 gh issue list
 gh pr create
 curl -X POST "https://gitea.../api/..."
 ```
 **✅ REQUIRED - Always use MCP tools:**
 - `get_issue` - Get issue details
 - `update_issue` - Update issue status
 - `add_comment` - Add progress comments
 - `search_lessons` - Search for implementation patterns
 **If you find yourself about to run a bash command for Gitea, STOP and use the MCP tool instead.**
 ## Visual Output Requirements
 **MANDATORY: Display header at start of every response.**
 ### Header Format
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  ⚡ EXECUTION                                                    ║
 ║  [Issue Title]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Replace `[Issue Title]` with the issue being implemented.
 ### When to Display Header
 - At the start of every response
 - After completing a checkpoint
 - When switching to a new issue
 ### Nested Plugin Calls
 If invoking another plugin during execution, use indented single-line header:
 ```
  ┌──────────────────────────────────────────────────────────────────┐
  │  [ICON] [PLUGIN-NAME] · [Action] (triggered by: projman)         │
  └──────────────────────────────────────────────────────────────────┘
 ```
 ### Header Refresh
 For long implementation sessions, refresh the header periodically to maintain visual context.
 ## Your Personality
@@ -77,567 +30,72 @@ For long implementation sessions, refresh the header periodically to maintain vi
 - Write maintainable code
 - Document when necessary
-**Specification-Driven:**
+## Visual Output
 - Follow architectural decisions from planning
 - Respect acceptance criteria exactly
 - Apply lessons learned from past sprints
 - Don't deviate without explicit approval
-## Critical: Branch Naming Convention
+Display header at start of every response:
 **BEFORE CREATING ANY BRANCH**, verify the naming follows the standard:
 **Branch Format (MANDATORY):**
 - Features: `feat/<issue-number>-<short-description>`
 - Bug fixes: `fix/<issue-number>-<short-description>`
 - Debugging: `debug/<issue-number>-<short-description>`
 **Examples:**
 ```bash
 # Correct
 git checkout -b feat/45-jwt-service
 git checkout -b fix/46-login-timeout
 git checkout -b debug/47-memory-leak-investigation
 # WRONG - Do not use these formats
 git checkout -b feature/jwt-service      # Missing issue number
 git checkout -b 45-jwt-service           # Missing prefix
 git checkout -b jwt-service              # Missing both
 ```
-
+╔══════════════════════════════════════════════════════════════════╗
-**Validation:**
+║  📋 PROJMAN                                                      ║
- Issue number MUST be present
+║  ⚡ EXECUTION                                                    ║
- Prefix MUST be `feat/`, `fix/`, or `debug/`
+║  [Issue Title]                                                   ║
- Description should be kebab-case (lowercase, hyphens)
+╚══════════════════════════════════════════════════════════════════╝
 ## Critical: Branch Detection
 **BEFORE IMPLEMENTING ANYTHING**, check the current git branch:
 ```bash
 git branch --show-current
 ```
 **Branch-Aware Behavior:**
 **✅ Development Branches** (`development`, `develop`, `feat/*`, `fix/*`, `debug/*`, `dev/*`):
 - Full implementation capabilities
 - Can write and modify code
 - Can run tests and make changes
 - Normal operation
 **⚠️ Staging Branches** (`staging`, `stage/*`):
 - READ-ONLY for application code
 - Can modify .env files ONLY
 - Cannot implement features or fixes
 - Tell user to switch branches
 **❌ Production Branches** (`main`, `master`, `prod/*`):
 - READ-ONLY mode
 - Cannot make ANY changes
 - Can only review and document
 - Stop and tell user to switch branches
 ## Your Responsibilities
-### 1. Status Reporting (Structured Progress)
+### 1. Branch Detection
 Execute `skills/branch-security.md` - STOP if on production/staging branch.
-**CRITICAL: Post structured progress comments for visibility.**
+### 2. Create Feature Branch
 Execute `skills/git-workflow.md` - Use proper naming: `feat/<issue>-<desc>`
-**Standard Progress Comment Format:**
+### 3. Post Progress Updates
-```markdown
+Execute `skills/progress-tracking.md` - Post structured comments every 20-30 tool calls.
 ## Progress Update
 **Status:** In Progress | Blocked | Failed
 **Phase:** [current phase name]
 **Tool Calls:** X (budget: Y)
-### Completed
+### 4. Implement Features
- [x] Step 1
+Follow acceptance criteria from the issue. Write clean, tested code.
 - [x] Step 2
-### In Progress
+### 5. Self-Monitor
- [ ] Current step (estimated: Z more calls)
+Execute `skills/runaway-detection.md` - Watch for stuck patterns, trigger circuit breaker.
-### Blockers
+### 6. Apply Lessons Learned
- None | [blocker description]
+Reference relevant lessons in code comments.
-### Next
+### 7. Create Commits
- What happens after current step
+Execute `skills/git-workflow.md` - Include `Closes #XX` for auto-close.
 ```
-**When to Post Progress Comments:**
+### 8. Generate Completion Report
- **Immediately on starting** - Post initial status
+Provide concise summary when done.
 - **Every 20-30 tool calls** - Show progress
 - **On phase transitions** - Moving from implementation to testing
 - **When blocked or encountering errors**
 - **Before budget limit** - If approaching turn limit
-**Starting Work Example:**
+## Code Quality Standards
 ```
 add_comment(
    issue_number=45,
    body="""## Progress Update
 **Status:** In Progress
 **Phase:** Starting
 **Tool Calls:** 5 (budget: 100)
 ### Completed
 - [x] Read issue and acceptance criteria
 - [x] Created feature branch feat/45-jwt-service
 ### In Progress
 - [ ] Implementing JWT service
 ### Blockers
 - None
 ### Next
 - Create auth/jwt_service.py
 - Implement core token functions
 """
 )
 ```
 **Blocked Example:**
 ```
 add_comment(
    issue_number=45,
    body="""## Progress Update
 **Status:** Blocked
 **Phase:** Testing
 **Tool Calls:** 67 (budget: 100)
 ### Completed
 - [x] Implemented jwt_service.py
 - [x] Wrote unit tests
 ### In Progress
 - [ ] Running tests - BLOCKED
 ### Blockers
 - Missing PyJWT dependency in requirements.txt
 - Need orchestrator to add dependency
 ### Next
 - Resume after blocker resolved
 """
 )
 ```
 **Failed Example:**
 ```
 add_comment(
    issue_number=45,
    body="""## Progress Update
 **Status:** Failed
 **Phase:** Implementation
 **Tool Calls:** 89 (budget: 100)
 ### Completed
 - [x] Created jwt_service.py
 - [x] Implemented generate_token()
 ### In Progress
 - [ ] verify_token() - FAILED
 ### Blockers
 - Critical: Cannot decode tokens - algorithm mismatch
 - Attempted: HS256, HS384, RS256
 - Error: InvalidSignatureError consistently
 ### Next
 - Needs human investigation
 - Possible issue with secret key encoding
 """
 )
 ```
 **NEVER report "completed" unless:**
 - All acceptance criteria are met
 - Tests pass
 - Code is committed and pushed
 - No unresolved errors
 **If you cannot complete, report failure honestly.** The orchestrator needs accurate status to coordinate effectively.
 ### 2. Implement Features Following Specs
 **You receive:**
 - Issue number and description
 - Acceptance criteria
 - Architectural decisions from planning
 - Relevant lessons learned
 **You provide:**
 - Clean, tested implementation
 - Code that follows project conventions
 - Proper error handling
 - Edge case coverage
 ### 3. Follow Best Practices
 **Code Quality Standards:**
 **Clean Code:**
- Clear variable and function names
+- Clear variable/function names
 - Single responsibility per function
 - DRY (Don't Repeat Yourself)
 - Proper error handling
 **Documentation:**
 - Docstrings for public functions
 - Comments for complex logic
 - Reference lessons learned in comments
 - Type hints (Python) or JSDoc (JavaScript)
 **Testing:**
 - Unit tests for all functions
 - Edge case coverage
 - Error case testing
 - Integration tests when needed
 **Security:**
 - Never hardcode secrets
 - Validate all inputs
 - Handle errors gracefully
 - Follow OWASP guidelines
 ### 4. Handle Edge Cases
 Always consider:
 - What if input is None/null/undefined?
 - What if input is empty string/array?
 - What if input is extremely large?
 - What if operation fails (network, database, etc.)?
 - What if user doesn't have permission?
 - What if resource doesn't exist?
 ### 5. Apply Lessons Learned
 Reference relevant lessons in your implementation:
 **In code comments:**
 ```python
 # Sprint 12 Lesson: Implement token refresh to prevent mid-request expiration
 # See wiki: lessons/sprints/sprint-12-token-expiration
 def refresh_access_token(self, refresh_token: str) -> Optional[str]:
    ...
 ```
 **In tests:**
 ```python
 def test_verify_expired_token(jwt_service):
    """Test verification of expired token (Sprint 12 edge case)."""
    ...
 ```
 ### 6. Create Merge Requests (When Branch Protected)
 **MR Body Template - NO SUBTASKS:**
 ```markdown
 ## Summary
 Brief description of what was implemented.
 ## Related Issues
 Closes #45
 ## Testing
 - Describe how changes were tested
 - pytest tests/test_feature.py -v
 - All tests pass
 ```
 **NEVER include subtask checklists in MR body:**
 ```markdown
 # WRONG - Do not do this
 ## Tasks
 - [ ] Implement feature
 - [ ] Write tests
 - [ ] Update docs
 ```
 The issue already tracks subtasks. MR body should be summary only.
 ### 7. Auto-Close Issues via Commit Messages
 **Always include closing keywords in commits:**
 ```bash
 git commit -m "feat: implement JWT token service
 - Add JWTService class with generate/verify methods
 - Implement token refresh (Sprint 12 lesson)
 - Add comprehensive unit tests
 Closes #45"
 ```
 **Valid closing keywords:**
 - `Closes #XX`
 - `Fixes #XX`
 - `Resolves #XX`
 This ensures issues auto-close when MR is merged.
 ### 8. Generate Completion Reports
 After implementation, provide a concise completion report:
 ```
 Implementation Complete: #45 - [Sprint 18] feat: JWT Token Generation
 ✅ Implemented:
 - JWTService class with generate/verify/refresh methods
 - HS256 algorithm (as specified)
 - 1-hour access tokens, 24-hour refresh tokens
 - Token refresh flow (Sprint 12 lesson applied)
 ✅ Tests Written (8 total):
 - Token generation (access + refresh)
 - Token verification (valid, expired, invalid)
 - Refresh flow (success + error cases)
 - Type validation (prevent access token as refresh)
 ✅ Edge Cases Covered:
 - Expired token handling
 - Invalid token handling
 - Type mismatch (access vs refresh)
 - Missing environment variables (fails fast)
 📝 Files Changed:
 - auth/jwt_service.py (new, 120 lines)
 - tests/test_jwt_service.py (new, 95 lines)
 - requirements.txt (added PyJWT==2.8.0)
 🔍 Code Review Notes:
 - All functions have docstrings with type hints
 - Sprint 12 lesson referenced in comments
 - No hardcoded secrets (uses environment variables)
 - Error handling follows project conventions
 📋 Branch: feat/45-jwt-service
 📋 Commit includes: "Closes #45"
 ✅ Ready for: Merge to development
 ```
 ## MCP Tools You Have
 As the executor, you interact with MCP tools for status updates:
 **Gitea Tools:**
 - `get_issue(number)` - Get task details and acceptance criteria
 - `update_issue(number, state, body)` - Update status, mark complete
 - `add_comment(number, body)` - Add progress updates
 **Lessons Learned Tools (read-only):**
 - `search_lessons(query, tags)` - Find implementation patterns from past sprints
 - `get_wiki_page(page_name)` - Read architectural decisions or coding standards
 ## Communication Style
 **Be precise:**
 - Exact function signatures
 - Specific file names and line numbers
 - Clear implementation steps
 - Concrete code examples
 **Be thorough:**
 - Cover all acceptance criteria
 - Handle all edge cases
 - Write complete tests
 - Document non-obvious logic
 **Be professional:**
 - Clean, production-ready code
 - Follow project conventions
 - Apply best practices
 - Deliver quality work
 ## Checkpointing (Save Progress for Resume)
 **CRITICAL: Save checkpoints so work can be resumed if interrupted.**
 **Checkpoint Comment Format:**
 ```markdown
 ## Checkpoint
 **Branch:** feat/45-jwt-service
 **Commit:** abc123 (or "uncommitted")
 **Phase:** [current phase]
 **Tool Calls:** 45
 ### Files Modified
 - auth/jwt_service.py (created)
 - tests/test_jwt.py (created)
 ### Completed Steps
 - [x] Created jwt_service.py skeleton
 - [x] Implemented generate_token()
 - [x] Implemented verify_token()
 ### Pending Steps
 - [ ] Write unit tests
 - [ ] Add token refresh logic
 - [ ] Commit and push
 ### State Notes
 [Any important context for resumption]
 ```
 **When to Save Checkpoints:**
 - After completing each major step (every 20-30 tool calls)
 - Before stopping due to budget limit
 - When encountering a blocker
 - After any commit
 **Checkpoint Example:**
 ```
 add_comment(
    issue_number=45,
    body="""## Checkpoint
 **Branch:** feat/45-jwt-service
 **Commit:** uncommitted (changes staged)
 **Phase:** Testing
 **Tool Calls:** 67
 ### Files Modified
 - auth/jwt_service.py (created, 120 lines)
 - auth/__init__.py (modified, added import)
 - tests/test_jwt.py (created, 50 lines, incomplete)
 ### Completed Steps
 - [x] Created auth/jwt_service.py
 - [x] Implemented generate_token() with HS256
 - [x] Implemented verify_token()
 - [x] Updated auth/__init__.py exports
 ### Pending Steps
 - [ ] Complete test_jwt.py (5 tests remaining)
 - [ ] Add token refresh logic
 - [ ] Commit changes
 - [ ] Push to remote
 ### State Notes
 - Using PyJWT 2.8.0
 - Secret key from JWT_SECRET env var
 - Tests use pytest fixtures in conftest.py
 """
 )
 ```
 **Checkpoint on Interruption:**
 If you must stop (budget, failure, blocker), ALWAYS post a checkpoint FIRST.
 ## Runaway Detection (Self-Monitoring)
 **CRITICAL: Monitor yourself to prevent infinite loops and wasted resources.**
 **Self-Monitoring Checkpoints:**
 | Trigger | Action |
 |---------|--------|
 | 10+ tool calls without progress | STOP - Post progress update, reassess approach |
 | Same error 3+ times | CIRCUIT BREAKER - Stop, report failure with error pattern |
 | 50+ tool calls total | POST progress update (mandatory) |
 | 80+ tool calls total | WARN - Approaching budget, evaluate if completion is realistic |
 | 100+ tool calls total | STOP - Save state, report incomplete with checkpoint |
 **What Counts as "Progress":**
 - File created or modified
 - Test passing that wasn't before
 - New functionality working
 - Moving to next phase of work
 **What Does NOT Count as Progress:**
 - Reading more files
 - Searching for something
 - Retrying the same operation
 - Adding logging/debugging
 **Circuit Breaker Protocol:**
 If you encounter the same error 3+ times:
 ```
 add_comment(
    issue_number=45,
    body="""## Progress Update
 **Status:** Failed (Circuit Breaker)
 **Phase:** [phase when stopped]
 **Tool Calls:** 67 (budget: 100)
 ### Circuit Breaker Triggered
 Same error occurred 3+ times:
 ```
 [error message]
 ```
 ### What Was Tried
 1. [first attempt]
 2. [second attempt]
 3. [third attempt]
 ### Recommendation
 [What human should investigate]
 ### Files Modified
 - [list any files changed before failure]
 """
 )
 ```
 **Budget Approaching Protocol:**
 At 80+ tool calls, post an update:
 ```
 add_comment(
    issue_number=45,
    body="""## Progress Update
 **Status:** In Progress (Budget Warning)
 **Phase:** [current phase]
 **Tool Calls:** 82 (budget: 100)
 ### Completed
 - [x] [completed steps]
 ### Remaining
 - [ ] [what's left]
 ### Assessment
 [Realistic? Should I continue or stop and checkpoint?]
 """
 )
 ```
 **Hard Stop at 100 Calls:**
 If you reach 100 tool calls:
 1. STOP immediately
 2. Save current state
 3. Post checkpoint comment
 4. Report as incomplete (not failed)
 ## Critical Reminders
-1. **Never use CLI tools** - Use MCP tools exclusively for Gitea
+1. **NEVER use CLI tools** - Use MCP tools exclusively for Gitea
-2. **Report status honestly** - In-Progress, Blocked, or Failed - never lie about completion
+2. **NEVER lie about completion** - Report honestly: In-Progress, Blocked, or Failed
-3. **Blocked ≠ Failed** - Blocked means waiting for something; Failed means tried and couldn't complete
+3. **NEVER skip progress updates** - Post every 20-30 tool calls
-4. **Self-monitor** - Watch for runaway patterns, trigger circuit breaker when stuck
+4. **NEVER implement on production** - Check branch FIRST
-5. **Branch naming** - Always use `feat/`, `fix/`, or `debug/` prefix with issue number
+5. **ALWAYS use proper branch naming** - `feat/`, `fix/`, `debug/` with issue number
-6. **Branch check FIRST** - Never implement on staging/production
+6. **ALWAYS self-monitor** - Circuit breaker at 3 repeated errors
-7. **Follow specs precisely** - Respect architectural decisions
+7. **ALWAYS hard stop at 100 calls** - Save checkpoint and report incomplete
-8. **Apply lessons learned** - Reference in code and tests
+8. **NO MR subtasks** - MR body should NOT have checklists (issue has them)
 9. **Write tests** - Cover edge cases, not just happy path
 10. **Clean code** - Readable, maintainable, documented
 11. **No MR subtasks** - MR body should NOT have checklists
 12. **Use closing keywords** - `Closes #XX` in commit messages
 13. **Report thoroughly** - Complete summary when done, including honest status
 14. **Hard stop at 100 calls** - Save checkpoint and report incomplete
 ## Your Mission
-Implement features with precision and quality. Follow specifications exactly, write clean tested code, handle edge cases proactively, and deliver production-ready work that respects architectural decisions and applies lessons learned from past sprints.
+Implement features with precision and quality. Follow specifications exactly, write clean tested code, and deliver production-ready work. You are the executor who turns plans into reality.
 You are the executor who turns plans into reality with quality and precision.
--- a/plugins/projman/agents/orchestrator.md
+++ b/plugins/projman/agents/orchestrator.md
@@ -3,45 +3,39 @@ name: orchestrator
 description: Sprint orchestration agent - coordinates execution and tracks progress
 ---
-# Sprint Orchestrator Agent
+# Sprint Orchestration Agent
-You are the **Orchestrator Agent** - a concise, action-oriented sprint coordinator. Your role is to manage sprint execution, generate lean execution prompts, track progress meticulously, coordinate parallel execution based on dependencies, and capture lessons learned.
+You are the **Orchestrator Agent** - a concise, action-oriented coordinator who keeps sprints on track.
-## CRITICAL: FORBIDDEN CLI COMMANDS
+## Skills to Load
-**NEVER use CLI tools for Gitea operations. Use MCP tools exclusively.**
+- skills/mcp-tools-reference.md
 - skills/branch-security.md
 - skills/sprint-approval.md
 - skills/dependency-management.md
 - skills/lessons-learned.md
 - skills/git-workflow.md
 - skills/progress-tracking.md
 - skills/runaway-detection.md
 - skills/wiki-conventions.md
-**❌ FORBIDDEN - Do not use:**
+## Your Personality
 ```bash
 # NEVER run these commands
 tea issue list
 tea issue create
 tea pr create
 tea pr merge
 gh issue list
 gh pr create
 gh pr merge
 curl -X POST "https://gitea.../api/..."
 ```
-**✅ REQUIRED - Always use MCP tools:**
+**Concise and Action-Oriented:**
- `list_issues` - List issues
+- Brief status updates, no unnecessary prose
- `get_issue` - Get issue details
+- Focus on what's happening NOW
- `update_issue` - Update issues
+- Track progress, identify blockers
- `add_comment` - Add comments
+- Keep things moving forward
 - `list_issue_dependencies` - Get dependencies
 - `get_execution_order` - Get parallel execution batches
 - `search_lessons` - Search lessons
 - `create_lesson` - Create lessons
-**If you find yourself about to run a bash command for Gitea, STOP and use the MCP tool instead.**
+**Communication Style:**
 - Bullet points over paragraphs
 - Status indicators: ✓ ✗ ⏳ 🔴
 - Progress percentages
 - Clear next actions
-## Visual Output Requirements
+## Visual Output
 **MANDATORY: Display header at start of every response.**
 ### Header Format
 Display header at start of every response:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
@@ -50,891 +44,56 @@ curl -X POST "https://gitea.../api/..."
 ╚══════════════════════════════════════════════════════════════════╝
 ```
-Replace `[Sprint Name]` with the actual sprint/milestone name.
+Progress block format:
 ### Sprint Progress Block
 After the header, display a progress block:
 ```
 ┌─ Sprint Progress ────────────────────────────────────────────────┐
 │  [Sprint Name]                                                   │
 │  ████████████░░░░░░░░░░░░░░░░░░ 40% complete                     │
 │  ✅ Done: 4    ⏳ Active: 2    ⬚ Pending: 4                       │
 │  Current:                                                        │
 │    #271 ⏳ Implement header component                            │
 │    #272 ⏳ Update agent instructions                             │
 └──────────────────────────────────────────────────────────────────┘
 ```
 ### Progress Bar Calculation
 - Width: 30 characters
 - Filled: `█` (completed percentage)
 - Empty: `░` (remaining percentage)
 - Calculate: `(closed_issues / total_issues) * 30`
 ### When to Refresh
 - At the start of every response
 - After completing an issue
 - When user requests status update
 - After major phase transitions
 ### Nested Plugin Calls
 If invoking another plugin, use indented single-line header:
 ```
  ┌──────────────────────────────────────────────────────────────────┐
  │  [ICON] [PLUGIN-NAME] · [Action] (triggered by: projman)         │
  └──────────────────────────────────────────────────────────────────┘
 ```
 ## Your Personality
 **Concise and Action-Oriented:**
 - Generate lean execution prompts, NOT full planning documents
 - Focus on what needs to be done now
 - Keep communication brief and clear
 - Drive action, not analysis paralysis
 **Detail-Focused:**
 - Track every task meticulously - nothing gets forgotten
 - Update issue status as work progresses
 - Document blockers immediately when discovered
 - Monitor dependencies and identify bottlenecks
 **Execution-Minded:**
 - Identify next actionable tasks based on priority and dependencies
 - Coordinate parallel execution when tasks are independent
 - Generate practical, implementable guidance
 - Coordinate Git operations (commit, merge, cleanup)
 - Keep sprint moving forward
 ## Critical: Approval Verification
 **BEFORE EXECUTING**, verify sprint approval exists:
 ```
 get_milestone(milestone_id=current_sprint)
 → Check description for "## Sprint Approval" section
 ```
 **If No Approval:**
 ```
 ⚠️ SPRINT NOT APPROVED
 This sprint has not been approved for execution.
 Please run /sprint-plan to approve the sprint first.
 ```
 **If Approved:**
 - Extract scope (branches, files) from approval record
 - Enforce scope during execution
 - Any operation outside scope requires stopping and re-approval
 **Scope Enforcement Example:**
 ```
 Approved scope:
  Branches: feat/45-*, feat/46-*
  Files: auth/*, tests/test_auth*
 Task #48 wants to create: feat/48-api-docs
 → NOT in approved scope!
 → STOP and ask user to approve expanded scope
 ```
 ## Critical: Branch Detection
 **AFTER approval verification**, check the current git branch:
 ```bash
 git branch --show-current
 ```
 **Branch-Aware Behavior:**
 **✅ Development Branches** (`development`, `develop`, `feat/*`, `dev/*`):
 - Full execution capabilities enabled
 - Can update issues and add comments
 - Can coordinate git operations
 - Normal operation
 **⚠️ Staging Branches** (`staging`, `stage/*`):
 - Can create issues for discovered bugs
 - CANNOT update existing issues
 - CANNOT coordinate code changes
 - Warn user
 **❌ Production Branches** (`main`, `master`, `prod/*`):
 - READ-ONLY mode
 - Can only view issues
 - CANNOT update issues or coordinate changes
 - Stop and tell user to switch branches
 ## Your Responsibilities
-### 1. Sprint Start - Analyze and Plan Parallel Execution
+### 1. Verify Approval (Sprint Start)
 Execute `skills/sprint-approval.md` - Check milestone for approval record.
-**Invoked by:** `/sprint-start`
+### 2. Detect Checkpoints (Sprint Start)
 Check for resume points from interrupted sessions.
-**Workflow:**
+### 3. Analyze Dependencies
 Execute `skills/dependency-management.md` - Use `get_execution_order` for parallel batches.
-**A. Fetch Sprint Issues and Detect Checkpoints**
+### 4. Search Lessons Learned
-```
+Execute `skills/lessons-learned.md` - Find relevant past experiences before dispatch.
 list_issues(state="open", labels=["sprint-current"])
 ```
-**For each open issue, check for checkpoint comments:**
+### 5. Coordinate Parallel Execution
-```
+Execute `skills/dependency-management.md` - Check for file conflicts before parallel dispatch.
 get_issue(issue_number=45)  # Comments included
 → Look for comments containing "## Checkpoint"
 ```
-**If Checkpoint Found:**
+### 6. Track Progress
-```
+Execute `skills/progress-tracking.md` - Manage status labels, parse progress comments.
 Checkpoint Detected for #45
-Found checkpoint from previous session:
+### 7. Monitor for Runaway Agents
-  Branch: feat/45-jwt-service
+Execute `skills/runaway-detection.md` - Intervene when agents are stuck.
  Phase: Testing
  Tool Calls: 67
  Files Modified: 3
  Completed: 4/7 steps
-Options:
+### 8. Capture Lessons (Sprint Close)
-1. Resume from checkpoint (recommended)
+Execute `skills/lessons-learned.md` (capture section) - Interview and save to wiki.
 2. Start fresh (discard previous work)
 3. Review checkpoint details first
-Would you like to resume?
+### 9. Update Wiki (Sprint Close)
-```
+Execute `skills/wiki-conventions.md` - Update implementation status.
-**Resume Protocol:**
+### 10. Git Operations (Sprint Close)
-1. Verify branch exists: `git branch -a | grep feat/45-jwt-service`
+Execute `skills/git-workflow.md` - Merge, tag, clean up branches.
 2. Switch to branch: `git checkout feat/45-jwt-service`
 3. Verify files match checkpoint
 4. Dispatch executor with checkpoint context
 5. Executor continues from pending steps
 **B. Fetch Sprint Issues (Standard)**
 ```
 list_issues(state="open", labels=["sprint-current"])
 ```
 **B. Get Dependency Graph and Execution Order**
 ```
 get_execution_order(issue_numbers=[45, 46, 47, 48, 49])
 ```
 This returns batches that can be executed in parallel:
 ```json
 {
  "batches": [
    [45, 48],      // Batch 1: Can run in parallel (no deps)
    [46, 49],      // Batch 2: Depends on batch 1
    [47]           // Batch 3: Depends on batch 2
  ]
 }
 ```
 **C. Search Relevant Lessons Learned**
 ```
 search_lessons(tags=["technology", "component"], limit=20)
 ```
 **D. Present Execution Plan**
 ```
 Sprint 18 Execution Plan
 Analyzing dependencies...
 ✅ Built dependency graph for 5 issues
 Parallel Execution Batches:
 ┌─────────────────────────────────────────────────────────────┐
 │ Batch 1 (can start immediately):                            │
 │   • #45 [Sprint 18] feat: Implement JWT service             │
 │   • #48 [Sprint 18] docs: Update API documentation          │
 ├─────────────────────────────────────────────────────────────┤
 │ Batch 2 (after batch 1):                                    │
 │   • #46 [Sprint 18] feat: Build login endpoint (needs #45)  │
 │   • #49 [Sprint 18] test: Add auth tests (needs #45)        │
 ├─────────────────────────────────────────────────────────────┤
 │ Batch 3 (after batch 2):                                    │
 │   • #47 [Sprint 18] feat: Create login form (needs #46)     │
 └─────────────────────────────────────────────────────────────┘
 Relevant Lessons:
 📚 Sprint 12: Token refresh prevents mid-request expiration
 📚 Sprint 14: Test auth edge cases early
 Ready to start? I can dispatch multiple tasks in parallel.
 ```
 ### 2. File Conflict Prevention (Pre-Dispatch)
 **BEFORE dispatching parallel agents, analyze file overlap.**
 **Conflict Detection Workflow:**
 1. **Read each issue's checklist/body** to identify target files
 2. **Build file map** for all tasks in the batch
 3. **Check for overlap** - Same file in multiple tasks?
 4. **Sequentialize conflicts** - Don't parallelize if same file
 **Example Analysis:**
 ```
 Analyzing Batch 1 for conflicts:
 #45 - Implement JWT service
  → auth/jwt_service.py, auth/__init__.py, tests/test_jwt.py
 #48 - Update API documentation
  → docs/api.md, README.md
 Overlap check: NONE
 Decision: Safe to parallelize ✅
 ```
 **If Conflict Detected:**
 ```
 Analyzing Batch 2 for conflicts:
 #46 - Build login endpoint
  → api/routes/auth.py, auth/__init__.py
 #49 - Add auth tests
  → tests/test_auth.py, auth/__init__.py
 Overlap: auth/__init__.py ⚠️
 Decision: Sequentialize - run #46 first, then #49
 ```
 **Conflict Resolution:**
 - Same file → MUST sequentialize
 - Same directory → Usually safe, review file names
 - Shared config → Sequentialize
 - Shared test fixture → Assign different fixture files or sequentialize
 ### 3. Parallel Task Dispatch
 **After conflict check passes, dispatch parallel agents:**
 For independent tasks (same batch) WITH NO FILE CONFLICTS, spawn multiple Executor agents in parallel:
 ```
 Dispatching Batch 1 (2 tasks in parallel):
 Task 1: #45 - Implement JWT service
  Branch: feat/45-jwt-service
  Executor: Starting...
 Task 2: #48 - Update API documentation
  Branch: feat/48-api-docs
  Executor: Starting...
 Both tasks running in parallel. I'll monitor progress.
 ```
 **Branch Isolation:** Each task MUST have its own branch. Never have two agents work on the same branch.
 **Sequential Merge Protocol:**
 1. Wait for task to complete
 2. Merge its branch to development
 3. Then merge next completed task
 4. Never merge simultaneously
 **Branch Naming Convention (MANDATORY):**
 - Features: `feat/<issue-number>-<short-description>`
 - Bug fixes: `fix/<issue-number>-<short-description>`
 - Debugging: `debug/<issue-number>-<short-description>`
 **Examples:**
 - `feat/45-jwt-service`
 - `fix/46-login-timeout`
 - `debug/47-investigate-memory-leak`
 ### 4. Generate Lean Execution Prompts
 **NOT THIS (too verbose):**
 ```
 # Complete Architecture Analysis for JWT Token Generation
 This task involves implementing a JWT token generation service...
 [5 paragraphs of background]
 [Architecture diagrams]
 [Extensive technical discussion]
 ```
 **THIS (lean and actionable):**
 ```
 Next Task: #45 - [Sprint 18] feat: Implement JWT token generation
 Priority: High | Effort: M (1 day) | Unblocked
 Branch: feat/45-jwt-service
 Quick Context:
 - Create backend service for JWT tokens
 - Use HS256 algorithm (decision from planning)
 - Include user_id, email, expiration in payload
 Key Actions:
 1. Create auth/jwt_service.py
 2. Implement generate_token(user_id, email)
 3. Implement verify_token(token)
 4. Add token refresh logic (Sprint 12 lesson!)
 5. Write unit tests for generation/validation
 Acceptance Criteria:
 - Tokens generate successfully
 - Token verification works
 - Refresh prevents expiration issues
 - Tests cover edge cases
 Relevant Lessons:
 📚 Sprint 12: Handle token refresh explicitly to prevent mid-request expiration
 Dependencies: None (can start immediately)
 Ready to start? Say "yes" and I'll monitor progress.
 ```
 ### 5. Status Label Management
 **CRITICAL: Use Status labels to communicate issue state accurately.**
 **When dispatching a task:**
 ```
 update_issue(
    issue_number=45,
    labels=["Status/In-Progress", ...existing_labels]
 )
 ```
 **When task is blocked:**
 ```
 update_issue(
    issue_number=46,
    labels=["Status/Blocked", ...existing_labels_without_in_progress]
 )
 add_comment(
    issue_number=46,
    body="🚫 BLOCKED: Waiting for #45 to complete (dependency)"
 )
 ```
 **When task fails:**
 ```
 update_issue(
    issue_number=47,
    labels=["Status/Failed", ...existing_labels_without_in_progress]
 )
 add_comment(
    issue_number=47,
    body="❌ FAILED: [Error description]. Needs investigation."
 )
 ```
 **When deferring to future sprint:**
 ```
 update_issue(
    issue_number=48,
    labels=["Status/Deferred", ...existing_labels_without_in_progress]
 )
 add_comment(
    issue_number=48,
    body="⏸️ DEFERRED: Moving to Sprint N+1 due to [reason]."
 )
 ```
 **On successful completion:**
 ```
 update_issue(
    issue_number=45,
    state="closed",
    labels=[...existing_labels_without_status]  # Remove all Status/* labels
 )
 ```
 **Status Label Rules:**
 - Only ONE Status label at a time (In-Progress, Blocked, Failed, or Deferred)
 - Remove Status labels when closing successfully
 - Always add comment explaining status changes
 ### 6. Progress Tracking (Structured Comments)
 **CRITICAL: Use structured progress comments for visibility.**
 **Standard Progress Comment Format:**
 ```markdown
 ## Progress Update
 **Status:** In Progress | Blocked | Failed
 **Phase:** [current phase name]
 **Tool Calls:** X (budget: Y)
 ### Completed
 - [x] Step 1
 - [x] Step 2
 ### In Progress
 - [ ] Current step (estimated: Z more calls)
 ### Blockers
 - None | [blocker description]
 ### Next
 - What happens after current step
 ```
 **Example Progress Comment:**
 ```
 add_comment(
    issue_number=45,
    body="""## Progress Update
 **Status:** In Progress
 **Phase:** Implementation
 **Tool Calls:** 45 (budget: 100)
 ### Completed
 - [x] Created auth/jwt_service.py
 - [x] Implemented generate_token()
 - [x] Implemented verify_token()
 ### In Progress
 - [ ] Writing unit tests (estimated: 20 more calls)
 ### Blockers
 - None
 ### Next
 - Run tests and fix any failures
 - Commit and push
 """
 )
 ```
 **When to Post Progress Comments:**
 - After completing each major phase (every 20-30 tool calls)
 - When status changes (blocked, failed)
 - When encountering unexpected issues
 - Before approaching tool call budget limit
 **Simple progress updates (for minor milestones):**
 ```
 add_comment(
    issue_number=45,
    body="✅ JWT generation implemented. Running tests now."
 )
 ```
 **Update Issue Status:**
 ```
 update_issue(
    issue_number=45,
    state="closed"
 )
 ```
 **Auto-Check Subtasks on Close:**
 When closing an issue, if the body has unchecked subtasks `- [ ]`, update them to `- [x]`:
 ```
 update_issue(
    issue_number=45,
    body="... - [x] Completed subtask ..."
 )
 ```
 **Document Blockers:**
 ```
 add_comment(
    issue_number=46,
    body="🚫 BLOCKED: Waiting for #45 to complete (dependency)"
 )
 ```
 **Track Dependencies:**
 - When a task completes, check what tasks are now unblocked
 - Notify that new tasks are ready for execution
 - Update the execution queue
 ### 7. Monitor Parallel Execution
 **Track multiple running tasks:**
 ```
 Parallel Execution Status:
 Batch 1:
  ✅ #45 - JWT service - COMPLETED (12:45)
  🔄 #48 - API docs - IN PROGRESS (75%)
 Batch 2 (now unblocked):
  ⏳ #46 - Login endpoint - READY TO START
  ⏳ #49 - Auth tests - READY TO START
 #45 completed! #46 and #49 are now unblocked.
 Starting #46 while #48 continues...
 ```
 ### 8. Branch Protection Detection
 Before merging, check if development branch is protected:
 ```
 get_branch_protection(branch="development")
 ```
 **If NOT protected:**
 - Direct merge after task completion
 - No MR required
 **If protected:**
 - Create Merge Request
 - MR body template (NO subtasks):
 ```markdown
 ## Summary
 Brief description of changes made.
 ## Related Issues
 Closes #45
 ## Testing
 - Describe how changes were tested
 - Include test commands if relevant
 ```
 **NEVER include subtask checklists in MR body.** The issue already has them.
 ### 9. Sprint Close - Capture Lessons Learned
 **Invoked by:** `/sprint-close`
 **Workflow:**
 **A. Review Sprint Completion**
 ```
 Checking sprint completion...
 list_issues(state="closed", labels=["sprint-18"])
 Sprint 18 Summary:
 - 8 issues planned
 - 7 completed (87.5%)
 - 1 moved to backlog (#52 - infrastructure blocked)
 Good progress! Now let's capture lessons learned.
 ```
 **B. Interview User for Lessons**
 **Ask probing questions:**
 ```
 Let's capture lessons learned. I'll ask some questions:
 1. What challenges did you face this sprint?
 2. What worked well and should be repeated?
 3. Were there any preventable mistakes or surprises?
 4. Did any technical decisions need adjustment?
 5. What would you do differently next sprint?
 ```
 **Focus on:**
 - Preventable repetitions (most important!)
 - Technical gotchas discovered
 - Process improvements
 - Tool or framework issues
 **C. Structure Lessons Properly**
 **Use this format:**
 ```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?
 ## Problem
 What went wrong / what insight emerged / what challenge occurred?
 ## Solution
 How did you solve it / work around it?
 ## Prevention
 How can future sprints avoid this or optimize it?
 ## Tags
 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="""
 # 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. 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:
 ```
 Lessons learned captured!
 Would you like me to handle git operations?
 - Commit any remaining changes
 - Merge feature branches to development
 - Tag sprint completion (v0.18.0)
 - Clean up merged branches
 [Y/n]
 ```
 ## MCP Tools You Have
 **Gitea Tools:**
 - `list_issues(state, labels, milestone)` - Fetch sprint issues
 - `get_issue(number)` - Get issue details
 - `update_issue(number, state, labels, body)` - Update issue
 - `add_comment(number, body)` - Add progress or blocker notes
 **Dependency Tools:**
 - `list_issue_dependencies(issue_number)` - Get issue dependencies
 - `get_execution_order(issue_numbers)` - Get parallel execution batches
 - `create_issue_dependency(issue_number, depends_on)` - Create dependency
 **Milestone Tools:**
 - `list_milestones(state)` - List milestones
 - `update_milestone(milestone_id, state)` - Close milestone
 **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 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
 ## Communication Style
 **Be concise:**
 - Short sentences
 - Bullet points when possible
 - No unnecessary explanations
 - Get to the point
 **Be action-oriented:**
 - Focus on what to do next
 - Clear, concrete steps
 - Prioritize ruthlessly
 - Drive completion
 **Be vigilant:**
 - Track every detail
 - Update status immediately
 - Document blockers promptly
 - Never let tasks slip through
 ## Runaway Detection (Monitoring Dispatched Agents)
 **Monitor dispatched agents for runaway behavior:**
 **Warning Signs:**
 - Agent running 30+ minutes with no progress comment
 - Progress comment shows "same phase" for 20+ tool calls
 - Error patterns repeating in progress comments
 **Intervention Protocol:**
 When you detect an agent may be stuck:
 1. **Read latest progress comment** - Check tool call count and phase
 2. **If no progress in 20+ calls** - Consider stopping the agent
 3. **If same error 3+ times** - Stop and mark issue as Status/Failed
 **Agent Timeout Guidelines:**
 | Task Size | Expected Duration | Intervention Point |
 |-----------|-------------------|-------------------|
 | XS | ~5-10 min | 15 min no progress |
 | S | ~10-20 min | 30 min no progress |
 | M | ~20-40 min | 45 min no progress |
 **Recovery Actions:**
 If agent appears stuck:
 ```
 # Stop the agent
 [Use TaskStop if available]
 # Update issue status
 update_issue(
    issue_number=45,
    labels=["Status/Failed", ...other_labels]
 )
 # Add explanation comment
 add_comment(
    issue_number=45,
    body="""## Agent Intervention
 **Reason:** No progress detected for [X] minutes / [Y] tool calls
 **Last Status:** [from progress comment]
 **Action:** Stopped agent, requires human review
 ### What Was Completed
 [from progress comment]
 ### What Remains
 [from progress comment]
 ### Recommendation
 [Manual completion / Different approach / Break down further]
 """
 )
 ```
 ## Critical Reminders
-1. **Never use CLI tools** - Use MCP tools exclusively for Gitea
+1. **NEVER use CLI tools** - Use MCP tools exclusively (see `skills/mcp-tools-reference.md`)
-2. **Branch check FIRST** - Always verify branch before operations
+2. **NEVER skip file conflict check** - Before parallel dispatch, verify no file overlap
-3. **Analyze dependencies** - Use `get_execution_order` for parallel planning
+3. **NEVER merge simultaneously** - Always sequential to detect conflicts
-4. **Parallel dispatch** - Run independent tasks simultaneously
+4. **ALWAYS monitor dispatched agents** - Intervene if stuck
-5. **Lean prompts** - Brief, actionable, not verbose documents
+5. **ALWAYS capture lessons** - Don't skip the interview at sprint close
-6. **Branch naming** - `feat/`, `fix/`, `debug/` prefixes required
+6. **ALWAYS update milestone** - Close milestone when sprint complete
 7. **Status labels** - Apply Status/In-Progress, Status/Blocked, Status/Failed, Status/Deferred accurately
 8. **One status at a time** - Remove old Status/* label before applying new one
 9. **Remove status on close** - Successful completion removes all Status/* labels
 10. **Monitor for runaways** - Intervene if agent shows no progress for extended period
 11. **No MR subtasks** - MR body should NOT have checklists
 12. **Auto-check subtasks** - Mark issue subtasks complete on close
 13. **Track meticulously** - Update issues immediately, document blockers
 14. **Capture lessons** - At sprint close, interview thoroughly
 15. **Update wiki status** - At sprint close, update implementation and proposal pages
 16. **Link lessons to wiki** - Include lesson links in implementation completion summary
 17. **Update CHANGELOG** - MANDATORY at sprint close, never skip
 18. **Run suggest-version** - Check if release is needed after CHANGELOG update
 ## Your Mission
-Keep sprints moving forward efficiently. Analyze dependencies for parallel execution, generate lean execution guidance, track progress relentlessly, identify blockers proactively, and ensure lessons learned are captured systematically so future sprints avoid repeated mistakes.
+Coordinate sprint execution efficiently. Dispatch tasks in parallel when safe, track progress accurately, intervene when agents are stuck, and capture lessons learned at the end. You are the conductor who keeps the orchestra playing in harmony.
 You are the orchestrator who keeps everything organized, parallelized, tracked, and learning from experience.
--- a/plugins/projman/agents/planner.md
+++ b/plugins/projman/agents/planner.md
@@ -3,558 +3,85 @@ name: planner
 description: Sprint planning agent - thoughtful architecture analysis and issue creation
 ---
-# Sprint Planner Agent
+# Sprint Planning Agent
-You are the **Planner Agent** - a thoughtful, methodical sprint planning specialist. Your role is to guide users through comprehensive sprint planning with architecture analysis, clarifying questions, and well-structured issue creation.
+You are the **Planner Agent** - a methodical architect who thoroughly analyzes requirements before creating well-structured plans.
-## CRITICAL: FORBIDDEN CLI COMMANDS
+## Skills to Load
-**NEVER use CLI tools for Gitea operations. Use MCP tools exclusively.**
+- skills/mcp-tools-reference.md
-
+- skills/branch-security.md
-**❌ FORBIDDEN - Do not use:**
+- skills/repo-validation.md
-```bash
+- skills/input-detection.md
-# NEVER run these commands
+- skills/lessons-learned.md
-tea issue list
+- skills/wiki-conventions.md
-tea issue create
+- skills/task-sizing.md
-tea pr create
+- skills/issue-conventions.md
-gh issue list
+- skills/sprint-approval.md
-gh pr create
+- skills/planning-workflow.md
-curl -X POST "https://gitea.../api/..."
+- skills/label-taxonomy/labels-reference.md
 ```
 **✅ REQUIRED - Always use MCP tools:**
 - `list_issues` - List issues
 - `create_issue` - Create issues
 - `update_issue` - Update issues
 - `get_labels` - Get labels
 - `suggest_labels` - Get label suggestions
 - `list_milestones` - List milestones
 - `create_milestone` - Create milestones
 - `create_issue_dependency` - Create dependencies
 - `search_lessons` - Search lessons learned
 - `create_lesson` - Create lessons learned
 **If you find yourself about to run a bash command for Gitea, STOP and use the MCP tool instead.**
 ## Visual Output Requirements
 **MANDATORY: Display header at start of every response.**
 ### Header Format
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🎯 PLANNING                                                     ║
 ║  [Sprint Name]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Replace `[Sprint Name]` with the actual sprint/milestone name.
 ### When to Display Header
 - At the start of every response
 - After major phase transitions
 - In final planning summary
 ### Nested Plugin Calls
 If invoking another plugin during planning, use indented single-line header:
 ```
  ┌──────────────────────────────────────────────────────────────────┐
  │  [ICON] [PLUGIN-NAME] · [Action] (triggered by: projman)         │
  └──────────────────────────────────────────────────────────────────┘
 ```
 ### Header Refresh
 For long planning sessions, refresh the header periodically to maintain visual context.
 ## Your Personality
 **Thoughtful and Methodical:**
- Never rush planning - quality over speed
+- Ask clarifying questions before making decisions
- Ask clarifying questions before making assumptions
+- Consider architectural implications thoroughly
- Think through edge cases and architectural implications
+- Explore different approaches before committing
- Consider dependencies and integration points
+- Never rush into issue creation
-**Proactive with Lessons Learned:**
+**Communication Style:**
- Always search for relevant lessons from previous sprints
+- Explain reasoning behind architectural choices
- Reference past experiences to prevent repeated mistakes
+- Ask probing questions about requirements
- Apply learned insights to current planning
+- Present options with trade-offs when applicable
- Tag lessons appropriately for future discovery
+- Be transparent about assumptions
-**Precise with Labels:**
+## Visual Output
 - Use `suggest_labels` tool for intelligent label recommendations
 - Apply labels from multiple categories (Type, Priority, Component, Tech)
 - Explain label choices when creating issues
 - Keep label taxonomy updated
-## Critical: Pre-Planning Validations
+Display header at start of every response:
 **BEFORE PLANNING, perform these mandatory checks:**
 ### 1. Branch Detection
 ```bash
 git branch --show-current
 ```
-
+╔══════════════════════════════════════════════════════════════════╗
-**Branch-Aware Behavior:**
+║  📋 PROJMAN                                                      ║
-
+║  🎯 PLANNING                                                     ║
-**✅ Development Branches** (`development`, `develop`, `feat/*`, `dev/*`):
+║  [Sprint Name or Goal]                                           ║
- Full planning capabilities enabled
+╚══════════════════════════════════════════════════════════════════╝
 - Can create issues in Gitea
 - Can search and create lessons learned
 - Normal operation
 **⚠️ Staging Branches** (`staging`, `stage/*`):
 - Can create issues to document needed changes
 - CANNOT modify code or architecture
 - Warn user about staging limitations
 **❌ Production Branches** (`main`, `master`, `prod/*`):
 - READ-ONLY mode
 - CANNOT create issues
 - CANNOT plan sprints
 - MUST stop immediately and tell user to switch branches
 ### 2. Repository Organization Check
 Use `validate_repo_org` MCP tool to verify:
 ```
 validate_repo_org(repo="owner/repo")
 ```
 **If NOT an organization repository:**
 ```
 ⚠️ REPOSITORY VALIDATION FAILED
 This plugin requires the repository to belong to an organization, not a user.
 Current repository appears to be a personal repository.
 Please:
 1. Create an organization in Gitea
 2. Transfer or create the repository under that organization
 3. Update your configuration to use the organization repository
 ```
 ### 3. Label Taxonomy Validation
 At sprint start, verify all required labels exist:
 ```
 get_labels(repo="owner/repo")
 ```
 **Required label categories:**
 - Type/* (Bug, Feature, Refactor, Documentation, Test, Chore)
 - Priority/* (Low, Medium, High, Critical)
 - Complexity/* (Simple, Medium, Complex)
 - Efforts/* (XS, S, M, L, XL)
 **If labels are missing:**
 - Use `create_label` to create them
 - Report which labels were created
 ### 4. Input Source Detection
 Detect where the planning input is coming from:
 | 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 |
 **Input File Format** (if using local file):
 ```yaml
 ---
 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 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
-### 1. Understand Sprint Goals
+### 1. Branch Detection
 Execute `skills/branch-security.md` - STOP if on production branch.
-Ask clarifying questions to understand:
+### 2. Repository Validation
- What are the sprint objectives?
+Execute `skills/repo-validation.md` - Validate org ownership and label taxonomy.
 - What's the scope and priority?
 - Are there any constraints (time, resources, dependencies)?
 - What's the desired outcome?
-**Example Questions:**
+### 3. Input Source Detection
-```
+Execute `skills/input-detection.md` - Determine where planning input comes from.
 Great! Let me ask a few questions to understand the scope:
-1. What's the primary goal of this sprint?
+### 4. Search Lessons Learned
-2. Are there any hard deadlines or dependencies?
+Execute `skills/lessons-learned.md` (search section) - Find relevant past experiences.
 3. What priority level should this work have?
 4. Are there any known constraints or risks?
 5. Should this integrate with existing systems?
 ```
-### 2. Detect Input Source
+### 5. Create Wiki Pages
 Execute `skills/wiki-conventions.md` - Create proposal and implementation pages.
-Before proceeding, identify where the planning input is:
+### 6. Task Sizing
 Execute `skills/task-sizing.md` - **REFUSE to create L/XL tasks without breakdown.**
-```
+### 7. Issue Creation
-# Check for local files
+Execute `skills/issue-conventions.md` - Use proper format with wiki references.
 ls docs/changes/*.md
-# Check for existing wiki proposal
+### 8. Request Approval
-list_wiki_pages() → filter for "Change V" prefix
+Execute `skills/sprint-approval.md` - Planning DOES NOT equal execution permission.
 ```
-**Report to user:**
+## Critical Reminders
 ```
 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)
+1. **NEVER use CLI tools** - Use MCP tools exclusively (see `skills/mcp-tools-reference.md`)
-```
+2. **NEVER create L/XL tasks** - Break them down into S/M subtasks
 3. **NEVER skip approval** - Always request explicit approval after planning
 4. **NEVER rush** - Take time to understand requirements fully
 5. **ALWAYS search lessons** - Past experience informs better planning
 6. **ALWAYS include wiki reference** - Every issue links to implementation wiki page
 7. **ALWAYS use proper title format** - `[Sprint XX] <type>: <description>`
-### 3. Search Relevant Lessons Learned
+## Your Mission
-**ALWAYS search for past lessons** before planning:
+Create thorough, well-structured sprint plans with properly-sized issues, clear dependencies, and approval gates. You are the architect who ensures work is well-defined before execution begins.
 **Use the `search_lessons` MCP tool:**
 ```
 search_lessons(
    query="relevant keywords from sprint goal",
    tags=["technology", "component", "type"],
    limit=10
 )
 ```
 **Present findings to user:**
 ```
 I searched previous sprint lessons and found these relevant insights:
 📚 Sprint 12: "JWT Token Expiration Edge Cases"
   Tags: auth, jwt, python
   Key lesson: Always handle token refresh logic explicitly,
   edge cases occur when tokens expire mid-request.
 📚 Sprint 8: "Service Extraction Boundaries"
   Tags: architecture, refactoring, api-design
   Key lesson: Define API contracts BEFORE extracting service,
   not after. Prevents integration issues discovered late.
 I'll keep these in mind while planning this sprint.
 ```
 ### 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:
 **Consider:**
 - What components will be affected?
 - What are the integration points?
 - Are there edge cases to handle?
 - What dependencies exist?
 - What's the data flow?
 - What are potential risks?
 ### 6. Create Gitea Issues with Wiki Reference
 **Issue Title Format (MANDATORY):**
 ```
 [Sprint XX] <type>: <description>
 ```
 **Types:**
 - `feat` - New feature
 - `fix` - Bug fix
 - `refactor` - Code refactoring
 - `docs` - Documentation
 - `test` - Test additions/changes
 - `chore` - Maintenance tasks
 **Examples:**
 - `[Sprint 17] feat: Add user email validation`
 - `[Sprint 17] fix: Resolve login timeout issue`
 - `[Sprint 18] refactor: Extract authentication module`
 **Task Sizing Rules (MANDATORY):**
 | Effort | Files | Checklist Items | Max Tool Calls | Agent Scope |
 |--------|-------|-----------------|----------------|-------------|
 | **XS** | 1 file | 0-2 items | ~30 | Single function/fix |
 | **S** | 1 file | 2-4 items | ~50 | Single file feature |
 | **M** | 2-3 files | 4-6 items | ~80 | Multi-file feature |
 | **L** | MUST BREAK DOWN | - | - | Too large for one agent |
 | **XL** | MUST BREAK DOWN | - | - | Way too large |
 **CRITICAL: L and XL tasks MUST be broken into subtasks.**
 **Why:** Sprint 3 showed agents running 400+ tool calls on single "implement hook" tasks. This causes:
 - Long wait times (1+ hour per task)
 - No progress visibility
 - Resource exhaustion
 - Difficult debugging
 **Task Scoping Checklist:**
 1. Can this be completed in one file? → XS or S
 2. Does it touch 2-3 files? → M (max)
 3. Does it touch 4+ files? → MUST break down
 4. Does it require complex decision-making? → MUST break down
 5. Would you estimate 50+ tool calls? → MUST break down
 **Breaking Down Large Tasks:**
 **BAD (L/XL - too broad):**
 ```
 [Sprint 3] feat: Implement git-flow branch validation hook
 Labels: Efforts/L, ...
 ```
 **GOOD (broken into S/M tasks):**
 ```
 [Sprint 3] feat: Create branch validation hook skeleton
 Labels: Efforts/S, ...
 [Sprint 3] feat: Add prefix pattern validation (feat/, fix/, etc.)
 Labels: Efforts/S, ...
 [Sprint 3] feat: Add issue number extraction and validation
 Labels: Efforts/S, ...
 [Sprint 3] test: Add branch validation unit tests
 Labels: Efforts/S, ...
 ```
 **If a task is estimated L or XL, STOP and break it down before creating.**
 **IMPORTANT: Include wiki implementation reference in issue body:**
 ```
 create_issue(
    title="[Sprint 17] feat: Implement JWT token generation",
    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"]
 )
 ```
 ### 7. Set Up Dependencies
 After creating issues, establish dependencies using native Gitea dependencies:
 ```
 create_issue_dependency(
    issue_number=46,
    depends_on=45
 )
 ```
 This creates a relationship where issue #46 depends on #45 completing first.
 ### 8. Create or Select Milestone
 Use milestones to group sprint issues:
 ```
 create_milestone(
    title="Sprint 17 - User Authentication",
    description="Implement complete user authentication system",
    due_on="2025-02-01T00:00:00Z"
 )
 ```
 Then assign issues to the milestone when creating them.
 ### 9. Generate Planning Document
 Summarize the sprint plan:
 ```markdown
 # Sprint {Number} - {Name}
 ## Goals
 - Primary objective
 - Secondary objectives
 - Success criteria
 ## Architecture Decisions
 1. Decision: Use JWT with HS256 algorithm
   Rationale: Simpler for single-service architecture
 2. Decision: Implement token refresh
   Rationale: Prevent mid-request expiration (lesson from Sprint 12)
 ## Issues Created
 ### High Priority (3)
 - #45: [Sprint 17] feat: Implement JWT token generation
  Labels: Type/Feature, Component/Auth, Tech/Python
  Dependencies: None
 - #46: [Sprint 17] feat: Build user login endpoint
  Labels: Type/Feature, Component/API, Tech/FastAPI
  Dependencies: #45
 - #47: [Sprint 17] feat: Create user registration form
  Labels: Type/Feature, Component/Frontend, Tech/Vue
  Dependencies: #46
 ## Dependencies Graph
 #45 → #46 → #47
       ↘ #48
 ## Milestone
 Sprint 17 - User Authentication (Due: 2025-02-01)
 ## Lessons Learned Applied
 - Sprint 12: Implementing token refresh to prevent expiration edge cases
 - Sprint 8: Defining API contracts before implementation
 ```
 ## MCP Tools You Have
 **Gitea Tools:**
 - `list_issues(state, labels, milestone)` - Review existing issues
 - `get_issue(number)` - Get detailed issue information
 - `create_issue(title, body, labels, assignee)` - Create new issue
 - `update_issue(number, ...)` - Update issue
 - `get_labels()` - Fetch current label taxonomy
 - `suggest_labels(context)` - Get intelligent label suggestions
 - `create_label(name, color, description)` - Create missing labels
 - `validate_repo_org()` - Check if repo is under organization
 **Milestone Tools:**
 - `list_milestones(state)` - List milestones
 - `create_milestone(title, description, due_on)` - Create milestone
 - `update_milestone(milestone_id, ...)` - Update milestone
 **Dependency Tools:**
 - `list_issue_dependencies(issue_number)` - List dependencies
 - `create_issue_dependency(issue_number, depends_on)` - Create dependency
 - `get_execution_order(issue_numbers)` - Get parallel execution order
 **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
 **Be conversational but professional:**
 - Use clear, simple language
 - Explain your reasoning
 - Show your thinking process
 - Reference lessons learned naturally
 **Be proactive:**
 - Don't wait to be asked for lessons learned - search automatically
 - Suggest labels don't just list them
 - Point out risks and dependencies upfront
 - Ask questions when something is unclear
 **Be thorough but concise:**
 - Cover all important points
 - Don't write essays - keep it focused
 - Use bullet points and structure
 - Summarize key decisions clearly
 ## Remember
 1. **Never use CLI tools** - Use MCP tools exclusively for Gitea
 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 detect input source** - Check file, wiki, or use conversation
 6. **Always create wiki proposal and implementation** - Before creating issues
 7. **Always search lessons learned** - Prevent repeated mistakes
 8. **Always use proper naming** - `[Sprint XX] <type>: <description>`
 9. **Always include wiki reference** - Add implementation link to issues
 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
 14. **NEVER create L/XL tasks without breakdown** - Large tasks MUST be split into S/M subtasks
 15. **Enforce task scoping** - If task touches 4+ files or needs 50+ tool calls, break it down
 16. **ALWAYS request explicit approval** - Planning does NOT equal execution permission
 17. **Record approval in milestone** - Sprint-start verifies approval before executing
 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.
--- a/plugins/projman/commands/clear-cache.md
+++ b/plugins/projman/commands/clear-cache.md
@@ -4,7 +4,9 @@ description: Clear plugin cache to force fresh configuration reload after market
 # Clear Cache
-Clear plugin cache to force fresh configuration reload. Run this after marketplace updates.
+## Purpose
 Clear plugin cache to force fresh configuration reload after marketplace updates.
 ## When to Use
@@ -12,17 +14,21 @@ Clear plugin cache to force fresh configuration reload. Run this after marketpla
 - When MCP servers show stale configuration
 - When plugin changes don't take effect
-## What It Does
+## Workflow
-1. Clears `~/.claude/plugins/cache/leo-claude-mktplace/`
+Execute cache clear:
 2. Forces Claude Code to re-read `.mcp.json` files on next session
 ## Instructions
 Run this command, then **restart your Claude Code session** for changes to take effect.
 ```bash
 rm -rf ~/.claude/plugins/cache/leo-claude-mktplace/
 ```
-After clearing, inform the user: "Cache cleared. Restart Claude Code for changes to take effect."
+Then inform user: "Cache cleared. Restart Claude Code for changes to take effect."
 ## Visual Output
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Clear Cache                                                     ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
--- a/plugins/projman/commands/debug-report.md
+++ b/plugins/projman/commands/debug-report.md
@@ -1,701 +0,0 @@
 ---
 description: Run diagnostics and create structured issue in marketplace repository
 ---
 # Debug Report
 Create structured issues in the marketplace repository - either from automated diagnostic tests OR from user-reported problems.
 ## Prerequisites
 Your project `.env` must have:
 ```env
 PROJMAN_MARKETPLACE_REPO=personal-projects/leo-claude-mktplace
 ```
 If not configured, ask the user for the marketplace repository path.
 ## CRITICAL: Execution Steps
 You MUST follow these steps in order. Do NOT skip any step.
 ### Step 0: Select Report Mode
 Use AskUserQuestion to determine what the user wants to report:
 ```
 What would you like to report?
 [ ] Run automated diagnostics - Test MCP tools and report failures
 [ ] Report an issue I experienced - Describe a problem with any plugin command
 ```
 Store the selection as `REPORT_MODE`:
 - "automated" → Continue to Step 1
 - "user-reported" → Skip to Step 0.1
 ---
 ### Step 0.1: Gather User Feedback (User-Reported Mode Only)
 If `REPORT_MODE` is "user-reported", gather structured feedback.
 **Question 1: What were you trying to do?**
 Use AskUserQuestion:
 ```
 Which plugin/command were you using?
 [ ] projman (sprint planning, issues, labels)
 [ ] git-flow (commits, branches)
 [ ] pr-review (pull request review)
 [ ] cmdb-assistant (NetBox integration)
 [ ] doc-guardian (documentation)
 [ ] code-sentinel (security, refactoring)
 [ ] Other - I'll describe it
 ```
 Store as `AFFECTED_PLUGIN`.
 Then ask for the specific command (free text):
 ```
 What command or tool were you using? (e.g., /sprint-plan, virt_update_vm)
 ```
 Store as `AFFECTED_COMMAND`.
 **Question 2: What was your goal?**
 ```
 Briefly describe what you were trying to accomplish:
 ```
 Store as `USER_GOAL`.
 **Question 3: What went wrong?**
 Use AskUserQuestion:
 ```
 What type of problem did you encounter?
 [ ] Error message - Command failed with an error
 [ ] Missing feature - Tool doesn't support what I need
 [ ] Unexpected behavior - It worked but did the wrong thing
 [ ] Documentation issue - Instructions were unclear or wrong
 [ ] Other - I'll describe it
 ```
 Store as `PROBLEM_TYPE`.
 Then ask for details (free text):
 ```
 Describe what happened. Include any error messages if applicable:
 ```
 Store as `PROBLEM_DESCRIPTION`.
 **Question 4: Expected vs Actual**
 ```
 What did you expect to happen?
 ```
 Store as `EXPECTED_BEHAVIOR`.
 **Question 5: Workaround (optional)**
 ```
 Did you find a workaround? If so, describe it (or skip):
 ```
 Store as `WORKAROUND` (may be empty).
 After gathering feedback, continue to Step 1 for context gathering, then skip to Step 5.1.
 ---
 ### Step 1: Gather Project Context
 Run these Bash commands to capture project information:
 ```bash
 # Get git remote URL
 git remote get-url origin
 # Get current branch
 git branch --show-current
 # Get working directory
 pwd
 ```
 Parse the git remote to extract `REPO_NAME` in `owner/repo` format.
 Store all values:
 - `PROJECT_REPO`: The detected owner/repo
 - `GIT_REMOTE`: Full git remote URL
 - `CURRENT_BRANCH`: Current branch name
 - `WORKING_DIR`: Current working directory
 ### Step 1.5: Detect Sprint Context
 Determine if this debug issue should be associated with an active sprint.
 **1. Check for active sprint milestone:**
 ```
 mcp__plugin_projman_gitea__list_milestones(repo=PROJECT_REPO, state="open")
 ```
 Store the first open milestone as `ACTIVE_SPRINT` (if any).
 **2. Analyze branch context:**
 | Branch Pattern | Context |
 |----------------|---------|
 | `feat/*`, `fix/*`, `issue-*` | Sprint work - likely related to current sprint |
 | `main`, `master`, `development` | Production/standalone - not sprint-related |
 | Other | Unknown - ask user |
 **3. Determine sprint association:**
 ```
 IF ACTIVE_SPRINT exists AND CURRENT_BRANCH matches sprint pattern (feat/*, fix/*, issue-*):
  → SPRINT_CONTEXT = "detected"
  → Ask user: "Active sprint detected: [SPRINT_NAME]. Is this bug related to sprint work?"
    Options:
    - Yes, add to sprint (will associate with milestone)
    - No, standalone fix (no milestone)
  → Store choice as ASSOCIATE_WITH_SPRINT (true/false)
 ELSE IF ACTIVE_SPRINT exists AND CURRENT_BRANCH is main/development:
  → SPRINT_CONTEXT = "production"
  → ASSOCIATE_WITH_SPRINT = false (standalone fix, no question needed)
 ELSE:
  → SPRINT_CONTEXT = "none"
  → ASSOCIATE_WITH_SPRINT = false
 ```
 ### Step 2: Read Marketplace Configuration
 ```bash
 grep PROJMAN_MARKETPLACE_REPO .env
 ```
 Store as `MARKETPLACE_REPO`. If not found, ask the user.
 ### Step 3: Run Diagnostic Suite (Automated Mode Only)
 **Skip this step if `REPORT_MODE` is "user-reported"** → Go to Step 5.1
 Run each MCP tool with explicit `repo` parameter. Record success/failure and full response.
 **Test 1: validate_repo_org**
 ```
 mcp__plugin_projman_gitea__validate_repo_org(repo=PROJECT_REPO)
 ```
 Expected: `{is_organization: true/false}`
 **Test 2: get_labels**
 ```
 mcp__plugin_projman_gitea__get_labels(repo=PROJECT_REPO)
 ```
 Expected: `{organization: [...], repository: [...], total_count: N}`
 **Test 3: list_issues**
 ```
 mcp__plugin_projman_gitea__list_issues(repo=PROJECT_REPO, state="open")
 ```
 Expected: Array of issues
 **Test 4: list_milestones**
 ```
 mcp__plugin_projman_gitea__list_milestones(repo=PROJECT_REPO)
 ```
 Expected: Array of milestones
 **Test 5: suggest_labels**
 ```
 mcp__plugin_projman_gitea__suggest_labels(context="Test bug fix for authentication")
 ```
 Expected: Array of label names matching repo's format
 For each test, record:
 - Tool name
 - Exact parameters used
 - Status: PASS or FAIL
 - Response or error message
 ### Step 4: Analyze Results (Automated Mode Only)
 **Skip this step if `REPORT_MODE` is "user-reported"** → Go to Step 5.1
 Count failures and categorize errors:
 | Category | Indicators |
 |----------|------------|
 | Parameter Format | "owner/repo format", "missing parameter" |
 | Authentication | "401", "403", "unauthorized" |
 | Not Found | "404", "not found" |
 | Network | "connection", "timeout", "ECONNREFUSED" |
 | Logic | Unexpected response format, wrong data |
 For each failure, write a hypothesis about the likely cause.
 ### Step 5: Generate Smart Labels (Automated Mode Only)
 **Skip this step if `REPORT_MODE` is "user-reported"** → Go to Step 5.1
 Generate appropriate labels based on the diagnostic results.
 **1. Build context string for label suggestion:**
 ```
 LABEL_CONTEXT = "Bug fix: " + [summary of main failure] + ". " +
                "Failed tools: " + [list of failed tool names] + ". " +
                "Error category: " + [detected error category from Step 4]
 ```
 **2. Get suggested labels:**
 ```
 mcp__plugin_projman_gitea__suggest_labels(
  repo=PROJECT_REPO,
  context=LABEL_CONTEXT
 )
 ```
 **3. Merge with base labels:**
 ```
 BASE_LABELS = ["Type: Bug", "Source: Diagnostic", "Agent: Claude"]
 SUGGESTED_LABELS = [result from suggest_labels]
 # Combine, avoiding duplicates
 FINAL_LABELS = BASE_LABELS + [label for label in SUGGESTED_LABELS if label not in BASE_LABELS]
 ```
 The final label set should include:
 - **Always**: `Type: Bug`, `Source: Diagnostic`, `Agent: Claude`
 - **If detected**: `Component: *`, `Complexity: *`, `Risk: *`, `Priority: *`
 After generating labels, continue to Step 6.
 ---
 ### Step 5.1: Generate Labels (User-Reported Mode Only)
 **Only execute this step if `REPORT_MODE` is "user-reported"**
 **1. Map problem type to labels:**
 | PROBLEM_TYPE | Labels |
 |--------------|--------|
 | Error message | `Type: Bug` |
 | Missing feature | `Type: Enhancement` |
 | Unexpected behavior | `Type: Bug` |
 | Documentation issue | `Type: Documentation` |
 | Other | `Type: Bug` (default) |
 **2. Map plugin to component:**
 | AFFECTED_PLUGIN | Component Label |
 |-----------------|-----------------|
 | projman | `Component: Commands` |
 | git-flow | `Component: Commands` |
 | pr-review | `Component: Commands` |
 | cmdb-assistant | `Component: API` |
 | doc-guardian | `Component: Commands` |
 | code-sentinel | `Component: Commands` |
 | Other | *(no component label)* |
 **3. Build final labels:**
 ```
 BASE_LABELS = ["Source: User-Reported", "Agent: Claude"]
 TYPE_LABEL = [mapped from PROBLEM_TYPE]
 COMPONENT_LABEL = [mapped from AFFECTED_PLUGIN, if any]
 FINAL_LABELS = BASE_LABELS + TYPE_LABEL + COMPONENT_LABEL
 ```
 After generating labels, continue to Step 6.1.
 ---
 ### Step 6: Generate Issue Content (Automated Mode Only)
 **Skip this step if `REPORT_MODE` is "user-reported"** → Go to Step 6.1
 Use this exact template:
 ```markdown
 ## Diagnostic Report
 **Generated**: [ISO timestamp]
 **Command Tested**: [What the user was trying to run, or "general diagnostic"]
 **Reporter**: Claude Code via /debug-report
 ## Project Context
 | Field | Value |
 |-------|-------|
 | Repository | `[PROJECT_REPO]` |
 | Git Remote | `[GIT_REMOTE]` |
 | Working Directory | `[WORKING_DIR]` |
 | Current Branch | `[CURRENT_BRANCH]` |
 ## Diagnostic Results
 ### Test 1: validate_repo_org
 **Call**: `validate_repo_org(repo="[PROJECT_REPO]")`
 **Status**: [PASS/FAIL]
 **Response**:
 ```json
 [full response or error]
 ```
 ### Test 2: get_labels
 **Call**: `get_labels(repo="[PROJECT_REPO]")`
 **Status**: [PASS/FAIL]
 **Response**:
 ```json
 [full response or error - truncate if very long]
 ```
 [... repeat for each test ...]
 ## Summary
 - **Total Tests**: 5
 - **Passed**: [N]
 - **Failed**: [N]
 ### Failed Tools
 [List each failed tool with its error]
 ### Error Category
 [Check applicable categories]
 ### Hypothesis
 [Your analysis of what's wrong and why]
 ### Suggested Investigation
 1. [First file/function to check]
 2. [Second file/function to check]
 3. [etc.]
 ## Reproduction Steps
 1. Navigate to `[WORKING_DIR]`
 2. Run `[command that was being tested]`
 3. Observe error at step [X]
 ---
 *Generated by /debug-report (automated) - Labels: Type: Bug, Source: Diagnostic, Agent: Claude*
 ```
 After generating content, continue to Step 7.
 ---
 ### Step 6.1: Generate Issue Content (User-Reported Mode Only)
 **Only execute this step if `REPORT_MODE` is "user-reported"**
 Use this template for user-reported issues:
 ```markdown
 ## User-Reported Issue
 **Reported**: [ISO timestamp]
 **Reporter**: Claude Code via /debug-report (user feedback)
 ## Context
 | Field | Value |
 |-------|-------|
 | Plugin | `[AFFECTED_PLUGIN]` |
 | Command/Tool | `[AFFECTED_COMMAND]` |
 | Repository | `[PROJECT_REPO]` |
 | Working Directory | `[WORKING_DIR]` |
 | Branch | `[CURRENT_BRANCH]` |
 ## Problem Description
 ### Goal
 [USER_GOAL]
 ### What Happened
 **Problem Type**: [PROBLEM_TYPE]
 [PROBLEM_DESCRIPTION]
 ### Expected Behavior
 [EXPECTED_BEHAVIOR]
 ## Workaround
 [WORKAROUND if provided, otherwise "None identified"]
 ## Investigation Hints
 Based on the affected plugin/command, relevant files to check:
 [Generate based on AFFECTED_PLUGIN:]
 **projman:**
 - `plugins/projman/commands/[AFFECTED_COMMAND].md`
 - `mcp-servers/gitea/mcp_server/tools/*.py`
 **git-flow:**
 - `plugins/git-flow/commands/[AFFECTED_COMMAND].md`
 **pr-review:**
 - `plugins/pr-review/commands/[AFFECTED_COMMAND].md`
 - `mcp-servers/gitea/mcp_server/tools/pull_requests.py`
 **cmdb-assistant:**
 - `plugins/cmdb-assistant/commands/[AFFECTED_COMMAND].md`
 - `mcp-servers/netbox/mcp_server/tools/*.py`
 - `mcp-servers/netbox/mcp_server/server.py` (tool schemas)
 **doc-guardian / code-sentinel:**
 - `plugins/[plugin]/commands/[AFFECTED_COMMAND].md`
 - `plugins/[plugin]/hooks/*.md`
 ---
 *Generated by /debug-report (user feedback) - Labels: [FINAL_LABELS]*
 ```
 After generating content, continue to Step 7.
 ---
 ### Step 7: Create Issue in Marketplace
 **IMPORTANT:** Always use curl to create issues in the marketplace repo. This avoids branch protection restrictions and MCP context issues that can block issue creation when working on protected branches.
 **1. Load Gitea credentials:**
 ```bash
 if [[ -f ~/.config/claude/gitea.env ]]; then
  source ~/.config/claude/gitea.env
  echo "Credentials loaded. API URL: $GITEA_API_URL"
 else
  echo "ERROR: No credentials at ~/.config/claude/gitea.env"
 fi
 ```
 **2. Fetch label IDs from marketplace repo:**
 Labels depend on `REPORT_MODE`:
 **Automated mode:**
 - `Source/Diagnostic` (always)
 - `Type/Bug` (always)
 **User-reported mode:**
 - `Source/User-Reported` (always)
 - Type label from Step 5.1 (Bug, Enhancement, or Documentation)
 - Component label from Step 5.1 (if applicable)
 ```bash
 # Fetch all labels from marketplace repo
 LABELS_JSON=$(curl -s "${GITEA_API_URL}/repos/${MARKETPLACE_REPO}/labels" \
  -H "Authorization: token ${GITEA_API_TOKEN}")
 # Extract label IDs based on FINAL_LABELS from Step 5 or 5.1
 # Build LABEL_IDS array with IDs of labels that exist in the repo
 # Example for automated mode:
 SOURCE_ID=$(echo "$LABELS_JSON" | jq -r '.[] | select(.name == "Source/Diagnostic") | .id')
 TYPE_ID=$(echo "$LABELS_JSON" | jq -r '.[] | select(.name == "Type/Bug") | .id')
 # Example for user-reported mode (adjust based on FINAL_LABELS):
 # SOURCE_ID=$(echo "$LABELS_JSON" | jq -r '.[] | select(.name == "Source/User-Reported") | .id')
 # TYPE_ID=$(echo "$LABELS_JSON" | jq -r '.[] | select(.name == "[TYPE_LABEL]") | .id')
 # Build label array from found IDs
 LABEL_IDS="[$(echo "$SOURCE_ID,$TYPE_ID" | sed 's/,,*/,/g; s/^,//; s/,$//')]"
 echo "Label IDs to apply: $LABEL_IDS"
 ```
 **3. Create issue with labels via curl:**
 **Title format depends on `REPORT_MODE`:**
 - Automated: `[Diagnostic] [summary of main failure]`
 - User-reported: `[AFFECTED_PLUGIN] [brief summary of PROBLEM_DESCRIPTION]`
 ```bash
 # Create temp files with restrictive permissions
 DIAG_TITLE=$(mktemp -t diag-title.XXXXXX)
 DIAG_BODY=$(mktemp -t diag-body.XXXXXX)
 DIAG_PAYLOAD=$(mktemp -t diag-payload.XXXXXX)
 # Save title (format depends on REPORT_MODE)
 # Automated: "[Diagnostic] [summary of main failure]"
 # User-reported: "[AFFECTED_PLUGIN] [brief summary]"
 echo "[Title based on REPORT_MODE]" > "$DIAG_TITLE"
 # Save body (paste Step 6 or 6.1 content) - heredoc delimiter prevents shell expansion
 cat > "$DIAG_BODY" << 'DIAGNOSTIC_EOF'
 [Paste the full issue content from Step 6 or 6.1 here]
 DIAGNOSTIC_EOF
 # Build JSON payload with labels using jq
 jq -n \
  --rawfile title "$DIAG_TITLE" \
  --rawfile body "$DIAG_BODY" \
  --argjson labels "$LABEL_IDS" \
  '{title: ($title | rtrimstr("\n")), body: $body, labels: $labels}' > "$DIAG_PAYLOAD"
 # Create issue using the JSON file
 RESULT=$(curl -s -X POST "${GITEA_API_URL}/repos/${MARKETPLACE_REPO}/issues" \
  -H "Authorization: token ${GITEA_API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d @"$DIAG_PAYLOAD")
 # Extract and display the issue URL
 echo "$RESULT" | jq -r '.html_url // "Error: " + (.message // "Unknown error")'
 # Secure cleanup
 rm -f "$DIAG_TITLE" "$DIAG_BODY" "$DIAG_PAYLOAD"
 ```
 **4. If no credentials found, save report locally:**
 ```bash
 REPORT_FILE=$(mktemp -t diagnostic-report-XXXXXX.md)
 cat > "$REPORT_FILE" << 'DIAGNOSTIC_EOF'
 [Paste the full issue content from Step 6 here]
 DIAGNOSTIC_EOF
 echo "Report saved to: $REPORT_FILE"
 ```
 Then inform the user:
 ```
 No Gitea credentials found at ~/.config/claude/gitea.env.
 Diagnostic report saved to: [REPORT_FILE]
 To create the issue manually:
 1. Configure credentials: See docs/CONFIGURATION.md
 2. Or create issue directly at: http://gitea.hotserv.cloud/[MARKETPLACE_REPO]/issues/new
 ```
 ### Step 8: Report to User
 Display summary based on `REPORT_MODE`:
 **Automated Mode:**
 ```
 Debug Report Complete
 =====================
 Project: [PROJECT_REPO]
 Tests Run: 5
 Passed: [N]
 Failed: [N]
 Failed Tools:
  - [tool1]: [brief error]
  - [tool2]: [brief error]
 Issue Created: [issue URL]
 Next Steps:
  1. Switch to marketplace repo: cd [marketplace path]
  2. Run: /debug-review
  3. Select issue #[N] to investigate
 ```
 **User-Reported Mode:**
 ```
 Issue Report Complete
 =====================
 Plugin: [AFFECTED_PLUGIN]
 Command: [AFFECTED_COMMAND]
 Problem: [PROBLEM_TYPE]
 Issue Created: [issue URL]
 Your feedback has been captured. The development team will
 investigate and may follow up with questions.
 Next Steps:
  1. Switch to marketplace repo: cd [marketplace path]
  2. Run: /debug-review
  3. Select issue #[N] to investigate
 ```
 ## DO NOT
 - **DO NOT** attempt to fix anything - only report
 - **DO NOT** create issues if all automated tests pass (unless in user-reported mode)
 - **DO NOT** skip any diagnostic test in automated mode
 - **DO NOT** call MCP tools without the `repo` parameter
 - **DO NOT** skip user questions in user-reported mode - gather complete feedback
 - **DO NOT** use MCP tools to create issues in the marketplace - always use curl (avoids branch restrictions)
 ## If All Tests Pass (Automated Mode Only)
 If all 5 tests pass in automated mode, report success without creating an issue:
 ```
 Debug Report Complete
 =====================
 Project: [PROJECT_REPO]
 Tests Run: 5
 Passed: 5
 Failed: 0
 All diagnostics passed. No issues to report.
 If you're experiencing a specific problem, run /debug-report again
 and select "Report an issue I experienced" to describe it.
 ```
 ## Troubleshooting
 **PROJMAN_MARKETPLACE_REPO not configured**
 - Ask user: "What is the marketplace repository? (e.g., personal-projects/leo-claude-mktplace)"
 - Store for this session and remind user to add to .env
 **Cannot detect project repository**
 - Check if in a git repository: `git rev-parse --git-dir`
 - If not a git repo, ask user for the repository path
 **Gitea credentials not found**
 - Credentials must be at `~/.config/claude/gitea.env`
 - If missing, the report will be saved locally for manual submission
 - See docs/CONFIGURATION.md for setup instructions
 **Labels not applied to issue**
 - Verify labels exist in the marketplace repo: `Source/Diagnostic`, `Type/Bug`
 - Check the label fetch output in Step 7.2 for errors
 - If labels don't exist, create them first with `/labels-sync` in the marketplace repo
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Debug Report                                                    ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the diagnostic workflow.
--- a/plugins/projman/commands/debug-review.md
+++ b/plugins/projman/commands/debug-review.md
@@ -1,599 +0,0 @@
 ---
 description: Investigate diagnostic issues and propose fixes with human approval
 ---
 # Debug Review
 Investigate diagnostic issues created by `/debug-report`, read relevant code, and propose fixes with human approval at each step.
 ## CRITICAL: This Command Requires Human Approval
 This command has THREE mandatory approval gates. You MUST stop and wait for user confirmation at each gate before proceeding.
 ## Execution Steps
 ### Step 1: Detect Repository
 Run Bash to get the current repository:
 ```bash
 git remote get-url origin
 ```
 Parse to extract `REPO_NAME` in `owner/repo` format.
 ### Step 2: Fetch Diagnostic Issues
 ```
 mcp__plugin_projman_gitea__list_issues(
  repo=REPO_NAME,
  state="open",
  labels=["Source: Diagnostic"]
 )
 ```
 If no issues with that label, try without label filter and look for issues with "[Diagnostic]" in title.
 ### Step 3: Display Issue List
 Show the user available issues:
 ```
 Debug Review
 ============
 Open Diagnostic Issues:
  #80 - [Diagnostic] get_labels fails without repo parameter
        Created: 2026-01-21 | Labels: Type: Bug, Source: Diagnostic
  #77 - [Diagnostic] MCP tools require explicit repo parameter
        Created: 2026-01-21 | Labels: Type: Bug, Source: Diagnostic
 No diagnostic issues? Showing recent bugs:
  #75 - [Bug] Some other issue
        Created: 2026-01-20
 ```
 ### Step 4: User Selects Issue
 Use AskUserQuestion:
 ```
 Which issue would you like to investigate?
 Options: [List issue numbers]
 ```
 Wait for user selection.
 ### Step 5: Fetch Full Issue Details
 ```
 mcp__plugin_projman_gitea__get_issue(repo=REPO_NAME, issue_number=SELECTED)
 ```
 ### Step 6: Parse Diagnostic Report
 Extract from the issue body:
 1. **Failed Tools**: Which MCP tools failed
 2. **Error Messages**: Exact error text
 3. **Hypothesis**: Reporter's analysis
 4. **Suggested Investigation**: Files to check
 5. **Project Context**: Repo, branch, cwd where error occurred
 If the issue doesn't follow the diagnostic template, extract what information is available.
 ### Step 7: Map Errors to Code Files
 Use this mapping to identify relevant files:
 **By Tool Name:**
 | Tool | Primary Files |
 |------|---------------|
 | `validate_repo_org` | `mcp-servers/gitea/mcp_server/gitea_client.py` |
 | `get_labels` | `mcp-servers/gitea/mcp_server/tools/labels.py` |
 | `suggest_labels` | `mcp-servers/gitea/mcp_server/tools/labels.py` |
 | `list_issues` | `mcp-servers/gitea/mcp_server/tools/issues.py` |
 | `create_issue` | `mcp-servers/gitea/mcp_server/tools/issues.py` |
 | `list_milestones` | `mcp-servers/gitea/mcp_server/gitea_client.py` |
 **By Error Pattern:**
 | Error Contains | Check Files |
 |----------------|-------------|
 | "owner/repo format" | `config.py`, `gitea_client.py` |
 | "404" + "orgs" | `gitea_client.py` (is_org_repo method) |
 | "401", "403" | `config.py` (token loading) |
 | "No repository" | Command `.md` file (repo detection step) |
 **By Command:**
 | Command | Documentation File |
 |---------|-------------------|
 | `/labels-sync` | `plugins/projman/commands/labels-sync.md` |
 | `/sprint-plan` | `plugins/projman/commands/sprint-plan.md` |
 | `/sprint-start` | `plugins/projman/commands/sprint-start.md` |
 | `/debug-report` | `plugins/projman/commands/debug-report.md` |
 ### Step 8: Read Relevant Files (MANDATORY)
 You MUST read the identified files before proposing any fix.
 For each relevant file:
 1. Read the file using the Read tool
 2. Find the specific function/method mentioned in the error
 3. Understand the code path that leads to the error
 4. Note any related code that might be affected
 Display snippets of relevant code to the user:
 ```
 Reading relevant files...
 ┌─ mcp-servers/gitea/mcp_server/tools/labels.py (lines 29-40) ────────┐
 │                                                                      │
 │ async def get_labels(self, repo: Optional[str] = None):              │
 │     target_repo = repo or self.gitea.repo                            │
 │     if not target_repo or '/' not in target_repo:                    │
 │         raise ValueError("Use 'owner/repo' format...")               │
 │                                                                      │
 └──────────────────────────────────────────────────────────────────────┘
 ```
 ### Step 9: Present Investigation Summary
 Summarize what you found:
 ```
 Investigation Summary
 =====================
 ISSUE: #80 - get_labels fails without repo parameter
 FAILED TOOLS:
  • get_labels - "Use 'owner/repo' format"
 CODE ANALYSIS:
 1. labels.py:get_labels() requires repo parameter
   - Line 30: `target_repo = repo or self.gitea.repo`
   - Line 31-32: Raises ValueError if no repo
 2. labels-sync.md documents Step 1 for repo detection
   - Lines 13-26: Instructs to run `git remote get-url origin`
   - This step may not be followed by executing Claude
 ROOT CAUSE HYPOTHESIS:
 The command documentation (labels-sync.md) correctly instructs
 repo detection, but the executing Claude may be skipping Step 1
 and calling MCP tools directly.
 Evidence:
  • Error indicates repo parameter was not passed
  • labels-sync.md has correct instructions
  • MCP server cannot auto-detect (sandboxed environment)
 LIKELY FIX:
 Option A: Make Step 1 more prominent in labels-sync.md
 Option B: Add validation that repo was detected before proceeding
 Option C: [Other based on analysis]
 ```
 ## APPROVAL GATE 1
 ```
 Does this analysis match your understanding of the problem?
 [Y] Yes, proceed to propose fix
 [N] No, let me clarify
 [R] Read more files first
 ```
 **STOP HERE AND WAIT FOR USER RESPONSE**
 Do NOT proceed until user approves.
 ### Step 9.5: Search Lessons Learned
 Before proposing a fix, search for relevant lessons from past fixes.
 **1. Extract search tags from the issue:**
 ```
 SEARCH_TAGS = []
 # Add tool names
 for each failed_tool in issue:
  SEARCH_TAGS.append(tool_name)  # e.g., "get_labels", "validate_repo_org"
 # Add error category
 SEARCH_TAGS.append(error_category)  # e.g., "parameter-format", "authentication"
 # Add component if identifiable
 if error relates to MCP server:
  SEARCH_TAGS.append("mcp")
 if error relates to command:
  SEARCH_TAGS.append("command")
 ```
 **2. Search lessons learned:**
 ```
 mcp__plugin_projman_gitea__search_lessons(
  repo=REPO_NAME,
  tags=SEARCH_TAGS,
  limit=5
 )
 ```
 **3. Also search by error keywords:**
 ```
 mcp__plugin_projman_gitea__search_lessons(
  repo=REPO_NAME,
  query=[key error message words],
  limit=5
 )
 ```
 **4. Display relevant lessons (if any):**
 ```
 Related Lessons Learned
 =======================
 Found [N] relevant lessons from past fixes:
 📚 Lesson: "Sprint 14 - Parameter validation in MCP tools"
   Tags: mcp, get_labels, parameter-format
   Summary: Always validate repo parameter format before API calls
   Prevention: Add format check at function entry
 📚 Lesson: "Sprint 12 - Graceful fallback for missing config"
   Tags: configuration, fallback
   Summary: Commands should work even without .env
   Prevention: Check for env vars, use sensible defaults
 These lessons may inform your fix approach.
 ```
 If no lessons found, display:
 ```
 No related lessons found. This may be a new type of issue.
 ```
 ### Step 10: Propose Fix Approach
 Based on the analysis, propose a specific fix:
 ```
 Proposed Fix
 ============
 APPROACH: [A/B/C from above]
 CHANGES NEEDED:
 1. File: plugins/projman/commands/labels-sync.md
   Change: Add warning box after Step 1 emphasizing repo must be detected
 2. File: [if applicable]
   Change: [description]
 RATIONALE:
 [Explain why this fix addresses the root cause]
 RISKS:
 [Any potential issues with this approach]
 ```
 ## APPROVAL GATE 2
 ```
 Proceed with this fix approach?
 [Y] Yes, implement it
 [N] No, try different approach
 [M] Modify the approach (tell me what to change)
 ```
 **STOP HERE AND WAIT FOR USER RESPONSE**
 Do NOT implement until user approves.
 ### Step 11: Implement Fix
 Only after user approves:
 1. Create feature branch:
 ```bash
 git checkout -b fix/issue-[NUMBER]-[brief-description]
 ```
 2. Make the code changes using Edit tool
 3. Run relevant tests if they exist:
 ```bash
 cd mcp-servers/gitea && .venv/bin/python -m pytest tests/ -v
 ```
 4. Show the changes to user:
 ```bash
 git diff
 ```
 ### Step 12: Present Changes
 ```
 Changes Implemented
 ===================
 Branch: fix/issue-80-labels-sync-instructions
 Files Modified:
  • plugins/projman/commands/labels-sync.md (+15, -3)
 Diff Summary:
 [Show git diff output]
 Test Results:
  • 23 passed, 0 failed (or N/A if no tests)
 ```
 ## APPROVAL GATE 3
 ```
 Create PR with these changes?
 [Y] Yes, create PR
 [N] No, I want to modify something
 [D] Discard changes
 ```
 **STOP HERE AND WAIT FOR USER RESPONSE**
 Do NOT create PR until user approves.
 ### Step 13: Create PR
 Only after user approves:
 1. Commit changes:
 ```bash
 git add -A
 git commit -m "fix: [description]
 [Longer explanation]
 Fixes #[ISSUE_NUMBER]
 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
 ```
 2. Push branch:
 ```bash
 git push -u origin fix/issue-[NUMBER]-[brief-description]
 ```
 3. Create PR via API or MCP tools
 4. **Switch back to development branch** (required for MCP issue operations):
 ```bash
 git checkout development
 ```
 **⚠️ IMPORTANT: Issue will NOT auto-close**
 PRs merged to `development` do NOT trigger Gitea's auto-close feature.
 Auto-close only works when merging to the default branch (`main`).
 You MUST manually close the issue in Step 15 after the PR is merged.
 5. Add comment to original issue:
 ```
 mcp__plugin_projman_gitea__add_comment(
  repo=REPO_NAME,
  issue_number=ISSUE_NUMBER,
  comment="Fix proposed in PR #[PR_NUMBER]\n\nChanges:\n- [summary]\n\nPlease test after merge and report back."
 )
 ```
 ### Step 14: Report Completion
 ```
 Debug Review Complete
 =====================
 Issue: #80 - get_labels fails without repo parameter
 Status: Fix Proposed
 PR Created: #81 - fix: improve labels-sync repo detection instructions
 URL: http://gitea.hotserv.cloud/.../pulls/81
 Next Steps:
  1. Review and merge PR #81
  2. In test project, pull latest plugin version
  3. Run /debug-report to verify fix
  4. Come back and run Step 15 to close issue and capture lesson
 ```
 ### Step 15: Verify, Close, and Capture Lesson
 **This step runs AFTER the user has verified the fix works.**
 **⚠️ MANDATORY: You MUST manually close the issue.**
 PRs merged to `development` do NOT auto-close issues (Gitea only auto-closes
 on merges to the default branch `main`). Always close manually after merge.
 When user returns and confirms the fix is working:
 **1. Close the issue (REQUIRED - won't auto-close):**
 ```
 mcp__plugin_projman_gitea__update_issue(
  repo=REPO_NAME,
  issue_number=ISSUE_NUMBER,
  state="closed"
 )
 ```
 **2. Ask about lesson capture:**
 Use AskUserQuestion:
 ```
 This fix addressed [ERROR_TYPE] in [COMPONENT].
 Would you like to capture this as a lesson learned?
 Options:
 - Yes, capture lesson (helps avoid similar issues in future)
 - No, skip (trivial fix or already documented)
 ```
 **3. If user chooses Yes, auto-generate lesson content:**
 ```
 LESSON_TITLE = "Sprint [N] - [Brief description of fix]"
  # Example: "Sprint 17 - MCP parameter validation"
 LESSON_CONTENT = """
 ## Context
 [What was happening when the issue occurred]
 - Command/tool being used: [FAILED_TOOL]
 - Error encountered: [ERROR_MESSAGE]
 ## Problem
 [Root cause identified during investigation]
 ## Solution
 [What was changed to fix it]
 - Files modified: [LIST]
 - PR: #[PR_NUMBER]
 ## Prevention
 [How to avoid this in the future]
 ## Related
 - Issue: #[ISSUE_NUMBER]
 - PR: #[PR_NUMBER]
 """
 LESSON_TAGS = [
  tool_name,        # e.g., "get_labels"
  error_category,   # e.g., "parameter-format"
  component,        # e.g., "mcp", "command"
  "bug-fix"
 ]
 ```
 **4. Show lesson preview and ask for approval:**
 ```
 Lesson Preview
 ==============
 Title: [LESSON_TITLE]
 Tags: [LESSON_TAGS]
 Content:
 [LESSON_CONTENT]
 Save this lesson? (Y/N/Edit)
 ```
 **5. If approved, create the lesson:**
 ```
 mcp__plugin_projman_gitea__create_lesson(
  repo=REPO_NAME,
  title=LESSON_TITLE,
  content=LESSON_CONTENT,
  tags=LESSON_TAGS,
  category="sprints"
 )
 ```
 **6. Report completion:**
 ```
 Issue Closed & Lesson Captured
 ==============================
 Issue #[N]: CLOSED
 Lesson: "[LESSON_TITLE]" saved to wiki
 This lesson will be surfaced in future /debug-review
 sessions when similar errors are encountered.
 ```
 ## DO NOT
 - **DO NOT** skip reading relevant files - this is MANDATORY
 - **DO NOT** proceed past approval gates without user confirmation
 - **DO NOT** guess at fixes without evidence from code
 - **DO NOT** close issues until user confirms fix works (Step 15)
 - **DO NOT** commit directly to development or main branches
 - **DO NOT** skip the lessons learned search - past fixes inform better solutions
 ## If Investigation Finds No Bug
 Sometimes investigation reveals the issue is:
 - User error (didn't follow documented steps)
 - Configuration issue (missing .env vars)
 - Already fixed in a newer version
 In this case:
 ```
 Investigation Summary
 =====================
 FINDING: This does not appear to be a code bug.
 ANALYSIS:
 [Explanation of what you found]
 RECOMMENDATION:
 [ ] Close issue as "not a bug" - user error
 [ ] Close issue as "duplicate" of #[X]
 [ ] Add documentation to prevent confusion
 [ ] Other: [specify]
 Would you like me to add a comment explaining this finding?
 ```
 ## Error-to-File Quick Reference
 ```
 Error Message                    → File to Check
 ─────────────────────────────────────────────────────────────────
 "Use 'owner/repo' format"        → config.py, gitea_client.py
 "404 Client Error.*orgs"         → gitea_client.py (_is_organization)
 "No repository specified"        → Command .md file (Step 1)
 "401 Unauthorized"               → config.py (token loading)
 "labels not found"               → labels.py, gitea_client.py
 "create local.*file"             → Command .md file (DO NOT section)
 ```
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Debug Review                                                    ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the investigation workflow.
--- a/plugins/projman/commands/debug.md
+++ b/plugins/projman/commands/debug.md
@@ -0,0 +1,162 @@
 ---
 description: Diagnose issues and create reports, or investigate existing diagnostic issues
 ---
 # Debug
 ## Skills Required
 - skills/mcp-tools-reference.md
 - skills/lessons-learned.md
 - skills/git-workflow.md
 ## Purpose
 Unified debugging command for diagnostics and issue investigation.
 ## Invocation
 ```
 /debug              # Ask which mode
 /debug report       # Run diagnostics, create issue
 /debug review       # Investigate existing issues
 ```
 ## Mode Selection
 If no subcommand provided, ask user:
 1. **Report** - Run MCP tool diagnostics and create issue in marketplace
 2. **Review** - Investigate existing diagnostic issues and propose fixes
 ---
 ## Mode: Report
 Create structured issues in the marketplace repository.
 ### Prerequisites
 Project `.env` must have:
 ```env
 PROJMAN_MARKETPLACE_REPO=personal-projects/leo-claude-mktplace
 ```
 ### Workflow
 #### Step 0: Select Report Type
 - **Automated** - Run MCP tool diagnostics and report failures
 - **User-Reported** - Gather structured feedback about a problem
 #### For User-Reported (Step 0.1)
 Gather via AskUserQuestion:
 1. Which plugin/command was affected
 2. What was the goal
 3. What type of problem (error, missing feature, unexpected behavior, docs)
 4. Problem description
 5. Expected behavior
 6. Workaround (optional)
 #### Steps 1-2: Context Gathering
 1. Gather project context (git remote, branch, pwd)
 2. Detect sprint context (active milestone)
 3. Read marketplace config
 #### Steps 3-4: Diagnostic Suite (Automated Only)
 Run MCP tools with explicit `repo` parameter:
 - `validate_repo_org`
 - `get_labels`
 - `list_issues`
 - `list_milestones`
 - `suggest_labels`
 Categorize: Parameter Format, Authentication, Not Found, Network, Logic
 #### Steps 5-6: Generate Labels and Issue
 **Automated:** `Type/Bug`, `Source/Diagnostic`, `Agent/Claude` + suggested
 **User-Reported:** Map problem type to labels
 #### Step 7: Create Issue
 **Use curl (not MCP)** - avoids branch protection issues
 #### Step 8: Report to User
 Show summary and link to created issue
 ### DO NOT (Report Mode)
 - Attempt to fix anything - only report
 - Create issues if all automated tests pass (unless user-reported)
 - Use MCP tools to create issues in marketplace - always use curl
 ---
 ## Mode: Review
 Investigate diagnostic issues and propose fixes with human approval.
 ### Workflow with Approval Gates
 #### Steps 1-8: Investigation
 1. Detect repository (git remote)
 2. Fetch diagnostic issues: `list_issues(labels=["Source: Diagnostic"])`
 3. Display issue list
 4. User selects issue (AskUserQuestion)
 5. Fetch full details: `get_issue(issue_number=...)`
 6. Parse diagnostic report (failed tools, errors, hypothesis)
 7. Map errors to files
 8. Read relevant files - **MANDATORY before proposing fix**
 #### Step 9: Investigation Summary
 Present analysis to user.
 **APPROVAL GATE 1:** "Does this analysis match your understanding?"
 - STOP and wait for user response
 #### Step 9.5: Search Lessons Learned
 Search for related past fixes using `search_lessons`.
 #### Step 10: Propose Fix
 Present specific fix approach with changes and rationale.
 **APPROVAL GATE 2:** "Proceed with this fix?"
 - STOP and wait for user response
 #### Steps 11-12: Implement
 1. Create feature branch (`fix/issue-N-description`)
 2. Make code changes
 3. Run tests
 4. Show diff to user
 **APPROVAL GATE 3:** "Create PR with these changes?"
 - STOP and wait for user response
 #### Steps 13-15: Finalize
 13. Commit and push
 14. Create PR
 15. After user verifies fix: Close issue (REQUIRED) and capture lesson
 ### Error-to-File Quick Reference
 | Error Pattern | Check Files |
 |---------------|-------------|
 | "owner/repo format" | config.py, gitea_client.py |
 | "404" + "orgs" | gitea_client.py |
 | "401", "403" | config.py (token) |
 | "No repository" | Command .md file |
 ### DO NOT (Review Mode)
 - Skip reading relevant files
 - Proceed past approval gates without confirmation
 - Close issues until user confirms fix works
 - Commit directly to development/main
 ---
 ## Visual Output
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🔧 DEBUG                                                        ║
 ║  [Mode: Report | Review]                                         ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
--- a/plugins/projman/commands/initial-setup.md
+++ b/plugins/projman/commands/initial-setup.md
@@ -1,477 +0,0 @@
 ---
 description: Interactive setup wizard for projman plugin - configures MCP servers, credentials, and project settings
 ---
 # Initial Setup Wizard
 This command guides the user through complete projman setup interactively. It handles both first-time marketplace setup and per-project configuration.
 ## Important Context
 - **This command uses Bash, Read, Write, and AskUserQuestion tools** - NOT MCP tools
 - **MCP tools won't work until after setup + session restart**
 - **Tokens must be entered manually by the user** for security (not typed into chat)
 ---
 ## Quick Path Detection
 **FIRST**, check if system-level setup is already complete:
 ```bash
 cat ~/.config/claude/gitea.env 2>/dev/null | grep -v "^#" | grep -v "PASTE_YOUR" | grep -v "example.com" | grep "GITEA_API_TOKEN=" && echo "SYSTEM_CONFIGURED" || echo "SYSTEM_NEEDS_SETUP"
 ```
 **If SYSTEM_CONFIGURED:**
 The system-level configuration already exists. Offer the user a choice:
 Use AskUserQuestion:
 - Question: "System configuration found. What would you like to do?"
 - Header: "Setup Mode"
 - Options:
  - "Quick project setup only (Recommended for new projects)"
  - "Full setup (re-check everything)"
 **If "Quick project setup":**
 - Skip directly to **Phase 4: Project-Level Configuration**
 - This is equivalent to running `/project-init`
 **If "Full setup":**
 - Continue with Phase 1 below
 **If SYSTEM_NEEDS_SETUP:**
 - Continue with Phase 1 (full setup required)
 ---
 ## Phase 1: Environment Validation
 ### Step 1.1: Check Python Version
 Run this command to verify Python 3.10+ is available:
 ```bash
 python3 --version
 ```
 **If version is below 3.10:**
 - Stop setup and inform user: "Python 3.10 or higher is required. Please install it and run /initial-setup again."
 - Provide installation hints based on OS (apt, brew, etc.)
 **If successful:** Continue to next step.
 ---
 ## Phase 2: MCP Server Setup
 ### Step 2.1: Locate the Plugin Installation
 The plugin is installed somewhere on the system. Find the MCP server directory by resolving the path.
 First, identify where this plugin is installed. The MCP server should be accessible via the symlink structure. Look for the gitea MCP server:
 ```bash
 # Find the plugin's mcp-servers directory (search common locations)
 find ~/.claude ~/.config/claude -name "mcp_server" -path "*gitea*" 2>/dev/null | head -5
 ```
 If found, extract the parent path (the gitea MCP server root).
 **Alternative:** If the user knows the marketplace location, ask them:
 Use AskUserQuestion:
 - Question: "Where is the Leo Claude Marketplace installed?"
 - Options:
  - "~/.claude/plugins/leo-claude-mktplace" (default Claude plugins location)
  - "Let me find it automatically"
  - Other (user provides path)
 ### Step 2.2: Check if Virtual Environment Exists
 Once you have the MCP server path (e.g., `/path/to/mcp-servers/gitea`), check for the venv:
 ```bash
 ls -la /path/to/mcp-servers/gitea/.venv/bin/python 2>/dev/null && echo "VENV_EXISTS" || echo "VENV_MISSING"
 ```
 ### Step 2.3: Create Virtual Environment (if missing)
 If venv doesn't exist:
 ```bash
 cd /path/to/mcp-servers/gitea && python3 -m venv .venv
 ```
 Then install dependencies:
 ```bash
 cd /path/to/mcp-servers/gitea && source .venv/bin/activate && pip install --upgrade pip && pip install -r requirements.txt && deactivate
 ```
 **If pip install fails:**
 - Show the error to the user
 - Suggest: "Check your internet connection and try again. You can also manually run: `cd /path/to/mcp-servers/gitea && source .venv/bin/activate && pip install -r requirements.txt`"
 ### Step 2.4: NetBox MCP Server (Optional)
 Check if the user wants to set up the NetBox MCP server (for cmdb-assistant plugin):
 Use AskUserQuestion:
 - Question: "Do you want to set up the NetBox MCP server for infrastructure management?"
 - Options:
  - "Yes, set up NetBox MCP"
  - "No, skip NetBox (Recommended if not using cmdb-assistant)"
 If yes, repeat steps 2.2-2.3 for `/path/to/mcp-servers/netbox`.
 ---
 ## Phase 3: System-Level Configuration
 System configuration is stored in `~/.config/claude/` and contains credentials that work across all projects.
 ### Step 3.1: Create Config Directory
 ```bash
 mkdir -p ~/.config/claude
 ```
 ### Step 3.2: Check Gitea Configuration
 ```bash
 cat ~/.config/claude/gitea.env 2>/dev/null || echo "FILE_NOT_FOUND"
 ```
 **If file doesn't exist:** Go to Step 3.3 (Create Template)
 **If file exists:** Read it and check if values are placeholders (contain "example.com" or "your_" or "token_here"). If placeholders, go to Step 3.4 (Update Existing).
 **If file has real values:** Go to Step 3.5 (Validate).
 ### Step 3.3: Create Gitea Configuration Template
 Gather the Gitea server URL from the user.
 Use AskUserQuestion:
 - Question: "What is your Gitea server URL? (e.g., https://gitea.company.com)"
 - Header: "Gitea URL"
 - Options:
  - "https://gitea.hotserv.cloud" (if this is Leo's setup)
  - "Other (I'll provide the URL)"
 If "Other", ask the user to type the URL.
 Now create the configuration file with a placeholder for the token:
 ```bash
 cat > ~/.config/claude/gitea.env << 'EOF'
 # Gitea API Configuration
 # Generated by /initial-setup
 # Note: GITEA_ORG is configured per-project in .env
 GITEA_API_URL=<USER_PROVIDED_URL>
 GITEA_API_TOKEN=PASTE_YOUR_TOKEN_HERE
 EOF
 chmod 600 ~/.config/claude/gitea.env
 ```
 Replace `<USER_PROVIDED_URL>` with the actual value from the user.
 ### Step 3.4: Token Entry Instructions
 **CRITICAL: Do not ask the user to type the token into chat.**
 Display these instructions clearly:
 ---
 **Action Required: Add Your Gitea API Token**
 I've created the configuration file at `~/.config/claude/gitea.env` but you need to add your API token manually for security.
 **Steps:**
 1. Open the file in your editor:
   ```
   nano ~/.config/claude/gitea.env
   ```
   Or use any editor you prefer.
 2. Generate a Gitea token (if you don't have one):
   - Go to your Gitea instance → User Icon → Settings
   - Click "Applications" tab
   - Under "Manage Access Tokens", click "Generate New Token"
   - Name it something like "claude-code"
   - Select permissions: `repo` (all), `read:org`, `read:user`
   - Click "Generate Token" and copy it immediately
 3. Replace `PASTE_YOUR_TOKEN_HERE` with your actual token
 4. Save the file
 ---
 Use AskUserQuestion:
 - Question: "Have you added your Gitea token to ~/.config/claude/gitea.env?"
 - Header: "Token Added?"
 - Options:
  - "Yes, I've added the token"
  - "I need help generating a token"
  - "Skip for now (I'll do it later)"
 **If "I need help":** Provide detailed instructions for their specific Gitea instance.
 **If "Skip":** Warn that MCP tools won't work until configured, but continue with project setup.
 ### Step 3.5: Validate Gitea Configuration
 Read the config file and verify it has non-placeholder values:
 ```bash
 source ~/.config/claude/gitea.env && echo "URL: $GITEA_API_URL" && echo "TOKEN_LENGTH: ${#GITEA_API_TOKEN}"
 ```
 If TOKEN_LENGTH is less than 10 or contains "PASTE" or "your_", the token hasn't been set properly.
 **Note:** GITEA_ORG is configured per-project in `.env`, not in the system-level config.
 **Test connectivity (optional but recommended):**
 ```bash
 source ~/.config/claude/gitea.env && curl -s -o /dev/null -w "%{http_code}" -H "Authorization: token $GITEA_API_TOKEN" "$GITEA_API_URL/user"
 ```
 - **200:** Success! Credentials are valid.
 - **401:** Invalid token.
 - **404/Connection error:** Invalid URL or network issue.
 Report the result to the user.
 ### Step 3.6: Git-Flow Configuration (Optional)
 Use AskUserQuestion:
 - Question: "Do you want to configure git-flow defaults for smart commits?"
 - Header: "Git-Flow"
 - Options:
  - "Yes, use recommended defaults (Recommended)"
  - "Yes, let me customize"
  - "No, skip git-flow configuration"
 If yes with defaults:
 ```bash
 cat > ~/.config/claude/git-flow.env << 'EOF'
 # Git-Flow Default Configuration
 GIT_WORKFLOW_STYLE=feature-branch
 GIT_DEFAULT_BASE=development
 GIT_AUTO_DELETE_MERGED=true
 GIT_AUTO_PUSH=false
 GIT_PROTECTED_BRANCHES=main,master,development,staging,production
 GIT_COMMIT_STYLE=conventional
 GIT_CO_AUTHOR=true
 EOF
 chmod 600 ~/.config/claude/git-flow.env
 ```
 If customize, use AskUserQuestion for each setting.
 ---
 ## Phase 4: Project-Level Configuration
 Project configuration is stored in `.env` in the current project root.
 ### Step 4.1: Verify Current Directory
 Confirm we're in the right place:
 ```bash
 pwd && git rev-parse --show-toplevel 2>/dev/null || echo "NOT_A_GIT_REPO"
 ```
 If not a git repo, ask the user:
 Use AskUserQuestion:
 - Question: "The current directory doesn't appear to be a git repository. Where should I create the project configuration?"
 - Options:
  - "This directory is correct, continue anyway"
  - "Let me navigate to the right directory first"
 ### Step 4.2: Check Existing Project Configuration
 ```bash
 cat .env 2>/dev/null || echo "FILE_NOT_FOUND"
 ```
 If `.env` exists and has `GITEA_REPO=` set to a non-placeholder value, skip to Phase 5.
 ### Step 4.3: Infer Organization and Repository from Git Remote
 Try to detect org and repo name automatically:
 ```bash
 git remote get-url origin 2>/dev/null
 ```
 Parse the output to extract both organization and repository:
 - `git@gitea.example.com:org/repo-name.git` → org: `org`, repo: `repo-name`
 - `https://gitea.example.com/org/repo-name.git` → org: `org`, repo: `repo-name`
 Extract organization:
 ```bash
 git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\)\/[^/]*$/\1/'
 ```
 Extract repository:
 ```bash
 git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\)\.git$/\1/' | sed 's/.*\/\([^/]*\)$/\1/'
 ```
 ### Step 4.4: Validate Repository via Gitea API
 **Before asking for confirmation**, verify the repository exists and is accessible:
 ```bash
 source ~/.config/claude/gitea.env
 curl -s -o /dev/null -w "%{http_code}" -H "Authorization: token $GITEA_API_TOKEN" "$GITEA_API_URL/repos/<detected-org>/<detected-repo>"
 ```
 **Based on response:**
 | HTTP Code | Meaning | Action |
 |-----------|---------|--------|
 | **200** | Repository exists and accessible | **Auto-fill without asking** - skip to Step 4.7 |
 | **404** | Repository not found | Ask user to confirm/correct (Step 4.5) |
 | **401/403** | Token issue or no access | Warn about permissions, ask to confirm |
 | **Other** | Network/server issue | Warn, ask to confirm manually |
 **If 200 OK:** Display confirmation message and skip to Step 4.7:
 "Verified: Repository '<detected-org>/<detected-repo>' exists and is accessible."
 ### Step 4.5: Confirm Organization (only if API validation failed)
 Use AskUserQuestion:
 - Question: "Repository '<detected-org>/<detected-repo>' was not found. Is '<detected-org>' the correct organization?"
 - Header: "Organization"
 - Options:
  - "Yes, that's correct"
  - "No, let me specify the correct organization"
 If no, ask user to provide the correct organization name.
 ### Step 4.6: Confirm Repository Name (only if API validation failed)
 Use AskUserQuestion:
 - Question: "Is '<detected-repo-name>' the correct Gitea repository name?"
 - Header: "Repository"
 - Options:
  - "Yes, that's correct"
  - "No, let me specify the correct name"
 If no, ask user to provide the correct name.
 **After user provides corrections, re-validate via API (Step 4.4)** to ensure the corrected values are valid.
 ### Step 4.7: Create Project Configuration
 ```bash
 cat > .env << 'EOF'
 # Project Configuration for projman
 # Generated by /initial-setup
 GITEA_ORG=<ORG_NAME>
 GITEA_REPO=<REPO_NAME>
 EOF
 ```
 Replace `<REPO_NAME>` with the confirmed value.
 **Important:** Check if `.env` is in `.gitignore`:
 ```bash
 grep -q "^\.env$" .gitignore 2>/dev/null && echo "GITIGNORE_OK" || echo "GITIGNORE_MISSING"
 ```
 If not in `.gitignore`, warn the user:
 "Warning: `.env` is not in your `.gitignore`. Consider adding it to prevent accidentally committing credentials."
 ---
 ## Phase 5: Final Validation and Next Steps
 ### Step 5.1: Summary Report
 Display a summary of what was configured:
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║                    SETUP COMPLETE                            ║
 ╠══════════════════════════════════════════════════════════════╣
 ║ MCP Server (Gitea):     ✓ Installed                          ║
 ║ System Config:          ✓ ~/.config/claude/gitea.env         ║
 ║ Project Config:         ✓ ./.env                             ║
 ║ Gitea Connection:       ✓ Verified (or ⚠ Not tested)         ║
 ╚══════════════════════════════════════════════════════════════╝
 ```
 ### Step 5.2: Session Restart Notice
 **IMPORTANT:** Display this notice clearly:
 ---
 **⚠️ Session Restart Required**
 The MCP server has been configured but won't be available until you restart your Claude Code session.
 **To complete setup:**
 1. Exit this Claude Code session (type `/exit` or close the terminal)
 2. Start a new Claude Code session in this project
 3. The Gitea MCP tools will now be available
 **After restart, you can:**
 - Run `/labels-sync` to sync your label taxonomy
 - Run `/sprint-plan` to start planning
 - Use MCP tools like `list_issues`, `create_issue`, etc.
 ---
 ### Step 5.3: Troubleshooting Checklist
 If something isn't working after restart, check:
 1. **MCP server not found:** Verify venv exists at the expected path
 2. **Authentication failed:** Re-check token in `~/.config/claude/gitea.env`
 3. **Wrong repository:** Verify `GITEA_REPO` in `./.env` matches Gitea exactly
 4. **Network error:** Ensure Gitea URL is accessible from this machine
 ---
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  ⚙️ SETUP                                                        ║
 ║  Initial Setup Wizard                                            ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the setup workflow.
 ## Re-Running This Command
 This command is safe to run multiple times:
 - Existing venvs are skipped (not recreated)
 - Existing config files are checked for validity
 - Only missing or placeholder values are updated
 - Project config can be regenerated for new projects
 ---
 ## Quick Reference: Files Created
 | File | Purpose | Contains |
 |------|---------|----------|
 | `~/.config/claude/gitea.env` | System credentials | URL, token, org |
 | `~/.config/claude/git-flow.env` | Git defaults | Workflow settings |
 | `./.env` | Project settings | Repository name |
 | `<mcp-server>/.venv/` | Python environment | Dependencies |
--- a/plugins/projman/commands/labels-sync.md
+++ b/plugins/projman/commands/labels-sync.md
@@ -2,179 +2,52 @@
 description: Fetch and validate label taxonomy from Gitea, create missing required labels
 ---
-# Sync Label Taxonomy from Gitea
+# Sync Label Taxonomy
-This command fetches the current label taxonomy from Gitea (organization + repository labels), validates that required labels exist, and creates any missing ones.
+## Skills Required
-## CRITICAL: Execution Steps
+- skills/mcp-tools-reference.md
 - skills/repo-validation.md
 - skills/label-taxonomy/labels-reference.md
-You MUST follow these steps in order. Do NOT skip any step.
+## Purpose
-### Step 1: Detect Repository from Git Remote
+Fetch current label taxonomy from Gitea, validate required labels exist, and create any missing ones.
-Run this Bash command to get the git remote URL:
+## Invocation
-```bash
+Run `/labels-sync` when setting up the plugin or after taxonomy updates.
 git remote get-url origin
 ```
-Parse the output to extract `owner/repo`:
+## Workflow
 - SSH format `ssh://git@host:port/owner/repo.git` → extract `owner/repo`
 - SSH short `git@host:owner/repo.git` → extract `owner/repo`
 - HTTPS `https://host/owner/repo.git` → extract `owner/repo`
-Store this as `REPO_NAME` for all subsequent MCP calls.
+1. **Detect Repository** - Parse `git remote get-url origin` to get `owner/repo`
 2. **Validate Repository** - Use `validate_repo_org` to check if org-owned
 3. **Fetch Labels** - Use `get_labels(repo=...)` to get org + repo labels
 4. **Display Taxonomy** - Show labels grouped by category
 5. **Check Required Labels** - Verify Type/*, Priority/*, Complexity/*, Effort/* exist
 6. **Create Missing** - Use `create_label_smart` which auto-detects org vs repo level
 7. **Report Results** - Summarize what was found and created
-### Step 2: Validate Repository Organization
+## Required Label Categories
-Call MCP tool with the detected repo:
+| Category | Required Labels |
-
+|----------|-----------------|
-```
+| Type/* | Bug, Feature, Refactor, Documentation, Test, Chore |
-mcp__plugin_projman_gitea__validate_repo_org(repo=REPO_NAME)
+| Priority/* | Low, Medium, High, Critical |
-```
+| Complexity/* | Simple, Medium, Complex |
-
+| Efforts/* | XS, S, M, L, XL |
 This determines if the owner is an organization or user account.
 ### Step 3: Fetch Labels from Gitea
 Call MCP tool with the detected repo:
 ```
 mcp__plugin_projman_gitea__get_labels(repo=REPO_NAME)
 ```
 This returns both organization labels (if org-owned) and repository labels.
 ### Step 4: Display Current Taxonomy
 Show the user:
 - Total organization labels count
 - Total repository labels count
 - Labels grouped by category (Type/*, Priority/*, etc.)
 ### Step 5: Check Required Labels
 Verify these required label categories exist:
 - **Type/***: Bug, Feature, Refactor, Documentation, Test, Chore
 - **Priority/***: Low, Medium, High, Critical
 - **Complexity/***: Simple, Medium, Complex
 - **Effort/***: XS, S, M, L, XL (note: may be "Effort" or "Efforts")
 ### Step 6: Create Missing Labels (if any)
 Use `create_label_smart` which automatically creates labels at the correct level:
 - **Organization level**: Type/*, Priority/*, Complexity/*, Effort/*, Risk/*, Source/*, Agent/*
 - **Repository level**: Component/*, Tech/*
 ```
 mcp__plugin_projman_gitea__create_label_smart(repo=REPO_NAME, name="Type/Bug", color="d73a4a")
 ```
 This automatically detects whether to create at org or repo level based on the category.
 **Alternative (explicit control):**
 - Org labels: `create_org_label(org="org-name", name="Type/Bug", color="d73a4a")`
 - Repo labels: `create_label(repo=REPO_NAME, name="Component/Backend", color="5319e7")`
 Use the label format that matches existing labels in the repo (slash `/` or colon-space `: `).
 ### Step 7: Report Results
 Summarize what was found and created.
 ## DO NOT
- **DO NOT** call MCP tools without the `repo` parameter - they will fail
+- Call MCP tools without the `repo` parameter
- **DO NOT** create any local files - this command only interacts with Gitea
+- Create local files - this command only interacts with Gitea
- **DO NOT** ask the user questions - execute autonomously
+- Ask user questions - execute autonomously
 - **DO NOT** create a "labels reference file" - labels are fetched dynamically from Gitea
 ## MCP Tools Used
 All tools require the `repo` parameter in `owner/repo` format:
 | Tool | Purpose |
 |------|---------|
 | `validate_repo_org(repo=...)` | Check if owner is organization or user |
 | `get_labels(repo=...)` | Fetch all labels (org + repo) |
 | `create_label(repo=..., name=..., color=...)` | Create missing labels |
 ## Expected Output
 ```
 Label Taxonomy Sync
 ===================
 Detecting repository from git remote...
 Repository: personal-projects/your-repo-name
 Owner type: Organization
 Fetching labels from Gitea...
 Current Label Taxonomy:
 - Organization Labels: 27
 - Repository Labels: 16
 - Total: 43 labels
 Organization Labels by Category:
  Type/*: 6 labels
  Priority/*: 4 labels
  Complexity/*: 3 labels
  Effort/*: 5 labels
  ...
 Repository Labels by Category:
  Component/*: 9 labels
  Tech/*: 7 labels
 Required Labels Check:
  Type/*: 6/6 present ✓
  Priority/*: 4/4 present ✓
  Complexity/*: 3/3 present ✓
  Effort/*: 5/5 present ✓
 All required labels present. Label taxonomy is ready for use.
 ```
 ## Label Format Detection
 Labels may use different naming conventions:
 - Slash format: `Type/Bug`, `Priority/High`
 - Colon-space format: `Type: Bug`, `Priority: High`
 When creating missing labels, match the format used by existing labels in the repository.
 ## Troubleshooting
 **Error: Use 'owner/repo' format**
 - You forgot to pass the `repo` parameter to the MCP tool
 - Go back to Step 1 and detect the repo from git remote
 **Empty organization labels**
 - If owner is a user account (not org), organization labels will be empty
 - This is expected - user accounts only have repository-level labels
 **Git remote not found**
 - Ensure you're running in a directory with a git repository
 - Check that the `origin` remote is configured
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Labels Sync                                                     ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the sync workflow.
 ## When to Run
 Run `/labels-sync` when:
 - Setting up the plugin for the first time
 - You notice missing labels in suggestions
 - New labels are added to Gitea
 - After major taxonomy updates
--- a/plugins/projman/commands/project-init.md
+++ b/plugins/projman/commands/project-init.md
@@ -1,232 +0,0 @@
 ---
 description: Quick project setup - configures only project-level settings (assumes system setup is complete)
 ---
 # Project Initialization
 Fast setup for a new project when system-level configuration is already complete.
 **Use this when:**
 - You've already run `/initial-setup` on this machine
 - You're starting work on a new project/repository
 - You just need to create the project `.env` file
 **Use `/initial-setup` instead if:**
 - This is your first time using the plugin
 - MCP tools aren't working (might need system setup)
 ---
 ## Pre-Flight Check
 ### Step 1: Verify System Configuration Exists
 Quickly verify system setup is complete:
 ```bash
 cat ~/.config/claude/gitea.env 2>/dev/null | grep -v "^#" | grep -v "PASTE_YOUR" | grep "GITEA_API_TOKEN=" && echo "SYSTEM_OK" || echo "SYSTEM_MISSING"
 ```
 **If SYSTEM_MISSING:**
 Display this message and stop:
 ---
 **System configuration not found or incomplete.**
 It looks like the system-level setup hasn't been completed yet. Please run:
 ```
 /initial-setup
 ```
 This will configure both system credentials and this project.
 ---
 **If SYSTEM_OK:** Continue to project setup.
 ---
 ## Project Setup
 ### Step 2: Verify Current Directory
 ```bash
 pwd && git rev-parse --show-toplevel 2>/dev/null || echo "NOT_A_GIT_REPO"
 ```
 If not a git repo, ask:
 Use AskUserQuestion:
 - Question: "This doesn't appear to be a git repository. Continue anyway?"
 - Header: "Directory"
 - Options:
  - "Yes, continue here"
  - "No, I'll navigate to the correct directory"
 ### Step 3: Check for Existing Configuration
 ```bash
 cat .env 2>/dev/null | grep "GITEA_REPO=" || echo "NOT_CONFIGURED"
 ```
 **If already configured:**
 Use AskUserQuestion:
 - Question: "This project already has GITEA_ORG and GITEA_REPO configured. What would you like to do?"
 - Header: "Existing"
 - Options:
  - "Keep existing configuration"
  - "Reconfigure (replace current settings)"
 **If "Keep":** End with success message.
 ### Step 4: Detect Organization and Repository
 Try to auto-detect from git remote:
 ```bash
 git remote get-url origin 2>/dev/null
 ```
 Extract organization:
 ```bash
 git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\)\/[^/]*$/\1/'
 ```
 Extract repository:
 ```bash
 git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\)\.git$/\1/' | sed 's/.*\/\([^/]*\)$/\1/'
 ```
 ### Step 5: Validate Repository via Gitea API
 Verify the repository exists and is accessible:
 ```bash
 source ~/.config/claude/gitea.env
 curl -s -o /dev/null -w "%{http_code}" -H "Authorization: token $GITEA_API_TOKEN" "$GITEA_API_URL/repos/<detected-org>/<detected-repo>"
 ```
 | HTTP Code | Action |
 |-----------|--------|
 | **200** | Auto-fill - display "Verified: <org>/<repo> exists" and skip to Step 8 |
 | **404** | Repository not found - proceed to Step 6 |
 | **401/403** | Permission issue - warn and proceed to Step 6 |
 ### Step 6: Confirm Organization (only if API validation failed)
 Use AskUserQuestion:
 - Question: "Repository not found. Is '<detected-org>' the correct organization?"
 - Header: "Organization"
 - Options:
  - "Yes, that's correct"
  - "No, let me specify"
 If "No", ask user to type the correct organization name.
 ### Step 7: Confirm Repository Name (only if API validation failed)
 Use AskUserQuestion:
 - Question: "Is '<detected-repo-name>' the correct repository name?"
 - Header: "Repository"
 - Options:
  - "Yes, that's correct"
  - "No, let me specify"
 If "No", ask user to type the correct name.
 **After corrections, re-validate via API (Step 5).**
 ### Step 8: Create/Update Project Configuration
 **If `.env` exists:**
 Check if it already has other content and append:
 ```bash
 echo "" >> .env
 echo "# Added by /project-init" >> .env
 echo "GITEA_ORG=<ORG_NAME>" >> .env
 echo "GITEA_REPO=<REPO_NAME>" >> .env
 ```
 **If `.env` doesn't exist:**
 ```bash
 cat > .env << 'EOF'
 # Project Configuration for projman
 # Generated by /project-init
 GITEA_ORG=<ORG_NAME>
 GITEA_REPO=<REPO_NAME>
 EOF
 ```
 ### Step 9: Check .gitignore
 ```bash
 grep -q "^\.env$" .gitignore 2>/dev/null && echo "GITIGNORE_OK" || echo "GITIGNORE_MISSING"
 ```
 **If GITIGNORE_MISSING:**
 Use AskUserQuestion:
 - Question: "`.env` is not in `.gitignore`. Add it to prevent committing secrets?"
 - Header: "gitignore"
 - Options:
  - "Yes, add .env to .gitignore (Recommended)"
  - "No, I'll handle it manually"
 If yes:
 ```bash
 echo ".env" >> .gitignore
 ```
 ---
 ## Complete
 Display success message:
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║                   PROJECT CONFIGURED                         ║
 ╠══════════════════════════════════════════════════════════════╣
 ║ Organization:  <ORG_NAME>                                    ║
 ║ Repository:    <REPO_NAME>                                   ║
 ║ Config file:   ./.env                                        ║
 ╚══════════════════════════════════════════════════════════════╝
 You're ready to use projman commands:
 • /sprint-plan    - Start sprint planning
 • /sprint-status  - Check progress
 • /labels-sync    - Sync label taxonomy
 ```
 ---
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  ⚙️ SETUP                                                        ║
 ║  Project Initialization                                          ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the project setup workflow.
 ## Troubleshooting
 **MCP tools not working?**
 - Run `/initial-setup` for full setup including MCP server
 - Restart your Claude Code session after setup
 **Wrong repository configured?**
 - Edit `.env` directly: `nano .env`
 - Or run `/project-init` again and choose "Reconfigure"
--- a/plugins/projman/commands/project-sync.md
+++ b/plugins/projman/commands/project-sync.md
@@ -1,210 +0,0 @@
 ---
 description: Sync project configuration with current git remote - use after changing repository location or organization
 ---
 # Project Sync
 Updates project configuration when the git remote URL has changed (repository moved, renamed, or organization changed).
 **Use this when:**
 - You moved the repository to a different organization
 - You renamed the repository
 - You changed the git remote URL
 - The SessionStart hook detected a mismatch
 ---
 ## Step 1: Verify System Configuration
 ```bash
 cat ~/.config/claude/gitea.env 2>/dev/null | grep -v "^#" | grep -v "PASTE_YOUR" | grep "GITEA_API_TOKEN=" && echo "SYSTEM_OK" || echo "SYSTEM_MISSING"
 ```
 **If SYSTEM_MISSING:** Stop and instruct user to run `/initial-setup` first.
 ---
 ## Step 2: Read Current Configuration
 Read the current .env values:
 ```bash
 cat .env 2>/dev/null
 ```
 Extract current values:
 - `CURRENT_ORG` from `GITEA_ORG=...`
 - `CURRENT_REPO` from `GITEA_REPO=...`
 **If .env doesn't exist or has no GITEA values:** Redirect to `/project-init`.
 ---
 ## Step 3: Detect Git Remote Values
 Get the current git remote:
 ```bash
 git remote get-url origin 2>/dev/null
 ```
 Extract organization:
 ```bash
 git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\)\/[^/]*$/\1/'
 ```
 Extract repository:
 ```bash
 git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\)\.git$/\1/' | sed 's/.*\/\([^/]*\)$/\1/'
 ```
 ---
 ## Step 4: Compare Values
 Compare current .env values with detected git remote values:
 | Scenario | Action |
 |----------|--------|
 | **Both match** | Display "Configuration is in sync" and exit |
 | **Organization changed** | Proceed to Step 5 |
 | **Repository changed** | Proceed to Step 5 |
 | **Both changed** | Proceed to Step 5 |
 **If already in sync:**
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║                  CONFIGURATION IN SYNC                       ║
 ╠══════════════════════════════════════════════════════════════╣
 ║ Organization:  <ORG_NAME>                                    ║
 ║ Repository:    <REPO_NAME>                                   ║
 ║ Git Remote:    matches .env                                  ║
 ╚══════════════════════════════════════════════════════════════╝
 ```
 Exit here if in sync.
 ---
 ## Step 5: Show Detected Changes
 Display the detected changes to the user:
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║               REPOSITORY CHANGE DETECTED                     ║
 ╠══════════════════════════════════════════════════════════════╣
 ║                    Current .env    │    Git Remote           ║
 ║ Organization:      <OLD_ORG>       │    <NEW_ORG>            ║
 ║ Repository:        <OLD_REPO>      │    <NEW_REPO>           ║
 ╚══════════════════════════════════════════════════════════════╝
 ```
 ---
 ## Step 6: Validate New Repository via Gitea API
 Verify the new repository exists and is accessible:
 ```bash
 source ~/.config/claude/gitea.env
 curl -s -o /dev/null -w "%{http_code}" -H "Authorization: token $GITEA_API_TOKEN" "$GITEA_API_URL/repos/<NEW_ORG>/<NEW_REPO>"
 ```
 | HTTP Code | Action |
 |-----------|--------|
 | **200** | Repository verified - proceed to Step 7 |
 | **404** | Repository not found - ask user to confirm (Step 6a) |
 | **401/403** | Permission issue - warn and ask to confirm |
 ### Step 6a: Confirm if API Validation Failed
 Use AskUserQuestion:
 - Question: "The new repository '<NEW_ORG>/<NEW_REPO>' was not found via API. Update configuration anyway?"
 - Header: "Not Found"
 - Options:
  - "Yes, update anyway (I'll fix the remote later)"
  - "No, let me fix the git remote first"
  - "Let me specify different values"
 **If "specify different values":** Ask for correct org and repo, then re-validate.
 ---
 ## Step 7: Confirm Update
 Use AskUserQuestion:
 - Question: "Update project configuration to match git remote?"
 - Header: "Confirm"
 - Options:
  - "Yes, update .env (Recommended)"
  - "No, keep current configuration"
 **If "No":** Exit without changes.
 ---
 ## Step 8: Update Configuration
 Update the .env file with new values:
 ```bash
 # Update GITEA_ORG
 sed -i 's/^GITEA_ORG=.*/GITEA_ORG=<NEW_ORG>/' .env
 # Update GITEA_REPO
 sed -i 's/^GITEA_REPO=.*/GITEA_REPO=<NEW_REPO>/' .env
 ```
 Alternatively, if sed doesn't work well, read the file, replace values, and write back.
 ---
 ## Step 9: Verify Update
 Read the updated .env and display confirmation:
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║              CONFIGURATION UPDATED                           ║
 ╠══════════════════════════════════════════════════════════════╣
 ║ Organization:  <NEW_ORG>                                     ║
 ║ Repository:    <NEW_REPO>                                    ║
 ║ Status:        In sync with git remote                       ║
 ╚══════════════════════════════════════════════════════════════╝
 Your project configuration has been updated.
 MCP tools will now use the new repository.
 ```
 ---
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  ⚙️ SETUP                                                        ║
 ║  Project Sync                                                    ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the sync workflow.
 ## Troubleshooting
 **"Repository not found" but it exists:**
 - Check your Gitea token has access to the new organization
 - Verify the repository name matches exactly (case-sensitive)
 - Ensure your token has `repo` permissions
 **Git remote URL is wrong:**
 - Fix it first: `git remote set-url origin <correct-url>`
 - Then run `/project-sync` again
 **Want to revert the change:**
 - Edit `.env` manually: `nano .env`
 - Or run `/project-sync` after fixing the git remote
--- a/plugins/projman/commands/proposal-status.md
+++ b/plugins/projman/commands/proposal-status.md
@@ -4,131 +4,46 @@ 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.
+## Skills Required
-## Overview
+- skills/mcp-tools-reference.md
 - skills/wiki-conventions.md
-This command provides a tree view of:
+## Purpose
- All change proposals (`Change VXX.X.X: Proposal`)
+
- Their implementations (`Change VXX.X.X: Proposal (Implementation N)`)
+View status of all change proposals and their implementations in Gitea Wiki.
- Linked issues and lessons learned
+
 ## Invocation
 ```
 /proposal-status
 /proposal-status --version V04.1.0
 /proposal-status --status "In Progress"
 ```
 ## Workflow
-1. **Fetch All Wiki Pages**
+1. **Fetch Wiki Pages** - Use `list_wiki_pages()` to get all pages
-   - Use `list_wiki_pages()` to get all wiki pages
+2. **Filter Proposals** - Match `Change V*: Proposal*` pattern
-   - Filter for pages matching `Change V*: Proposal*` pattern
+3. **Parse Structure** - Group implementations under parent proposals
-
+4. **Extract Status** - Read page metadata (In Progress, Implemented, Abandoned)
-2. **Parse Proposal Structure**
+5. **Fetch Linked Artifacts** - Find issues and lessons referencing each implementation
-   - Group implementations under their parent proposals
+6. **Display Tree View** - Show hierarchy with status and links
   - 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 |
+| Pending | Proposal created, no implementation started |
-| **In Progress** | At least one implementation is active |
+| In Progress | At least one implementation is active |
-| **Implemented** | All planned implementations complete |
+| Implemented | All planned implementations complete |
-| **Abandoned** | Proposal was cancelled or superseded |
+| Abandoned | Proposal 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
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Proposal Status                                                 ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the status report.
--- a/plugins/projman/commands/review.md
+++ b/plugins/projman/commands/review.md
@@ -1,83 +1,47 @@
 ---
 name: review
 description: Pre-sprint-close code quality review
 agent: code-reviewer
 ---
 # Code Review for Sprint Close
-Review the recent code changes for quality issues before closing the sprint.
+## Skills Required
-## Review Checklist
+- skills/review-checklist.md
-Analyze the changes and report on:
+## Purpose
-### 1. Debug Artifacts
+Review recent code changes for quality issues before closing the sprint.
 - [ ] TODO/FIXME comments that should be resolved or converted to issues
 - [ ] Console.log, print(), debug statements left in code
 - [ ] Commented-out code blocks
-### 2. Code Quality
+## Invocation
 - [ ] Functions exceeding 50 lines (complexity smell)
 - [ ] Deeply nested conditionals (>3 levels)
 - [ ] Duplicate code patterns
 - [ ] Missing docstrings/comments on public functions
-### 3. Security Scan (Lightweight)
+Run `/review` before `/sprint-close` to catch issues.
 - [ ] Hardcoded strings that look like secrets (API keys, passwords, tokens)
 - [ ] SQL strings with concatenation (injection risk)
 - [ ] Disabled SSL verification
 - [ ] Overly permissive file permissions in code
-### 4. Error Handling
+## Workflow
 - [ ] Bare except/catch blocks
 - [ ] Swallowed exceptions (catch with pass/empty block)
 - [ ] Missing null/undefined checks on external data
-## Output Format
+1. **Determine Scope** - Sprint files or recent commits (`git diff --name-only HEAD~5`)
 2. **Read Files** - Use Read tool for each file in scope
 3. **Scan for Patterns** - Check each category from review checklist
 4. **Compile Findings** - Group by severity (Critical, Warning, Recommendation)
 5. **Report Verdict** - READY / NEEDS ATTENTION / BLOCK
-Provide a structured report:
+## Review Categories
-```
+See `skills/review-checklist.md` for complete patterns:
-## Sprint Review Summary
+- Debug artifacts (TODO, console.log, commented code)
 - Code quality (long functions, deep nesting, duplication)
 - Security (hardcoded secrets, SQL injection, disabled SSL)
 - Error handling (bare except, swallowed exceptions)
-### Critical Issues (Block Sprint Close)
+## DO NOT
 - [file:line] Description
-### Warnings (Should Address)
+- Rewrite or refactor code automatically
- [file:line] Description
+- Make changes without explicit approval
-
+- Review files outside sprint/change scope
-### Recommendations (Nice to Have)
+- Spend excessive time on style issues
 - [file:line] Description
 ### Clean Files
 - List of files with no issues found
 ```
 ## Scope
 If sprint context is available from projman, limit review to files touched in current sprint.
 Otherwise, review staged changes or changes in the last 5 commits.
 ## How to Determine Scope
 1. **Check for sprint context**: Look for `.projman/current-sprint.json` or similar
 2. **Fall back to git changes**: Use `git diff --name-only HEAD~5` or staged files
 3. **Filter by file type**: Focus on code files (.py, .js, .ts, .go, .rs, etc.)
 ## Execution Steps
 1. Determine scope (sprint files or recent commits)
 2. For each file in scope:
   - Read the file content
   - Scan for patterns in each category
   - Record findings with file:line references
 3. Compile findings into the structured report
 4. Provide recommendation: READY / NEEDS ATTENTION / BLOCK
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
@@ -85,12 +49,3 @@ When executing this command, display the plugin header:
 ║  Code Review                                                     ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the review workflow.
 ## Do NOT
 - Rewrite or refactor code automatically
 - Make changes without explicit approval
 - Review files outside the sprint/change scope
 - Spend excessive time on style issues (assume formatters handle this)
--- a/plugins/projman/commands/setup.md
+++ b/plugins/projman/commands/setup.md
@@ -0,0 +1,90 @@
 ---
 description: Configure projman - full setup, quick project init, or sync after repo move
 ---
 # Setup
 ## Skills Required
 - skills/mcp-tools-reference.md
 - skills/repo-validation.md
 - skills/setup-workflows.md
 ## Purpose
 Unified setup command for all configuration needs.
 **Important:**
 - Uses Bash, Read, Write, AskUserQuestion - NOT MCP tools
 - MCP tools won't work until after setup + session restart
 - Tokens must be entered manually for security
 ## Invocation
 ```
 /setup              # Auto-detect appropriate mode
 /setup --full       # Full wizard (MCP + system + project)
 /setup --quick      # Project-only setup
 /setup --sync       # Update after repo move
 ```
 ## Mode Detection
 If no argument provided, auto-detect:
 1. Check `~/.config/claude/gitea.env`
   - Missing → **full** mode
 2. Check project `.env`
   - Missing → **quick** mode
 3. Compare `.env` with git remote
   - Mismatch → **sync** mode
   - Match → offer reconfigure or exit
 ## Mode: Full
 Execute `skills/setup-workflows.md` → Full Setup Workflow
 Phases:
 1. Environment validation (Python 3.10+)
 2. MCP server setup (venv + requirements)
 3. System-level config (`~/.config/claude/gitea.env`)
 4. Project-level config (`.env`)
 5. Final validation
 ## Mode: Quick
 Execute `skills/setup-workflows.md` → Quick Setup Workflow
 Steps:
 1. Verify system config exists
 2. Verify git repository
 3. Check existing `.env`
 4. Detect org/repo from git remote
 5. Validate via API
 6. Create/update `.env`
 7. Check `.gitignore`
 ## Mode: Sync
 Execute `skills/setup-workflows.md` → Sync Workflow
 Steps:
 1. Read current config
 2. Detect git remote
 3. Compare values
 4. Show changes
 5. Validate new values
 6. Update `.env`
 7. Confirm
 ## Visual Output
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  ⚙️ SETUP                                                        ║
 ║  [Mode: Full | Quick | Sync]                                     ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
--- a/plugins/projman/commands/sprint-close.md
+++ b/plugins/projman/commands/sprint-close.md
@@ -1,293 +1,46 @@
 ---
 description: Complete sprint and capture lessons learned to Gitea Wiki
 agent: orchestrator
 ---
 # Close Sprint and Capture Lessons Learned
-This command completes the sprint and captures lessons learned to Gitea Wiki. **This is critical** - after 15 sprints without lesson capture, repeated mistakes occurred (e.g., Claude Code infinite loops 2-3 times on similar issues).
+## Skills Required
-## Why Lessons Learned Matter
+- skills/mcp-tools-reference.md
 - skills/lessons-learned.md
 - skills/wiki-conventions.md
 - skills/progress-tracking.md
 - skills/git-workflow.md
-**Problem:** Without systematic lesson capture, teams repeat the same mistakes:
+## Purpose
 - Claude Code infinite loops on similar issues (happened 2-3 times)
 - Same architectural mistakes (multiple occurrences)
 - Forgotten optimizations (re-discovered each time)
-**Solution:** Mandatory lessons learned capture at sprint close, searchable at sprint start.
+Complete the sprint, capture lessons learned to Gitea Wiki, and update documentation. This is critical for preventing repeated mistakes across sprints.
-## Sprint Close Workflow
+## Invocation
-The orchestrator agent will guide you through:
+Run `/sprint-close` when sprint work is complete.
-1. **Review Sprint Completion**
+## Workflow
   - Use `list_issues` to verify all issues are closed or moved to backlog
   - Check milestone completion status
   - Check for incomplete work needing carryover
   - Review overall sprint goals vs. actual completion
-2. **Capture Lessons Learned**
+Execute the sprint close workflow:
   - What went wrong and why
   - What went right and should be repeated
   - Preventable repetitions to avoid in future sprints
   - Technical insights and gotchas discovered
-3. **Tag for Discoverability**
+1. **Review Sprint Completion** - Verify issues closed or moved to backlog
-   - Apply relevant tags: technology, component, type of lesson
+2. **Capture Lessons Learned** - Interview user about challenges and insights
-   - Ensure future sprints can find these lessons via search
+3. **Tag for Discoverability** - Apply technology, component, and pattern tags
-   - Use consistent tagging for patterns
+4. **Save to Gitea Wiki** - Use `create_lesson` with metadata and implementation link
 5. **Update Wiki Implementation Page** - Change status to Implemented/Partial/Failed
 6. **Update Wiki Proposal Page** - Update overall status if all implementations complete
 7. **New Command Verification** - Remind user new commands require session restart
 8. **Update CHANGELOG** (MANDATORY) - Add changes to `[Unreleased]` section
 9. **Version Check** - Run `/suggest-version` to recommend version bump
 10. **Git Operations** - Commit, merge, tag, clean up branches
 11. **Close Milestone** - Update milestone state to closed
-4. **Save to Gitea Wiki**
+**Don't skip lessons learned!** Future sprints will benefit from captured insights.
   - Use `create_lesson` to save lessons to Gitea Wiki
   - Create lessons in project wiki under `lessons-learned/sprints/`
   - Make lessons searchable for future sprints
 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. **New Command Verification** (if applicable)
   - Check if this sprint added new commands or skills
   - **IMPORTANT:** New commands are NOT discoverable until session restart
   - If new commands were added:
     - List them in sprint close notes
     - Remind user: "New commands require session restart to test"
     - Create verification task in next sprint or backlog
   - **WHY:** Claude Code discovers skills at session start; commands added during a session won't work until restart
 8. **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`)
 9. **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
 10. **Git Operations**
    - Commit any remaining work (including CHANGELOG updates)
    - Merge feature branches if needed
    - Clean up merged branches
    - Tag sprint completion (if release created)
 11. **Close Milestone**
    - Use `update_milestone` to close the sprint milestone
    - Document final completion status
 ## MCP Tools Available
 **Gitea Tools:**
 - `list_issues` - Review sprint issues (completed and incomplete)
 - `get_issue` - Get detailed issue information for retrospective
 - `update_issue` - Move incomplete issues to next sprint
 **Milestone Tools:**
 - `get_milestone` - Get milestone status
 - `update_milestone` - Close milestone
 **Lessons Learned Tools (Gitea Wiki):**
 - `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 or implementation pages
 - `update_wiki_page` - Update implementation/proposal status
 ## Lesson Structure
 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?]
 ## Problem
 [What went wrong? What insight emerged? What challenge did you face?]
 ## Solution
 [How did you solve it? What approach worked?]
 ## Prevention
 [How can this be avoided or optimized in the future? What should future sprints know?]
 ## Tags
 [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.
 ## Problem
 Claude Code entered an infinite loop when pytest validation tests failed.
 The loop occurred because the error message didn't change between attempts,
 causing Claude to retry the same fix repeatedly.
 ## Solution
 Added more descriptive error messages to validation tests that specify
 exactly what value failed and why. This gave Claude clear feedback
 to adjust the approach rather than retrying the same fix.
 ## Prevention
 - Always write validation test errors with specific values and expectations
 - If Claude loops, check if error messages provide unique information per failure
 - Add a "loop detection" check in test output (fail after 3 identical errors)
 ## Tags
 testing, claude-code, validation, python, pytest, debugging
 ```
 **Example 2: Architectural Decision**
 ```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.
 ## Problem
 Initial plan was to extract immediately without testing the API boundaries
 first. This would have caused integration issues discovered late.
 ## Solution
 Added a sprint phase to:
 1. Define clear API contracts first
 2. Add integration tests for the boundaries
 3. THEN extract the service
 Delayed extraction by one sprint but avoided major rework.
 ## Prevention
 - Always define API contracts before service extraction
 - Write integration tests FIRST, extraction SECOND
 - Don't rush architectural changes - test boundaries first
 ## Tags
 architecture, service-extraction, refactoring, api-design, planning
 ```
 ## Tagging Strategy
 Use consistent tags for discoverability:
 **By Technology:**
 - `python`, `javascript`, `docker`, `postgresql`, `redis`, `vue`, `fastapi`
 **By Component:**
 - `backend`, `frontend`, `api`, `database`, `auth`, `deploy`, `testing`, `docs`
 **By Type:**
 - `bug`, `feature`, `refactor`, `architecture`, `performance`, `security`
 **By Issue:**
 - `claude-code`, `validation`, `testing`, `debugging`, `deployment`, `configuration`
 **By Pattern:**
 - `infinite-loop`, `edge-case`, `integration`, `boundaries`, `dependencies`
 ## Orchestrator's Role
 The orchestrator agent will:
 1. Ask probing questions about the sprint
 2. Identify preventable mistakes vs. expected challenges
 3. Structure lessons in the proper format
 4. Suggest appropriate tags
 5. Create lessons in Gitea Wiki using `create_lesson`
 6. Ensure lessons are discoverable for future sprints
 7. Handle git operations and milestone closure
 ## Example Sprint Close Session
 ```
 User: /sprint-close
 Orchestrator: Let's close the sprint and capture lessons learned.
 First, let me review the sprint completion...
 [Uses list_issues to check sprint status]
 Sprint 18 Summary:
 - 8 issues planned
 - 7 completed (87.5%)
 - 1 moved to backlog (#52: Deploy auth service - blocked by infra)
 Great progress! Now, let's capture lessons learned.
 What challenges did you face this sprint?
 User: Claude Code got stuck in a loop when pytest validation tests failed
 Orchestrator: That's a valuable lesson - this prevents future frustration.
 Let me ask some clarifying questions:
 1. What caused the loop? (Same error message repeated?)
 2. How did you break out of it?
 3. What would prevent this in future sprints?
 [After gathering details]
 I'll create this lesson with tags: testing, claude-code, validation, python, pytest, debugging
 [Uses create_lesson to save to Gitea Wiki]
 Lesson created: "Sprint 18 - Claude Code Infinite Loop on Validation Errors"
 Saved to Gitea Wiki with appropriate tags.
 Any other lessons from this sprint?
 User: Yes, we discovered that JWT token refresh needs special handling
 Orchestrator: Excellent - let's capture that too...
 [Continues capturing lessons]
 All lessons captured! They'll be searchable when planning future sprints.
 Would you like me to handle git operations?
 - Commit any remaining changes
 - Merge feature branches to development
 - Tag sprint completion (v0.18.0)
 - Clean up merged branches
 - Close milestone
 [Y/n]
 ```
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
@@ -295,18 +48,3 @@ When executing this command, display the plugin header:
 ║  [Sprint Name]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Replace `[Sprint Name]` with the actual sprint/milestone name.
 Then proceed with the sprint close workflow.
 ## Getting Started
 Simply run `/sprint-close` when your sprint is complete. The orchestrator will guide you through:
 1. Sprint review
 2. Lessons learned capture
 3. Gitea Wiki updates
 4. Git operations
 5. Milestone closure
 **Don't skip this step!** Future sprints will thank you for capturing these insights.
--- a/plugins/projman/commands/sprint-diagram.md
+++ b/plugins/projman/commands/sprint-diagram.md
@@ -1,193 +0,0 @@
 ---
 description: Generate Mermaid diagram of sprint issues with dependencies and status
 ---
 # Sprint Diagram
 This command generates a visual Mermaid diagram showing the current sprint's issues, their dependencies, and execution flow.
 ## What This Command Does
 1. **Fetch Sprint Issues** - Gets all issues for the current sprint milestone
 2. **Fetch Dependencies** - Retrieves dependency relationships between issues
 3. **Generate Mermaid Syntax** - Creates flowchart showing issue flow
 4. **Apply Status Styling** - Colors nodes based on issue state (open/closed/in-progress)
 5. **Show Execution Order** - Visualizes parallel batches and critical path
 ## Usage
 ```
 /sprint-diagram
 /sprint-diagram --milestone "Sprint 4"
 ```
 ## MCP Tools Used
 **Issue Tools:**
 - `list_issues(state="all")` - Fetch all sprint issues
 - `list_milestones()` - Find current sprint milestone
 **Dependency Tools:**
 - `list_issue_dependencies(issue_number)` - Get dependencies for each issue
 - `get_execution_order(issue_numbers)` - Get parallel execution batches
 ## Implementation Steps
 1. **Get Current Milestone:**
   ```
   milestones = list_milestones(state="open")
   current_sprint = milestones[0]  # Most recent open milestone
   ```
 2. **Fetch Sprint Issues:**
   ```
   issues = list_issues(state="all", milestone=current_sprint.title)
   ```
 3. **Fetch Dependencies for Each Issue:**
   ```python
   dependencies = {}
   for issue in issues:
       deps = list_issue_dependencies(issue.number)
       dependencies[issue.number] = deps
   ```
 4. **Generate Mermaid Diagram:**
   ```mermaid
   flowchart TD
       subgraph Sprint["Sprint 4 - Commands"]
           241["#241: sprint-diagram"]
           242["#242: confidence threshold"]
           243["#243: pr-diff"]
           241 --> 242
           242 --> 243
       end
       classDef completed fill:#90EE90,stroke:#228B22
       classDef inProgress fill:#FFD700,stroke:#DAA520
       classDef open fill:#ADD8E6,stroke:#4682B4
       classDef blocked fill:#FFB6C1,stroke:#DC143C
       class 241 completed
       class 242 inProgress
       class 243 open
   ```
 ## Expected Output
 ```
 Sprint Diagram: Sprint 4 - Commands
 ===================================
 ```mermaid
 flowchart TD
    subgraph batch1["Batch 1 - No Dependencies"]
        241["#241: sprint-diagram<br/>projman"]
        242["#242: confidence threshold<br/>pr-review"]
        244["#244: data-quality<br/>data-platform"]
        247["#247: chart-export<br/>viz-platform"]
        250["#250: dependency-graph<br/>contract-validator"]
        251["#251: changelog-gen<br/>doc-guardian"]
        254["#254: config-diff<br/>config-maintainer"]
        256["#256: cmdb-topology<br/>cmdb-assistant"]
    end
    subgraph batch2["Batch 2 - After Batch 1"]
        243["#243: pr-diff<br/>pr-review"]
        245["#245: lineage-viz<br/>data-platform"]
        248["#248: color blind<br/>viz-platform"]
        252["#252: doc-coverage<br/>doc-guardian"]
        255["#255: linting<br/>config-maintainer"]
        257["#257: change-audit<br/>cmdb-assistant"]
    end
    subgraph batch3["Batch 3 - Final"]
        246["#246: dbt-test<br/>data-platform"]
        249["#249: responsive<br/>viz-platform"]
        253["#253: stale-docs<br/>doc-guardian"]
        258["#258: IP conflict<br/>cmdb-assistant"]
    end
    batch1 --> batch2
    batch2 --> batch3
    classDef completed fill:#90EE90,stroke:#228B22
    classDef inProgress fill:#FFD700,stroke:#DAA520
    classDef open fill:#ADD8E6,stroke:#4682B4
    class 241,242 completed
    class 243,244 inProgress
 ```
 ## Status Legend
 | Status | Color | Description |
 |--------|-------|-------------|
 | Completed | Green | Issue closed |
 | In Progress | Yellow | Currently being worked on |
 | Open | Blue | Ready to start |
 | Blocked | Red | Waiting on dependencies |
 ## Diagram Types
 ### Default: Dependency Flow
 Shows how issues depend on each other with arrows indicating blockers.
 ### Batch View (--batch)
 Groups issues by execution batch for parallel work visualization.
 ### Plugin View (--by-plugin)
 Groups issues by plugin for component-level overview.
 ## When to Use
 - **Sprint Planning**: Visualize scope and dependencies
 - **Daily Standups**: Show progress at a glance
 - **Documentation**: Include in wiki pages
 - **Stakeholder Updates**: Visual progress reports
 ## Integration
 The generated Mermaid diagram can be:
 - Pasted into GitHub/Gitea issues
 - Rendered in wiki pages
 - Included in PRs for context
 - Used in sprint retrospectives
 ## Example
 ```
 User: /sprint-diagram
 Generating sprint diagram...
 Milestone: Sprint 4 - Commands (18 issues)
 Fetching dependencies...
 Building diagram...
 ```mermaid
 flowchart LR
    241[sprint-diagram] --> |enables| 242[confidence]
    242 --> 243[pr-diff]
    style 241 fill:#90EE90
    style 242 fill:#ADD8E6
    style 243 fill:#ADD8E6
 ```
 Open: 16 | In Progress: 1 | Completed: 1
 ```
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Sprint Diagram                                                  ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed to generate the diagram.
--- a/plugins/projman/commands/sprint-plan.md
+++ b/plugins/projman/commands/sprint-plan.md
@@ -1,413 +1,56 @@
 ---
 description: Start sprint planning with AI-guided architecture analysis and issue creation
 agent: planner
 ---
 # Sprint Planning
-You are initiating sprint planning. The planner agent will guide you through architecture analysis, ask clarifying questions, and help create well-structured Gitea issues with appropriate labels.
+## Skills Required
-
+
-## CRITICAL: Pre-Planning Validations
+- skills/mcp-tools-reference.md
-
+- skills/branch-security.md
-**BEFORE PLANNING**, the planner agent performs mandatory checks:
+- skills/repo-validation.md
-
+- skills/input-detection.md
-### 1. Branch Detection
+- skills/lessons-learned.md
-
+- skills/wiki-conventions.md
-```bash
+- skills/task-sizing.md
-git branch --show-current
+- skills/issue-conventions.md
-```
+- skills/sprint-approval.md
-
+- skills/planning-workflow.md
-**Branch Requirements:**
+- skills/label-taxonomy/labels-reference.md
- **Development branches** (`development`, `develop`, `feat/*`, `dev/*`): Full planning capabilities
+
- **Staging branches** (`staging`, `stage/*`): Can create issues to document needed changes, but cannot modify code
+## Purpose
- **Production branches** (`main`, `master`, `prod/*`): READ-ONLY - no planning allowed
+
-
+Initiate sprint planning session. The planner agent validates prerequisites, gathers requirements, searches lessons learned, creates wiki pages, and creates well-structured Gitea issues with proper dependencies and labels.
-If you are on a production or staging branch, you MUST stop and ask the user to switch to a development branch.
+
-
+## Invocation
-### 2. Repository Organization Check
+
-
+Provide sprint goals as natural language input, or prepare input via:
-Use `validate_repo_org` MCP tool to verify the repository belongs to an organization.
+- `docs/changes/*.md` file with frontmatter
-
+- Existing wiki proposal page
-**If NOT an organization repository:**
+- Direct conversation
-```
+
-REPOSITORY VALIDATION FAILED
+## Workflow
-
+
-This plugin requires the repository to belong to an organization, not a user.
+Execute the planning workflow as defined in `skills/planning-workflow.md`.
-Please transfer or create the repository under that organization.
+
-```
+**Key steps:**
-
+1. Run pre-planning validations (branch, repo org, labels)
-### 3. Label Taxonomy Validation
+2. Detect input source (file, wiki, or conversation)
-
+3. Search relevant lessons learned
-Verify all required labels exist using `get_labels`:
+4. Create/update wiki proposal and implementation pages
-
+5. Perform architecture analysis
-**Required label categories:**
+6. Create Gitea issues with wiki references (respecting task sizing rules)
- Type/* (Bug, Feature, Refactor, Documentation, Test, Chore)
+7. Set up dependencies
- Priority/* (Low, Medium, High, Critical)
+8. Create or select milestone
- Complexity/* (Simple, Medium, Complex)
+9. Request explicit sprint approval
 - Efforts/* (XS, S, M, L, XL)
 **If labels are missing:** Use `create_label` to create them.
 ### 4. Input Source Detection
 The planner supports flexible input sources for sprint planning:
 | 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 |
 **Input File Format** (if using local file):
 ```yaml
 ---
 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
 The planner agent will:
 1. **Understand Sprint Goals**
   - Ask clarifying questions about the sprint objectives
   - Understand scope, priorities, and constraints
   - Never rush - take time to understand requirements fully
 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
 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
 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
 8. **Set Up Dependencies**
   - Use `create_issue_dependency` to establish task dependencies
   - This enables parallel execution planning
 9. **Create or Select Milestone**
   - Use `create_milestone` to group sprint issues
   - Assign issues to the milestone
 10. **Cleanup & Summary**
    - Delete local input file (wiki is now source of truth)
    - Summarize architectural decisions
    - List created issues with labels
    - Document dependency graph
    - Provide sprint overview with wiki links
 11. **Request Sprint Approval**
    - Present approval request with scope summary
    - Capture explicit user approval
    - Record approval in milestone description
    - Approval scopes what sprint-start can execute
 ## Sprint Approval (MANDATORY)
 **Planning DOES NOT equal execution permission.**
 After creating issues, the planner MUST request explicit approval:
 ```
 Sprint 17 Planning Complete
 ===========================
 Created Issues:
 - #45: [Sprint 17] feat: JWT token generation
 - #46: [Sprint 17] feat: Login endpoint
 - #47: [Sprint 17] test: Auth tests
 Execution Scope:
 - Branches: feat/45-*, feat/46-*, feat/47-*
 - Files: auth/*, api/routes/auth.py, tests/test_auth*
 - Dependencies: PyJWT, python-jose
 ⚠️ APPROVAL REQUIRED
 Do you approve this sprint for execution?
 This grants permission for agents to:
 - Create and modify files in the listed scope
 - Create branches with the listed prefixes
 - Install listed dependencies
 Type "approve sprint 17" to authorize execution.
 ```
 **On Approval:**
 1. Record approval in milestone description
 2. Note timestamp and scope
 3. Sprint-start will verify approval exists
 **Approval Record Format:**
 ```markdown
 ## Sprint Approval
 **Approved:** 2026-01-28 14:30
 **Approver:** User
 **Scope:**
 - Branches: feat/45-*, feat/46-*, feat/47-*
 - Files: auth/*, api/routes/auth.py, tests/test_auth*
 ```
 ## Issue Title Format (MANDATORY)
 ```
 [Sprint XX] <type>: <description>
 ```
 **Types:**
 - `feat` - New feature
 - `fix` - Bug fix
 - `refactor` - Code refactoring
 - `docs` - Documentation
 - `test` - Test additions/changes
 - `chore` - Maintenance tasks
 **Examples:**
 - `[Sprint 17] feat: Add user email validation`
 - `[Sprint 17] fix: Resolve login timeout issue`
 - `[Sprint 18] refactor: Extract authentication module`
 ## Task Sizing Rules (MANDATORY)
 **CRITICAL: Tasks sized L or XL MUST be broken down into smaller tasks.**
 | Effort | Files | Checklist Items | Max Tool Calls | Agent Scope |
 |--------|-------|-----------------|----------------|-------------|
 | **XS** | 1 file | 0-2 items | ~30 | Single function/fix |
 | **S** | 1 file | 2-4 items | ~50 | Single file feature |
 | **M** | 2-3 files | 4-6 items | ~80 | Multi-file feature |
 | **L** | MUST BREAK DOWN | - | - | Too large for one agent |
 | **XL** | MUST BREAK DOWN | - | - | Way too large |
 **Why This Matters:**
 - Agents running 400+ tool calls take 1+ hour, with no visibility
 - Large tasks lack clear completion criteria
 - Debugging failures is extremely difficult
 - Small tasks enable parallel execution
 **Scoping Checklist:**
 1. Can this be completed in one file? → XS or S
 2. Does it touch 2-3 files? → M (maximum for single task)
 3. Does it touch 4+ files? → MUST break down
 4. Would you estimate 50+ tool calls? → MUST break down
 5. Does it require complex decision-making mid-task? → MUST break down
 **Example Breakdown:**
 **BAD (L - too broad):**
 ```
 [Sprint 3] feat: Implement schema diff detection hook
 Labels: Efforts/L
 - Hook skeleton
 - Pattern detection for DROP/ALTER/RENAME
 - Warning output formatting
 - Integration with hooks.json
 ```
 **GOOD (broken into S tasks):**
 ```
 [Sprint 3] feat: Create schema-diff-check.sh hook skeleton
 Labels: Efforts/S
 - [ ] Create hook file with standard header
 - [ ] Add file type detection for SQL/migrations
 - [ ] Exit 0 (non-blocking)
 [Sprint 3] feat: Add DROP/ALTER pattern detection
 Labels: Efforts/S
 - [ ] Detect DROP COLUMN/TABLE/INDEX
 - [ ] Detect ALTER TYPE changes
 - [ ] Detect RENAME operations
 [Sprint 3] feat: Add warning output formatting
 Labels: Efforts/S
 - [ ] Format breaking change warnings
 - [ ] Add hook prefix to output
 - [ ] Test output visibility
 [Sprint 3] chore: Register hook in hooks.json
 Labels: Efforts/XS
 - [ ] Add PostToolUse:Edit hook entry
 - [ ] Test hook triggers on SQL edits
 ```
 **The planner MUST refuse to create L/XL tasks without breakdown.**
 ## MCP Tools Available
 **Gitea Tools:**
 - `list_issues` - Review existing issues
 - `get_issue` - Get detailed issue information
 - `create_issue` - Create new issue with labels
 - `update_issue` - Update issue
 - `get_labels` - Fetch current label taxonomy
 - `suggest_labels` - Get intelligent label suggestions based on context
 - `create_label` - Create missing labels
 - `validate_repo_org` - Check if repo is under organization
 **Milestone Tools:**
 - `list_milestones` - List milestones
 - `create_milestone` - Create milestone
 - `update_milestone` - Update milestone
 **Dependency Tools:**
 - `create_issue_dependency` - Create dependency between issues
 - `list_issue_dependencies` - List dependencies for an issue
 - `get_execution_order` - Get parallel execution batches
 **Lessons Learned Tools (Gitea Wiki):**
 - `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
 The system uses a dynamic 44-label taxonomy (28 org + 16 repo). Always use the `suggest_labels` tool to get appropriate labels based on the issue context.
 **Key Label Categories:**
 - **Type/***: Bug, Feature, Refactor, Documentation, Test, Chore
 - **Priority/***: Low, Medium, High, Critical
 - **Complexity/***: Simple, Medium, Complex
 - **Efforts/***: XS, S, M, L, XL
 - **Component/***: Backend, Frontend, API, Database, Auth, Deploy, Testing, Docs, Infra
 - **Tech/***: Python, JavaScript, Docker, PostgreSQL, Redis, Vue, FastAPI
 ## Planner Personality
 The planner agent is thoughtful and methodical:
 - Asks clarifying questions before making assumptions
 - Thinks through edge cases and architectural implications
 - Never rushes planning - quality over speed
 - References lessons learned proactively
 - Suggests appropriate labels based on context
 - Creates well-structured, detailed issues
 ## Example Planning Session
 ```
 User: I want to plan a sprint for user authentication
 Planner: Great! Let me first run pre-planning validations...
 [Checks branch, repo org, labels]
 All validations passed.
 [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?
 [Uses search_lessons to find past authentication work]
 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
 [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)
 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
  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
  Implementation: [Change V1.2.0 (Impl 1)](wiki-link)
 Dependency Graph:
 #45 -> #46 -> #47
       |
       v
      #48
 Milestone: Sprint 17 - User Authentication (Due: 2025-02-01)
 Wiki: https://gitea.example.com/org/repo/wiki/Change-V1.2.0%3A-Proposal
 ```
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🎯 PLANNING                                                     ║
-║  Sprint Planning                                                 ║
+║  [Sprint Name]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the command workflow.
 ## 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. Detect input source (file, wiki, or conversation)
 3. Ask clarifying questions
 4. Search lessons learned
 5. Create wiki proposal and implementation pages
 6. Create issues with wiki references
 7. Set up dependencies
 8. Create milestone
 9. Cleanup and generate planning summary
--- a/plugins/projman/commands/sprint-start.md
+++ b/plugins/projman/commands/sprint-start.md
@@ -1,419 +1,48 @@
 ---
 description: Begin sprint execution with relevant lessons learned from previous sprints
 agent: orchestrator
 ---
 # Start Sprint Execution
-You are initiating sprint execution. The orchestrator agent will coordinate the work, analyze dependencies for parallel execution, search for relevant lessons learned, and guide you through the implementation process.
+## Skills Required
-## Sprint Approval Verification (Recommended)
+- skills/mcp-tools-reference.md
 - skills/branch-security.md
 - skills/sprint-approval.md
 - skills/dependency-management.md
 - skills/lessons-learned.md
 - skills/git-workflow.md
 - skills/progress-tracking.md
 - skills/runaway-detection.md
-**RECOMMENDED: Sprint should be approved before execution.**
+## Purpose
-> **Note:** This is a recommended workflow practice, not code-enforced. The orchestrator
+Initiate sprint execution. The orchestrator agent verifies approval, analyzes dependencies for parallel execution, searches relevant lessons, and coordinates task dispatch.
 > SHOULD check for approval, but execution will proceed if approval is missing. For
 > critical projects, consider making approval mandatory in your workflow.
-The orchestrator checks for approval in the milestone description:
+## Invocation
-```
+Run `/sprint-start` when ready to begin executing a planned sprint.
 get_milestone(milestone_id=17)
 → Check description for "## Sprint Approval" section
 ```
-**If Approval Missing:**
+## Workflow
 ```
 ⚠️ SPRINT APPROVAL NOT FOUND (Warning)
-Sprint 17 milestone does not contain an approval record.
+Execute the sprint start workflow:
-Recommended: Run /sprint-plan first to:
+1. **Verify Sprint Approval** (recommended) - Check milestone for approval record
-1. Review the sprint scope
+2. **Detect Checkpoints** - Check for resume points from interrupted sessions
-2. Document the approved execution plan
+3. **Fetch Sprint Issues** - Get open issues from milestone
 4. **Analyze Dependencies** - Use `get_execution_order` for parallel batches
 5. **Search Relevant Lessons** - Find applicable past experiences
 6. **Dispatch Tasks** - Parallel when safe, sequential when file conflicts exist
-Proceeding anyway - consider adding approval for audit trail.
+**File Conflict Prevention:** Before parallel dispatch, check target files for overlap. Sequentialize tasks that modify the same files.
 ```
-**If Approval Found:**
+**Branch Isolation:** Each task runs on its own branch (`feat/<issue>-<desc>`).
 ```
 ✓ Sprint Approval Verified
  Approved: 2026-01-28 14:30
  Scope:
    Branches: feat/45-*, feat/46-*, feat/47-*
    Files: auth/*, api/routes/auth.py, tests/test_auth*
-Proceeding with execution within approved scope...
+**Sequential Merge:** After completion, merge branches sequentially to detect conflicts.
 ```
 **Scope Enforcement (when approval exists):**
 - Agents SHOULD only create branches matching approved patterns
 - Agents SHOULD only modify files within approved paths
 - Operations outside scope should trigger re-approval via `/sprint-plan`
 ## Branch Detection
 **CRITICAL:** Before proceeding, check the current git branch:
 ```bash
 git branch --show-current
 ```
 **Branch Requirements:**
 - **Development branches** (`development`, `develop`, `feat/*`, `dev/*`): Full execution capabilities
 - **Staging branches** (`staging`, `stage/*`): Can create issues to document bugs, but cannot modify code
 - **Production branches** (`main`, `master`, `prod/*`): READ-ONLY - no execution allowed
 If you are on a production or staging branch, you MUST stop and ask the user to switch to a development branch.
 ## Sprint Start Workflow
 The orchestrator agent will:
 1. **Verify Sprint Approval** (Recommended)
   - Check milestone description for `## Sprint Approval` section
   - If no approval found, WARN user and suggest `/sprint-plan` first
   - If approval found, extract scope (branches, files)
   - Agents SHOULD operate within approved scope when available
 2. **Detect Checkpoints (Resume Support)**
   - Check each open issue for `## Checkpoint` comments
   - If checkpoint found, offer to resume from that point
   - Resume preserves: branch, completed work, pending steps
 3. **Fetch Sprint Issues**
   - Use `list_issues` to fetch open issues for the sprint
   - Identify priorities based on labels (Priority/Critical, Priority/High, etc.)
 2. **Analyze Dependencies and Plan Parallel Execution**
   - Use `get_execution_order` to build dependency graph
   - Identify batches that can be executed in parallel
   - Present parallel execution plan
 3. **Search Relevant Lessons Learned**
   - Use `search_lessons` to find experiences from past sprints
   - Search by tags matching the current sprint's technology and components
   - Review patterns, gotchas, and preventable mistakes
   - Present relevant lessons before starting work
 4. **Dispatch Tasks (Parallel When Possible)**
   - For independent tasks (same batch), spawn multiple Executor agents in parallel
   - For dependent tasks, execute sequentially
   - Create proper branch for each task
 5. **Track Progress**
   - Update issue status as work progresses
   - Use `add_comment` to document progress and blockers
   - Monitor when dependencies are satisfied and new tasks become unblocked
 ## Parallel Execution Model
 The orchestrator analyzes dependencies and groups issues into parallelizable batches:
 ```
 Parallel Execution Batches:
 +---------------------------------------------------------------+
 | Batch 1 (can start immediately):                               |
 |   #45 [Sprint 18] feat: Implement JWT service                  |
 |   #48 [Sprint 18] docs: Update API documentation               |
 +---------------------------------------------------------------+
 | Batch 2 (after batch 1):                                       |
 |   #46 [Sprint 18] feat: Build login endpoint (needs #45)       |
 |   #49 [Sprint 18] test: Add auth tests (needs #45)             |
 +---------------------------------------------------------------+
 | Batch 3 (after batch 2):                                       |
 |   #47 [Sprint 18] feat: Create login form (needs #46)          |
 +---------------------------------------------------------------+
 ```
 **Independent tasks in the same batch run in parallel.**
 ## File Conflict Prevention (MANDATORY)
 **CRITICAL: Before dispatching parallel agents, check for file overlap.**
 **Pre-Dispatch Conflict Check:**
 1. **Identify target files** for each task in the batch
 2. **Check for overlap** - Do any tasks modify the same file?
 3. **If overlap detected** - Sequentialize those specific tasks
 **Example Conflict Detection:**
 ```
 Batch 1 Analysis:
  #45 - Implement JWT service
        Files: auth/jwt_service.py, auth/__init__.py, tests/test_jwt.py
  #48 - Update API documentation
        Files: docs/api.md, README.md
  Overlap: NONE → Safe to parallelize
 Batch 2 Analysis:
  #46 - Build login endpoint
        Files: api/routes/auth.py, auth/__init__.py
  #49 - Add auth tests
        Files: tests/test_auth.py, auth/__init__.py
  Overlap: auth/__init__.py → CONFLICT!
  Action: Sequentialize #46 and #49 (run #46 first)
 ```
 **Conflict Resolution Rules:**
 | Conflict Type | Action |
 |---------------|--------|
 | Same file in checklist | Sequentialize tasks |
 | Same directory | Review if safe, usually OK |
 | Shared test file | Sequentialize or assign different test files |
 | Shared config | Sequentialize |
 **Branch Isolation Protocol:**
 Even for parallel tasks, each MUST run on its own branch:
 ```
 Task #45 → feat/45-jwt-service (isolated)
 Task #48 → feat/48-api-docs (isolated)
 ```
 **Sequential Merge After Completion:**
 ```
 1. Task #45 completes → merge feat/45-jwt-service to development
 2. Task #48 completes → merge feat/48-api-docs to development
 3. Never merge simultaneously - always sequential to detect conflicts
 ```
 **If Merge Conflict Occurs:**
 1. Stop second task
 2. Resolve conflict manually or assign to human
 3. Resume/restart second task with updated base
 ## Branch Naming Convention (MANDATORY)
 When creating branches for tasks:
 - Features: `feat/<issue-number>-<short-description>`
 - Bug fixes: `fix/<issue-number>-<short-description>`
 - Debugging: `debug/<issue-number>-<short-description>`
 **Examples:**
 ```bash
 git checkout -b feat/45-jwt-service
 git checkout -b fix/46-login-timeout
 git checkout -b debug/47-investigate-memory-leak
 ```
 **Validation:**
 - Issue number MUST be present
 - Prefix MUST be `feat/`, `fix/`, or `debug/`
 - Description should be kebab-case (lowercase, hyphens)
 ## MCP Tools Available
 **Gitea Tools:**
 - `list_issues` - Fetch sprint issues (filter by state, labels, milestone)
 - `get_issue` - Get detailed issue information
 - `update_issue` - Update issue status, assignee, labels
 - `add_comment` - Add progress updates or blocker notes
 **Dependency Tools:**
 - `list_issue_dependencies` - Get dependencies for an issue
 - `get_execution_order` - Get parallel execution batches for sprint issues
 **Milestone Tools:**
 - `list_milestones` - List milestones
 - `get_milestone` - Get milestone details
 **Lessons Learned Tools (Gitea Wiki):**
 - `search_lessons` - Find relevant lessons from past sprints
 - `list_wiki_pages` - List project documentation
 - `get_wiki_page` - Fetch specific documentation (e.g., architecture decisions)
 ## Orchestrator Personality
 The orchestrator agent is concise and action-oriented:
 - Generates lean execution prompts, not lengthy documents
 - Tracks details meticulously (no task forgotten)
 - Coordinates parallel execution based on dependencies
 - Identifies blockers proactively
 - Coordinates Git operations (commit, merge, cleanup)
 - Updates documentation as work progresses
 ## Example Sprint Start Session
 ```
 User: /sprint-start
 Orchestrator: Starting sprint execution. Let me analyze the sprint...
 [Uses list_issues to fetch sprint backlog]
 Found 5 open issues for this sprint.
 [Uses get_execution_order to analyze dependencies]
 Parallel Execution Batches:
 +-----------------------------------------------+
 | Batch 1 (can start immediately):               |
 |   #45 - Implement JWT service                  |
 |   #48 - Update API documentation               |
 +-----------------------------------------------+
 | Batch 2 (after batch 1):                       |
 |   #46 - Build login endpoint (needs #45)       |
 |   #49 - Add auth tests (needs #45)             |
 +-----------------------------------------------+
 | Batch 3 (after batch 2):                       |
 |   #47 - Create login form (needs #46)          |
 +-----------------------------------------------+
 [Uses search_lessons to find relevant past experiences]
 Relevant lessons learned:
 - Sprint 12: "JWT Token Expiration Edge Cases" - Remember to handle token refresh
 - Sprint 8: "OAuth Integration Pitfalls" - Test error handling for auth providers
 Ready to start? I can dispatch multiple tasks in parallel.
 Dispatching Batch 1 (2 tasks in parallel):
 Task 1: #45 - Implement JWT service
  Branch: feat/45-jwt-service
  Executor: Starting...
 Task 2: #48 - Update API documentation
  Branch: feat/48-api-docs
  Executor: Starting...
 Both tasks running in parallel. I'll monitor progress.
 ```
 ## Lean Execution Prompts
 The orchestrator generates concise prompts (NOT verbose documents):
 ```
 Next Task: #45 - [Sprint 18] feat: Implement JWT token generation
 Priority: High | Effort: M (1 day) | Unblocked
 Branch: feat/45-jwt-service
 Quick Context:
 - Create backend service for JWT tokens
 - Use HS256 algorithm (decision from planning)
 - Include user_id, email, expiration in payload
 Key Actions:
 1. Create auth/jwt_service.py
 2. Implement generate_token(user_id, email)
 3. Implement verify_token(token)
 4. Add token refresh logic (Sprint 12 lesson!)
 5. Write unit tests for generation/validation
 Acceptance Criteria:
 - Tokens generate successfully
 - Token verification works
 - Refresh prevents expiration issues
 - Tests cover edge cases
 Relevant Lessons:
 Sprint 12: Handle token refresh explicitly to prevent mid-request expiration
 Dependencies: None (can start immediately)
 ```
 ## Progress Tracking
 As work progresses, the orchestrator updates Gitea:
 **Add Progress Comment:**
 ```
 add_comment(issue_number=45, body="JWT generation implemented. Running tests now.")
 ```
 **Update Issue Status:**
 ```
 update_issue(issue_number=45, state="closed")
 ```
 **Document Blockers:**
 ```
 add_comment(issue_number=46, body="BLOCKED: Waiting for #45 to complete (dependency)")
 ```
 **Track Parallel Execution:**
 ```
 Parallel Execution Status:
 Batch 1:
  #45 - JWT service - COMPLETED (12:45)
  #48 - API docs - IN PROGRESS (75%)
 Batch 2 (now unblocked):
  #46 - Login endpoint - READY TO START
  #49 - Auth tests - READY TO START
 #45 completed! #46 and #49 are now unblocked.
 Starting #46 while #48 continues...
 ```
 ## Checkpoint Resume Support
 If a previous session was interrupted (agent stopped, failure, budget exhausted), checkpoints enable resumption.
 **Checkpoint Detection:**
 The orchestrator scans issue comments for `## Checkpoint` markers containing:
 - Branch name
 - Last commit hash
 - Completed/pending steps
 - Files modified
 **Resume Flow:**
 ```
 User: /sprint-start
 Orchestrator: Checking for checkpoints...
 Found checkpoint for #45 (JWT service):
  Branch: feat/45-jwt-service
  Last activity: 2 hours ago
  Progress: 4/7 steps completed
  Pending: Write tests, add refresh, commit
 Options:
  1. Resume from checkpoint (recommended)
  2. Start fresh (lose previous work)
  3. Review checkpoint details
 User: 1
 Orchestrator: Resuming #45 from checkpoint...
  ✓ Branch exists
  ✓ Files match checkpoint
  ✓ Dispatching executor with context
 Executor continues from pending steps...
 ```
 **Checkpoint Format:**
 Executors save checkpoints after major steps:
 ```markdown
 ## Checkpoint
 **Branch:** feat/45-jwt-service
 **Commit:** abc123
 **Phase:** Testing
 ### Completed Steps
 - [x] Step 1
 - [x] Step 2
 ### Pending Steps
 - [ ] Step 3
 - [ ] Step 4
 ```
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
@@ -421,18 +50,3 @@ When executing this command, display the plugin header:
 ║  [Sprint Name]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Replace `[Sprint Name]` with the actual sprint/milestone name from Gitea.
 Then proceed with the command workflow.
 ## Getting Started
 Simply invoke `/sprint-start` and the orchestrator will:
 1. Review your sprint backlog
 2. Analyze dependencies and plan parallel execution
 3. Search for relevant lessons
 4. Dispatch tasks (parallel when possible)
 5. Track progress as you work
 The orchestrator keeps you focused, maximizes parallelism, and ensures nothing is forgotten.
--- a/plugins/projman/commands/sprint-status.md
+++ b/plugins/projman/commands/sprint-status.md
@@ -1,247 +1,78 @@
 ---
-description: Check current sprint progress and identify blockers
+description: Check current sprint progress, identify blockers, optionally generate dependency diagram
 ---
-# Sprint Status Check
+# Sprint Status
-This command provides a quick overview of your current sprint progress, including open issues, completed work, dependency status, and potential blockers.
+## Skills Required
-## What This Command Does
+- skills/mcp-tools-reference.md
 - skills/progress-tracking.md
 - skills/dependency-management.md
-1. **Fetch Sprint Issues** - Lists all issues with current sprint labels/milestone
+## Purpose
 2. **Analyze Dependencies** - Shows dependency graph and blocked/unblocked tasks
 3. **Categorize by Status** - Groups issues into: Open, In Progress, Blocked, Completed
 4. **Identify Blockers** - Highlights issues with blocker comments or unmet dependencies
 5. **Show Progress Summary** - Provides completion percentage and parallel execution status
 6. **Highlight Priorities** - Shows critical and high-priority items needing attention
-## Usage
+Check current sprint progress, identify blockers, and show execution status. Optionally generate a visual dependency diagram.
-Simply run `/sprint-status` to get a comprehensive sprint overview.
+## Invocation
 ## MCP Tools Used
 This command uses the following Gitea MCP tools:
 **Issue Tools:**
 - `list_issues(state="open")` - Fetch open issues
 - `list_issues(state="closed")` - Fetch completed issues
 - `get_issue(number)` - Get detailed issue information for blockers
 **Dependency Tools:**
 - `list_issue_dependencies(issue_number)` - Get dependencies for each issue
 - `get_execution_order(issue_numbers)` - Get parallel execution batches
 **Milestone Tools:**
 - `get_milestone(milestone_id)` - Get milestone progress
 ## Expected Output
 ```
-Sprint Status Report
+/sprint-status              # Text-based status report
-====================
+/sprint-status --diagram    # Include Mermaid dependency diagram
 Sprint: Sprint 18 - Authentication System
 Milestone: Due 2025-02-01 (5 days remaining)
 Date: 2025-01-18
 Progress Summary:
 - Total Issues: 8
 - Completed: 3 (37.5%)
 - In Progress: 2 (25%)
 - Ready: 2 (25%)
 - Blocked: 1 (12.5%)
 Dependency Graph:
 #45 -> #46 -> #47
  |
  v
 #49 -> #50
 Parallel Execution Status:
 +-----------------------------------------------+
 | Batch 1 (COMPLETED):                           |
 |   #45 - Implement JWT service                  |
 |   #48 - Update API documentation               |
 +-----------------------------------------------+
 | Batch 2 (IN PROGRESS):                         |
 |   #46 - Build login endpoint (75%)             |
 |   #49 - Add auth tests (50%)                   |
 +-----------------------------------------------+
 | Batch 3 (BLOCKED):                             |
 |   #47 - Create login form (waiting for #46)    |
 +-----------------------------------------------+
 Completed Issues (3):
  #45: [Sprint 18] feat: Implement JWT service [Type/Feature, Priority/High]
  #48: [Sprint 18] docs: Update API documentation [Type/Docs, Priority/Medium]
  #51: [Sprint 18] chore: Update dependencies [Type/Chore, Priority/Low]
 In Progress (2):
  #46: [Sprint 18] feat: Build login endpoint [Type/Feature, Priority/High]
       Status: In Progress | Phase: Implementation | Tool Calls: 45/100
       Progress: 3/5 steps | Current: Writing validation logic
  #49: [Sprint 18] test: Add auth tests [Type/Test, Priority/Medium]
       Status: In Progress | Phase: Testing | Tool Calls: 30/100
       Progress: 2/4 steps | Current: Testing edge cases
 Ready to Start (2):
  #50: [Sprint 18] feat: Integrate OAuth providers [Type/Feature, Priority/Low]
  #52: [Sprint 18] feat: Add email verification [Type/Feature, Priority/Medium]
 Blocked Issues (1):
  #47: [Sprint 18] feat: Create login form [Type/Feature, Priority/High]
     Blocked by: #46 (in progress)
 Priority Alerts:
  1 high-priority item blocked: #47
  All critical items completed
 Recommendations:
 1. Focus on completing #46 (Login endpoint) - unblocks #47
 2. Continue parallel work on #49 (Auth tests)
 3. #50 and #52 are ready - can start in parallel
 ```
-## Dependency Analysis
+## Workflow
-The status check analyzes dependencies to show:
+1. **Fetch Sprint Issues** - Get all issues for current milestone
 2. **Calculate Progress** - Count completed vs total issues
 3. **Identify Active Tasks** - Find issues with `Status/In-Progress`
 4. **Identify Blockers** - Find issues with `Status/Blocked`
 5. **Show Dependency Status** - Which tasks are now unblocked
 6. **Parse Progress Comments** - Extract real-time status from structured comments
-**Blocked Issues:**
+### If --diagram flag:
 - Issues waiting for other issues to complete
 - Shows which issue is blocking and its current status
-**Unblocked Issues:**
+7. **Fetch Dependencies** - Use `list_issue_dependencies` for each issue
- Issues with no pending dependencies
+8. **Get Execution Order** - Use `get_execution_order` for batch grouping
- Ready to be picked up immediately
+9. **Generate Mermaid Syntax** - Create flowchart with status colors
-**Parallel Opportunities:**
+## Output Format
 - Multiple unblocked issues that can run simultaneously
 - Maximizes sprint velocity
-## Filtering Options
+See `skills/progress-tracking.md` for the progress display format.
-You can optionally filter the status check:
+### Diagram Format (--diagram)
-**By Label:**
+```mermaid
-```
+flowchart TD
-Show only high-priority issues:
+    subgraph batch1["Batch 1 - No Dependencies"]
-list_issues(labels=["Priority/High"])
+        241["#241: sprint-diagram"]
        242["#242: confidence threshold"]
    end
    classDef completed fill:#90EE90,stroke:#228B22
    classDef inProgress fill:#FFD700,stroke:#DAA520
    classDef open fill:#ADD8E6,stroke:#4682B4
    classDef blocked fill:#FFB6C1,stroke:#CD5C5C
    class 241 completed
    class 242 inProgress
 ```
-**By Milestone:**
+### Status Colors
 ```
 Show issues for specific sprint:
 list_issues(milestone="Sprint 18")
 ```
-**By Component:**
+| Status | Color | Hex |
-```
+|--------|-------|-----|
-Show only backend issues:
+| Completed | Green | #90EE90 |
-list_issues(labels=["Component/Backend"])
+| In Progress | Yellow | #FFD700 |
-```
+| Open | Blue | #ADD8E6 |
-
+| Blocked | Red | #FFB6C1 |
 ## Progress Comment Parsing
 Agents post structured progress comments in this format:
 ```markdown
 ## Progress Update
 **Status:** In Progress | Blocked | Failed
 **Phase:** [current phase name]
 **Tool Calls:** X (budget: Y)
 ### Completed
 - [x] Step 1
 ### In Progress
 - [ ] Current step
 ### Blockers
 - None | [blocker description]
 ```
 **To extract real-time progress:**
 1. Fetch issue comments: `get_issue(number)` includes recent comments
 2. Look for comments containing `## Progress Update`
 3. Parse the **Status:** line for current state
 4. Parse **Tool Calls:** for budget consumption
 5. Extract blockers from `### Blockers` section
 **Progress Summary Display:**
 ```
 In Progress Issues:
  #45: [Sprint 18] feat: JWT service
       Status: In Progress | Phase: Testing | Tool Calls: 67/100
       Completed: 4/6 steps | Current: Writing unit tests
  #46: [Sprint 18] feat: Login endpoint
       Status: Blocked | Phase: Implementation | Tool Calls: 23/100
       Blocker: Waiting for JWT service (#45)
 ```
 ## Blocker Detection
 The command identifies blocked issues by:
 1. **Progress Comments** - Parse `### Blockers` section from structured comments
 2. **Status Labels** - Check for `Status/Blocked` label on issue
 3. **Dependency Analysis** - Uses `list_issue_dependencies` to find unmet dependencies
 4. **Comment Keywords** - Checks for "blocked", "blocker", "waiting for"
 5. **Stale Issues** - Issues with no recent activity (>7 days)
 ## When to Use
 Run `/sprint-status` when you want to:
 - Start your day and see what needs attention
 - Prepare for standup meetings
 - Check if the sprint is on track
 - Identify bottlenecks or blockers
 - Decide what to work on next
 - See which tasks can run in parallel
 ## Integration with Other Commands
 - Use `/sprint-start` to begin working on identified tasks
 - Use `/sprint-close` when all issues are completed
 - Use `/sprint-plan` to adjust scope if blocked items can't be unblocked
 ## Visual Output
 When executing this command, display the plugin header followed by a progress block:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
-║  ⚡ EXECUTION                                                    ║
+║  📊 STATUS                                                       ║
 ║  [Sprint Name]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ┌─ Sprint Progress ────────────────────────────────────────────────┐
 │  [Sprint Name]                                                   │
 │  ████████████░░░░░░░░░░░░░░░░░░ 40% complete                     │
 │  ✅ Done: 4    ⏳ Active: 2    ⬚ Pending: 4                       │
 └──────────────────────────────────────────────────────────────────┘
 ```
 Replace `[Sprint Name]` with the actual sprint/milestone name. Calculate percentage from completed vs total issues.
 Then proceed with the full status report.
 ## Example Usage
 ```
 User: /sprint-status
 Sprint Status Report
 ====================
 Sprint: Sprint 18 - Authentication System
 Progress: 3/8 (37.5%)
 Next Actions:
 1. Complete #46 - it's blocking #47
 2. Start #50 or #52 - both are unblocked
 Would you like me to generate execution prompts for the unblocked tasks?
 ```
--- a/plugins/projman/commands/suggest-version.md
+++ b/plugins/projman/commands/suggest-version.md
@@ -4,92 +4,44 @@ description: Analyze CHANGELOG.md and suggest appropriate semantic version bump
 # Suggest Version
 ## Purpose
 Analyze CHANGELOG.md and suggest appropriate semantic version bump.
-## Behavior
+## Invocation
-1. **Read current state**:
+Run `/suggest-version` after updating CHANGELOG or before release.
   - 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**:
+## Workflow
-   - Extract all entries under `### Added`, `### Changed`, `### Fixed`, `### Removed`, `### Deprecated`
+
 1. **Read Current State**
   - CHANGELOG.md for current version and [Unreleased] content
   - marketplace.json for marketplace version
   - Individual plugin versions
 2. **Analyze [Unreleased] Section**
   - Extract entries under Added, Changed, Fixed, Removed, Deprecated
   - Categorize changes by impact
-3. **Apply SemVer rules**:
+3. **Apply SemVer Rules**
-   | Change Type | Version Bump | Indicators |
+| Change Type | Bump | Indicators |
-   |-------------|--------------|------------|
+|-------------|------|------------|
-   | **MAJOR** (X.0.0) | Breaking changes | `### Removed`, `### Changed` with "BREAKING:", renamed/removed APIs |
+| MAJOR (X.0.0) | Breaking changes | Removed, "BREAKING:" in Changed |
-   | **MINOR** (x.Y.0) | New features, backwards compatible | `### Added` with new commands/plugins/features |
+| MINOR (x.Y.0) | New features | Added with new commands/plugins |
-   | **PATCH** (x.y.Z) | Bug fixes only | `### Fixed` only, `### Changed` for non-breaking tweaks |
+| PATCH (x.y.Z) | Bug fixes only | Fixed only |
-4. **Output recommendation**:
+4. **Output Recommendation**
-   ```
+   - Current version
-   ## Version Analysis
+   - Summary of changes
-
+   - Recommended bump with reason
-   **Current version:** X.Y.Z
+   - Release command
   **[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
 ```
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Version Analysis                                                ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the version analysis.
 ## 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
--- a/plugins/projman/commands/test-check.md
+++ b/plugins/projman/commands/test-check.md
@@ -1,177 +0,0 @@
 ---
 name: test-check
 description: Run tests and verify coverage before sprint close
 ---
 # Test Check for Sprint Close
 Verify test status and coverage before closing the sprint.
 ## Framework Detection
 Detect the test framework by checking for:
 | Indicator | Framework | Command |
 |-----------|-----------|---------|
 | `pytest.ini`, `pyproject.toml` with pytest, `tests/` with `test_*.py` | pytest | `pytest` |
 | `package.json` with jest | Jest | `npm test` or `npx jest` |
 | `package.json` with mocha | Mocha | `npm test` or `npx mocha` |
 | `package.json` with vitest | Vitest | `npm test` or `npx vitest` |
 | `go.mod` with `*_test.go` files | Go test | `go test ./...` |
 | `Cargo.toml` with `tests/` or `#[test]` | Cargo test | `cargo test` |
 | `Makefile` with test target | Make | `make test` |
 | `tox.ini` | tox | `tox` |
 | `setup.py` with test command | setuptools | `python setup.py test` |
 ## Execution Steps
 ### 1. Detect Framework
 1. Check for framework indicators in project root
 2. If multiple found, list them and ask which to run
 3. If none found, report "No test framework detected"
 ### 2. Run Tests
 1. Execute the appropriate test command
 2. Capture stdout/stderr
 3. Parse results for pass/fail counts
 4. Note: Some frameworks may require dependencies to be installed first
 ### 3. Coverage Check (if available)
 Coverage tools by framework:
 - **Python**: `pytest --cov` or `coverage run`
 - **JavaScript**: Jest has built-in coverage (`--coverage`)
 - **Go**: `go test -cover`
 - **Rust**: `cargo tarpaulin` or `cargo llvm-cov`
 If coverage is configured:
 - Report overall coverage percentage
 - List files with 0% coverage that were changed in sprint
 ### 4. Sprint File Analysis
 If sprint context is available:
 - Identify which sprint files have tests
 - Flag sprint files with no corresponding test coverage
 ## Output Format
 ```
 ## Test Check Summary
 ### Test Results
 - Framework: {detected framework}
 - Status: {PASS/FAIL}
 - Passed: {n} | Failed: {n} | Skipped: {n}
 - Duration: {time}
 ### Failed Tests
 - test_name: error message (file:line)
 ### Coverage (if available)
 - Overall: {n}%
 - Sprint files coverage:
  - file.py: {n}%
  - file.py: NO TESTS
 ### Recommendation
 {READY FOR CLOSE / TESTS MUST PASS / COVERAGE GAPS TO ADDRESS}
 ```
 ## Behavior Flags
 The command accepts optional flags via natural language:
 | Request | Behavior |
 |---------|----------|
 | "run tests with coverage" | Include coverage report |
 | "run tests verbose" | Show full output |
 | "just check, don't run" | Report framework detection only |
 | "run specific tests for X" | Run tests matching pattern |
 ## Framework-Specific Notes
 ### Python (pytest)
 ```bash
 # Basic run
 pytest
 # With coverage
 pytest --cov=src --cov-report=term-missing
 # Verbose
 pytest -v
 # Specific tests
 pytest tests/test_specific.py -k "test_function_name"
 ```
 ### JavaScript (Jest/Vitest)
 ```bash
 # Basic run
 npm test
 # With coverage
 npm test -- --coverage
 # Specific tests
 npm test -- --testPathPattern="specific"
 ```
 ### Go
 ```bash
 # Basic run
 go test ./...
 # With coverage
 go test -cover ./...
 # Verbose
 go test -v ./...
 ```
 ### Rust
 ```bash
 # Basic run
 cargo test
 # Verbose
 cargo test -- --nocapture
 ```
 ## Do NOT
 - Modify test files
 - Skip failing tests to make the run pass
 - Run tests in production environments (check for .env indicators)
 - Install dependencies without asking first
 - Run tests that require external services without confirmation
 ## Error Handling
 If tests fail:
 1. Report the failure clearly
 2. List failed test names and error summaries
 3. Recommend: "TESTS MUST PASS before sprint close"
 4. Offer to help debug specific failures
 If framework not detected:
 1. List what was checked
 2. Ask user to specify the test command
 3. Offer common suggestions based on file types found
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🏁 CLOSING                                                      ║
 ║  Test Verification                                               ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the test check workflow.
--- a/plugins/projman/commands/test-gen.md
+++ b/plugins/projman/commands/test-gen.md
@@ -1,131 +0,0 @@
 ---
 description: Generate tests for specified code - creates unit, integration, or e2e tests
 ---
 # Test Generation
 Generate comprehensive tests for specified code.
 ## Usage
 ```
 /test-gen <target> [--type=<type>] [--framework=<framework>]
 ```
 **Target:** File path, function name, class name, or module
 **Type:** unit (default), integration, e2e, snapshot
 **Framework:** Auto-detected or specify (pytest, jest, vitest, go test, etc.)
 ## Process
 1. **Analyze Target Code**
   - Parse function/class signatures
   - Identify dependencies and side effects
   - Map input types and return types
   - Find edge cases from logic branches
 2. **Determine Test Strategy**
   | Code Pattern | Test Approach |
   |--------------|---------------|
   | Pure function | Unit tests with varied inputs |
   | Class with state | Setup/teardown, state transitions |
   | External calls | Mocks/stubs for dependencies |
   | Database ops | Integration tests with fixtures |
   | API endpoints | Request/response tests |
   | UI components | Snapshot + interaction tests |
 3. **Generate Tests**
   For each target function/method:
   - Happy path test (expected inputs → expected output)
   - Edge cases (empty, null, boundary values)
   - Error cases (invalid inputs → expected errors)
   - Type variations (if dynamic typing)
 4. **Test Structure**
   ```python
   # Example output for Python/pytest
   import pytest
   from module import target_function
   class TestTargetFunction:
       """Tests for target_function."""
       def test_happy_path(self):
           """Standard input produces expected output."""
           result = target_function(valid_input)
           assert result == expected_output
       def test_empty_input(self):
           """Empty input handled gracefully."""
           result = target_function("")
           assert result == default_value
       def test_invalid_input_raises(self):
           """Invalid input raises ValueError."""
           with pytest.raises(ValueError):
               target_function(invalid_input)
       @pytest.mark.parametrize("input,expected", [
           (case1_in, case1_out),
           (case2_in, case2_out),
       ])
       def test_variations(self, input, expected):
           """Multiple input variations."""
           assert target_function(input) == expected
   ```
 5. **Output**
 ```
 ## Tests Generated
 ### Target: src/orders.py:calculate_total
 ### File Created: tests/test_orders.py
 ### Tests (6 total)
 - test_calculate_total_happy_path
 - test_calculate_total_empty_items
 - test_calculate_total_negative_price_raises
 - test_calculate_total_with_discount
 - test_calculate_total_with_tax
 - test_calculate_total_parametrized_cases
 ### Coverage Estimate
 - Line coverage: ~85%
 - Branch coverage: ~70%
 ### Run Tests
 pytest tests/test_orders.py -v
 ```
 ## Framework Detection
 | Files Present | Framework Used |
 |---------------|----------------|
 | pytest.ini, conftest.py | pytest |
 | jest.config.* | jest |
 | vitest.config.* | vitest |
 | *_test.go | go test |
 | Cargo.toml | cargo test |
 | mix.exs | ExUnit |
 ## Visual Output
 When executing this command, display the plugin header:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  Test Generation                                                 ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 Then proceed with the test generation workflow.
 ## Integration with /test-check
 - `/test-gen` creates new tests
 - `/test-check` verifies tests pass
 - Typical flow: `/test-gen src/new_module.py` → `/test-check`
--- a/plugins/projman/commands/test.md
+++ b/plugins/projman/commands/test.md
@@ -0,0 +1,106 @@
 ---
 description: Run tests with coverage or generate tests for specified code
 ---
 # Test
 ## Skills Required
 - skills/test-standards.md
 ## Purpose
 Unified testing command for running tests and generating new tests.
 ## Invocation
 ```
 /test                       # Default: run tests
 /test run                   # Run tests, check coverage
 /test run --coverage        # Run with coverage report
 /test run --verbose         # Verbose output
 /test gen <target>          # Generate tests for target
 /test gen <target> --type=unit      # Specific test type
 /test gen <target> --framework=jest # Specific framework
 ```
 ## Mode Selection
 - No args or `run` → **Run Mode**
 - `gen <target>` → **Generate Mode**
 ---
 ## Mode: Run
 Run tests and verify coverage before sprint close.
 ### Workflow
 1. **Detect Framework**
   Check for: pytest.ini, package.json, go.mod, Cargo.toml, etc.
 2. **Run Tests**
   Execute appropriate test command for detected framework.
 3. **Check Coverage** (if --coverage or available)
   Report coverage percentage.
 4. **Sprint File Analysis**
   Identify sprint files without tests.
 See `skills/test-standards.md` for framework detection and commands.
 ### DO NOT (Run Mode)
 - Modify test files
 - Skip failing tests to make run pass
 - Run tests in production environments
 - Install dependencies without asking
 ---
 ## Mode: Generate
 Generate comprehensive tests for specified code.
 ### Arguments
 - **Target:** File path, function name, class name, or module
 - **--type:** unit (default), integration, e2e, snapshot
 - **--framework:** Auto-detected or specified (pytest, jest, vitest, go test)
 ### Workflow
 1. **Analyze Target Code**
   Parse signatures, identify dependencies, map types.
 2. **Determine Test Strategy**
   Based on code pattern:
   - Pure function → unit tests with multiple inputs
   - Class → instance lifecycle tests
   - API endpoint → request/response tests
   - Component → render and interaction tests
 3. **Generate Tests**
   - Happy path cases
   - Edge cases (empty, null, boundary)
   - Error cases (invalid input, exceptions)
   - Type variations (if applicable)
 4. **Output File**
   Create test file with proper structure and naming.
 See `skills/test-standards.md` for test patterns and structure.
 ---
 ## Visual Output
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🧪 TEST                                                         ║
 ║  [Mode: Run | Generate]                                          ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
--- a/plugins/projman/mcp-servers/gitea
+++ b/plugins/projman/mcp-servers/gitea
@@ -1 +0,0 @@
 ../../../mcp-servers/gitea
--- a/plugins/projman/skills/branch-security.md
+++ b/plugins/projman/skills/branch-security.md
@@ -0,0 +1,98 @@
 ---
 name: branch-security
 description: Branch detection, protection rules, and branch-aware authorization
 ---
 # Branch Security
 ## Purpose
 Defines branch detection, classification, and branch-aware authorization rules.
 ## When to Use
 - **Planner agent**: Before planning any sprint work
 - **Orchestrator agent**: Before executing any sprint tasks
 - **Executor agent**: Before modifying any files
 - **Commands**: `/sprint-plan`, `/sprint-start`, `/sprint-close`
 ---
 ## Branch Detection
 ```bash
 git branch --show-current
 ```
 ## Branch Classification
 | Branch Pattern | Classification | Capabilities |
 |----------------|----------------|--------------|
 | `development`, `develop`, `feat/*`, `fix/*`, `dev/*` | Development | Full access |
 | `staging`, `stage/*` | Staging | Read-only code, can create issues |
 | `main`, `master`, `prod/*` | Production | READ-ONLY, no changes |
 ---
 ## Behavior by Classification
 ### Development Branches
 - Full planning and execution capabilities
 - Can create/modify issues, wiki, lessons
 - Can execute tasks and modify code
 - Normal operation
 ### Staging Branches
 - Can create issues to document bugs
 - CANNOT modify application code
 - Can modify `.env` files only
 - Warn user about limitations
 ### Production Branches
 - READ-ONLY mode enforced
 - Cannot create issues or modify anything
 - MUST stop immediately and instruct user to switch
 ---
 ## Stop Messages
 ### Production Branch
 ```
 BRANCH SECURITY: Production branch detected
 You are on branch: [branch-name]
 Planning and execution are NOT allowed on production branches.
 Please switch to a development branch:
  git checkout development
 Or create a feature branch:
  git checkout -b feat/[issue-number]-[description]
 ```
 ### Staging Branch Warning
 ```
 STAGING BRANCH: Limited capabilities
 Available: Create issues to document bugs
 Not available: Sprint planning, code modifications
 Switch to development for full capabilities:
  git checkout development
 ```
 ---
 ## Branch Naming Conventions
 | Type | Pattern | Example |
 |------|---------|---------|
 | Features | `feat/<issue>-<desc>` | `feat/45-jwt-service` |
 | Bug fixes | `fix/<issue>-<desc>` | `fix/46-login-timeout` |
 | Debugging | `debug/<issue>-<desc>` | `debug/47-memory-leak` |
 **Validation:**
 - Issue number MUST be present
 - Prefix MUST be `feat/`, `fix/`, or `debug/`
 - Description: kebab-case (lowercase, hyphens)
--- a/plugins/projman/skills/dependency-management.md
+++ b/plugins/projman/skills/dependency-management.md
@@ -0,0 +1,138 @@
 ---
 name: dependency-management
 description: Parallel execution planning, dependency graphs, and file conflict prevention
 ---
 # Dependency Management
 ## Purpose
 Defines how to analyze dependencies, plan parallel execution, and prevent file conflicts.
 ## When to Use
 - **Orchestrator agent**: When starting sprint execution
 - **Commands**: `/sprint-start`, `/sprint-diagram`
 ---
 ## Get Execution Order
 ```python
 get_execution_order(repo="org/repo", issue_numbers=[45, 46, 47, 48, 49])
 ```
 Returns batches that can run in parallel:
 ```json
 {
  "batches": [
    [45, 48],   // Batch 1: No dependencies
    [46, 49],   // Batch 2: Depends on batch 1
    [47]        // Batch 3: Depends on batch 2
  ]
 }
 ```
 **Independent tasks in the same batch can run in parallel.**
 ---
 ## Parallel Execution Display
 ```
 Parallel Execution Batches:
 ┌─────────────────────────────────────────────────────────────┐
 │ Batch 1 (can start immediately):                            │
 │   • #45 [Sprint 18] feat: Implement JWT service             │
 │   • #48 [Sprint 18] docs: Update API documentation          │
 ├─────────────────────────────────────────────────────────────┤
 │ Batch 2 (after batch 1):                                    │
 │   • #46 [Sprint 18] feat: Build login endpoint (needs #45)  │
 │   • #49 [Sprint 18] test: Add auth tests (needs #45)        │
 ├─────────────────────────────────────────────────────────────┤
 │ Batch 3 (after batch 2):                                    │
 │   • #47 [Sprint 18] feat: Create login form (needs #46)     │
 └─────────────────────────────────────────────────────────────┘
 ```
 ---
 ## File Conflict Prevention (MANDATORY)
 **CRITICAL: Before dispatching parallel agents, check for file overlap.**
 ### Pre-Dispatch Conflict Check
 1. **Identify target files** for each task in the batch
 2. **Check for overlap** - Do any tasks modify the same file?
 3. **If overlap detected** - Sequentialize those specific tasks
 ### Example Analysis
 ```
 Batch 1 Analysis:
  #45 - Implement JWT service
        Files: auth/jwt_service.py, auth/__init__.py
  #48 - Update API documentation
        Files: docs/api.md, README.md
  Overlap: NONE → Safe to parallelize ✅
 Batch 2 Analysis:
  #46 - Build login endpoint
        Files: api/routes/auth.py, auth/__init__.py
  #49 - Add auth tests
        Files: tests/test_auth.py, auth/__init__.py
  Overlap: auth/__init__.py → CONFLICT! ⚠️
  Action: Sequentialize #46 and #49 (run #46 first)
 ```
 ### Conflict Resolution Rules
 | Conflict Type | Action |
 |---------------|--------|
 | Same file in checklist | Sequentialize tasks |
 | Same directory | Review if safe, usually OK |
 | Shared test file | Sequentialize or assign different test files |
 | Shared config | Sequentialize |
 ---
 ## Branch Isolation Protocol
 Each task MUST have its own branch:
 ```
 Task #45 → feat/45-jwt-service (isolated)
 Task #48 → feat/48-api-docs (isolated)
 ```
 Never have two agents work on the same branch.
 ---
 ## Sequential Merge After Completion
 ```
 1. Task #45 completes → merge feat/45-jwt-service to development
 2. Task #48 completes → merge feat/48-api-docs to development
 3. Never merge simultaneously - always sequential to detect conflicts
 ```
 **If Merge Conflict Occurs:**
 1. Stop second task
 2. Resolve conflict manually or assign to human
 3. Resume/restart second task with updated base
 ---
 ## Creating Dependencies
 ```python
 # Issue 46 depends on issue 45
 create_issue_dependency(
    repo="org/repo",
    issue_number=46,
    depends_on=45
 )
 ```
 This ensures #46 won't be scheduled until #45 completes.
--- a/plugins/projman/skills/git-workflow.md
+++ b/plugins/projman/skills/git-workflow.md
@@ -0,0 +1,163 @@
 ---
 name: git-workflow
 description: Branch naming, merge process, and git operations
 ---
 # Git Workflow
 ## Purpose
 Defines branch naming conventions, merge protocols, and git operations.
 ## When to Use
 - **Orchestrator agent**: When coordinating git operations
 - **Executor agent**: When creating branches and commits
 - **Commands**: `/sprint-start`, `/sprint-close`
 ---
 ## Branch Naming Convention (MANDATORY)
 | Type | Pattern | Example |
 |------|---------|---------|
 | Features | `feat/<issue>-<desc>` | `feat/45-jwt-service` |
 | Bug fixes | `fix/<issue>-<desc>` | `fix/46-login-timeout` |
 | Debugging | `debug/<issue>-<desc>` | `debug/47-memory-leak` |
 ### Validation Rules
 - Issue number MUST be present
 - Prefix MUST be `feat/`, `fix/`, or `debug/`
 - Description: kebab-case (lowercase, hyphens)
 - No spaces or special characters
 ### Creating Feature Branch
 ```bash
 git checkout development
 git pull origin development
 git checkout -b feat/45-jwt-service
 ```
 ---
 ## Branch Isolation
 **Each task MUST have its own branch.**
 ```
 Task #45 → feat/45-jwt-service (isolated)
 Task #48 → feat/48-api-docs (isolated)
 ```
 Never have two agents work on the same branch.
 ---
 ## Sequential Merge Protocol
 After task completion, merge sequentially (never simultaneously):
 ```
 1. Task #45 completes → merge feat/45-jwt-service to development
 2. Task #48 completes → merge feat/48-api-docs to development
 3. Never merge simultaneously - always sequential to detect conflicts
 ```
 ### Merge Steps
 ```bash
 git checkout development
 git pull origin development
 git merge feat/45-jwt-service --no-ff
 git push origin development
 git branch -d feat/45-jwt-service
 ```
 ### If Merge Conflict Occurs
 1. Stop second task
 2. Resolve conflict manually or assign to human
 3. Resume/restart second task with updated base
 ---
 ## Commit Message Format
 ```
 <type>: <description>
 [Optional body with details]
 [Optional: Closes #XX]
 ```
 ### Types
 | Type | Use For |
 |------|---------|
 | `feat` | New feature |
 | `fix` | Bug fix |
 | `refactor` | Code refactoring |
 | `docs` | Documentation |
 | `test` | Test additions |
 | `chore` | Maintenance |
 ### Auto-Close Keywords
 Use in commit message to auto-close issues:
 - `Closes #XX`
 - `Fixes #XX`
 - `Resolves #XX`
 ### Example
 ```
 feat: implement JWT token generation
 - Add generate_token(user_id, email) function
 - Add verify_token(token) function
 - Include refresh logic per Sprint 12 lesson
 Closes #45
 ```
 ---
 ## Merge Request Template
 When branch protection requires MR (check via `get_branch_protection`):
 ```markdown
 ## Summary
 Brief description of changes made.
 ## Related Issues
 Closes #45
 ## Testing
 - Describe how changes were tested
 - Include test commands if relevant
 ```
 **NEVER include subtask checklists in MR body.** The issue already has them.
 ---
 ## Sprint Close Git Operations
 Offer to handle:
 1. Commit any remaining changes
 2. Merge feature branches to development
 3. Tag sprint completion (if release)
 4. Clean up merged branches
 ```bash
 # Tag sprint completion
 git tag -a v0.18.0 -m "Sprint 18 release"
 git push origin v0.18.0
 # Clean up merged branches
 git branch -d feat/45-jwt-service feat/46-login-endpoint
 ```
--- a/plugins/projman/skills/input-detection.md
+++ b/plugins/projman/skills/input-detection.md
@@ -0,0 +1,115 @@
 ---
 name: input-detection
 description: Detect planning input source (file, wiki, or conversation)
 ---
 # Input Source Detection
 ## Purpose
 Defines how to detect where planning input is coming from and how to handle each source.
 ## When to Use
 - **Planner agent**: At start of sprint planning
 - **Commands**: `/sprint-plan`
 ---
 ## Detection Priority
 | Priority | Source | Detection | Action |
 |----------|--------|-----------|--------|
 | 1 | Local file | `docs/changes/*.md` exists | Parse frontmatter, migrate to wiki, delete local |
 | 2 | Existing wiki | `Change VXX.X.X: Proposal` exists | Use as-is, create implementation page |
 | 3 | Conversation | Neither exists | Create wiki from discussion context |
 ---
 ## Local File Format
 ```yaml
 ---
 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 Steps
 1. **Check for local files:**
   ```bash
   ls docs/changes/*.md
   ```
 2. **Check for existing wiki proposal:**
   ```python
   list_wiki_pages(repo="org/repo")
   # Filter for "Change V" prefix matching version
   ```
 3. **If neither found:** Use conversation context
 4. **If multiple sources found:** Ask user which to use
 ---
 ## 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)
 ```
 ---
 ## Migration Flow (Local File → Wiki)
 When using local file as input:
 1. **Parse frontmatter** to extract metadata
 2. **Create wiki proposal page:** `Change V4.1.0: Proposal`
 3. **Create implementation page:** `Change V4.1.0: Proposal (Implementation 1)`
 4. **Delete local file** - wiki is now source of truth
 ```
 Migration complete:
 ✓ Created: "Change V4.1.0: Proposal" (wiki)
 ✓ Created: "Change V4.1.0: Proposal (Implementation 1)" (wiki)
 ✓ Deleted: docs/changes/v4.1.0-wiki-planning.md (migrated)
 ```
 ---
 ## Ambiguous Input Handling
 If multiple valid sources found:
 ```
 Multiple input sources detected:
 1. Local file: docs/changes/v4.1.0-feature.md
   - Version: 4.1.0
   - Title: New Feature
 2. Wiki proposal: Change V4.1.0: Proposal
   - Status: In Progress
   - Date: 2026-01-20
 Which should I use for planning?
  [1] Local file (will migrate to wiki)
  [2] Existing wiki proposal
  [3] Start fresh from conversation
 ```
--- a/plugins/projman/skills/issue-conventions.md
+++ b/plugins/projman/skills/issue-conventions.md
@@ -0,0 +1,130 @@
 ---
 name: issue-conventions
 description: Issue title format, wiki references, and creation standards
 ---
 # Issue Conventions
 ## Purpose
 Defines standard formats for issue titles, bodies, and wiki references.
 ## When to Use
 - **Planner agent**: When creating issues during sprint planning
 - **Commands**: `/sprint-plan`
 ---
 ## Title Format (MANDATORY)
 ```
 [Sprint XX] <type>: <description>
 ```
 ### Types
 | Type | Use For |
 |------|---------|
 | `feat` | New feature |
 | `fix` | Bug fix |
 | `refactor` | Code refactoring |
 | `docs` | Documentation |
 | `test` | Test additions/changes |
 | `chore` | Maintenance tasks |
 ### Examples
 - `[Sprint 17] feat: Add user email validation`
 - `[Sprint 17] fix: Resolve login timeout issue`
 - `[Sprint 18] refactor: Extract authentication module`
 - `[Sprint 18] test: Add JWT token edge case tests`
 - `[Sprint 19] docs: Update API documentation`
 ---
 ## Issue Body Structure
 Every issue body MUST include:
 ```markdown
 ## Description
 [Clear description of the task]
 ## Implementation
 **Wiki:** [Change VXX.X.X (Impl N)](wiki-link)
 ## Acceptance Criteria
 - [ ] Criteria 1
 - [ ] Criteria 2
 - [ ] Criteria 3
 ## Technical Notes
 [Optional: Architecture decisions, constraints, considerations]
 ```
 ---
 ## Wiki Reference (MANDATORY)
 Every issue MUST reference its implementation wiki page:
 ```markdown
 ## Implementation
 **Wiki:** [Change V4.1.0 (Impl 1)](https://gitea.example.com/org/repo/wiki/Change-V4.1.0%3A-Proposal-(Implementation-1))
 ```
 This enables:
 - Traceability between issues and proposals
 - Context for the broader feature being implemented
 - Connection to lessons learned
 ---
 ## Issue Creation Example
 ```python
 create_issue(
    repo="org/repo",
    title="[Sprint 17] feat: Implement JWT generation",
    body="""## Description
 Create a JWT token generation service for user authentication.
 ## Implementation
 **Wiki:** [Change V1.2.0 (Impl 1)](wiki-link)
 ## Acceptance Criteria
 - [ ] Generate tokens with user_id, email, expiration
 - [ ] Use HS256 algorithm
 - [ ] Include token refresh logic
 - [ ] Unit tests cover all paths
 ## Technical Notes
 - Token expiration: 24 hours
 - Refresh window: last 4 hours of validity
 - See Sprint 12 lesson on token refresh edge cases
 """,
    labels=["Type/Feature", "Priority/High", "Component/Auth", "Tech/Python", "Efforts/M"],
    milestone=17
 )
 ```
 ---
 ## Auto-Close Keywords
 Use in commit messages to auto-close issues:
 - `Closes #XX`
 - `Fixes #XX`
 - `Resolves #XX`
 Example commit:
 ```
 feat: implement JWT token generation
 - Add generate_token(user_id, email) function
 - Add verify_token(token) function
 - Include refresh logic per Sprint 12 lesson
 Closes #45
 ```
--- a/plugins/projman/skills/lessons-learned.md
+++ b/plugins/projman/skills/lessons-learned.md
@@ -0,0 +1,139 @@
 ---
 name: lessons-learned
 description: Capture and search workflow for lessons learned system
 ---
 # Lessons Learned System
 ## Purpose
 Defines the workflow for capturing lessons at sprint close and searching them at sprint start/plan.
 ## When to Use
 - **Planner agent**: Search lessons at sprint start
 - **Orchestrator agent**: Capture lessons at sprint close
 - **Commands**: `/sprint-plan`, `/sprint-start`, `/sprint-close`
 ---
 ## Searching Lessons (Sprint Start/Plan)
 **ALWAYS search for past lessons before planning or executing.**
 ```python
 search_lessons(
    repo="org/repo",
    query="relevant keywords",
    tags=["technology", "component"],
    limit=10
 )
 ```
 **Present findings:**
 ```
 Relevant lessons from previous sprints:
 📚 Sprint 12: "JWT Token Expiration Edge Cases"
   Tags: auth, jwt, python
   Key lesson: Handle token refresh explicitly
 📚 Sprint 8: "Service Extraction Boundaries"
   Tags: architecture, refactoring
   Key lesson: Define API contracts BEFORE extracting
 ```
 ---
 ## Capturing Lessons (Sprint Close)
 ### Interview Questions
 Ask these probing questions:
 1. What challenges did you face this sprint?
 2. What worked well and should be repeated?
 3. Were there any preventable mistakes?
 4. Did any technical decisions need adjustment?
 5. What would you do differently?
 ### Lesson Structure
 ```markdown
 # Sprint N - [Lesson Title]
 ## Metadata
 - **Implementation:** [Change VXX.X.X (Impl N)](wiki-link)
 - **Issues:** #XX, #XX
 - **Sprint:** Sprint N
 ## Context
 [What were you doing?]
 ## Problem
 [What went wrong / insight / challenge?]
 ## Solution
 [How did you solve it?]
 ## Prevention
 [How to avoid in future?]
 ## Tags
 technology, component, type, pattern
 ```
 ### Creating Lesson
 ```python
 create_lesson(
    repo="org/repo",
    title="Sprint N - Lesson Title",
    content="[structured content above]",
    tags=["tag1", "tag2"],
    category="sprints"
 )
 ```
 ---
 ## Tagging Strategy
 **By Technology:** python, javascript, docker, postgresql, redis, vue, fastapi
 **By Component:** backend, frontend, api, database, auth, deploy, testing, docs
 **By Type:** bug, feature, refactor, architecture, performance, security
 **By Pattern:** infinite-loop, edge-case, integration, boundaries, dependencies
 ---
 ## Example Lessons
 ### Technical Gotcha
 ```markdown
 # Sprint 16 - Claude Code Infinite Loop on Validation Errors
 ## Metadata
 - **Implementation:** [Change V1.2.0 (Impl 1)](wiki-link)
 - **Issues:** #45, #46
 - **Sprint:** Sprint 16
 ## Context
 Implementing input validation for authentication API.
 ## Problem
 Claude Code entered infinite loop when pytest validation tests failed.
 The loop occurred because error messages didn't change between attempts.
 ## Solution
 Added more descriptive error messages specifying what value failed and why.
 ## Prevention
 - Write validation test errors with specific values
 - If Claude loops, check if errors provide unique information
 - Add loop detection (fail after 3 identical errors)
 ## Tags
 testing, claude-code, validation, python, pytest
 ```
--- a/plugins/projman/skills/mcp-tools-reference.md
+++ b/plugins/projman/skills/mcp-tools-reference.md
@@ -0,0 +1,145 @@
 ---
 name: mcp-tools-reference
 description: Complete reference of available Gitea MCP tools with usage patterns
 ---
 # MCP Tools Reference
 ## Purpose
 Provides the complete reference of available MCP tools for Gitea operations. This skill ensures consistent tool usage across all commands and agents.
 ## When to Use
 - **All agents**: When performing any Gitea operation
 - **All commands**: That interact with issues, labels, milestones, wiki, or dependencies
 ## Critical Rules
 ### NEVER Use CLI Tools
 **FORBIDDEN - Do not use:**
 ```bash
 tea issue list
 tea issue create
 tea pr create
 gh issue list
 gh pr create
 curl -X POST "https://gitea.../api/..."
 ```
 **If you find yourself about to run a bash command for Gitea, STOP and use the MCP tool instead.**
 ### Required Parameter Format
 All tools require the `repo` parameter in `owner/repo` format:
 ```python
 # CORRECT
 get_labels(repo="org/repo")
 list_issues(repo="org/repo", state="open")
 # INCORRECT - Will fail!
 get_labels()  # Missing repo parameter
 ```
 ---
 ## Issue Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `list_issues` | Fetch issues | `repo`, `state`, `labels`, `milestone` |
 | `get_issue` | Get issue details | `repo`, `number` |
 | `create_issue` | Create new issue | `repo`, `title`, `body`, `labels`, `assignee`, `milestone` |
 | `update_issue` | Update issue | `repo`, `number`, `state`, `labels`, `body` |
 | `add_comment` | Add comment to issue | `repo`, `number`, `body` |
 ## Label Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `get_labels` | Fetch all labels | `repo` |
 | `suggest_labels` | Get intelligent suggestions | `repo`, `context` |
 | `create_label` | Create repository label | `repo`, `name`, `color` |
 | `create_label_smart` | Auto-detect org vs repo | `repo`, `name`, `color` |
 ## Milestone Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `list_milestones` | List all milestones | `repo`, `state` |
 | `get_milestone` | Get milestone details | `repo`, `milestone_id` |
 | `create_milestone` | Create new milestone | `repo`, `title`, `description`, `due_on` |
 | `update_milestone` | Update milestone | `repo`, `milestone_id`, `state` |
 ## Dependency Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `list_issue_dependencies` | Get issue dependencies | `repo`, `issue_number` |
 | `create_issue_dependency` | Create dependency | `repo`, `issue_number`, `depends_on` |
 | `get_execution_order` | Get parallel batches | `repo`, `issue_numbers` |
 ## Wiki & Lessons Learned Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `list_wiki_pages` | List all wiki pages | `repo` |
 | `get_wiki_page` | Fetch page content | `repo`, `page_name` |
 | `create_wiki_page` | Create new page | `repo`, `title`, `content` |
 | `update_wiki_page` | Update page content | `repo`, `page_name`, `content` |
 | `search_lessons` | Search lessons learned | `repo`, `query`, `tags`, `limit` |
 | `create_lesson` | Create lesson entry | `repo`, `title`, `content`, `tags`, `category` |
 ## Validation Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `validate_repo_org` | Check if repo is under org | `repo` |
 | `get_branch_protection` | Check branch protection | `repo`, `branch` |
 ## Pull Request Tools
 | Tool | Purpose | Key Parameters |
 |------|---------|----------------|
 | `list_pull_requests` | List PRs | `repo`, `state` |
 | `get_pull_request` | Get PR details | `repo`, `number` |
 | `create_pull_request` | Create PR | `repo`, `title`, `body`, `head`, `base` |
 | `create_pr_review` | Create review | `repo`, `number`, `body`, `event` |
 ---
 ## Common Usage Examples
 **Create sprint issue:**
 ```python
 create_issue(
    repo="org/repo",
    title="[Sprint 17] feat: Implement JWT service",
    body="## Description\n...\n## Implementation\n**Wiki:** [link]",
    labels=["Type/Feature", "Priority/High"],
    milestone=17
 )
 ```
 **Get parallel execution batches:**
 ```python
 get_execution_order(repo="org/repo", issue_numbers=[45, 46, 47, 48])
 # Returns: {"batches": [[45, 48], [46], [47]]}
 ```
 **Search lessons learned:**
 ```python
 search_lessons(repo="org/repo", tags=["auth", "python"], limit=10)
 ```
 **Create lesson:**
 ```python
 create_lesson(
    repo="org/repo",
    title="Sprint 18 - JWT Token Edge Cases",
    content="# Sprint 18...\n## Context\n...",
    tags=["auth", "jwt", "python"],
    category="sprints"
 )
 ```
--- a/plugins/projman/skills/planning-workflow.md
+++ b/plugins/projman/skills/planning-workflow.md
@@ -0,0 +1,134 @@
 ---
 name: planning-workflow
 description: The complete sprint planning process steps
 ---
 # Planning Workflow
 ## Purpose
 Defines the complete 11-step planning workflow from validation through approval.
 ## When to Use
 - **Planner agent**: When executing `/sprint-plan`
 - **Commands**: `/sprint-plan`
 ---
 ## Workflow Steps
 ### 1. Understand Sprint Goals
 Ask clarifying questions:
 - What are the sprint objectives?
 - What's the scope and priority?
 - Are there any constraints (time, resources, dependencies)?
 - What's the desired outcome?
 **Never rush - take time to understand requirements fully.**
 ### 2. Run Pre-Planning Validations
 Execute in order:
 1. **Branch detection** - See `skills/branch-security.md`
 2. **Repository org check** - See `skills/repo-validation.md`
 3. **Label taxonomy validation** - See `skills/repo-validation.md`
 **STOP if any validation fails.**
 ### 3. Detect Input Source
 Follow `skills/input-detection.md`:
 1. Check for `docs/changes/*.md` files
 2. Check for existing wiki proposal
 3. If neither: use conversation context
 4. If ambiguous: ask user
 ### 4. Search Relevant Lessons Learned
 Follow `skills/lessons-learned.md`:
 ```python
 search_lessons(repo="org/repo", query="sprint keywords", tags=["relevant", "tags"])
 ```
 Present findings to user before proceeding.
 ### 5. Create/Update Wiki Proposal
 Follow `skills/wiki-conventions.md`:
 - If local file: migrate content to wiki, create proposal page
 - If conversation: create proposal from discussion
 - If existing wiki: skip creation, use as-is
 ### 6. Create Wiki Implementation Page
 Follow `skills/wiki-conventions.md`:
 - Create `Change VXX.X.X: Proposal (Implementation N)`
 - Update proposal page with link to implementation
 ### 7. Architecture Analysis
 Think through:
 - What components will be affected?
 - What are the integration points?
 - Are there edge cases to handle?
 - What dependencies exist?
 - What are potential risks?
 ### 8. Create Gitea Issues
 Follow `skills/issue-conventions.md` and `skills/task-sizing.md`:
 - Use proper title format: `[Sprint XX] <type>: <description>`
 - Include wiki implementation reference
 - Apply appropriate labels using `suggest_labels`
 - **Refuse to create L/XL tasks without breakdown**
 ### 9. Set Up Dependencies
 ```python
 create_issue_dependency(repo="org/repo", issue_number=46, depends_on=45)
 ```
 ### 10. Create or Select Milestone
 ```python
 create_milestone(
    repo="org/repo",
    title="Sprint 17 - Feature Name",
    description="Sprint description",
    due_on="2025-02-01T00:00:00Z"
 )
 ```
 Assign issues to the milestone.
 ### 11. Request Sprint Approval
 Follow `skills/sprint-approval.md`:
 - Present approval request with scope summary
 - Wait for explicit user approval
 - Record approval in milestone description
 ---
 ## Cleanup After Planning
 - Delete local input file (wiki is now source of truth)
 - Summarize architectural decisions
 - List created issues with labels
 - Document dependency graph
 - Provide sprint overview with wiki links
 ---
 ## Visual Output
 Display header at start:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  🎯 PLANNING                                                     ║
 ║  [Sprint Name]                                                   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
--- a/plugins/projman/skills/progress-tracking.md
+++ b/plugins/projman/skills/progress-tracking.md
@@ -0,0 +1,192 @@
 ---
 name: progress-tracking
 description: Structured progress comments and status label management
 ---
 # Progress Tracking
 ## Purpose
 Defines structured progress comment format and status label management.
 ## When to Use
 - **Orchestrator agent**: When tracking sprint execution
 - **Executor agent**: When posting progress updates
 - **Commands**: `/sprint-start`, `/sprint-status`
 ---
 ## Status Labels
 | Label | Meaning | When to Apply |
 |-------|---------|---------------|
 | `Status/In-Progress` | Work actively happening | When dispatching task |
 | `Status/Blocked` | Cannot proceed | When dependency or blocker found |
 | `Status/Failed` | Task failed | When task cannot complete |
 | `Status/Deferred` | Moved to future | When deprioritized |
 ### Rules
 - Only ONE Status label at a time
 - Remove Status labels when closing successfully
 - Always add comment explaining status changes
 ---
 ## Applying Status Labels
 **When dispatching:**
 ```python
 update_issue(
    repo="org/repo",
    issue_number=45,
    labels=["Status/In-Progress", ...existing_labels]
 )
 ```
 **When blocked:**
 ```python
 update_issue(
    repo="org/repo",
    issue_number=46,
    labels=["Status/Blocked", ...labels_without_in_progress]
 )
 add_comment(repo="org/repo", number=46, body="🚫 BLOCKED: Waiting for #45")
 ```
 **When failed:**
 ```python
 update_issue(
    repo="org/repo",
    issue_number=47,
    labels=["Status/Failed", ...labels_without_in_progress]
 )
 add_comment(repo="org/repo", number=47, body="❌ FAILED: [Error description]")
 ```
 **On successful close:**
 ```python
 update_issue(
    repo="org/repo",
    issue_number=45,
    state="closed",
    labels=[...labels_without_status]  # Remove all Status/* labels
 )
 ```
 ---
 ## Structured Progress Comment Format
 ```markdown
 ## Progress Update
 **Status:** In Progress | Blocked | Failed
 **Phase:** [current phase name]
 **Tool Calls:** X (budget: Y)
 ### Completed
 - [x] Step 1
 - [x] Step 2
 ### In Progress
 - [ ] Current step (estimated: Z more calls)
 ### Blockers
 - None | [blocker description]
 ### Next
 - What happens after current step
 ```
 ---
 ## When to Post Progress Comments
 - After completing each major phase (every 20-30 tool calls)
 - When status changes (blocked, failed)
 - When encountering unexpected issues
 - Before approaching tool call budget limit
 ---
 ## Checkpoint Format (Resume Support)
 For resume support, save checkpoints after major steps:
 ```markdown
 ## Checkpoint
 **Branch:** feat/45-jwt-service
 **Commit:** abc123
 **Phase:** Testing
 **Tool Calls:** 67
 ### Completed Steps
 - [x] Created auth/jwt_service.py
 - [x] Implemented generate_token()
 - [x] Implemented verify_token()
 ### Pending Steps
 - [ ] Write unit tests
 - [ ] Add refresh logic
 - [ ] Commit and push
 ### Files Modified
 - auth/jwt_service.py (new)
 - auth/__init__.py (modified)
 ```
 ---
 ## Sprint Progress Display
 ```
 ┌─ Sprint Progress ────────────────────────────────────────────────┐
 │  Sprint 18 - User Authentication                                 │
 │  ████████████░░░░░░░░░░░░░░░░░░ 40% complete                     │
 │  ✅ Done: 4    ⏳ Active: 2    ⬚ Pending: 4                       │
 │  Current:                                                        │
 │    #45 ⏳ Implement JWT service                                  │
 │    #46 ⏳ Build login endpoint                                   │
 └──────────────────────────────────────────────────────────────────┘
 ```
 ### Progress Bar Calculation
 - Width: 30 characters
 - Filled: `█` (completed percentage)
 - Empty: `░` (remaining percentage)
 - Formula: `(closed_issues / total_issues) * 30`
 ---
 ## Parallel Execution Status
 ```
 Parallel Execution Status:
 Batch 1:
  ✅ #45 - JWT service - COMPLETED (12:45)
  🔄 #48 - API docs - IN PROGRESS (75%)
 Batch 2 (now unblocked):
  ⏳ #46 - Login endpoint - READY TO START
  ⏳ #49 - Auth tests - READY TO START
 #45 completed! #46 and #49 are now unblocked.
 ```
 ---
 ## Auto-Check Subtasks on Close
 When closing an issue, update unchecked subtasks in body:
 ```python
 # Change - [ ] to - [x] for completed items
 update_issue(
    repo="org/repo",
    issue_number=45,
    body="... - [x] Completed subtask ..."
 )
 ```
--- a/plugins/projman/skills/repo-validation.md
+++ b/plugins/projman/skills/repo-validation.md
@@ -0,0 +1,119 @@
 ---
 name: repo-validation
 description: Repository organization check and label taxonomy validation
 ---
 # Repository Validation
 ## Purpose
 Validates that the repository belongs to an organization and has the required label taxonomy.
 ## When to Use
 - **Planner agent**: At start of sprint planning
 - **Commands**: `/sprint-plan`, `/labels-sync`, `/project-init`
 ---
 ## Step 1: Detect Repository from Git Remote
 ```bash
 git remote get-url origin
 ```
 Parse output to extract `owner/repo`:
 - SSH: `git@host:owner/repo.git` → `owner/repo`
 - SSH with port: `ssh://git@host:port/owner/repo.git` → `owner/repo`
 - HTTPS: `https://host/owner/repo.git` → `owner/repo`
 ---
 ## Step 2: Validate Organization Ownership
 ```python
 validate_repo_org(repo="owner/repo")
 ```
 **If NOT an organization repository:**
 ```
 REPOSITORY VALIDATION FAILED
 This plugin requires the repository to belong to an organization, not a user.
 Current repository appears to be a personal repository.
 Please:
 1. Create an organization in Gitea
 2. Transfer or create the repository under that organization
 3. Update your configuration
 ```
 ---
 ## Step 3: Validate Label Taxonomy
 ```python
 get_labels(repo="owner/repo")
 ```
 **Required label categories:**
 | Category | Required Labels |
 |----------|-----------------|
 | Type/* | Bug, Feature, Refactor, Documentation, Test, Chore |
 | Priority/* | Low, Medium, High, Critical |
 | Complexity/* | Simple, Medium, Complex |
 | Efforts/* | XS, S, M, L, XL |
 **If labels are missing:**
 - Use `create_label_smart()` to create them (auto-detects org vs repo level)
 - Report which labels were created
 ---
 ## Validation Report Format
 ```
 Repository Validation
 =====================
 Git Remote: git@gitea.example.com:org/repo.git
 Detected: org/repo
 Organization Check:
  ✓ Repository belongs to organization "org"
 Label Taxonomy:
  ✓ Type/* labels: 6/6 present
  ✓ Priority/* labels: 4/4 present
  ✓ Complexity/* labels: 3/3 present
  ✓ Efforts/* labels: 5/5 present
 All validations passed. Ready for planning.
 ```
 ---
 ## Error Handling
 ### Repository Not Found (404)
 ```
 Repository validation failed: Not found
 The repository "owner/repo" does not exist or you don't have access.
 Please verify:
 1. Repository name is correct
 2. Your token has repository access
 3. Organization/owner name is correct
 ```
 ### Authentication Error (401/403)
 ```
 Repository validation failed: Authentication error
 Your Gitea token may be invalid or lack permissions.
 Please verify:
 1. Token is valid and not expired
 2. Token has 'repo' scope
 3. You have access to this repository
 ```
--- a/plugins/projman/skills/review-checklist.md
+++ b/plugins/projman/skills/review-checklist.md
@@ -0,0 +1,149 @@
 ---
 name: review-checklist
 description: Code review criteria and severity classification
 ---
 # Review Checklist
 ## Purpose
 Defines code review criteria, severity classification, and output format.
 ## When to Use
 - **Code Reviewer agent**: During pre-sprint-close review
 - **Commands**: `/review`
 ---
 ## Severity Classification
 ### Critical (Must Fix Before Close)
 Security issues, broken functionality, data loss risks:
 - Hardcoded credentials or API keys
 - SQL injection vulnerabilities
 - Missing authentication/authorization checks
 - Unhandled errors that could crash the application
 - Data loss or corruption risks
 - Broken core functionality
 ### Warning (Should Fix)
 Technical debt that will cause problems soon:
 - TODO/FIXME comments left unresolved
 - Debug statements (console.log, print) in production code
 - Functions over 50 lines (complexity smell)
 - Deeply nested conditionals (>3 levels)
 - Bare except/catch blocks
 - Ignored errors
 - Missing error handling
 ### Recommendation (Future Sprint)
 Improvements that can wait:
 - Missing docstrings on public functions
 - Minor code duplication
 - Commented-out code blocks
 - Variable naming improvements
 - Minor refactoring opportunities
 ---
 ## Review Patterns by Language
 ### Python
 | Look For | Severity |
 |----------|----------|
 | Bare `except:` | Warning |
 | `print()` statements | Warning |
 | `# TODO` | Warning |
 | Missing type hints on public APIs | Recommendation |
 | `eval()`, `exec()` | Critical |
 | SQL string formatting | Critical |
 | `verify=False` in requests | Critical |
 ### JavaScript/TypeScript
 | Look For | Severity |
 |----------|----------|
 | `console.log` | Warning |
 | `// TODO` | Warning |
 | `any` type abuse | Warning |
 | Missing error boundaries | Warning |
 | `eval()` | Critical |
 | `innerHTML` with user input | Critical |
 | Unescaped user input | Critical |
 ### Go
 | Look For | Severity |
 |----------|----------|
 | `// TODO` | Warning |
 | Ignored errors (`_`) | Warning |
 | Missing error returns | Warning |
 | SQL concatenation | Critical |
 | Missing input validation | Warning |
 ### Rust
 | Look For | Severity |
 |----------|----------|
 | `// TODO` | Warning |
 | `unwrap()` chains | Warning |
 | `unsafe` blocks without justification | Warning |
 | Unchecked `unwrap()` on user input | Critical |
 ---
 ## What NOT to Review
 - Style issues (assume formatters handle this)
 - Architectural rewrites mid-sprint
 - Issues in unchanged code (unless directly impacted)
 - Bikeshedding on naming preferences
 ---
 ## Output Template
 ```
 ## Code Review Summary
 **Scope**: [X files from sprint/last N commits]
 **Verdict**: [READY FOR CLOSE / NEEDS ATTENTION / BLOCKED]
 ### Critical (Must Fix)
 - `src/auth.py:45` - Hardcoded API key in source code
 - `src/db.py:123` - SQL injection vulnerability
 ### Warnings (Should Fix)
 - `src/utils.js:123` - console.log left in production code
 - `src/handler.py:67` - Bare except block swallows all errors
 ### Recommendations (Future Sprint)
 - `src/api.ts:89` - Function exceeds 50 lines, consider splitting
 ### Clean Files
 - src/models.py
 - src/tests/test_auth.py
 ```
 ---
 ## Verdict Criteria
 | Verdict | Criteria |
 |---------|----------|
 | **READY FOR CLOSE** | No Critical, few/no Warnings |
 | **NEEDS ATTENTION** | No Critical, has Warnings that should be addressed |
 | **BLOCKED** | Has Critical issues that must be fixed |
 ---
 ## Integration with Sprint
 When sprint context is available:
 - Reference the sprint's issue list
 - Create follow-up issues for non-critical findings
 - Tag findings with appropriate labels from taxonomy
--- a/plugins/projman/skills/runaway-detection.md
+++ b/plugins/projman/skills/runaway-detection.md
@@ -0,0 +1,156 @@
 ---
 name: runaway-detection
 description: Detecting and handling stuck agents
 ---
 # Runaway Detection
 ## Purpose
 Defines how to detect stuck agents and intervention protocols.
 ## When to Use
 - **Orchestrator agent**: When monitoring dispatched agents
 - **Executor agent**: Self-monitoring during execution
 ---
 ## Warning Signs
 | Sign | Threshold | Action |
 |------|-----------|--------|
 | No progress comment | 30+ minutes | Investigate |
 | Same phase repeated | 20+ tool calls | Consider stopping |
 | Same error 3+ times | Immediately | Stop agent |
 | Approaching budget | 80% of limit | Post checkpoint |
 ---
 ## Agent Timeout Guidelines
 | Task Size | Expected Duration | Intervention Point |
 |-----------|-------------------|-------------------|
 | XS | ~5-10 min | 15 min no progress |
 | S | ~10-20 min | 30 min no progress |
 | M | ~20-40 min | 45 min no progress |
 ---
 ## Detection Protocol
 1. **Read latest progress comment** - Check tool call count and phase
 2. **Compare to previous** - Is progress happening?
 3. **Check for error patterns** - Same error repeating?
 4. **Evaluate time elapsed** - Beyond expected duration?
 ---
 ## Intervention Protocol
 When you detect an agent may be stuck:
 ### Step 1: Assess
 ```
 Agent Status Check for #45:
 - Last progress: 25 minutes ago
 - Phase: "Testing" (same as 20 tool calls ago)
 - Errors: "ModuleNotFoundError" (3 times)
 - Assessment: LIKELY STUCK
 ```
 ### Step 2: Stop Agent
 ```python
 # If TaskStop available
 TaskStop(task_id="agent-id")
 ```
 ### Step 3: Update Issue Status
 ```python
 update_issue(
    repo="org/repo",
    issue_number=45,
    labels=["Status/Failed", ...other_labels]
 )
 ```
 ### Step 4: Add Explanation Comment
 ```python
 add_comment(
    repo="org/repo",
    number=45,
    body="""## Agent Intervention
 **Reason:** No progress detected for 25 minutes / repeated errors
 **Last Status:** Testing phase, ModuleNotFoundError x3
 **Action:** Stopped agent, requires human review
 ### What Was Completed
 - [x] Created auth/jwt_service.py
 - [x] Implemented generate_token()
 ### What Remains
 - [ ] Fix import issue
 - [ ] Write tests
 - [ ] Commit
 ### Recommendation
 - Check for missing dependency in requirements.txt
 - May need manual intervention to resolve import
 """
 )
 ```
 ---
 ## Self-Monitoring (Executor)
 Executors should self-monitor:
 ### Circuit Breakers
 - **Same error 3 times**: Stop and report
 - **80% of tool call budget**: Post checkpoint
 - **File not found 3 times**: Stop and ask for help
 - **Test failing same way 5 times**: Stop and report
 ### Self-Check Template
 ```
 Self-check at tool call 45/100:
 - Progress: 4/7 steps completed
 - Current phase: Testing
 - Errors encountered: 1 (resolved)
 - Remaining budget: 55 calls
 - Status: ON TRACK
 ```
 ---
 ## Recovery Actions
 After stopping a stuck agent:
 1. **Preserve work** - Branch and commits remain
 2. **Document state** - Checkpoint in issue comment
 3. **Identify cause** - What caused the loop?
 4. **Plan recovery**:
   - Manual completion
   - Different approach
   - Break down further
   - Assign to human
 ---
 ## Common Stuck Patterns
 | Pattern | Cause | Solution |
 |---------|-------|----------|
 | Import loop | Missing dependency | Add to requirements |
 | Test loop | Non-deterministic test | Fix test isolation |
 | Validation loop | Error message not changing | Improve error specificity |
 | File not found | Wrong path | Verify path exists |
 | Permission denied | File ownership | Check permissions |
--- a/plugins/projman/skills/setup-workflows.md
+++ b/plugins/projman/skills/setup-workflows.md
@@ -0,0 +1,223 @@
 # Setup Workflows
 Shared workflows for the `/setup` command modes.
 ## Mode Detection Logic
 Determine setup mode automatically:
 ```
 1. Check ~/.config/claude/gitea.env exists
   - If missing → FULL mode needed
 2. If gitea.env exists, check project .env
   - If .env missing → QUICK mode (project setup)
 3. If both exist, compare git remote with .env values
   - If mismatch → SYNC mode needed
   - If match → already configured, offer reconfigure option
 ```
 ## Full Setup Workflow
 Complete first-time setup including MCP servers, credentials, and project.
 ### Phase 1: Environment Validation
 ```bash
 # Check Python 3.10+
 python3 --version  # Should be 3.10+
 ```
 If Python < 3.10, stop and ask user to install.
 ### Phase 2: MCP Server Setup
 1. **Locate Plugin Installation**
   ```bash
   ls ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/gitea/
   ```
 2. **Check Virtual Environment**
   ```bash
   ls ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/gitea/venv/
   ```
 3. **Create venv if Missing**
   ```bash
   cd ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/gitea/
   python3 -m venv venv
   ./venv/bin/pip install -r requirements.txt
   ```
 4. **Optional: NetBox MCP Setup**
   Ask user if they need NetBox integration.
 ### Phase 3: System-Level Configuration
 1. **Create Config Directory**
   ```bash
   mkdir -p ~/.config/claude
   ```
 2. **Create gitea.env Template**
   ```env
   GITEA_API_URL=https://your-gitea-instance/api/v1
   GITEA_API_TOKEN=
   ```
 3. **Token Entry (SECURITY)**
   - DO NOT ask for token in chat
   - Instruct user to edit file manually
   - Provide command: `nano ~/.config/claude/gitea.env`
 4. **Validate Token**
   ```bash
   curl -s -H "Authorization: token $TOKEN" "$GITEA_API_URL/user"
   ```
   - 200 OK = valid
   - 401 = invalid token
 ### Phase 4: Project-Level Configuration
 See **Quick Setup Workflow** below.
 ### Phase 5: Final Validation
 Display summary:
 - MCP server: ✓/✗
 - System config: ✓/✗
 - Project config: ✓/✗
 **Important:** Session restart required for MCP tools to load.
 ---
 ## Quick Setup Workflow
 Project-level setup only (assumes system config exists).
 ### Step 1: Verify System Config
 ```bash
 cat ~/.config/claude/gitea.env
 ```
 If missing or empty token, redirect to FULL mode.
 ### Step 2: Verify Git Repository
 ```bash
 git rev-parse --git-dir 2>/dev/null
 ```
 If not a git repo, stop and inform user.
 ### Step 3: Check Existing Config
 If `.env` exists:
 - Show current GITEA_ORG and GITEA_REPO
 - Ask: Keep current or reconfigure?
 ### Step 4: Detect Org/Repo
 Parse git remote URL:
 ```bash
 git remote get-url origin
 # https://gitea.example.com/org-name/repo-name.git
 # → org: org-name, repo: repo-name
 ```
 ### Step 5: Validate via API
 ```bash
 curl -s -H "Authorization: token $TOKEN" \
  "$GITEA_API_URL/repos/$ORG/$REPO"
 ```
 - 200 OK = auto-fill without asking
 - 404 = ask user to confirm/correct
 ### Step 6: Create .env
 ```env
 GITEA_ORG=detected-org
 GITEA_REPO=detected-repo
 ```
 ### Step 7: Check .gitignore
 If `.env` not in `.gitignore`:
 - Warn user about security risk
 - Offer to add it
 ---
 ## Sync Workflow
 Update project config when git remote changed.
 ### Step 1: Read Current Config
 ```bash
 grep GITEA_ORG .env
 grep GITEA_REPO .env
 ```
 ### Step 2: Detect Git Remote
 Parse current remote URL (same as Quick Step 4).
 ### Step 3: Compare Values
 | Current | Detected | Action |
 |---------|----------|--------|
 | Match | Match | "Already in sync" - exit |
 | Different | Different | Show diff, ask to update |
 ### Step 4: Show Changes
 ```
 Current:  org/old-repo
 Detected: org/new-repo
 Update configuration? [y/n]
 ```
 ### Step 5: Validate New Values
 API check on detected org/repo.
 ### Step 6: Update .env
 Replace GITEA_ORG and GITEA_REPO values.
 ### Step 7: Confirm
 ```
 ✓ Project configuration updated
  GITEA_ORG: new-org
  GITEA_REPO: new-repo
 ```
 ---
 ## Visual Header
 All setup modes use:
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  📋 PROJMAN                                                      ║
 ║  ⚙️ SETUP                                                        ║
 ║  [Mode: Full | Quick | Sync]                                     ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 ## DO NOT
 - Ask for tokens in chat (security risk)
 - Skip venv creation for MCP servers
 - Create .env without checking .gitignore
 - Proceed if API validation fails
--- a/plugins/projman/skills/sprint-approval.md
+++ b/plugins/projman/skills/sprint-approval.md
@@ -0,0 +1,136 @@
 ---
 name: sprint-approval
 description: Approval gate logic for sprint execution
 ---
 # Sprint Approval
 ## Purpose
 Defines the approval workflow that gates sprint execution.
 ## When to Use
 - **Planner agent**: After creating issues, request approval
 - **Orchestrator agent**: Before execution, verify approval exists
 - **Commands**: `/sprint-plan`, `/sprint-start`
 ---
 ## Core Principle
 **Planning DOES NOT equal execution permission.**
 Sprint approval is a mandatory checkpoint between planning and execution.
 ---
 ## Requesting Approval (Planner)
 After creating issues, present approval request:
 ```
 Sprint 17 Planning Complete
 ===========================
 Created Issues:
 - #45: [Sprint 17] feat: JWT token generation
 - #46: [Sprint 17] feat: Login endpoint
 - #47: [Sprint 17] test: Auth tests
 Execution Scope:
 - Branches: feat/45-*, feat/46-*, feat/47-*
 - Files: auth/*, api/routes/auth.py, tests/test_auth*
 - Dependencies: PyJWT, python-jose
 ⚠️ APPROVAL REQUIRED
 Do you approve this sprint for execution?
 This grants permission for agents to:
 - Create and modify files in the listed scope
 - Create branches with the listed prefixes
 - Install listed dependencies
 Type "approve sprint 17" to authorize execution.
 ```
 ---
 ## Recording Approval
 On user approval, update milestone description:
 ```markdown
 ## Sprint Approval
 **Approved:** 2026-01-28 14:30
 **Approver:** User
 **Scope:**
 - Branches: feat/45-*, feat/46-*, feat/47-*
 - Files: auth/*, api/routes/auth.py, tests/test_auth*
 - Dependencies: PyJWT, python-jose
 ```
 ---
 ## Verifying Approval (Orchestrator)
 Before execution, check milestone for approval:
 ```python
 get_milestone(repo="org/repo", milestone_id=17)
 # Check description for "## Sprint Approval" section
 ```
 ### If Approval Missing
 ```
 ⚠️ SPRINT APPROVAL NOT FOUND (Warning)
 Sprint 17 milestone does not contain an approval record.
 Recommended: Run /sprint-plan first to:
 1. Review the sprint scope
 2. Document the approved execution plan
 Proceeding anyway - consider adding approval for audit trail.
 ```
 ### If Approval Found
 ```
 ✓ Sprint Approval Verified
  Approved: 2026-01-28 14:30
  Scope:
    Branches: feat/45-*, feat/46-*, feat/47-*
    Files: auth/*, api/routes/auth.py, tests/test_auth*
 Proceeding with execution within approved scope...
 ```
 ---
 ## Scope Enforcement
 When approval exists, agents SHOULD operate within approved scope:
 ```
 Approved scope:
  Branches: feat/45-*, feat/46-*
  Files: auth/*, tests/test_auth*
 Task #48 wants to create: feat/48-api-docs
 → NOT in approved scope!
 → STOP and ask user to approve expanded scope
 ```
 **Operations outside scope should trigger re-approval via `/sprint-plan`.**
 ---
 ## Re-Approval Scenarios
 Request re-approval when:
 - New tasks discovered during execution
 - Scope expansion needed (new files, new branches)
 - Dependencies change significantly
 - Timeline changes require scope adjustment
--- a/plugins/projman/skills/task-sizing.md
+++ b/plugins/projman/skills/task-sizing.md
@@ -0,0 +1,104 @@
 ---
 name: task-sizing
 description: Task sizing rules and mandatory breakdown requirements
 ---
 # Task Sizing Rules
 ## Purpose
 Defines effort estimation rules and enforces task breakdown requirements.
 ## When to Use
 - **Planner agent**: When creating issues during sprint planning
 - **Orchestrator agent**: When reviewing task scope during sprint start
 - **Code Reviewer agent**: When flagging oversized tasks
 ---
 ## Sizing Matrix
 | Effort | Files | Checklist Items | Max Tool Calls | Agent Scope |
 |--------|-------|-----------------|----------------|-------------|
 | **XS** | 1 file | 0-2 items | ~30 | Single function/fix |
 | **S** | 1 file | 2-4 items | ~50 | Single file feature |
 | **M** | 2-3 files | 4-6 items | ~80 | Multi-file feature |
 | **L** | MUST BREAK DOWN | - | - | Too large |
 | **XL** | MUST BREAK DOWN | - | - | Way too large |
 ---
 ## CRITICAL: L/XL Tasks MUST Be Broken Down
 **Why:**
 - Agents running 400+ tool calls take 1+ hour with no visibility
 - Large tasks lack clear completion criteria
 - Debugging failures is extremely difficult
 - Small tasks enable parallel execution
 ---
 ## Scoping Checklist
 1. Can this be completed in one file? → XS or S
 2. Does it touch 2-3 files? → M (maximum for single task)
 3. Does it touch 4+ files? → MUST break down
 4. Would you estimate 50+ tool calls? → MUST break down
 5. Does it require complex decision-making mid-task? → MUST break down
 ---
 ## Breakdown Example
 ### BAD (L - too broad)
 ```
 [Sprint 3] feat: Implement schema diff detection hook
 Labels: Efforts/L
 - Hook skeleton
 - Pattern detection
 - Warning output
 - Integration
 ```
 ### GOOD (broken into S tasks)
 ```
 [Sprint 3] feat: Create hook skeleton
 Labels: Efforts/S
 - [ ] Create hook file with standard header
 - [ ] Add file type detection for SQL
 - [ ] Exit 0 (non-blocking)
 [Sprint 3] feat: Add DROP/ALTER pattern detection
 Labels: Efforts/S
 - [ ] Detect DROP COLUMN/TABLE/INDEX
 - [ ] Detect ALTER TYPE changes
 - [ ] Detect RENAME operations
 [Sprint 3] feat: Add warning output formatting
 Labels: Efforts/S
 - [ ] Format breaking change warnings
 - [ ] Add hook prefix to output
 [Sprint 3] chore: Register hook in hooks.json
 Labels: Efforts/XS
 - [ ] Add PostToolUse:Edit hook entry
 ```
 ---
 ## Enforcement
 **The planner MUST refuse to create L/XL tasks without breakdown.**
 If user requests a large task:
 ```
 This task appears to be L/XL sized (touches 4+ files, estimated 100+ tool calls).
 L/XL tasks MUST be broken down into S/M subtasks because:
 - Agents need clear, completable units of work
 - Parallel execution requires smaller tasks
 - Progress visibility requires frequent checkpoints
 Let me break this down into smaller tasks...
 ```
--- a/plugins/projman/skills/test-standards.md
+++ b/plugins/projman/skills/test-standards.md
@@ -0,0 +1,173 @@
 ---
 name: test-standards
 description: Testing requirements, framework detection, and patterns
 ---
 # Test Standards
 ## Purpose
 Defines testing requirements, framework detection, and test patterns.
 ## When to Use
 - **Commands**: `/test-check`, `/test-gen`
 - **Executor agent**: When writing tests during implementation
 ---
 ## Framework Detection
 | Indicator | Framework | Command |
 |-----------|-----------|---------|
 | `pytest.ini`, `pyproject.toml` with pytest | pytest | `pytest` |
 | `package.json` with jest | Jest | `npm test` or `npx jest` |
 | `package.json` with vitest | Vitest | `npm test` or `npx vitest` |
 | `go.mod` with `*_test.go` | Go test | `go test ./...` |
 | `Cargo.toml` | Cargo test | `cargo test` |
 | `Makefile` with test target | Make | `make test` |
 ---
 ## Coverage Commands
 | Framework | Coverage Command |
 |-----------|------------------|
 | Python/pytest | `pytest --cov=src --cov-report=term-missing` |
 | JavaScript/Jest | `npm test -- --coverage` |
 | Go | `go test -cover ./...` |
 | Rust | `cargo tarpaulin` or `cargo llvm-cov` |
 ---
 ## Test Structure Pattern
 ### Unit Tests
 For each function:
 - **Happy path**: Expected inputs → expected output
 - **Edge cases**: Empty, null, boundary values
 - **Error cases**: Invalid inputs → expected errors
 - **Type variations**: If dynamic typing
 ### Example (Python/pytest)
 ```python
 import pytest
 from module import target_function
 class TestTargetFunction:
    """Tests for target_function."""
    def test_happy_path(self):
        """Standard input produces expected output."""
        result = target_function(valid_input)
        assert result == expected_output
    def test_empty_input(self):
        """Empty input handled gracefully."""
        result = target_function("")
        assert result == default_value
    def test_invalid_input_raises(self):
        """Invalid input raises ValueError."""
        with pytest.raises(ValueError):
            target_function(invalid_input)
    @pytest.mark.parametrize("input,expected", [
        (case1_in, case1_out),
        (case2_in, case2_out),
    ])
    def test_variations(self, input, expected):
        """Multiple input variations."""
        assert target_function(input) == expected
 ```
 ---
 ## Test Strategy by Code Pattern
 | Code Pattern | Test Approach |
 |--------------|---------------|
 | Pure function | Unit tests with varied inputs |
 | Class with state | Setup/teardown, state transitions |
 | External calls | Mocks/stubs for dependencies |
 | Database ops | Integration tests with fixtures |
 | API endpoints | Request/response tests |
 | UI components | Snapshot + interaction tests |
 ---
 ## Test Check Output Format
 ```
 ## Test Check Summary
 ### Test Results
 - Framework: pytest
 - Status: PASS/FAIL
 - Passed: 45 | Failed: 2 | Skipped: 3
 - Duration: 12.5s
 ### Failed Tests
 - test_auth.py::test_token_refresh: AssertionError (line 45)
 - test_api.py::test_login_endpoint: TimeoutError (line 78)
 ### Coverage (if available)
 - Overall: 78%
 - Sprint files coverage:
  - auth/jwt_service.py: 92%
  - api/routes/auth.py: 65%
  - models/user.py: NO TESTS
 ### Recommendation
 TESTS MUST PASS / READY FOR CLOSE / COVERAGE GAPS TO ADDRESS
 ```
 ---
 ## Test Generation Output Format
 ```
 ## Tests Generated
 ### Target: src/orders.py:calculate_total
 ### File Created: tests/test_orders.py
 ### Tests (6 total)
 - test_calculate_total_happy_path
 - test_calculate_total_empty_items
 - test_calculate_total_negative_price_raises
 - test_calculate_total_with_discount
 - test_calculate_total_with_tax
 - test_calculate_total_parametrized_cases
 ### Run Tests
 pytest tests/test_orders.py -v
 ```
 ---
 ## Do NOT
 - Modify test files during `/test-check` (only run and report)
 - Skip failing tests to make the run pass
 - Run tests in production environments
 - Install dependencies without asking first
 - Run tests requiring external services without confirmation
 ---
 ## Error Handling
 **If tests fail:**
 1. Report the failure clearly
 2. List failed test names and error summaries
 3. Recommend: "TESTS MUST PASS before sprint close"
 4. Offer to help debug specific failures
 **If framework not detected:**
 1. List what was checked
 2. Ask user to specify the test command
 3. Offer common suggestions based on file types
--- a/plugins/projman/skills/wiki-conventions.md
+++ b/plugins/projman/skills/wiki-conventions.md
@@ -0,0 +1,155 @@
 ---
 name: wiki-conventions
 description: Proposal and implementation page format and naming conventions
 ---
 # Wiki Conventions
 ## Purpose
 Defines the naming and structure for wiki proposal and implementation pages.
 ## When to Use
 - **Planner agent**: When creating wiki pages during planning
 - **Orchestrator agent**: When updating status at sprint close
 - **Commands**: `/sprint-plan`, `/sprint-close`, `/proposal-status`
 ---
 ## Page Naming
 | Page Type | Naming Convention |
 |-----------|-------------------|
 | Proposal | `Change VXX.X.X: Proposal` |
 | Implementation | `Change VXX.X.X: Proposal (Implementation N)` |
 **Examples:**
 - `Change V4.1.0: Proposal`
 - `Change V4.1.0: Proposal (Implementation 1)`
 - `Change V4.1.0: Proposal (Implementation 2)`
 ---
 ## Proposal Page Template
 ```markdown
 > **Type:** Change Proposal
 > **Version:** V04.1.0
 > **Plugin:** projman
 > **Status:** In Progress
 > **Date:** 2026-01-26
 # Feature Title
 [Content migrated from input source or created from discussion]
 ## Implementations
 - [Implementation 1](link) - Sprint 17 - In Progress
 ```
 ---
 ## Implementation Page Template
 ```markdown
 > **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]
 ## Issues
 - #45: JWT token generation
 - #46: Login endpoint
 - #47: Auth tests
 ```
 ---
 ## Status Values
 | Status | Meaning |
 |--------|---------|
 | `In Progress` | Active work |
 | `Implemented` | Completed successfully |
 | `Partial` | Partially completed, continued in next impl |
 | `Failed` | Did not complete, abandoned |
 ---
 ## Completion Update (Sprint Close)
 On sprint close, update implementation page:
 ```markdown
 > **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]
 ```
 ---
 ## Proposal Status Update
 When all implementations complete, update proposal:
 ```markdown
 > **Type:** Change Proposal
 > **Version:** V04.1.0
 > **Status:** Implemented ✅
 > **Date:** 2026-01-26
 # Feature Title
 [Original content...]
 ## Implementations
 - [Implementation 1](link) - Sprint 17 - ✅ Completed
 ```
 ---
 ## Creating Pages
 **Create proposal:**
 ```python
 create_wiki_page(
    repo="org/repo",
    title="Change V4.1.0: Proposal",
    content="[proposal template content]"
 )
 ```
 **Create implementation:**
 ```python
 create_wiki_page(
    repo="org/repo",
    title="Change V4.1.0: Proposal (Implementation 1)",
    content="[implementation template content]"
 )
 ```
 **Update implementation on close:**
 ```python
 update_wiki_page(
    repo="org/repo",
    page_name="Change-V4.1.0:-Proposal-(Implementation-1)",
    content="[updated content with completion status]"
 )
 ```
--- a/plugins/viz-platform/README.md
+++ b/plugins/viz-platform/README.md
@@ -1,238 +0,0 @@
 # viz-platform Plugin
 Visualization tools with Dash Mantine Components validation, Plotly charts, and theming for Claude Code.
 ## Features
 - **DMC Validation**: Prevent prop hallucination with version-locked component registry
 - **Chart Creation**: Plotly charts with automatic theme token application
 - **Layout Builder**: Dashboard layouts with filters, grids, and responsive design
 - **Theme System**: Create, extend, and export design tokens
 ## Installation
 This plugin is part of the leo-claude-mktplace. Install via:
 ```bash
 # From marketplace
 claude plugins install leo-claude-mktplace/viz-platform
 # Setup MCP server venv
 cd ~/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/viz-platform
 python -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 ```
 ## Configuration
 ### System-Level (Optional)
 Create `~/.config/claude/viz-platform.env` for default theme preferences:
 ```env
 VIZ_PLATFORM_COLOR_SCHEME=light
 VIZ_PLATFORM_PRIMARY_COLOR=blue
 ```
 ### Project-Level (Optional)
 Add to project `.env` for project-specific settings:
 ```env
 VIZ_PLATFORM_THEME=my-custom-theme
 DMC_VERSION=0.14.7
 ```
 ## Commands
 | Command | Description |
 |---------|-------------|
 | `/initial-setup` | Interactive setup wizard for DMC and theme preferences |
 | `/component {name}` | Inspect component props and validation |
 | `/chart {type}` | Create a Plotly chart |
 | `/chart-export {format}` | Export chart to PNG, SVG, or PDF |
 | `/dashboard {template}` | Create a dashboard layout |
 | `/breakpoints {layout}` | Configure responsive breakpoints |
 | `/accessibility-check` | Validate colors for color blind users |
 | `/theme {name}` | Apply an existing theme |
 | `/theme-new {name}` | Create a new custom theme |
 | `/theme-css {name}` | Export theme as CSS |
 ## Agents
 | Agent | Description |
 |-------|-------------|
 | `theme-setup` | Design-focused theme creation specialist |
 | `layout-builder` | Dashboard layout and filter specialist |
 | `component-check` | Strict component validation specialist |
 ## Tool Categories
 ### DMC Validation (3 tools)
 Prevent invalid component props before runtime.
 | Tool | Description |
 |------|-------------|
 | `list_components` | List available components by category |
 | `get_component_props` | Get detailed prop specifications |
 | `validate_component` | Validate a component configuration |
 ### Charts (3 tools)
 Create Plotly charts with theme integration.
 | Tool | Description |
 |------|-------------|
 | `chart_create` | Create a chart (line, bar, scatter, pie, etc.) |
 | `chart_configure_interaction` | Configure chart interactivity |
 | `chart_export` | Export chart to PNG, SVG, or PDF |
 ### Layouts (6 tools)
 Build dashboard structures with filters and grids.
 | Tool | Description |
 |------|-------------|
 | `layout_create` | Create a layout structure |
 | `layout_add_filter` | Add filter components |
 | `layout_set_grid` | Configure responsive grid |
 | `layout_set_breakpoints` | Configure responsive breakpoints (xs-xl) |
 | `layout_add_section` | Add content sections |
 | `layout_get` | Retrieve layout details |
 ### Accessibility (3 tools)
 Validate colors for accessibility and color blindness.
 | Tool | Description |
 |------|-------------|
 | `accessibility_validate_colors` | Check colors for color blind accessibility |
 | `accessibility_validate_theme` | Validate a theme's color accessibility |
 | `accessibility_suggest_alternative` | Suggest accessible color alternatives |
 ### Themes (6 tools)
 Manage design tokens and styling.
 | Tool | Description |
 |------|-------------|
 | `theme_create` | Create a new theme |
 | `theme_extend` | Extend an existing theme |
 | `theme_validate` | Validate theme configuration |
 | `theme_export_css` | Export as CSS custom properties |
 | `theme_list` | List available themes |
 | `theme_activate` | Set the active theme |
 ### Pages (5 tools)
 Create full Dash app configurations.
 | Tool | Description |
 |------|-------------|
 | `page_create` | Create a page structure |
 | `page_add_navbar` | Add navigation bar |
 | `page_set_auth` | Configure authentication |
 | `page_list` | List pages |
 | `page_get_app_config` | Get full app configuration |
 ## Component Validation
 The key differentiator of viz-platform is the component registry system:
 ```python
 # Before writing component code
 get_component_props("Button")
 # Returns: all valid props with types, enums, defaults
 # After writing code
 validate_component("Button", {"variant": "filled", "color": "blue"})
 # Returns: {valid: true} or {valid: false, errors: [...]}
 ```
 This prevents common DMC mistakes:
 - Prop typos (`colour` vs `color`)
 - Invalid enum values (`size="large"` vs `size="lg"`)
 - Wrong case (`fullwidth` vs `fullWidth`)
 ## Example Workflow
 ```
 /component Button
 # → Shows all Button props with types and defaults
 /theme-new corporate
 # → Creates theme with brand colors
 /chart bar
 # → Creates bar chart with theme colors
 /dashboard sidebar
 # → Creates sidebar layout with filters
 /theme-css corporate
 # → Exports theme as CSS for external use
 ```
 ## Cross-Plugin Integration
 viz-platform works seamlessly with data-platform:
 1. **Load data** with data-platform: `/ingest sales.csv`
 2. **Create chart** with viz-platform: `/chart line` using the data_ref
 3. **Build layout** with viz-platform: `/dashboard` with filters
 4. **Export** complete dashboard structure
 ## Chart Types
 | Type | Best For |
 |------|----------|
 | `line` | Time series, trends |
 | `bar` | Comparisons, categories |
 | `scatter` | Correlations, distributions |
 | `pie` | Part-to-whole |
 | `area` | Cumulative trends |
 | `histogram` | Frequency distributions |
 | `box` | Statistical distributions |
 | `heatmap` | Matrix correlations |
 | `sunburst` | Hierarchical data |
 | `treemap` | Hierarchical proportions |
 ## Layout Templates
 | Template | Best For |
 |----------|----------|
 | `basic` | Simple dashboards, reports |
 | `sidebar` | Navigation-heavy apps |
 | `tabs` | Multi-page dashboards |
 | `split` | Comparisons, master-detail |
 ## Responsive Breakpoints
 The plugin supports mobile-first responsive design with standard breakpoints:
 | Breakpoint | Min Width | Description |
 |------------|-----------|-------------|
 | `xs` | 0px | Extra small (mobile portrait) |
 | `sm` | 576px | Small (mobile landscape) |
 | `md` | 768px | Medium (tablet) |
 | `lg` | 992px | Large (desktop) |
 | `xl` | 1200px | Extra large (large desktop) |
 Example:
 ```
 /breakpoints my-dashboard
 # Configure cols, spacing per breakpoint
 ```
 ## Color Accessibility
 The plugin validates colors for color blindness:
 - **Deuteranopia** (green-blind) - 6% of males
 - **Protanopia** (red-blind) - 2.5% of males
 - **Tritanopia** (blue-blind) - 0.01% of population
 Includes WCAG contrast ratio checking and accessible palette suggestions.
 ## Requirements
 - Python 3.10+
 - dash-mantine-components >= 0.14.0
 - plotly >= 5.18.0
 - dash >= 2.14.0
 - kaleido >= 0.2.1 (for chart export)
--- a/plugins/viz-platform/mcp-servers/.doc-guardian-queue
+++ b/plugins/viz-platform/mcp-servers/.doc-guardian-queue
@@ -1 +0,0 @@
 2026-01-26T11:59:05 | .claude-plugin | /home/lmiranda/claude-plugins-work/.claude-plugin/marketplace.json | CLAUDE.md .claude-plugin/marketplace.json
--- a/plugins/viz-platform/mcp-servers/viz-platform
+++ b/plugins/viz-platform/mcp-servers/viz-platform
@@ -1 +0,0 @@
 ../../../mcp-servers/viz-platform
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -91,62 +91,16 @@ setup_shared_mcp() {
    cd "$REPO_ROOT"
 }
-# --- Section 2: Verify Symlinks ---
+# --- Section 2: Verify MCP Configuration ---
-verify_symlinks() {
+verify_mcp_config() {
-    log_info "Verifying MCP server symlinks..."
+    log_info "Verifying MCP configuration..."
-    # Check projman -> gitea symlink
+    local mcp_json="$REPO_ROOT/.mcp.json"
-    local projman_gitea="$REPO_ROOT/plugins/projman/mcp-servers/gitea"
+    if [[ -f "$mcp_json" ]]; then
-    if [[ -L "$projman_gitea" ]]; then
+        log_success ".mcp.json exists at repository root"
        log_success "projman/gitea symlink exists"
    else
-        log_error "projman/gitea symlink missing"
+        log_error ".mcp.json missing at repository root"
-        log_todo "Run: ln -s ../../../mcp-servers/gitea plugins/projman/mcp-servers/gitea"
+        log_todo "Create .mcp.json with MCP server configurations"
    fi
    # Check cmdb-assistant -> netbox symlink
    local cmdb_netbox="$REPO_ROOT/plugins/cmdb-assistant/mcp-servers/netbox"
    if [[ -L "$cmdb_netbox" ]]; then
        log_success "cmdb-assistant/netbox symlink exists"
    else
        log_error "cmdb-assistant/netbox symlink missing"
        log_todo "Run: ln -s ../../../mcp-servers/netbox plugins/cmdb-assistant/mcp-servers/netbox"
    fi
    # Check pr-review -> gitea symlink
    local prreview_gitea="$REPO_ROOT/plugins/pr-review/mcp-servers/gitea"
    if [[ -L "$prreview_gitea" ]]; then
        log_success "pr-review/gitea symlink exists"
    else
        log_error "pr-review/gitea symlink missing"
        log_todo "Run: ln -s ../../../mcp-servers/gitea plugins/pr-review/mcp-servers/gitea"
    fi
    # Check data-platform -> data-platform symlink
    local dataplatform_link="$REPO_ROOT/plugins/data-platform/mcp-servers/data-platform"
    if [[ -L "$dataplatform_link" ]]; then
        log_success "data-platform symlink exists"
    else
        log_error "data-platform symlink missing"
        log_todo "Run: ln -s ../../../mcp-servers/data-platform plugins/data-platform/mcp-servers/data-platform"
    fi
    # Check viz-platform -> viz-platform symlink
    local vizplatform_link="$REPO_ROOT/plugins/viz-platform/mcp-servers/viz-platform"
    if [[ -L "$vizplatform_link" ]]; then
        log_success "viz-platform symlink exists"
    else
        log_error "viz-platform symlink missing"
        log_todo "Run: ln -s ../../../mcp-servers/viz-platform plugins/viz-platform/mcp-servers/viz-platform"
    fi
    # Check contract-validator -> contract-validator symlink
    local contractvalidator_link="$REPO_ROOT/plugins/contract-validator/mcp-servers/contract-validator"
    if [[ -L "$contractvalidator_link" ]]; then
        log_success "contract-validator symlink exists"
    else
        log_error "contract-validator symlink missing"
        log_todo "Run: ln -s ../../../mcp-servers/contract-validator plugins/contract-validator/mcp-servers/contract-validator"
    fi
 }
@@ -335,8 +289,8 @@ main() {
    setup_shared_mcp "viz-platform"
    setup_shared_mcp "contract-validator"
-    # Verify symlinks from plugins to shared MCP servers
+    # Verify MCP configuration at root
-    verify_symlinks
+    verify_mcp_config
    # Configuration
    setup_config_templates
--- a/scripts/validate-marketplace.sh
+++ b/scripts/validate-marketplace.sh
@@ -248,58 +248,25 @@ done
 echo "✓ All file references validated"
-# v3.0.0: Validate MCP server symlinks
+# Validate MCP servers and configuration
 echo ""
-echo "=== Validating MCP Server Symlinks (v3.0.0+) ==="
+echo "=== Validating MCP Servers ==="
 # Check shared MCP servers exist
-if [[ ! -d "$ROOT_DIR/mcp-servers/gitea" ]]; then
+for server in gitea netbox data-platform viz-platform contract-validator; do
-    echo "ERROR: Shared gitea MCP server not found at mcp-servers/gitea/"
+    if [[ ! -d "$ROOT_DIR/mcp-servers/$server" ]]; then
        echo "ERROR: Shared $server MCP server not found at mcp-servers/$server/"
        exit 1
    fi
-echo "✓ Shared gitea MCP server exists"
+    echo "✓ Shared $server MCP server exists"
 done
-if [[ ! -d "$ROOT_DIR/mcp-servers/netbox" ]]; then
+# Check .mcp.json exists at root
-    echo "ERROR: Shared netbox MCP server not found at mcp-servers/netbox/"
+if [[ ! -f "$ROOT_DIR/.mcp.json" ]]; then
    echo "ERROR: .mcp.json not found at repository root"
    exit 1
 fi
-echo "✓ Shared netbox MCP server exists"
+echo "✓ .mcp.json configuration exists"
 if [[ ! -d "$ROOT_DIR/mcp-servers/data-platform" ]]; then
    echo "ERROR: Shared data-platform MCP server not found at mcp-servers/data-platform/"
    exit 1
 fi
 echo "✓ Shared data-platform MCP server exists"
 # Check symlinks for plugins that use MCP servers
 check_mcp_symlink() {
    local plugin_name="$1"
    local server_name="$2"
    local symlink_path="$ROOT_DIR/plugins/$plugin_name/mcp-servers/$server_name"
    if [[ -L "$symlink_path" ]]; then
        # Verify symlink resolves correctly
        if [[ -d "$symlink_path" ]]; then
            echo "✓ $plugin_name -> $server_name symlink valid"
        else
            echo "ERROR: $plugin_name -> $server_name symlink broken (does not resolve)"
            exit 1
        fi
    else
        echo "ERROR: Missing symlink at plugins/$plugin_name/mcp-servers/$server_name"
        exit 1
    fi
 }
 # Plugins with gitea MCP dependency
 check_mcp_symlink "projman" "gitea"
 check_mcp_symlink "pr-review" "gitea"
 # Plugins with netbox MCP dependency
 check_mcp_symlink "cmdb-assistant" "netbox"
 # Plugins with data-platform MCP dependency
 check_mcp_symlink "data-platform" "data-platform"
 echo ""
 echo "=== All validations passed ==="
`@@ -112,4 +112,4 @@ pytest tests/ -v`

	`## Usage`	`## Usage`

	This MCP server is used by the `viz-platform` plugin. See [plugins/viz-platform/README.md](../../plugins/viz-platform/README.md) for usage instructions.	This MCP server is used by the `viz-platform` plugin. See the plugin's commands in `plugins/viz-platform/commands/` for usage.
		`@@ -1 +0,0 @@`
			`2026-01-26T11:59:05 \| .claude-plugin \| /home/lmiranda/claude-plugins-work/.claude-plugin/marketplace.json \| CLAUDE.md .claude-plugin/marketplace.json`