Merge pull request 'feat: add plugin name prefixes to hooks and improve git-flow sync' (#105 ) from feat/hook-improvements-and-sync-prune into development

feat: add plugin name prefixes to hooks and improve git-flow sync
- Add [plugin-name] prefix to all hook messages for better identification - Make doc-guardian hook notification-only (non-blocking) - Add stale branch detection to /commit-sync with git fetch --prune - Enhance /branch-cleanup to handle stale branches separately Closes improvements for hook UX and git workflow Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-22 21:14:32 +00:00 · 2026-01-22 16:13:17 -05:00 · 2026-01-22 20:01:32 +00:00 · 2026-01-22 14:28:01 -05:00 · 2026-01-22 14:19:05 -05:00 · 2026-01-22 18:36:36 +00:00
145 changed files with 11606 additions and 8150 deletions
--- a/.claude-plugin/marketplace.json
+++ b/.claude-plugin/marketplace.json
@@ -1,35 +1,154 @@
 {
-  "name": "bandit-claude-marketplace",
+  "name": "leo-claude-mktplace",
  "version": "2.0.0",
  "description": "Project management plugins with Gitea and NetBox integrations",
  "owner": {
-    "name": "Bandit Labs",
+    "name": "Leo Miranda",
-    "email": "dev@banditlabs.io"
+    "email": "leobmiranda@gmail.com"
  },
  "metadata": {
    "description": "Project management plugins with Gitea and NetBox integrations",
    "version": "3.1.0"
  },
  "plugins": [
    {
      "name": "projman",
-      "version": "2.0.0",
+      "version": "3.1.0",
      "description": "Sprint planning and project management with Gitea integration",
-      "source": "./plugins/projman"
+      "source": "./plugins/projman",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/projman/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "mcpServers": ["./.mcp.json"],
      "category": "development",
      "tags": ["sprint", "agile", "gitea", "project-management"],
      "license": "MIT"
    },
    {
      "name": "doc-guardian",
      "version": "1.0.0",
      "description": "Automatic documentation drift detection and synchronization",
      "source": "./plugins/doc-guardian",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/doc-guardian/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "hooks": ["./hooks/hooks.json"],
      "category": "productivity",
      "tags": ["documentation", "drift-detection", "sync"],
      "license": "MIT"
    },
    {
      "name": "code-sentinel",
      "version": "1.0.0",
      "description": "Security scanning and code refactoring tools",
      "source": "./plugins/code-sentinel",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/code-sentinel/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "hooks": ["./hooks/hooks.json"],
      "category": "security",
      "tags": ["security-scan", "refactoring", "vulnerabilities"],
      "license": "MIT"
    },
    {
      "name": "project-hygiene",
      "version": "0.1.0",
      "description": "Post-task cleanup hook that removes temp files and manages orphaned files",
-      "source": "./plugins/project-hygiene"
+      "source": "./plugins/project-hygiene",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/project-hygiene/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "hooks": ["./hooks/hooks.json"],
      "category": "productivity",
      "tags": ["cleanup", "automation", "hygiene"],
      "license": "MIT"
    },
    {
      "name": "cmdb-assistant",
      "version": "1.0.0",
      "description": "NetBox CMDB integration for infrastructure management",
-      "source": "./plugins/cmdb-assistant"
+      "source": "./plugins/cmdb-assistant",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/cmdb-assistant/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "mcpServers": ["./.mcp.json"],
      "category": "infrastructure",
      "tags": ["cmdb", "netbox", "dcim", "ipam"],
      "license": "MIT"
    },
    {
      "name": "claude-config-maintainer",
      "version": "1.0.0",
      "description": "CLAUDE.md optimization and maintenance for Claude Code projects",
-      "source": "./plugins/claude-config-maintainer"
+      "source": "./plugins/claude-config-maintainer",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/claude-config-maintainer/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "category": "development",
      "tags": ["claude-md", "configuration", "optimization"],
      "license": "MIT"
    },
    {
      "name": "clarity-assist",
      "version": "1.0.0",
      "description": "Prompt optimization and requirement clarification with ND-friendly accommodations",
      "source": "./plugins/clarity-assist",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/clarity-assist/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "category": "productivity",
      "tags": ["prompts", "requirements", "clarification", "nd-friendly"],
      "license": "MIT"
    },
    {
      "name": "git-flow",
      "version": "1.0.0",
      "description": "Git workflow automation with intelligent commit messages and branch management",
      "source": "./plugins/git-flow",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/git-flow/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "category": "development",
      "tags": ["git", "workflow", "commits", "branching"],
      "license": "MIT"
    },
    {
      "name": "pr-review",
      "version": "1.0.0",
      "description": "Multi-agent pull request review with confidence scoring and actionable feedback",
      "source": "./plugins/pr-review",
      "author": {
        "name": "Leo Miranda",
        "email": "leobmiranda@gmail.com"
      },
      "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/pr-review/README.md",
      "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
      "mcpServers": ["./.mcp.json"],
      "category": "development",
      "tags": ["code-review", "pull-requests", "security", "quality"],
      "license": "MIT"
    }
  ]
 }
--- a/.mcp.json
+++ b/.mcp.json
@@ -1,28 +0,0 @@
 {
  "mcpServers": {
    "gitea": {
      "command": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/gitea/.venv/bin/python",
      "args": ["-m", "mcp_server.server"],
      "cwd": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/gitea",
      "env": {
        "PYTHONPATH": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/gitea"
      }
    },
    "wikijs": {
      "command": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/wikijs/.venv/bin/python",
      "args": ["-m", "mcp_server.server"],
      "cwd": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/wikijs",
      "env": {
        "PYTHONPATH": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/wikijs"
      }
    },
    "netbox": {
      "command": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/netbox/.venv/bin/python",
      "args": ["-m", "mcp_server.server"],
      "cwd": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/netbox",
      "env": {
        "PYTHONPATH": "/home/lmiranda/repos/bandit/support-claude-mktplace/mcp-servers/netbox"
      }
    }
  }
 }
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,10 +1,204 @@
 # Changelog
-All notable changes to support-claude-mktplace will be documented in this file.
+All notable changes to the Leo Claude Marketplace will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
-## [Unreleased]
+## [3.1.1] - 2026-01-22
 ### Added
 - **git-flow:** `/commit-sync` now prunes stale remote-tracking branches with `git fetch --prune`
 - **git-flow:** `/commit-sync` detects and reports local branches with deleted upstreams
 - **git-flow:** `/branch-cleanup` now handles stale branches (upstream gone) separately from merged branches
 - **git-flow:** New `GIT_CLEANUP_STALE` environment variable for stale branch cleanup control
 ### Changed
 - **All hooks:** Added `[plugin-name]` prefix to all hook messages for better identification
  - `[projman]`, `[pr-review]`, `[code-sentinel]`, `[doc-guardian]` prefixes
 - **doc-guardian:** Hook now notification-only (no file reads or blocking operations)
  - Suggests running `/doc-sync` instead of performing inline checks
  - Significantly reduces workflow interruption
 ### Fixed
 - doc-guardian hook no longer stalls workflow with deep file analysis
 ---
 ## [3.1.0] - 2026-01-21
 ### Added
 #### Debug Workflow Commands (projman)
 - **`/debug-report`** - Run diagnostics in test projects, create structured issues in marketplace
  - Runs 5 diagnostic MCP tool tests with explicit repo parameter
  - Captures full project context (git remote, cwd, branch)
  - Generates structured issue with hypothesis and investigation steps
  - Creates issue in configured marketplace repository automatically
 - **`/debug-review`** - Investigate diagnostic issues with human approval gates
  - Lists open diagnostic issues for triage
  - Maps errors to relevant code files using error-to-file mapping
  - MANDATORY: Reads relevant files before proposing any fix
  - Three approval gates: investigation summary, fix approach, PR creation
  - Creates feature branch, commits, and PR with proper linking
 #### MCP Server Improvements
 - Dynamic label format detection in `suggest_labels`
  - Supports slash format (`Type/Bug`) and colon-space format (`Type: Bug`)
  - Fetches actual labels from repo and matches suggestions to real format
  - Handles Effort/Efforts singular/plural normalization
 ### Changed
 - **`/labels-sync`** completely rewritten with explicit execution steps
  - Step 1 now explicitly requires running `git remote get-url origin` via Bash
  - All MCP tool calls show required `repo` parameter
  - Added "DO NOT" section preventing common mistakes
  - Removed confusing "Label Reference" section that caused file creation prompts
 ### Fixed
 - MCP tools no longer fail with "Use 'owner/repo' format" error
  - Root cause: MCP server is sandboxed and cannot auto-detect project directory
  - Solution: Command documentation now instructs Claude to detect repo via Bash first
 ---
 ## [3.0.1] - 2026-01-21
 ### Added
 - `/project-init` command for quick project setup when system is already configured
 - `/project-sync` command to sync .env with git remote after repository move/rename
 - SessionStart hooks for automatic mismatch detection between git remote and .env
 - Interactive setup wizard (`/initial-setup`) redesigned to use Claude tools instead of bash script
 ### Changed
 - `GITEA_ORG` moved from system-level to project-level configuration (different projects may belong to different organizations)
 - Environment variables renamed to match MCP server expectations:
  - `GITEA_URL` → `GITEA_API_URL` (must include `/api/v1`)
  - `GITEA_TOKEN` → `GITEA_API_TOKEN`
  - `NETBOX_URL` → `NETBOX_API_URL` (must include `/api`)
  - `NETBOX_TOKEN` → `NETBOX_API_TOKEN`
 - Setup commands now validate repository via Gitea API before saving configuration
 - README.md simplified to show only wizard setup path (manual setup moved to CONFIGURATION.md)
 ### Fixed
 - API URL paths in curl commands (removed redundant `/api/v1` since it's now in the URL variable)
 - Documentation now correctly references environment variable names
 ---
 ## [3.0.0] - 2026-01-20
 ### Added
 #### New Plugins
 - **clarity-assist** v1.0.0 - Prompt optimization with ND accommodations
  - `/clarify` command for full 4-D methodology optimization
  - `/quick-clarify` command for rapid single-pass clarification
  - clarity-coach agent with ND-friendly questioning patterns
  - prompt-patterns skill with optimization rules
 - **git-flow** v1.0.0 - Git workflow automation
  - `/commit` command with smart conventional commit messages
  - `/commit-push`, `/commit-merge`, `/commit-sync` workflow commands
  - `/branch-start`, `/branch-cleanup` branch management commands
  - `/git-status` enhanced status with recommendations
  - `/git-config` interactive configuration
  - git-assistant agent for complex operations
  - workflow-patterns skill with branching strategies
 - **pr-review** v1.0.0 - Multi-agent pull request review
  - `/pr-review` command for comprehensive multi-agent review
  - `/pr-summary` command for quick PR overview
  - `/pr-findings` command for filtering review findings
  - coordinator agent for orchestrating reviews
  - security-reviewer, performance-analyst, maintainability-auditor, test-validator agents
  - review-patterns skill with confidence scoring rules
 #### Gitea MCP Server Enhancements
 - 6 new Pull Request tools:
  - `list_pull_requests` - List PRs with filters
  - `get_pull_request` - Get PR details
  - `get_pr_diff` - Get PR diff
  - `get_pr_comments` - Get PR comments
  - `create_pr_review` - Create review (approve, request changes, comment)
  - `add_pr_comment` - Add comment to PR
 #### Documentation
 - `docs/CONFIGURATION.md` - Centralized configuration guide for all plugins
 ### Changed
 - **BREAKING:** Marketplace renamed from `claude-code-marketplace` to `leo-claude-mktplace`
 - **BREAKING:** MCP servers moved from plugin directories to shared `mcp-servers/` at repository root
 - All plugins now have `category`, `tags`, and `license` fields in marketplace.json
 - Plugin MCP dependencies now use symlinks to shared servers
 - projman version bumped to 3.0.0 (includes PR tools integration)
 - projman CONFIGURATION.md slimmed down, links to central docs
 ### Removed
 - Standalone MCP server directories inside plugins (replaced with symlinks)
 ---
 ## [2.3.0] - 2026-01-20
 ### Added
 #### New Plugins
 - **doc-guardian** v1.0.0 - Documentation lifecycle management
  - `/doc-audit` command for full project documentation drift analysis
  - `/doc-sync` command to batch apply pending documentation updates
  - PostToolUse hook for automatic drift detection
  - Stop hook reminder for pending updates
  - doc-analyzer agent for cross-reference analysis
  - doc-patterns skill for documentation structure knowledge
 - **code-sentinel** v1.0.0 - Security scanning and refactoring
  - `/security-scan` command for comprehensive security audit
  - `/refactor` command to apply refactoring patterns
  - `/refactor-dry` command to preview refactoring opportunities
  - PreToolUse hook for real-time security scanning
  - security-reviewer agent for vulnerability analysis
  - refactor-advisor agent for code structure improvements
  - security-patterns skill for vulnerability detection rules
 #### projman Enhancements
 - `/test-gen` command - Generate unit, integration, and e2e tests for specified code
 ### Changed
 - Marketplace version bumped to 2.3.0
 - projman version bumped to 2.3.0
 ## [2.2.0] - 2026-01-20
 ### Added
 - `/review` command for pre-sprint-close code quality checks (projman)
 - `/test-check` command for test verification before sprint close (projman)
 - `code-reviewer` agent for structured code review workflow (projman)
 - Validation script (`scripts/validate-marketplace.sh`) for marketplace compliance
 - `homepage` and `repository` fields to all plugin entries in marketplace.json
 - `metadata` wrapper for description/version in marketplace.json
 - Keywords to all plugin manifests for better discoverability
 - `commands` and `agents` directory references to plugin manifests
 - Versioning rule: version displayed only in main README.md title
 ### Changed
 - Updated marketplace.json with required fields per Claude Code spec
 - Fixed installation documentation to use official Claude Code methods
 - Prioritized public HTTPS URL over Tailscale SSH URL in documentation
 - Updated all plugin manifests with author, homepage, repository, license fields
 - Consolidated version display to main README.md title only
 - Removed version numbers from plugin documentation titles
 ### Fixed
 - Plugin manifests now include all required fields per Claude Code spec
 - Installation section uses `extraKnownMarketplaces` instead of undocumented `pluginMarketplace`
 ### Removed
 - `docs/references/` directory (obsolete planning documents)
 - Version numbers from individual plugin README titles
 - Version section from plugins/projman/README.md
 ## [2.1.0] - 2026-01-15
 ### Added
 - `docs/CANONICAL-PATHS.md` - Single source of truth for all file paths
@@ -15,16 +209,12 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 - Update documentation (`docs/UPDATING.md`)
 - `/initial-setup` slash command
 - File creation governance rules in CLAUDE.md
 - Architecture diagram specifications in `docs/architecture/`
 - `.scratch/` directory for transient work
 - `scripts/` directory for setup automation
 - `docs/architecture/` for Draw.io diagrams
 - `docs/workflows/` for workflow documentation
 ### Changed
 - Replaced `docs/CORRECT-ARCHITECTURE.md` reference with `docs/CANONICAL-PATHS.md`
 - Added mandatory path verification section to CLAUDE.md
 - Reorganized documentation into `docs/references/`, `docs/architecture/`, `docs/workflows/`
 - Updated CLAUDE.md with file creation governance
 ### Fixed
@@ -32,21 +222,44 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 ### Removed
 - Organization/workspace GID variable (no longer needed)
 - Deprecated `cmdb-assistant/` plugin
 - Development output files (test scripts, status reports)
 - IDE-specific workspace files
 - Stray files from project root
-## [0.1.0] - Initial Release
+## [2.0.0] - 2026-01-06
 ### Added
- projman plugin for sprint management
+- Full Gitea integration with wiki, milestones, dependencies
 - Parallel execution batching via dependency graph
 - Wiki tools for lessons learned (`create_lesson`, `search_lessons`)
 - Milestone tools (`list_milestones`, `create_milestone`, `update_milestone`)
 - Dependency tools (`list_issue_dependencies`, `create_issue_dependency`, `get_execution_order`)
 - Validation tools (`validate_repo_org`, `get_branch_protection`)
 - MCP servers bundled inside plugins (not shared at root)
 ### Changed
 - MCP server architecture: bundled in plugins instead of shared at root
 - Configuration uses `${CLAUDE_PLUGIN_ROOT}/mcp-servers/` paths
 ## [1.0.0] - 2025-12-15
 ### Added
 - projman plugin with basic sprint commands
 - `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close` commands
 - `/labels-sync` command for label taxonomy synchronization
 - Three-agent model (planner, orchestrator, executor)
 - Gitea MCP server with issue and label tools
 - 43-label taxonomy system
 - Hybrid configuration system (system + project level)
 - Branch-aware security model
 ## [0.1.0] - 2025-12-01
 ### Added
 - Initial repository structure
 - projman plugin structure (planned)
 - projman-pmo plugin structure (planned)
 - project-hygiene plugin for cleanup automation
- Gitea MCP server
+- claude-config-maintainer plugin structure
- Wiki.js MCP server
+- cmdb-assistant plugin structure
- 43-label taxonomy system
+- Basic marketplace manifest
 - Lessons learned capture system
 - Hybrid configuration system (system + project level)
 - Three-agent model (planner, orchestrator, executor)
 - Branch-aware security model
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,478 +1,258 @@
 # CLAUDE.md
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+This file provides guidance to Claude Code when working with code in this repository.
 ## Project Overview
-This repository contains Claude Code plugins for project management:
+**Repository:** leo-claude-mktplace
 **Version:** 3.0.1
 **Status:** Production Ready
-1. **`projman`** - Single-repository project management plugin with Gitea integration
+A plugin marketplace for Claude Code containing:
 2. **`projman-pmo`** - Multi-project PMO coordination plugin
 3. **`claude-config-maintainer`** - CLAUDE.md optimization and maintenance plugin
 4. **`cmdb-assistant`** - NetBox CMDB integration for infrastructure management
-These plugins transform a proven 15-sprint workflow into reusable, distributable tools for managing software development with Claude Code, Gitea, and agile methodologies.
+| Plugin | Description | Version |
 |--------|-------------|---------|
 | `projman` | Sprint planning and project management with Gitea integration | 3.0.0 |
 | `git-flow` | Git workflow automation with smart commits and branch management | 1.0.0 |
 | `pr-review` | Multi-agent PR review with confidence scoring | 1.0.0 |
 | `clarity-assist` | Prompt optimization with ND-friendly accommodations | 1.0.0 |
 | `doc-guardian` | Automatic documentation drift detection and synchronization | 1.0.0 |
 | `code-sentinel` | Security scanning and code refactoring tools | 1.0.0 |
 | `claude-config-maintainer` | CLAUDE.md optimization and maintenance | 1.0.0 |
 | `cmdb-assistant` | NetBox CMDB integration for infrastructure management | 1.0.0 |
 | `project-hygiene` | Post-task cleanup automation via hooks | 0.1.0 |
-**Status:** projman v1.0.0 complete with full Gitea integration
+## Quick Start
-## File Creation Governance
+```bash
 # Validate marketplace compliance
 ./scripts/validate-marketplace.sh
-### Allowed Root Files
+# After updates
-
+./scripts/post-update.sh   # Rebuild venvs, verify symlinks
 Only these files may exist at the repository root:
 - `CLAUDE.md` - This file
 - `README.md` - Repository overview
 - `LICENSE` - License file
 - `CHANGELOG.md` - Version history
 - `.gitignore` - Git ignore rules
 - `.env.example` - Environment template (if needed)
 ### Allowed Root Directories
 Only these directories may exist at the repository root:
 | Directory | Purpose |
 |-----------|---------|
 | `.claude/` | Claude Code local settings |
 | `.claude-plugin/` | Marketplace manifest |
 | `.claude-plugins/` | Local marketplace definitions |
 | `.scratch/` | Transient work (auto-cleaned) |
 | `docs/` | Documentation |
 | `hooks/` | Shared hooks (if any) |
 | `plugins/` | All plugins (projman, projman-pmo, project-hygiene, cmdb-assistant, claude-config-maintainer) |
 | `scripts/` | Setup and maintenance scripts |
 ### File Creation Rules
 1. **No new root files** - Do not create files directly in the repository root unless listed above
 2. **No new root directories** - Do not create top-level directories without explicit approval
 3. **Transient work goes in `.scratch/`** - Any temporary files, test outputs, or exploratory work must be created in `.scratch/`
 4. **Clean up after tasks** - Delete files in `.scratch/` when the task is complete
 5. **Documentation location** - All documentation goes in `docs/` with appropriate subdirectory:
   - `docs/references/` - Reference specifications and summaries
   - `docs/architecture/` - Architecture diagrams (Draw.io files)
   - `docs/workflows/` - Workflow documentation
 6. **No output files** - Do not leave generated output, logs, or test results outside designated directories
 ### Enforcement
 Before creating any file, verify:
 1. Is this file type allowed in the target location?
 2. If temporary, am I using `.scratch/`?
 3. If documentation, am I using the correct `docs/` subdirectory?
 4. Will this file be cleaned up after the task?
 **Violation of these rules creates technical debt and project chaos.**
 ## Path Verification (MANDATORY)
 ### Before Generating Any Prompt or Creating Any File
 **This is non-negotiable. Failure to follow causes structural damage.**
 1. **READ `docs/CANONICAL-PATHS.md` FIRST**
   - This file is the single source of truth
   - Never infer paths from memory or context
   - Never assume paths based on conversation history
 2. **List All Paths**
   - Before generating a prompt, list every file path it will create/modify
   - Show the list to the user
 3. **Verify Each Path**
   - Check each path against `docs/CANONICAL-PATHS.md`
   - If a path is not in that file, STOP and ask
 4. **Show Verification**
   - Present a verification table to user:
   ```
   | Path | Matches CANONICAL-PATHS.md? |
   |------|----------------------------|
   | plugins/projman/... | ✅ Yes |
 ```
-5. **Get Confirmation**
+### Plugin Commands by Category
   - User must confirm paths are correct before proceeding
-### Relative Path Rules
+| Category | Commands |
 |----------|----------|
 | **Setup** | `/initial-setup`, `/project-init`, `/project-sync` |
 | **Sprint** | `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close` |
 | **Quality** | `/review`, `/test-check`, `/test-gen` |
 | **PR Review** | `/pr-review:initial-setup`, `/pr-review:project-init` |
 | **Docs** | `/doc-audit`, `/doc-sync` |
 | **Security** | `/security-scan`, `/refactor`, `/refactor-dry` |
 | **Config** | `/config-analyze`, `/config-optimize` |
 | **Debug** | `/debug-report`, `/debug-review` |
- Plugin to bundled MCP server: `${CLAUDE_PLUGIN_ROOT}/mcp-servers/{server}`
+## Repository Structure
 - Marketplace to plugin: `./../../../plugins/{plugin-name}`
 - **ALWAYS calculate from CANONICAL-PATHS.md, never from memory**
 ### Recovery Protocol
 If you suspect paths are wrong:
 1. Read `docs/CANONICAL-PATHS.md`
 2. Compare actual structure against documented structure
 3. Report discrepancies
 4. Generate corrective prompt if needed
 ## Core Architecture
 ### Three-Agent Model
 The plugins implement a three-agent architecture that mirrors the proven workflow:
 **Planner Agent** (`agents/planner.md`)
 - Performs architecture analysis and sprint planning
 - Creates detailed planning documents
 - Makes architectural decisions
 - Creates Gitea issues with appropriate labels
 - Personality: Asks clarifying questions, thinks through edge cases, never rushes
 **Orchestrator Agent** (`agents/orchestrator.md`)
 - Coordinates sprint execution
 - Generates lean execution prompts (not full docs)
 - Tracks progress and updates documentation
 - Handles Git operations (commit, merge, cleanup)
 - Manages task dependencies
 - Personality: Concise, action-oriented, tracks details meticulously
 **Executor Agent** (`agents/executor.md`)
 - Implements features according to execution prompts
 - Writes clean, tested code
 - Follows architectural decisions from planning
 - Generates completion reports
 - Personality: Implementation-focused, follows specs precisely
 ### MCP Server Integration
 **Gitea MCP Server** (Python) - bundled in projman plugin
 **Issue Tools:**
 - `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
 - `get_labels` - Fetch org + repo label taxonomy
 - `suggest_labels` - Analyze context and suggest appropriate labels
 **Milestone Tools:**
 - `list_milestones` - List sprint milestones
 - `get_milestone` - Get milestone details
 - `create_milestone` - Create sprint milestone
 - `update_milestone` - Update/close milestone
 **Dependency Tools:**
 - `list_issue_dependencies` - Get issue dependencies
 - `create_issue_dependency` - Create dependency between issues
 - `get_execution_order` - Get parallel execution batches
 **Wiki Tools (Gitea Wiki):**
 - `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:**
 - `validate_repo_org` - Check repo belongs to organization
 - `get_branch_protection` - Check branch protection rules
 - `create_label` - Create missing required labels
 **Key Architecture Points:**
 - MCP servers are **bundled inside each plugin** at `plugins/{plugin}/mcp-servers/`
 - This ensures plugins work when cached by Claude Code (only plugin directory is cached)
 - Configuration uses hybrid approach (system-level + project-level)
 - All plugins reference `${CLAUDE_PLUGIN_ROOT}/mcp-servers/` in their `.mcp.json` files
 ## Branch-Aware Security Model
 Plugin behavior adapts to the current Git branch to prevent accidental changes:
 **Development Mode** (`development`, `feat/*`)
 - Full access to all operations
 - Can create Gitea issues
 - Can modify all files
 **Staging Mode** (`staging`)
 - Read-only for application code
 - Can modify `.env` files
 - Can create issues to document needed fixes
 - Warns on attempted code changes
 **Production Mode** (`main`)
 - Read-only for application code
 - Emergency-only `.env` modifications
 - Can create incident issues
 - Blocks code changes
 This behavior is implemented in both CLAUDE.md (file-level) and plugin agents (tool-level).
 ## Label Taxonomy System
 The project uses a sophisticated 43-label taxonomy at organization level:
 **Organization Labels (27):**
 - Agent/2, Complexity/3, Efforts/5, Priority/4, Risk/3, Source/4, Type/6
 **Repository Labels (16):**
 - Component/9, Tech/7
 **Important Labels:**
 - `Type/Refactor` - For architectural changes and code restructuring (exclusive Type label)
 - Used for service extraction, architecture modifications, technical debt
 The label system includes:
 - `skills/label-taxonomy/labels-reference.md` - Local reference synced from Gitea
 - Label suggestion logic that detects appropriate labels from context
 - `/labels-sync` command to review and sync changes from Gitea
 ## Lessons Learned System
 **Critical Feature:** After 15 sprints without lesson capture, repeated mistakes occurred (e.g., Claude Code infinite loops on similar issues 2-3 times).
 **Gitea Wiki Structure:**
 Lessons learned are stored in the Gitea repository's built-in wiki under `lessons-learned/sprints/`.
 **Workflow:**
 - Orchestrator captures lessons at sprint close via Gitea Wiki MCP tools
 - Planner searches relevant lessons at sprint start using `search_lessons`
 - Tags enable cross-project lesson discovery
 - Focus on preventable repetitions, not every detail
 - Web interface available through Gitea Wiki
 ## Development Workflow
 ### Build Order
 1. **Phase 1-8:** Build `projman` plugin first (single-repo)
 2. **Phase 9-11:** Build `pmo` plugin second (multi-project)
 3. **Phase 12:** Production deployment
 See [docs/reference-material/projman-implementation-plan.md](docs/reference-material/projman-implementation-plan.md) for the complete 12-phase implementation plan.
 ### Repository Structure (DEFINITIVE)
 ⚠️ **See `docs/CANONICAL-PATHS.md` for the authoritative path reference - THIS IS THE SINGLE SOURCE OF TRUTH**
 ```
-bandit/support-claude-mktplace/
+leo-claude-mktplace/
 ├── .claude-plugin/
-│   └── marketplace.json
+│   └── marketplace.json          # Marketplace manifest
-├── plugins/                        # ← ALL PLUGINS (with bundled MCP servers)
+├── mcp-servers/                  # SHARED MCP servers (v3.0.0+)
-│   ├── projman/                    # ← PROJECT PLUGIN
+│   ├── gitea/                    # Gitea MCP (issues, PRs, wiki)
-│   │   ├── .claude-plugin/
+│   └── netbox/                   # NetBox MCP (CMDB)
-│   │   │   └── plugin.json
+├── plugins/
-│   │   ├── .mcp.json               # Points to ${CLAUDE_PLUGIN_ROOT}/mcp-servers/
+│   ├── projman/                  # Sprint management
-│   │   ├── mcp-servers/            # ← MCP servers BUNDLED IN plugin
+│   │   ├── .claude-plugin/plugin.json
 │   │   │   └── gitea/              # Gitea + Wiki tools
 │   │   │       ├── .venv/
 │   │   │       ├── requirements.txt
 │   │   │       ├── mcp_server/
 │   │   │       └── tests/
 │   │   ├── commands/
 │   │   │   ├── sprint-plan.md
 │   │   │   ├── sprint-start.md
 │   │   │   ├── sprint-status.md
 │   │   │   ├── sprint-close.md
 │   │   │   ├── labels-sync.md
 │   │   │   └── initial-setup.md
 │   │   ├── agents/
 │   │   │   ├── planner.md
 │   │   │   ├── orchestrator.md
 │   │   │   └── executor.md
 │   │   ├── skills/
 │   │   │   └── label-taxonomy/
 │   │   │       └── labels-reference.md
 │   │   ├── README.md
 │   │   └── CONFIGURATION.md
 │   ├── projman-pmo/                # ← PMO PLUGIN
 │   │   ├── .claude-plugin/
 │   │   │   └── plugin.json
 │   │   ├── .mcp.json
-│   │   ├── commands/
+│   │   ├── mcp-servers/gitea -> ../../../mcp-servers/gitea  # SYMLINK
-│   │   ├── agents/
+│   │   ├── commands/             # 12 commands (incl. setup)
-│   │   │   └── pmo-coordinator.md
+│   │   ├── hooks/                # SessionStart mismatch detection
-│   │   └── README.md
+│   │   ├── agents/               # 4 agents
-│   ├── cmdb-assistant/             # ← CMDB PLUGIN
+│   │   └── skills/label-taxonomy/
-│   │   ├── .claude-plugin/
+│   ├── git-flow/                 # Git workflow automation
-│   │   │   └── plugin.json
+│   │   ├── .claude-plugin/plugin.json
-│   │   ├── .mcp.json               # Points to ${CLAUDE_PLUGIN_ROOT}/mcp-servers/
+│   │   ├── commands/             # 8 commands
 │   │   ├── mcp-servers/            # ← MCP servers BUNDLED IN plugin
 │   │   │   └── netbox/
 │   │   │       ├── .venv/
 │   │   │       ├── requirements.txt
 │   │   │       └── mcp_server/
 │   │   ├── commands/
 │   │   └── agents/
-│   └── project-hygiene/            # ← CLEANUP PLUGIN
+│   ├── pr-review/                # Multi-agent PR review
-│       └── ...
+│   │   ├── .claude-plugin/plugin.json
-├── scripts/                        # Setup and maintenance scripts
+│   │   ├── .mcp.json
-│   ├── setup.sh
+│   │   ├── mcp-servers/gitea -> ../../../mcp-servers/gitea  # SYMLINK
-│   └── post-update.sh
+│   │   ├── commands/             # 6 commands (incl. setup)
 │   │   ├── hooks/                # SessionStart mismatch detection
 │   │   └── agents/               # 5 agents
 │   ├── clarity-assist/           # Prompt optimization (NEW v3.0.0)
 │   │   ├── .claude-plugin/plugin.json
 │   │   ├── commands/             # 2 commands
 │   │   └── agents/
 │   ├── doc-guardian/             # Documentation drift detection
 │   ├── code-sentinel/            # Security scanning & refactoring
 │   ├── claude-config-maintainer/
 │   ├── cmdb-assistant/
 │   └── project-hygiene/
 ├── scripts/
 │   ├── setup.sh, post-update.sh
 │   └── validate-marketplace.sh   # Marketplace compliance validation
 └── docs/
    ├── CANONICAL-PATHS.md        # Single source of truth for paths
    └── CONFIGURATION.md          # Centralized configuration guide
 ```
 ### Key Design Decisions
 **MCP Servers (Bundled in Plugins):**
 - **Gitea MCP**: Issues, labels, wiki, milestones, dependencies (bundled in projman)
 - **NetBox MCP**: Infrastructure management (bundled in cmdb-assistant)
 - Servers are **bundled inside each plugin** that needs them
 - This ensures plugins work when cached by Claude Code
 **Python Implementation:**
 - Python chosen over Node.js for MCP servers
 - Better suited for configuration management and modular code
 - Easier to maintain and extend
 - Virtual environment (.venv) per MCP server
 **Hybrid Configuration:**
 - **System-level**: `~/.config/claude/gitea.env` (credentials)
 - **Project-level**: `project-root/.env` (repository specification)
 - Merge strategy: project overrides system
 - Benefits: Single token per service, easy multi-project setup
 **Skills as Knowledge, Not Orchestrators:**
 - Skills provide supporting knowledge loaded when relevant
 - Agents are the primary interface
 - Reduces token usage
 - Makes knowledge reusable across agents
 **Branch Detection:**
 - Two layers: CLAUDE.md (file access) + Plugin agents (tool usage)
 - Defense in depth approach
 - Plugin works with or without CLAUDE.md
 ## Multi-Project Context (PMO Plugin)
 The `projman-pmo` plugin coordinates interdependent projects across an organization. Example use cases:
 - Main product repository
 - Marketing/documentation sites
 - Extracted services
 - Supporting tools
 PMO plugin adds:
 - Cross-project issue aggregation (all repos in organization)
 - Dependency tracking and visualization
 - Resource allocation across projects
 - Deployment coordination
 - Multi-project prioritization
 - Company-wide lessons learned search
 **Configuration Difference:**
 - PMO operates at company level (no `GITEA_REPO`)
 - Accesses all repositories in organization
 - Aggregates issues and lessons across projects
 Build PMO plugin AFTER projman is working and validated.
 ## Testing Approach
 **Local Marketplace:**
 Create local marketplace for plugin development:
 ```
 ~/projman-dev-marketplace/
 ├── .claude-plugin/
 │   └── marketplace.json
 └── projman/              # Symlink to plugin directory
 ```
 **Integration Testing:**
 Test in a real repository with actual Gitea instance before distribution.
 **Success Metrics:**
 - Sprint planning time reduced 40%
 - Manual steps eliminated: 10+ per sprint
 - Lessons learned capture rate: 100% (vs 0% before)
 - Label accuracy on issues: 90%+
 - User satisfaction: Better than current manual workflow
 ## Important Notes
 - **Never modify docker-compose files with 'version' attribute** - It's obsolete
 - **Focus on implementation, not over-engineering** - This system has been validated over 15 sprints
 - **Lessons learned is critical** - Prevents repeated mistakes (e.g., Claude infinite loops)
 - **Type/Refactor label** - Newly implemented at org level for architectural work
 - **Branch detection must be 100% reliable** - Prevents production accidents
 - **Python for MCP servers** - Use Python 3.8+ with virtual environments
 - **CLI tools forbidden** - Use MCP tools exclusively, never CLI tools like `tea` or `gh`
 ## CRITICAL: Rules You MUST Follow
-### DO NOT MODIFY .gitignore Without Explicit Permission
+### File Operations
- This is a **private repository** - credentials in `.env` files are intentional
+- **NEVER** create files in repository root unless listed in "Allowed Root Files"
- **NEVER** add `.env` or `.env.*` to .gitignore
+- **NEVER** modify `.gitignore` without explicit permission
- **NEVER** add venv patterns unless explicitly asked
+- **ALWAYS** use `.scratch/` for temporary/exploratory work
- If you think something should be ignored, ASK FIRST
+- **ALWAYS** verify paths against `docs/CANONICAL-PATHS.md` before creating files
-### Plugin Structure Requirements
+### Plugin Development
- **plugin.json MUST be in `.claude-plugin/` directory** - NOT in plugin root
+- **plugin.json MUST be in `.claude-plugin/` directory** (not plugin root)
- Every plugin in the repo MUST be listed in the marketplace.json
+- **Every plugin MUST be listed in marketplace.json**
- After creating/modifying a plugin, VERIFY it's in the marketplace
+- **MCP servers are SHARED at root** with symlinks from plugins
 - **MCP server venv path**: `${CLAUDE_PLUGIN_ROOT}/mcp-servers/{name}/.venv/bin/python`
 - **CLI tools forbidden** - Use MCP tools exclusively (never `tea`, `gh`, etc.)
-### Hooks Syntax (Claude Code Official)
+### Hooks (Valid Events Only)
- **Valid events**: `PreToolUse`, `PostToolUse`, `UserPromptSubmit`, `SessionStart`, `SessionEnd`, `Notification`, `Stop`, `SubagentStop`, `PreCompact`
+`PreToolUse`, `PostToolUse`, `UserPromptSubmit`, `SessionStart`, `SessionEnd`, `Notification`, `Stop`, `SubagentStop`, `PreCompact`
- **INVALID events**: `task-completed`, `file-changed`, `git-commit-msg-needed` (these DO NOT exist)
+
- Hooks schema:
+**INVALID:** `task-completed`, `file-changed`, `git-commit-msg-needed`
-```json
+
-{
+### Allowed Root Files
-  "hooks": {
+`CLAUDE.md`, `README.md`, `LICENSE`, `CHANGELOG.md`, `.gitignore`, `.env.example`
-    "EventName": [
+
-      {
+### Allowed Root Directories
-        "matcher": "optional-pattern",
+`.claude/`, `.claude-plugin/`, `.claude-plugins/`, `.scratch/`, `docs/`, `hooks/`, `mcp-servers/`, `plugins/`, `scripts/`
-        "hooks": [
+
-          {
+## Architecture
-            "type": "command",
+
-            "command": "${CLAUDE_PLUGIN_ROOT}/path/to/script.sh"
+### Four-Agent Model (projman)
-          }
+
-        ]
+| Agent | Personality | Responsibilities |
-      }
+|-------|-------------|------------------|
-    ]
+| **Planner** | Thoughtful, methodical | Sprint planning, architecture analysis, issue creation, lesson search |
-  }
+| **Orchestrator** | Concise, action-oriented | Sprint execution, parallel batching, Git operations, lesson capture |
-}
+| **Executor** | Implementation-focused | Code implementation, branch management, MR creation |
 | **Code Reviewer** | Thorough, practical | Pre-close quality review, security scan, test verification |
 ### MCP Server Tools (Gitea)
 | Category | Tools |
 |----------|-------|
 | Issues | `list_issues`, `get_issue`, `create_issue`, `update_issue`, `add_comment` |
 | Labels | `get_labels`, `suggest_labels`, `create_label` |
 | Milestones | `list_milestones`, `get_milestone`, `create_milestone`, `update_milestone` |
 | Dependencies | `list_issue_dependencies`, `create_issue_dependency`, `get_execution_order` |
 | Wiki | `list_wiki_pages`, `get_wiki_page`, `create_wiki_page`, `create_lesson`, `search_lessons` |
 | **Pull Requests** | `list_pull_requests`, `get_pull_request`, `get_pr_diff`, `get_pr_comments`, `create_pr_review`, `add_pr_comment` *(NEW v3.0.0)* |
 | Validation | `validate_repo_org`, `get_branch_protection` |
 ### Hybrid Configuration
 | Level | Location | Purpose |
 |-------|----------|---------|
 | System | `~/.config/claude/gitea.env` | Credentials (GITEA_API_URL, GITEA_API_TOKEN) |
 | Project | `.env` in project root | Repository specification (GITEA_ORG, GITEA_REPO) |
 **Note:** `GITEA_ORG` is at project level since different projects may belong to different organizations.
 ### Branch-Aware Security
 | Branch Pattern | Mode | Capabilities |
 |----------------|------|--------------|
 | `development`, `feat/*` | Development | Full access |
 | `staging` | Staging | Read-only code, can create issues |
 | `main`, `master` | Production | Read-only, emergency only |
 ## Label Taxonomy
 43 labels total: 27 organization + 16 repository
 **Organization:** Agent/2, Complexity/3, Efforts/5, Priority/4, Risk/3, Source/4, Type/6
 **Repository:** Component/9, Tech/7
 Sync with `/labels-sync` command.
 ## Lessons Learned System
 Stored in Gitea Wiki under `lessons-learned/sprints/`.
 **Workflow:**
 1. Orchestrator captures at sprint close via MCP tools
 2. Planner searches at sprint start using `search_lessons`
 3. Tags enable cross-project discovery
 ## Common Operations
 ### Adding a New Plugin
 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`
 4. If using MCP server, create symlink: `ln -s ../../../mcp-servers/{server} plugins/{name}/mcp-servers/{server}`
 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`
 3. Update marketplace description if significant
 ### Validation
 ```bash
 ./scripts/validate-marketplace.sh  # Validates all manifests
 ```
-### MCP Server Configuration
+## Path Verification Protocol
 - MCP servers MUST use venv python: `${CLAUDE_PLUGIN_ROOT}/../../mcp-servers/NAME/.venv/bin/python`
 - NEVER use bare `python` command - always use venv path
 - Test MCP servers after any config change
-### Before Completing Any Plugin Work
+**Before creating any file:**
-1. Verify plugin.json is in `.claude-plugin/` directory
+
-2. Verify plugin is listed in marketplace.json
+1. Read `docs/CANONICAL-PATHS.md`
-3. Test MCP server configs load correctly
+2. List all paths to be created/modified
-4. Verify hooks use valid event types
+3. Verify each against canonical paths
-5. Check .gitignore wasn't modified inappropriately
+4. If not in canonical paths, STOP and ask
 ## Documentation Index
-This repository contains comprehensive planning documentation:
+| Document | Purpose |
 |----------|---------|
 | `docs/CANONICAL-PATHS.md` | **Single source of truth** for paths |
 | `docs/COMMANDS-CHEATSHEET.md` | All commands quick reference |
 | `docs/CONFIGURATION.md` | Centralized setup guide |
 | `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 |
- **`docs/CANONICAL-PATHS.md`** - ⚠️ SINGLE SOURCE OF TRUTH for all paths (MANDATORY reading before any file operations)
+## Installation Paths
 - **`docs/DOCUMENT-INDEX.md`** - Complete guide to all planning documents
 - **`docs/projman-implementation-plan-updated.md`** - Full 12-phase implementation plan
 - **`docs/projman-python-quickstart.md`** - Python-specific implementation guide
 - **`docs/two-mcp-architecture-guide.md`** - Deep dive into two-MCP architecture
-**Start with:** `docs/DOCUMENT-INDEX.md` for navigation guidance
+Understanding where files live is critical for debugging:
-## Recent Updates (Updated: 2025-06-11)
+| Context | Path | Purpose |
 |---------|------|---------|
 | **Source** | `~/claude-plugins-work/` | Development - edit here |
 | **Installed** | `~/.claude/plugins/marketplaces/leo-claude-mktplace/` | Runtime - Claude uses this |
 | **Cache** | `~/.claude/` | Plugin metadata and settings |
-### Planning Phase Complete
+**Key insight:** Edits to source require reinstall/update to take effect at runtime.
 - Comprehensive 12-phase implementation plan finalized
 - Architecture decisions documented and validated
 - Two-MCP-server approach confirmed (Gitea + Wiki.js)
 - Python selected for MCP server implementation
 - Hybrid configuration strategy defined (system + project level)
 - Wiki.js structure planned with configurable base path
 - Repository structure designed with shared MCP servers
-### Key Architectural Decisions Made
+## Debugging & Troubleshooting
 1. **Shared MCP Servers**: Both plugins use the same MCP codebase at `mcp-servers/`
 2. **Mode Detection**: MCP servers detect project vs company-wide mode via environment variables
 3. **Python Implementation**: MCP servers written in Python (not Node.js) for better configuration handling
 4. **Wiki.js Integration**: Lessons learned and documentation moved to Wiki.js for better collaboration
 5. **Hybrid Config**: System-level credentials + project-level paths for flexibility
-### Next Steps
+See `docs/DEBUGGING-CHECKLIST.md` for systematic troubleshooting.
- Begin Phase 1.1a: Gitea MCP Server implementation
+
- Set up Python virtual environments
+**Common Issues:**
- Create configuration loaders
+| Symptom | Likely Cause | Fix |
- Implement core Gitea tools (issues, labels)
+|---------|--------------|-----|
- Write integration tests
+| "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 |
 | 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-review` - Investigate and propose fixes
 ## Versioning Rules
 - Version displayed ONLY in main `README.md` title: `# Leo Claude Marketplace - vX.Y.Z`
 - `CHANGELOG.md` is authoritative for version history
 - Follow [SemVer](https://semver.org/): MAJOR.MINOR.PATCH
 - On release: Update README title → CHANGELOG → marketplace.json → plugin.json files
 ---
 **Last Updated:** 2026-01-22
--- a/21
+++ b/21
@@ -0,0 +1,21 @@
 MIT License
 Copyright (c) 2025 Leo Miranda
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
--- a/README.md
+++ b/README.md
@@ -1,62 +1,106 @@
-# Claude Code Marketplace - Bandit Labs
+# Leo Claude Marketplace - v3.1.1
 A collection of Claude Code plugins for project management, infrastructure automation, and development workflows.
 ## Plugins
-### [projman](./plugins/projman/README.md) v2.0.0
+### Development & Project Management
 #### [projman](./plugins/projman/README.md)
 **Sprint Planning and Project Management**
 AI-guided sprint planning with full Gitea integration. Transforms a proven 15-sprint workflow into a distributable plugin.
- Three-agent model: Planner, Orchestrator, Executor
+- Four-agent model: Planner, Orchestrator, Executor, Code Reviewer
 - Intelligent label suggestions from 43-label taxonomy
 - Lessons learned capture via Gitea Wiki
 - Native issue dependencies with parallel execution
 - Milestone management for sprint organization
 - Branch-aware security (development/staging/production)
 - Pre-sprint-close code quality review and test verification
-**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/initial-setup`
+**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/initial-setup`, `/project-init`, `/project-sync`, `/review`, `/test-check`, `/test-gen`
-### [claude-config-maintainer](./plugins/claude-config-maintainer/README.md)
+#### [git-flow](./plugins/git-flow/README.md) *NEW in v3.0.0*
 **Git Workflow Automation**
 Smart git operations with intelligent commit messages and branch management.
 - Auto-generated conventional commit messages
 - Multiple workflow styles (simple, feature-branch, pr-required, trunk-based)
 - Branch naming enforcement
 - Merge and cleanup automation
 - Protected branch awareness
 **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*
 **Multi-Agent PR Review**
 Comprehensive pull request review using specialized agents.
 - Multi-agent review: Security, Performance, Maintainability, Tests
 - Confidence scoring (only reports HIGH/MEDIUM confidence findings)
 - Actionable feedback with suggested fixes
 - Gitea integration for automated review submission
 **Commands:** `/pr-review`, `/pr-summary`, `/pr-findings`, `/initial-setup`, `/project-init`, `/project-sync`
 #### [claude-config-maintainer](./plugins/claude-config-maintainer/README.md)
 **CLAUDE.md Optimization and Maintenance**
 Analyze, optimize, and create CLAUDE.md configuration files for Claude Code projects.
 - Structure and clarity scoring (100-point system)
 - Automatic optimization with preview and backup
 - Project-aware initialization with stack detection
 - Best practices enforcement
 **Commands:** `/config-analyze`, `/config-optimize`, `/config-init`
-### [cmdb-assistant](./plugins/cmdb-assistant/README.md)
+### Productivity
 **NetBox CMDB Integration**
-Full CRUD operations for network infrastructure management directly from Claude Code.
+#### [clarity-assist](./plugins/clarity-assist/README.md) *NEW in v3.0.0*
 **Prompt Optimization with ND Accommodations**
- Device, IP, site, and rack management
+Transform vague requests into clear specifications using structured methodology.
 - Smart search across all NetBox modules
 - Conversational infrastructure queries
 - Audit trail and change tracking
-**Commands:** `/cmdb-search`, `/cmdb-device`, `/cmdb-ip`, `/cmdb-site`
+- 4-D methodology: Deconstruct, Diagnose, Develop, Deliver
 - ND-friendly question patterns (option-based, chunked)
 - Conflict detection and escalation protocols
-### [project-hygiene](./plugins/project-hygiene/README.md)
+**Commands:** `/clarify`, `/quick-clarify`
 #### [doc-guardian](./plugins/doc-guardian/README.md)
 **Documentation Lifecycle Management**
 Automatic documentation drift detection and synchronization.
 **Commands:** `/doc-audit`, `/doc-sync`
 #### [project-hygiene](./plugins/project-hygiene/README.md)
 **Post-Task Cleanup Automation**
 Hook-based cleanup that runs after Claude completes work.
- Deletes temp files (`*.tmp`, `*.bak`, `__pycache__`, etc.)
+### Security
- Warns about unexpected files in project root
+
- Identifies orphaned supporting files
+#### [code-sentinel](./plugins/code-sentinel/README.md)
- Configurable via `.hygiene.json`
+**Security Scanning & Refactoring**
 Security vulnerability detection and code refactoring tools.
 **Commands:** `/security-scan`, `/refactor`, `/refactor-dry`
 ### Infrastructure
 #### [cmdb-assistant](./plugins/cmdb-assistant/README.md)
 **NetBox CMDB Integration**
 Full CRUD operations for network infrastructure management directly from Claude Code.
 **Commands:** `/initial-setup`, `/cmdb-search`, `/cmdb-device`, `/cmdb-ip`, `/cmdb-site`
 ## MCP Servers
-MCP servers are **bundled inside each plugin** that needs them. This ensures plugins work when cached by Claude Code.
+MCP servers are **shared at repository root** with **symlinks** from plugins that use them.
-### Gitea MCP Server (bundled in projman)
+### Gitea MCP Server (shared)
 Full Gitea API integration for project management.
@@ -67,9 +111,10 @@ Full Gitea API integration for project management.
 | Wiki | `list_wiki_pages`, `get_wiki_page`, `create_wiki_page`, `create_lesson`, `search_lessons` |
 | Milestones | `list_milestones`, `get_milestone`, `create_milestone`, `update_milestone` |
 | Dependencies | `list_issue_dependencies`, `create_issue_dependency`, `get_execution_order` |
 | **Pull Requests** | `list_pull_requests`, `get_pull_request`, `get_pr_diff`, `get_pr_comments`, `create_pr_review`, `add_pr_comment` *(NEW in v3.0.0)* |
 | Validation | `validate_repo_org`, `get_branch_protection` |
-### NetBox MCP Server (bundled in cmdb-assistant)
+### NetBox MCP Server (shared)
 Comprehensive NetBox REST API integration for infrastructure management.
@@ -89,132 +134,136 @@ Comprehensive NetBox REST API integration for infrastructure management.
 - Python 3.10+
 - Access to target services (Gitea, NetBox as needed)
-### Quick Start
+### Add Marketplace to Claude Code
-1. **Clone the repository:**
+**Option 1 - CLI command (recommended):**
 ```bash
-   git clone ssh://git@hotserv.tailc9b278.ts.net:2222/bandit/support-claude-mktplace.git
+/plugin marketplace add https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git
   cd support-claude-mktplace
 ```
-2. **Install MCP server dependencies:**
+**Option 2 - Settings file (for team distribution):**
   ```bash
   # Gitea MCP (for projman)
   cd plugins/projman/mcp-servers/gitea
   python3 -m venv .venv
   source .venv/bin/activate
   pip install -r requirements.txt
   deactivate
-   # NetBox MCP (for cmdb-assistant)
+Add to `.claude/settings.json` in your target project:
   cd ../../../cmdb-assistant/mcp-servers/netbox
   python3 -m venv .venv
   source .venv/bin/activate
   pip install -r requirements.txt
   deactivate
   ```
 3. **Configure system-level credentials:**
   ```bash
   mkdir -p ~/.config/claude
   # Gitea credentials
   cat > ~/.config/claude/gitea.env << 'EOF'
   GITEA_URL=https://gitea.example.com
   GITEA_TOKEN=your_token
   GITEA_ORG=your_org
   EOF
   # NetBox credentials
   cat > ~/.config/claude/netbox.env << 'EOF'
   NETBOX_API_URL=https://netbox.example.com/api
   NETBOX_API_TOKEN=your_token
   EOF
   chmod 600 ~/.config/claude/*.env
   ```
 4. **Configure project-level settings:**
   ```bash
   # In your target project root
   cat > .env << 'EOF'
   GITEA_REPO=your-repository-name
   EOF
   ```
 5. **Add marketplace to Claude Code:**
   Add to your project's `.claude/settings.json`:
 ```json
 {
-     "pluginMarketplace": "/path/to/support-claude-mktplace"
+  "extraKnownMarketplaces": {
    "leo-claude-mktplace": {
      "source": {
        "source": "git",
        "url": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git"
      }
    }
  }
 }
 ```
 ### Run Interactive Setup
 After installing plugins, run the setup wizard:
 ```
 /initial-setup
 ```
 The wizard handles everything:
 - Sets up MCP server (Python venv + dependencies)
 - Creates system config (`~/.config/claude/gitea.env`)
 - Guides you through adding your API token
 - Detects and validates your repository via API
 - Creates 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 manual setup and advanced options.
 ## Verifying Plugin Installation
 After installing plugins, the `/plugin` command may show `(no content)` - this is normal Claude Code behavior and doesn't indicate an error.
 **To verify a plugin is installed correctly:**
 1. **Check installed plugins list:**
   ```
   /plugin list
   ```
   Look for `✔ plugin-name · Installed`
 2. **Test a plugin command directly:**
   ```
   /git-flow:git-status
   /projman:sprint-status
   /clarity-assist:clarify
   ```
   If the command executes and shows output, the plugin is working.
 3. **Check for loading errors:**
   ```
   /plugin list
   ```
   Look for any `Plugin Loading Errors` section - this indicates manifest issues.
 **Command format:** All plugin commands use the format `/plugin-name:command-name`
 | Plugin | Test Command |
 |--------|--------------|
 | git-flow | `/git-flow:git-status` |
 | projman | `/projman:sprint-status` |
 | pr-review | `/pr-review:pr-summary` |
 | clarity-assist | `/clarity-assist:clarify` |
 | doc-guardian | `/doc-guardian:doc-audit` |
 | code-sentinel | `/code-sentinel:security-scan` |
 | claude-config-maintainer | `/claude-config-maintainer:config-analyze` |
 | cmdb-assistant | `/cmdb-assistant:cmdb-search` |
 ## Repository Structure
 ```
-support-claude-mktplace/
+leo-claude-mktplace/
 ├── .claude-plugin/                # Marketplace manifest
 │   └── marketplace.json
-├── plugins/                       # All plugins (with bundled MCP servers)
+├── mcp-servers/                   # SHARED MCP servers (v3.0.0+)
-│   ├── projman/                   # Sprint management plugin
+│   ├── gitea/                     # Gitea MCP (issues, PRs, wiki)
-│   │   ├── .claude-plugin/
+│   └── netbox/                    # NetBox MCP (CMDB)
-│   │   ├── .mcp.json
+├── plugins/                       # All plugins
-│   │   ├── mcp-servers/           # Bundled MCP server
+│   ├── projman/                   # Sprint management
-│   │   │   └── gitea/
+│   ├── git-flow/                  # Git workflow automation (NEW)
-│   │   ├── commands/
+│   ├── pr-review/                 # PR review (NEW)
-│   │   ├── agents/
+│   ├── clarity-assist/            # Prompt optimization (NEW)
-│   │   └── skills/
+│   ├── claude-config-maintainer/  # CLAUDE.md optimization
 │   ├── claude-config-maintainer/  # CLAUDE.md optimization plugin
 │   │   ├── .claude-plugin/
 │   │   ├── commands/
 │   │   └── agents/
 │   ├── cmdb-assistant/            # NetBox CMDB integration
-│   │   ├── .claude-plugin/
+│   ├── doc-guardian/              # Documentation drift detection
-│   │   ├── .mcp.json
+│   ├── code-sentinel/             # Security scanning
-│   │   ├── mcp-servers/           # Bundled MCP server
+│   └── project-hygiene/           # Cleanup automation
-│   │   │   └── netbox/
+├── docs/                          # Documentation
-│   │   ├── commands/
+│   ├── CANONICAL-PATHS.md         # Path reference
-│   │   └── agents/
+│   └── CONFIGURATION.md           # Setup guide
-│   ├── projman-pmo/               # PMO coordination plugin (planned)
+└── scripts/                       # Setup scripts
 │   └── project-hygiene/           # Cleanup automation plugin
 ├── docs/                          # Reference documentation
 │   ├── CANONICAL-PATHS.md         # Single source of truth for paths
 │   └── references/
 └── scripts/                       # Setup and maintenance scripts
 ```
 ## Key Features (v2.0.0)
 ### Parallel Execution
 Tasks are batched by dependency graph for optimal 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)
 ```
 ### Naming Conventions
 - **Tasks:** `[Sprint XX] <type>: <description>`
 - **Branches:** `feat/`, `fix/`, `debug/` prefixes with issue numbers
 ### CLI Tools Blocked
 All agents use MCP tools exclusively. CLI tools like `tea` or `gh` are forbidden to ensure consistent, auditable operations.
 ## Documentation
 | Document | Description |
 |----------|-------------|
 | [CLAUDE.md](./CLAUDE.md) | Main project instructions |
 | [CONFIGURATION.md](./docs/CONFIGURATION.md) | Centralized setup guide |
 | [COMMANDS-CHEATSHEET.md](./docs/COMMANDS-CHEATSHEET.md) | All commands quick reference |
 | [UPDATING.md](./docs/UPDATING.md) | Update guide for the marketplace |
 | [CANONICAL-PATHS.md](./docs/CANONICAL-PATHS.md) | Authoritative path reference |
-| [projman/CONFIGURATION.md](./plugins/projman/CONFIGURATION.md) | Projman setup guide |
+| [CHANGELOG.md](./CHANGELOG.md) | Version history |
 ## License
-MIT License - Bandit Labs
+MIT License
 ## Support
 - **Issues**: Contact repository maintainer
- **Repository**: `ssh://git@hotserv.tailc9b278.ts.net:2222/bandit/support-claude-mktplace.git`
+- **Repository**: `https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git`
--- a/docs/CANONICAL-PATHS.md
+++ b/docs/CANONICAL-PATHS.md
@@ -2,44 +2,112 @@
 **This file defines ALL valid paths in this repository. No exceptions. No inference. No assumptions.**
-Last Updated: 2025-12-15
+Last Updated: 2026-01-20 (v3.0.0)
 ---
 ## Repository Root Structure
 ```
-support-claude-mktplace/
+leo-claude-mktplace/
 ├── .claude/                    # Claude Code local settings
-├── .claude-plugin/             # Marketplace manifest (bandit-claude-marketplace)
+├── .claude-plugin/             # Marketplace manifest
 │   └── marketplace.json
 ├── .scratch/                   # Transient work (auto-cleaned)
 ├── docs/                       # All documentation
 │   ├── architecture/           # Draw.io diagrams and specs
-│   ├── references/             # Reference specifications
+│   ├── CANONICAL-PATHS.md      # This file - single source of truth
 │   ├── CONFIGURATION.md        # Centralized configuration guide
 │   ├── DEBUGGING-CHECKLIST.md  # Systematic troubleshooting guide
 │   ├── UPDATING.md             # Update guide
 │   └── workflows/              # Workflow documentation
 ├── hooks/                      # Shared hooks (if any)
-├── plugins/                    # ALL plugins with bundled MCP servers
+├── mcp-servers/                # SHARED MCP servers (v3.0.0+)
-│   ├── projman/
+│   ├── gitea/                  # Gitea MCP server
 │   │   ├── mcp_server/
 │   │   │   ├── server.py
 │   │   │   ├── gitea_client.py
 │   │   │   ├── config.py
 │   │   │   └── tools/
 │   │   │       ├── issues.py
 │   │   │       ├── labels.py
 │   │   │       ├── wiki.py
 │   │   │       ├── milestones.py
 │   │   │       ├── dependencies.py
 │   │   │       └── pull_requests.py  # NEW in v3.0.0
 │   │   ├── requirements.txt
 │   │   └── .venv/
 │   └── netbox/                 # NetBox MCP server
 │       ├── mcp_server/
 │       ├── requirements.txt
 │       └── .venv/
 ├── plugins/                    # ALL plugins
 │   ├── projman/                # Sprint management
 │   │   ├── .claude-plugin/
-│   │   ├── mcp-servers/        # MCP servers bundled IN plugin
+│   │   ├── .mcp.json
-│   │   │   └── gitea/          # Gitea + Wiki tools
+│   │   ├── mcp-servers/
 │   │   │   └── gitea -> ../../../mcp-servers/gitea  # SYMLINK
 │   │   ├── commands/
 │   │   ├── agents/
-│   │   └── skills/
+│   │   ├── skills/
-│   ├── projman-pmo/
+│   │   └── claude-md-integration.md
-│   ├── project-hygiene/
+│   ├── doc-guardian/           # Documentation drift detection
 │   ├── cmdb-assistant/
 │   │   ├── .claude-plugin/
-│   │   ├── mcp-servers/        # MCP servers bundled IN plugin
+│   │   ├── hooks/
 │   │   │   └── netbox/
 │   │   ├── commands/
-│   │   └── agents/
+│   │   ├── agents/
-│   └── claude-config-maintainer/
+│   │   ├── skills/
 │   │   └── claude-md-integration.md
 │   ├── code-sentinel/          # Security scanning & refactoring
 │   │   ├── .claude-plugin/
 │   │   ├── hooks/
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
 │   │   └── 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
 │   ├── claude-config-maintainer/
 │   │   ├── .claude-plugin/
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   └── claude-md-integration.md
 │   ├── project-hygiene/
 │   │   ├── .claude-plugin/
 │   │   ├── hooks/
 │   │   └── claude-md-integration.md
 │   ├── clarity-assist/         # NEW in v3.0.0
 │   │   ├── .claude-plugin/
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
 │   │   └── claude-md-integration.md
 │   ├── git-flow/               # NEW in v3.0.0
 │   │   ├── .claude-plugin/
 │   │   ├── commands/
 │   │   ├── agents/
 │   │   ├── skills/
 │   │   └── claude-md-integration.md
 │   └── pr-review/              # NEW in v3.0.0
 │       ├── .claude-plugin/
 │       ├── .mcp.json
 │       ├── mcp-servers/
 │       │   └── gitea -> ../../../mcp-servers/gitea  # SYMLINK
 │       ├── commands/
-│       └── agents/
+│       ├── agents/
 │       ├── skills/
 │       └── claude-md-integration.md
 ├── scripts/                    # Setup and maintenance scripts
 │   ├── setup.sh                # Initial setup (create venvs, config templates)
 │   ├── post-update.sh          # Post-update (rebuild venvs, verify symlinks)
 │   ├── check-venv.sh           # Check if venvs exist (for hooks)
 │   └── validate-marketplace.sh # Marketplace compliance validation
 ├── CLAUDE.md
 ├── README.md
 ├── LICENSE
@@ -60,32 +128,40 @@ support-claude-mktplace/
 | 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 integration snippet | `plugins/{plugin-name}/claude-md-integration.md` | `plugins/projman/claude-md-integration.md` |
-### MCP Server Paths (Bundled in Plugins)
+### MCP Server Paths (v3.0.0 Architecture)
-MCP servers are now **bundled inside each plugin** to ensure they work when plugins are cached.
+MCP servers are **shared at repository root** with **symlinks** from plugins.
 | Context | Pattern | Example |
 |---------|---------|---------|
-| MCP server location | `plugins/{plugin}/mcp-servers/{server}/` | `plugins/projman/mcp-servers/gitea/` |
+| Shared MCP server | `mcp-servers/{server}/` | `mcp-servers/gitea/` |
-| MCP server code | `plugins/{plugin}/mcp-servers/{server}/mcp_server/` | `plugins/projman/mcp-servers/gitea/mcp_server/` |
+| MCP server code | `mcp-servers/{server}/mcp_server/` | `mcp-servers/gitea/mcp_server/` |
-| MCP venv | `plugins/{plugin}/mcp-servers/{server}/.venv/` | `plugins/projman/mcp-servers/gitea/.venv/` |
+| MCP venv | `mcp-servers/{server}/.venv/` | `mcp-servers/gitea/.venv/` |
 | Plugin symlink | `plugins/{plugin}/mcp-servers/{server}` | `plugins/projman/mcp-servers/gitea` |
-### Relative Path Patterns (CRITICAL)
+### Symlink Pattern
-| From | To | Pattern |
+Plugins that use MCP servers create symlinks:
-|------|----|---------|
+```bash
-| Plugin .mcp.json | Bundled MCP server | `${CLAUDE_PLUGIN_ROOT}/mcp-servers/{server}` |
+# From plugin directory
-| marketplace.json | Plugin | `./plugins/{plugin-name}` |
+ln -s ../../../mcp-servers/gitea plugins/projman/mcp-servers/gitea
 ```
 The symlink target is relative: `../../../mcp-servers/{server}`
 ### Documentation Paths
 | Type | Location |
 |------|----------|
 | Reference specs | `docs/references/` |
 | Architecture diagrams | `docs/architecture/` |
 | Workflow docs | `docs/workflows/` |
 | This file | `docs/CANONICAL-PATHS.md` |
 | Update guide | `docs/UPDATING.md` |
 | Configuration guide | `docs/CONFIGURATION.md` |
 | Commands cheat sheet | `docs/COMMANDS-CHEATSHEET.md` |
 | Debugging checklist | `docs/DEBUGGING-CHECKLIST.md` |
 ---
@@ -103,15 +179,15 @@ MCP servers are now **bundled inside each plugin** to ensure they work when plug
 2. Verify each path against patterns in this file
 3. Show verification to user before proceeding
-### Relative Path Calculation
+### Relative Path Calculation (v3.0.0)
-From `plugins/projman/.mcp.json` to bundled `mcp-servers/gitea/`:
+From `plugins/projman/.mcp.json` to shared `mcp-servers/gitea/`:
 ```
 plugins/projman/.mcp.json
-  → MCP servers are IN the plugin at mcp-servers/
+  → Uses ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/
  → Symlink at plugins/projman/mcp-servers/gitea points to ../../../mcp-servers/gitea
-Result: mcp-servers/gitea/
+Result in .mcp.json: ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/.venv/bin/python
 With variable: ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/
 ```
 From `.claude-plugin/marketplace.json` to `plugins/projman/`:
@@ -130,18 +206,28 @@ Result: ./plugins/projman
 | Wrong | Why | Correct |
 |-------|-----|---------|
 | `projman/` at root | Plugins go in `plugins/` | `plugins/projman/` |
-| `mcp-servers/` at root | MCP servers are bundled in plugins | `plugins/{plugin}/mcp-servers/` |
+| Direct path in .mcp.json to root mcp-servers | Use symlink | Symlink at `plugins/{plugin}/mcp-servers/` |
-| `../../mcp-servers/` from plugin | Old pattern, doesn't work with caching | `${CLAUDE_PLUGIN_ROOT}/mcp-servers/` |
+| Creating new mcp-servers inside plugins | Use shared + symlink | Symlink to `mcp-servers/` |
-| `./../../../plugins/projman` in marketplace | Wrong (old nested structure) | `./plugins/projman` |
+| Hardcoding absolute paths | Breaks portability | Use `${CLAUDE_PLUGIN_ROOT}` |
 ---
-## Architecture Note
+## Architecture Note (v3.0.0)
-MCP servers are bundled inside each plugin (not shared at root) because:
+MCP servers are now **shared at repository root** with **symlinks** from plugins:
- Claude Code caches only the plugin directory when installed
+
- Relative paths to parent directories break in the cache
+**Benefits:**
- Each plugin must be self-contained to work properly
+- Single source of truth for each MCP server
 - Updates apply to all plugins automatically
 - Reduced duplication
 - Symlinks work with Claude Code caching
 **Symlink Pattern:**
 ```
 plugins/projman/mcp-servers/gitea -> ../../../mcp-servers/gitea
 plugins/cmdb-assistant/mcp-servers/netbox -> ../../../mcp-servers/netbox
 plugins/pr-review/mcp-servers/gitea -> ../../../mcp-servers/gitea
 ```
 ---
@@ -149,5 +235,11 @@ MCP servers are bundled inside each plugin (not shared at root) because:
 | Date | Change | By |
 |------|--------|-----|
-| 2025-12-15 | Restructured: MCP servers now bundled in plugins | Claude Code |
+| 2026-01-20 | v3.0.0: MCP servers moved to root with symlinks | Claude Code |
 | 2026-01-20 | v3.0.0: Added clarity-assist, git-flow, pr-review plugins | Claude Code |
 | 2026-01-20 | v3.0.0: Added docs/CONFIGURATION.md | Claude Code |
 | 2026-01-20 | v3.0.0: Renamed marketplace to leo-claude-mktplace | Claude Code |
 | 2026-01-20 | Removed docs/references/ (obsolete planning docs) | Claude Code |
 | 2026-01-19 | Added claude-md-integration.md path pattern | Claude Code |
 | 2025-12-15 | Restructured: MCP servers bundled in plugins | Claude Code |
 | 2025-12-12 | Initial creation | Claude Code |
--- a/docs/COMMANDS-CHEATSHEET.md
+++ b/docs/COMMANDS-CHEATSHEET.md
@@ -0,0 +1,217 @@
 # Plugin Commands Cheat Sheet
 Quick reference for all commands in the Leo Claude Marketplace.
 ---
 ## Command Reference Table
 | Plugin | Command | Auto | Manual | Description |
 |--------|---------|:----:|:------:|-------------|
 | **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** | `/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** | `/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** | `/project-init` | | X | Quick project setup (assumes system config exists) |
 | **projman** | `/project-sync` | | X | Sync config with git remote after repo move/rename |
 | **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 |
 | **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 |
 | **git-flow** | `/commit-sync` | | X | Full sync: commit, push, and sync with upstream/base branch |
 | **git-flow** | `/branch-start` | | X | Create new feature/fix/chore branch with naming conventions |
 | **git-flow** | `/branch-cleanup` | | X | Remove merged branches locally and optionally on remote |
 | **git-flow** | `/git-status` | | X | Enhanced git status with recommendations |
 | **git-flow** | `/git-config` | | X | Configure git-flow settings for the project |
 | **pr-review** | `/initial-setup` | | X | Setup wizard for pr-review (shares Gitea MCP with projman) |
 | **pr-review** | `/project-init` | | X | Quick project setup for PR reviews |
 | **pr-review** | `/project-sync` | | X | Sync config with git remote after repo move/rename |
 | **pr-review** | *SessionStart hook* | X | | Detects git remote vs .env mismatch |
 | **pr-review** | `/pr-review` | | X | Full multi-agent PR review with confidence scoring |
 | **pr-review** | `/pr-summary` | | X | Quick summary of PR changes |
 | **pr-review** | `/pr-findings` | | X | List and filter review findings by category/severity |
 | **clarity-assist** | `/clarify` | | X | Full 4-D prompt optimization with ND accommodations |
 | **clarity-assist** | `/quick-clarify` | | X | Rapid single-pass clarification for simple requests |
 | **doc-guardian** | `/doc-audit` | | X | Full documentation audit - scans for doc drift |
 | **doc-guardian** | `/doc-sync` | | X | Synchronize pending documentation updates |
 | **doc-guardian** | *PostToolUse hook* | X | | Silently detects doc drift on Write/Edit |
 | **code-sentinel** | `/security-scan` | | X | Full security audit (SQL injection, XSS, secrets, etc.) |
 | **code-sentinel** | `/refactor` | | X | Apply refactoring patterns to improve code |
 | **code-sentinel** | `/refactor-dry` | | X | Preview refactoring without applying changes |
 | **code-sentinel** | *PreToolUse hook* | X | | Scans code before writing; blocks critical issues |
 | **claude-config-maintainer** | `/config-analyze` | | X | Analyze CLAUDE.md for optimization opportunities |
 | **claude-config-maintainer** | `/config-optimize` | | X | Optimize CLAUDE.md structure with preview/backup |
 | **claude-config-maintainer** | `/config-init` | | X | Initialize new CLAUDE.md for a project |
 | **cmdb-assistant** | `/initial-setup` | | X | Setup wizard for NetBox MCP server |
 | **cmdb-assistant** | `/cmdb-search` | | X | Search NetBox for devices, IPs, sites |
 | **cmdb-assistant** | `/cmdb-device` | | X | Manage network devices (create, view, update, delete) |
 | **cmdb-assistant** | `/cmdb-ip` | | X | Manage IP addresses and prefixes |
 | **cmdb-assistant** | `/cmdb-site` | | X | Manage sites, locations, racks, and regions |
 | **project-hygiene** | *PostToolUse hook* | X | | Removes temp files, warns about unexpected root files |
 ---
 ## Plugins by Category
 | Category | Plugins | Primary Use |
 |----------|---------|-------------|
 | **Setup** | projman, pr-review, cmdb-assistant | `/initial-setup`, `/project-init` |
 | **Task Planning** | projman, clarity-assist | Sprint management, requirement clarification |
 | **Code Quality** | code-sentinel, pr-review | Security scanning, PR reviews |
 | **Documentation** | doc-guardian, claude-config-maintainer | Doc sync, CLAUDE.md maintenance |
 | **Git Operations** | git-flow | Commits, branches, workflow automation |
 | **Infrastructure** | cmdb-assistant | NetBox CMDB management |
 | **Maintenance** | project-hygiene | Automatic cleanup |
 ---
 ## Hook-Based Automation Summary
 | Plugin | Hook Event | Behavior |
 |--------|------------|----------|
 | **projman** | SessionStart | Checks git remote vs .env; warns if mismatch detected |
 | **pr-review** | SessionStart | Checks git remote vs .env; warns if mismatch detected |
 | **doc-guardian** | PostToolUse (Write/Edit) | Silently tracks documentation drift |
 | **code-sentinel** | PreToolUse (Write/Edit) | Scans for security issues; blocks critical vulnerabilities |
 | **project-hygiene** | PostToolUse (Write/Edit) | Cleans temp files, warns about misplaced files |
 ---
 ## Dev Workflow Examples
 ### Example 1: Starting a New Feature Sprint
 A typical workflow for planning and executing a feature sprint:
 ```
 1. /clarify                  # Clarify requirements if vague
 2. /sprint-plan              # Plan the sprint with architecture analysis
 3. /labels-sync              # Ensure labels are up-to-date
 4. /sprint-start             # Begin execution with dependency ordering
 5. /branch-start feat/...    # Create feature branch
   ... implement features ...
 6. /commit                   # Commit with conventional message
 7. /sprint-status            # Check progress mid-sprint
 8. /review                   # Pre-close quality review
 9. /test-check               # Verify test coverage
 10. /sprint-close            # Capture lessons learned
 ```
 ### Example 2: Daily Development Cycle
 Quick daily workflow with git-flow:
 ```
 1. /git-status               # Check current state
 2. /branch-start fix/...     # Start bugfix branch
   ... make changes ...
 3. /commit                   # Auto-generate commit message
 4. /commit-push              # Push to remote
 5. /branch-cleanup           # Clean merged branches
 ```
 ### Example 3: Pull Request Review Workflow
 Reviewing a PR before merge:
 ```
 1. /pr-summary               # Quick overview of changes
 2. /pr-review                # Full multi-agent review
 3. /pr-findings              # Filter findings by severity
 4. /security-scan            # Deep security audit if needed
 ```
 ### Example 4: Documentation Maintenance
 Keeping docs in sync:
 ```
 1. /doc-audit                # Scan for documentation drift
 2. /doc-sync                 # Apply pending updates
 3. /config-analyze           # Check CLAUDE.md health
 4. /config-optimize          # Optimize if needed
 ```
 ### Example 5: Code Refactoring Session
 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
 5. /commit                   # Commit with descriptive message
 ```
 ### Example 6: Infrastructure Documentation
 Managing infrastructure with CMDB:
 ```
 1. /cmdb-search "server"     # Find existing devices
 2. /cmdb-device view X       # Check device details
 3. /cmdb-ip list             # List available IPs
 4. /cmdb-site view Y         # Check site info
 ```
 ### Example 7: First-Time Setup (New Machine)
 Setting up the marketplace for the first time:
 ```
 1. /initial-setup            # Full setup: MCP + system config + project
   # → Follow prompts for Gitea URL, org
   # → Add token manually when prompted
   # → Confirm repository name
 2. # Restart Claude Code session
 3. /labels-sync              # Sync Gitea labels
 4. /sprint-plan              # Plan first sprint
 ```
 ### Example 8: New Project Setup (System Already Configured)
 Adding a new project when system config exists:
 ```
 1. /project-init             # Quick project setup
   # → Confirms detected repo name
   # → Creates .env
 2. /labels-sync              # Sync Gitea labels
 3. /sprint-plan              # Plan first sprint
 ```
 ---
 ## Quick Tips
 - **Hooks run automatically** - doc-guardian and code-sentinel protect you without manual invocation
 - **Use `/commit` over `git commit`** - generates better commit messages following conventions
 - **Run `/review` before `/sprint-close`** - catches issues before closing the sprint
 - **Use `/clarify` for vague requests** - especially helpful for complex requirements
 - **`/refactor-dry` is safe** - always preview before applying refactoring changes
 ---
 ## MCP Server Requirements
 Some plugins require MCP server connectivity:
 | Plugin | MCP Server | Purpose |
 |--------|------------|---------|
 | projman | Gitea | Issues, PRs, wiki, labels, milestones |
 | pr-review | Gitea | PR operations and reviews |
 | cmdb-assistant | NetBox | Infrastructure CMDB |
 Ensure credentials are configured in `~/.config/claude/gitea.env` or `~/.config/claude/netbox.env`.
 ---
 *Last Updated: 2026-01-22*
--- a/docs/CONFIGURATION.md
+++ b/docs/CONFIGURATION.md
@@ -0,0 +1,547 @@
 # Configuration Guide
 Centralized configuration documentation for all plugins and MCP servers in the Leo Claude Marketplace.
 ---
 ## Quick Start
 **After installing the marketplace and plugins via Claude Code:**
 ```
 /initial-setup
 ```
 The interactive wizard handles everything except manually adding your API tokens.
 ---
 ## Setup Flow Diagram
 ```
 ┌─────────────────────────────────────────────────────────────────────────────┐
 │                           FIRST TIME SETUP                                  │
 │                         (once per machine)                                  │
 └─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
                            /initial-setup
                                    │
     ┌──────────────────────────────┼──────────────────────────────┐
     ▼                              ▼                              ▼
 ┌─────────────┐            ┌─────────────────┐            ┌─────────────────┐
 │  PHASE 1    │            │    PHASE 2      │            │    PHASE 3      │
 │  Automated  │───────────▶│    Automated    │───────────▶│   Interactive   │
 │             │            │                 │            │                 │
 │ • Check     │            │ • Find MCP path │            │ • Ask Gitea URL │
 │   Python    │            │ • Create venv   │            │ • Ask Org name  │
 │   version   │            │ • Install deps  │            │ • Create config │
 └─────────────┘            └─────────────────┘            └─────────────────┘
                                                                   │
                                                                   ▼
                                                   ┌───────────────────────────┐
                                                   │        PHASE 4            │
                                                   │     USER ACTION           │
                                                   │                           │
                                                   │  Edit config file to add  │
                                                   │  API token (for security) │
                                                   │                           │
                                                   │  nano ~/.config/claude/   │
                                                   │       gitea.env           │
                                                   └───────────────────────────┘
                                                                   │
                                                                   ▼
     ┌──────────────────────────────┬──────────────────────────────┐
     ▼                              ▼                              ▼
 ┌─────────────┐            ┌─────────────────┐            ┌─────────────────┐
 │  PHASE 5    │            │    PHASE 6      │            │    PHASE 7      │
 │ Interactive │            │    Automated    │            │    Automated    │
 │             │            │                 │            │                 │
 │ • Confirm   │            │ • Create .env   │            │ • Test API      │
 │   repo name │            │ • Check         │            │ • Show summary  │
 │   from git  │            │   .gitignore    │            │ • Restart note  │
 └─────────────┘            └─────────────────┘            └─────────────────┘
                                                                   │
                                                                   ▼
                                                   ┌───────────────────────────┐
                                                   │      RESTART SESSION      │
                                                   │                           │
                                                   │  MCP tools available      │
                                                   │  after restart            │
                                                   └───────────────────────────┘
 ┌─────────────────────────────────────────────────────────────────────────────┐
 │                          NEW PROJECT SETUP                                  │
 │                        (once per project)                                   │
 └─────────────────────────────────────────────────────────────────────────────┘
                                    │
                    ┌───────────────┴───────────────┐
                    ▼                               ▼
             /project-init                   /initial-setup
             (direct path)                   (smart detection)
                    │                               │
                    │                    ┌──────────┴──────────┐
                    │                    ▼                     ▼
                    │              "Quick setup"         "Full setup"
                    │               (skips to              (re-runs
                    │              project config)          everything)
                    │                    │                     │
                    └────────────────────┴─────────────────────┘
                                         │
                                         ▼
                              ┌─────────────────────┐
                              │   PROJECT CONFIG    │
                              │                     │
                              │ • Detect repo from  │
                              │   git remote        │
                              │ • Confirm with user │
                              │ • Create .env       │
                              │ • Check .gitignore  │
                              └─────────────────────┘
                                         │
                                         ▼
                                      Done!
 ```
 ---
 ## What Runs Automatically vs User Interaction
 ### `/initial-setup` - Full Setup
 | Phase | Type | What Happens |
 |-------|------|--------------|
 | **1. Environment Check** | Automated | Verifies Python 3.10+ is installed |
 | **2. MCP Server Setup** | Automated | Finds plugin path, creates venv, installs dependencies |
 | **3. System Config Creation** | Interactive | Asks for Gitea URL and organization name |
 | **4. Token Entry** | **User Action** | User manually edits config file to add API token |
 | **5. Project Detection** | Interactive | Shows detected repo name, asks for confirmation |
 | **6. Project Config** | Automated | Creates `.env` file, checks `.gitignore` |
 | **7. Validation** | Automated | Tests API connectivity, shows summary |
 ### `/project-init` - Quick Project Setup
 | Phase | Type | What Happens |
 |-------|------|--------------|
 | **1. Pre-flight Check** | Automated | Verifies system config exists |
 | **2. Project Detection** | Interactive | Shows detected repo name, asks for confirmation |
 | **3. Project Config** | Automated | Creates/updates `.env` file |
 | **4. Gitignore Check** | Interactive | Asks to add `.env` to `.gitignore` if missing |
 ---
 ## Three Commands for Different Scenarios
 | Command | When to Use | What It Does |
 |---------|-------------|--------------|
 | `/initial-setup` | First time on a machine | Full setup: MCP server + system config + project config |
 | `/project-init` | Starting a new project | Quick setup: project config only (assumes system is ready) |
 | `/project-sync` | After repo move/rename | Updates .env to match current git remote |
 **Typical workflow:**
 1. Install plugin → run `/initial-setup` (once per machine)
 2. Start new project → run `/project-init` (once per project)
 3. Repository moved? → run `/project-sync` (updates config)
 **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
 ---
 ## Configuration Architecture
 This marketplace uses a **hybrid configuration** approach:
 ```
 ┌─────────────────────────────────────────────────────────────────┐
 │                    SYSTEM-LEVEL (once per machine)             │
 │                    ~/.config/claude/                            │
 ├─────────────────────────────────────────────────────────────────┤
 │  gitea.env     │  GITEA_API_URL, GITEA_API_TOKEN                       │
 │  netbox.env    │  NETBOX_API_URL, NETBOX_API_TOKEN                     │
 │  git-flow.env  │  GIT_WORKFLOW_STYLE, GIT_DEFAULT_BASE, etc.   │
 └─────────────────────────────────────────────────────────────────┘
                              │
                              │ Shared across all projects
                              ▼
 ┌─────────────────────────────────────────────────────────────────┐
 │                  PROJECT-LEVEL (once per project)              │
 │                  <project-root>/.env                            │
 ├─────────────────────────────────────────────────────────────────┤
 │  GITEA_ORG               │  Organization for this project      │
 │  GITEA_REPO              │  Repository name for this project   │
 │  GIT_WORKFLOW_STYLE      │  (optional) Override system default │
 │  PR_REVIEW_*             │  (optional) PR review settings      │
 └─────────────────────────────────────────────────────────────────┘
 ```
 **Benefits:**
 - Single token per service (update once, use everywhere)
 - Easy multi-project setup (just run `/project-init` in each project)
 - Security (tokens never committed to git, never typed into AI chat)
 - Project isolation (each project can override defaults)
 ---
 ## Prerequisites
 Before running `/initial-setup`:
 1. **Python 3.10+** installed
   ```bash
   python3 --version  # Should be 3.10.0 or higher
   ```
 2. **Git repository** initialized (for project setup)
   ```bash
   git status  # Should show initialized repository
   ```
 3. **Claude Code** installed and working with the marketplace
 ---
 ## Setup Methods
 ### Method 1: Interactive Wizard (Recommended)
 Run the setup wizard in Claude Code:
 ```
 /initial-setup
 ```
 The wizard will guide you through each step interactively.
 **Note:** After first-time setup, you'll need to restart your Claude Code session for MCP tools to become available.
 ### Method 2: Manual Setup
 If you prefer to set up manually or need to troubleshoot:
 #### Step 1: MCP Server Setup
 ```bash
 # Navigate to marketplace directory
 cd /path/to/leo-claude-mktplace
 # Set up Gitea MCP server
 cd mcp-servers/gitea
 python3 -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 deactivate
 # (Optional) Set up NetBox MCP server
 cd ../netbox
 python3 -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 deactivate
 ```
 #### Step 2: System Configuration
 ```bash
 mkdir -p ~/.config/claude
 # Gitea configuration (credentials only)
 cat > ~/.config/claude/gitea.env << 'EOF'
 GITEA_API_URL=https://gitea.example.com
 GITEA_API_TOKEN=your_token_here
 EOF
 chmod 600 ~/.config/claude/gitea.env
 ```
 #### Step 3: Project Configuration
 In each project root:
 ```bash
 cat > .env << 'EOF'
 GITEA_ORG=your-organization
 GITEA_REPO=your-repo-name
 EOF
 ```
 Add `.env` to `.gitignore` if not already there.
 ### Method 3: Automation Script (CI/Scripting)
 For automated setups or CI environments:
 ```bash
 cd /path/to/leo-claude-mktplace
 ./scripts/setup.sh
 ```
 This script is useful for CI/CD pipelines and bulk provisioning.
 ---
 ## Configuration Reference
 ### System-Level Files
 Located in `~/.config/claude/`:
 | File | Required By | Purpose |
 |------|-------------|---------|
 | `gitea.env` | projman, pr-review | Gitea API credentials |
 | `netbox.env` | cmdb-assistant | NetBox API credentials |
 | `git-flow.env` | git-flow | Default git workflow settings |
 ### Gitea Configuration
 ```bash
 # ~/.config/claude/gitea.env
 GITEA_API_URL=https://gitea.example.com/api/v1
 GITEA_API_TOKEN=your_gitea_token_here
 ```
 | Variable | Description | Example |
 |----------|-------------|---------|
 | `GITEA_API_URL` | Gitea API endpoint (with `/api/v1`) | `https://gitea.example.com/api/v1` |
 | `GITEA_API_TOKEN` | Personal access token | `abc123...` |
 **Note:** `GITEA_ORG` is configured at the project level (see below) since different projects may belong to different organizations.
 **Generating a Gitea Token:**
 1. Log into Gitea → **User Icon** → **Settings**
 2. **Applications** tab → **Manage Access Tokens**
 3. **Generate New Token** with permissions:
   - `repo` (all sub-permissions)
   - `read:org`
   - `read:user`
   - `write:repo` (for wiki access)
 4. Copy token immediately (shown only once)
 ### NetBox Configuration
 ```bash
 # ~/.config/claude/netbox.env
 NETBOX_API_URL=https://netbox.example.com
 NETBOX_API_TOKEN=your_netbox_token_here
 ```
 | Variable | Description | Example |
 |----------|-------------|---------|
 | `NETBOX_API_URL` | NetBox base URL | `https://netbox.example.com` |
 | `NETBOX_API_TOKEN` | API token | `abc123...` |
 ### Git-Flow Configuration
 ```bash
 # ~/.config/claude/git-flow.env
 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
 ```
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_WORKFLOW_STYLE` | `feature-branch` | Branching strategy |
 | `GIT_DEFAULT_BASE` | `development` | Default base branch |
 | `GIT_AUTO_DELETE_MERGED` | `true` | Delete merged branches |
 | `GIT_AUTO_PUSH` | `false` | Auto-push after commit |
 | `GIT_PROTECTED_BRANCHES` | `main,master,...` | Protected branches |
 | `GIT_COMMIT_STYLE` | `conventional` | Commit message style |
 | `GIT_CO_AUTHOR` | `true` | Include Claude co-author |
 ---
 ## Project-Level Configuration
 Create `.env` in each project root:
 ```bash
 # Required for projman, pr-review
 GITEA_ORG=your-organization
 GITEA_REPO=your-repo-name
 # Optional: Override git-flow defaults
 GIT_WORKFLOW_STYLE=pr-required
 GIT_DEFAULT_BASE=main
 # Optional: PR review settings
 PR_REVIEW_CONFIDENCE_THRESHOLD=0.5
 PR_REVIEW_AUTO_SUBMIT=false
 ```
 | Variable | Required | Description |
 |----------|----------|-------------|
 | `GITEA_ORG` | Yes | Gitea organization for this project |
 | `GITEA_REPO` | Yes | Repository name (must match Gitea exactly) |
 | `GIT_WORKFLOW_STYLE` | No | Override system default |
 | `PR_REVIEW_*` | No | PR review settings |
 ---
 ## Plugin Configuration Summary
 | Plugin | System Config | Project Config | Setup Commands |
 |--------|---------------|----------------|----------------|
 | **projman** | gitea.env | .env (GITEA_ORG, GITEA_REPO) | `/initial-setup`, `/project-init`, `/project-sync` |
 | **pr-review** | gitea.env | .env (GITEA_ORG, GITEA_REPO) | `/initial-setup`, `/project-init`, `/project-sync` |
 | **git-flow** | git-flow.env (optional) | .env (optional) | None needed |
 | **clarity-assist** | None | None | None needed |
 | **cmdb-assistant** | netbox.env | None | `/initial-setup` |
 | **doc-guardian** | None | None | None needed |
 | **code-sentinel** | None | None | None needed |
 | **project-hygiene** | None | None | None needed |
 | **claude-config-maintainer** | None | None | None needed |
 ---
 ## Multi-Project Workflow
 Once system-level config is set up, adding new projects is simple:
 **Option 1: Use `/project-init` (faster)**
 ```
 cd ~/projects/new-project
 /project-init
 ```
 **Option 2: Use `/initial-setup` (auto-detects)**
 ```
 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.
 ---
 ## Automatic Validation Features
 ### API Validation
 When running `/initial-setup`, `/project-init`, or `/project-sync`, the commands:
 1. **Detect** organization and repository from git remote URL
 2. **Validate** via Gitea API: `GET /api/v1/repos/{org}/{repo}`
 3. **Auto-fill** if repository exists and is accessible (no confirmation needed)
 4. **Ask for confirmation** only if validation fails (404 or permission error)
 This catches typos and permission issues before saving configuration.
 ### Mismatch Detection (SessionStart Hook)
 When you start a Claude Code session, a hook automatically:
 1. Reads `GITEA_ORG` and `GITEA_REPO` from `.env`
 2. Compares with current `git remote get-url origin`
 3. **Warns** if mismatch detected: "Repository location mismatch. Run `/project-sync` to update."
 This helps when you:
 - Move a repository to a different organization
 - Rename a repository
 - Clone a repo but forget to update `.env`
 ---
 ## Verification
 ### Test Gitea Connection
 ```bash
 source ~/.config/claude/gitea.env
 curl -H "Authorization: token $GITEA_API_TOKEN" "$GITEA_API_URL/user"
 ```
 ### Verify Project Setup
 In Claude Code, after restarting your session:
 ```
 /labels-sync
 ```
 If this works, your setup is complete.
 ---
 ## Troubleshooting
 ### MCP tools not available
 **Cause:** Session wasn't restarted after setup.
 **Solution:** Exit Claude Code and start a new session.
 ### "Configuration not found" error
 ```bash
 # Check system config exists
 ls -la ~/.config/claude/gitea.env
 # Check permissions (should be 600)
 stat ~/.config/claude/gitea.env
 ```
 ### Authentication failed
 ```bash
 # Test token directly
 source ~/.config/claude/gitea.env
 curl -H "Authorization: token $GITEA_API_TOKEN" "$GITEA_API_URL/user"
 ```
 If you get 401, regenerate your token in Gitea.
 ### MCP server won't start
 ```bash
 # Check venv exists
 ls /path/to/mcp-servers/gitea/.venv
 # Reinstall if missing
 cd /path/to/mcp-servers/gitea
 rm -rf .venv
 python3 -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 deactivate
 ```
 ### Wrong repository
 ```bash
 # Check project .env
 cat .env
 # Verify GITEA_REPO matches the Gitea repository name exactly
 ```
 ---
 ## Security Best Practices
 1. **Never commit tokens**
   - Keep credentials in `~/.config/claude/` only
   - Add `.env` to `.gitignore`
 2. **Secure configuration files**
   ```bash
   chmod 600 ~/.config/claude/*.env
   ```
 3. **Never type tokens into AI chat**
   - Always edit config files directly in your editor
   - The `/initial-setup` wizard respects this
 4. **Rotate tokens periodically**
   - Every 6-12 months
   - Immediately if compromised
 5. **Minimum permissions**
   - Only grant required token permissions
   - Use separate tokens for different environments
--- a/docs/DEBUGGING-CHECKLIST.md
+++ b/docs/DEBUGGING-CHECKLIST.md
@@ -0,0 +1,213 @@
 # Debugging Checklist for Marketplace Troubleshooting
 **Purpose:** Systematic approach to diagnose and fix plugin loading issues.
 Last Updated: 2026-01-22
 ---
 ## Step 1: Identify the Loading Path
 Claude Code loads plugins from different locations depending on context:
 | Location | Path | When Used |
 |----------|------|-----------|
 | **Source** | `~/claude-plugins-work/` | When developing in this directory |
 | **Installed** | `~/.claude/plugins/marketplaces/leo-claude-mktplace/` | After marketplace install |
 | **Cache** | `~/.claude/` | Plugin metadata, settings |
 **Determine which path Claude is using:**
 ```bash
 # Check if installed marketplace exists
 ls -la ~/.claude/plugins/marketplaces/leo-claude-mktplace/
 # Check Claude's current plugin loading
 cat ~/.claude/settings.local.json | grep -A5 "mcpServers"
 ```
 **Key insight:** If you're editing source but Claude uses installed, your changes won't take effect.
 ---
 ## Step 2: Verify Files Exist at Runtime Location
 Check the files Claude will actually load:
 ```bash
 # For installed marketplace
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
 # Check MCP server exists
 ls -la $RUNTIME/mcp-servers/gitea/
 ls -la $RUNTIME/mcp-servers/netbox/
 # Check plugin manifests
 ls -la $RUNTIME/plugins/projman/.claude-plugin/plugin.json
 ls -la $RUNTIME/plugins/pr-review/.claude-plugin/plugin.json
 # Check .mcp.json files
 cat $RUNTIME/plugins/projman/.mcp.json
 ```
 ---
 ## Step 3: Verify Virtual Environments Exist
 **This is the most common failure point after installation.**
 MCP servers require Python venvs to exist at the INSTALLED location:
 ```bash
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
 # Check venvs exist
 ls -la $RUNTIME/mcp-servers/gitea/.venv/bin/python
 ls -la $RUNTIME/mcp-servers/netbox/.venv/bin/python
 # If missing, create them:
 cd $RUNTIME && ./scripts/setup.sh
 ```
 **Common error:** "X MCP servers failed to start" = venvs don't exist in installed path.
 ---
 ## Step 4: Verify Symlink Resolution
 Plugins use symlinks to shared MCP servers. Verify they resolve correctly:
 ```bash
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
 # Check symlinks exist and resolve
 readlink -f $RUNTIME/plugins/projman/mcp-servers/gitea
 readlink -f $RUNTIME/plugins/pr-review/mcp-servers/gitea
 readlink -f $RUNTIME/plugins/cmdb-assistant/mcp-servers/netbox
 # Should resolve to:
 # $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
 Manually test if the MCP server can start:
 ```bash
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
 # Test Gitea MCP
 cd $RUNTIME/mcp-servers/gitea
 PYTHONPATH=. .venv/bin/python -c "from mcp_server.server import main; print('OK')"
 # Test NetBox MCP
 cd $RUNTIME/mcp-servers/netbox
 PYTHONPATH=. .venv/bin/python -c "from mcp_server.server import main; print('OK')"
 ```
 **If import fails:** Check requirements.txt installed, check Python version compatibility.
 ---
 ## Step 6: Verify Configuration Files
 Check environment variables are set:
 ```bash
 # System-level credentials (should exist)
 cat ~/.config/claude/gitea.env
 # Should contain: GITEA_API_URL, GITEA_API_TOKEN
 cat ~/.config/claude/netbox.env
 # Should contain: NETBOX_API_URL, NETBOX_API_TOKEN
 # Project-level config (in target project)
 cat /path/to/project/.env
 # Should contain: GITEA_ORG, GITEA_REPO
 ```
 ---
 ## Step 7: Verify Hooks Configuration
 Check hooks are valid:
 ```bash
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
 # List all hooks.json files
 find $RUNTIME/plugins -name "hooks.json" -exec echo "=== {} ===" \; -exec cat {} \;
 # Verify hook events are valid
 # Valid: PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, SessionEnd,
 #        Notification, Stop, SubagentStop, PreCompact
 # INVALID: task-completed, file-changed, git-commit-msg-needed
 ```
 ---
 ## Quick Diagnostic Commands
 Run these to quickly identify issues:
 ```bash
 RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
 echo "=== Installation Status ==="
 [ -d "$RUNTIME" ] && echo "Installed: YES" || echo "Installed: NO"
 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 ==="
 [ -L "$RUNTIME/plugins/projman/mcp-servers/gitea" ] && echo "projman->gitea: OK" || echo "projman->gitea: 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"
 [ -f ~/.config/claude/netbox.env ] && echo "netbox.env: OK" || echo "netbox.env: MISSING"
 ```
 ---
 ## Common Issues and Fixes
 | 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 |
 | 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) |
 ---
 ## After Fixing Issues
 1. **Restart Claude Code** - Plugins are loaded at startup
 2. **Verify fix works** - Run a simple command that uses the MCP
 3. **Document the issue** - If it's a new failure mode, add to this checklist
 ---
 ## Automated Diagnostics
 Use these commands for automated checking:
 - `/debug-report` - Run full diagnostics, create issue if problems found
 - `/debug-review` - Investigate existing diagnostic issues and propose fixes
 ---
 ## Related Documentation
 - `CLAUDE.md` - Installation Paths and Troubleshooting sections
 - `docs/CONFIGURATION.md` - Setup and configuration guide
 - `docs/UPDATING.md` - Update procedures
--- a/docs/UPDATING.md
+++ b/docs/UPDATING.md
@@ -1,24 +1,71 @@
-# Updating support-claude-mktplace
+# Updating Leo Claude Marketplace
 This guide covers how to update your local installation when new versions are released.
-## Quick Update
+---
 ## ⚠️ CRITICAL: Run Setup in Installed Location
 When Claude Code installs a marketplace, it copies files to `~/.claude/plugins/marketplaces/` but **does NOT create Python virtual environments**. You must run setup manually after installation or update.
 **After installing or updating the marketplace:**
 ```bash
-# 1. Pull latest changes
+cd ~/.claude/plugins/marketplaces/leo-claude-mktplace && ./scripts/setup.sh
-cd /path/to/support-claude-mktplace
+```
 This creates the required `.venv` directories for MCP servers. Without this step, **all MCP servers will fail to start**.
 ---
 ## Quick Update (Source Repository)
 ```bash
 # 1. Pull latest changes to source
 cd /path/to/leo-claude-mktplace
 git pull origin main
-# 2. Run post-update script
+# 2. Run post-update script (updates source repo venvs)
 ./scripts/post-update.sh
 # 3. CRITICAL: Run setup in installed marketplace location
 cd ~/.claude/plugins/marketplaces/leo-claude-mktplace && ./scripts/setup.sh
 ```
 **Then restart your Claude Code session** to load any changes.
 ---
 ## What the Post-Update Script Does
-1. **Updates Python dependencies** for Gitea and Wiki.js MCP servers
+1. **Updates Python dependencies** for MCP servers (gitea, netbox)
 2. **Shows recent changelog entries** so you know what changed
 3. **Validates your configuration** is still compatible
 ---
 ## After Updating: Re-run Setup if Needed
 ### When to Re-run `/initial-setup`
 You typically **don't need** to re-run setup after updates. However, re-run if:
 - Changelog mentions **new required environment variables**
 - Changelog mentions **breaking changes** to configuration
 - MCP tools stop working after update
 ### For Existing Projects
 If an update requires new project-level configuration:
 ```
 /project-init
 ```
 This will detect existing settings and only add what's missing.
 ---
 ## Manual Steps After Update
 Some updates may require manual configuration changes:
@@ -29,8 +76,7 @@ If the changelog mentions new environment variables:
 1. Check the variable name and purpose in the changelog
 2. Add it to the appropriate config file:
-   - Gitea variables → `~/.config/claude/gitea.env`
+   - System variables → `~/.config/claude/gitea.env` or `netbox.env`
   - Wiki.js variables → `~/.config/claude/wikijs.env`
   - Project variables → `.env` in your project root
 ### New MCP Server Features
@@ -38,14 +84,50 @@ If the changelog mentions new environment variables:
 If a new MCP server tool is added:
 1. The post-update script handles dependency installation
-2. Check `docs/references/MCP-*.md` for usage documentation
+2. Check plugin documentation for usage
-3. New tools are available immediately after update
+3. New tools are available immediately after session restart
 ### Breaking Changes
 Breaking changes will be clearly marked in CHANGELOG.md with migration instructions.
-## Troubleshooting
+### Setup Script and Configuration Workflow Changes
 When updating, review if changes affect the setup workflow:
 1. **Check for setup command changes:**
   ```bash
   git diff HEAD~1 plugins/*/commands/initial-setup.md
   git diff HEAD~1 plugins/*/commands/project-init.md
   git diff HEAD~1 plugins/*/commands/project-sync.md
   ```
 2. **Check for hook changes:**
   ```bash
   git diff HEAD~1 plugins/*/hooks/hooks.json
   ```
 3. **Check for configuration structure changes:**
   ```bash
   git diff HEAD~1 docs/CONFIGURATION.md
   ```
 **If setup commands changed:**
 - Review what's new (new validation steps, new prompts, etc.)
 - Consider re-running `/initial-setup` or `/project-init` to benefit from improvements
 - Existing configurations remain valid unless changelog notes breaking changes
 **If hooks changed:**
 - Restart your Claude Code session to load new hooks
 - New hooks (like SessionStart validation) activate automatically
 **If configuration structure changed:**
 - Check if new variables are required
 - Run `/project-sync` if repository detection logic improved
 ---
 ## Troubleshooting Updates
 ### Dependencies fail to install
@@ -57,27 +139,52 @@ python3 -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 deactivate
 # Repeat for wikijs
 cd ../wikijs
 rm -rf .venv
 python3 -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 deactivate
 ```
 ### Configuration no longer works
 1. Check CHANGELOG.md for breaking changes
-2. Compare your config files with updated `.env.example` (if provided)
+2. Run `/initial-setup` to re-validate and fix configuration
-3. Run `./scripts/setup.sh` to validate configuration
+3. Compare your config files with documentation in `docs/CONFIGURATION.md`
-### MCP server won't start
+### MCP server won't start after update
 **Most common cause:** Virtual environments don't exist in the installed marketplace.
 ```bash
 # Fix: Run setup in installed location
 cd ~/.claude/plugins/marketplaces/leo-claude-mktplace && ./scripts/setup.sh
 ```
 If that doesn't work:
 1. Check Python version: `python3 --version` (requires 3.10+)
-2. Verify venv exists: `ls mcp-servers/gitea/.venv`
+2. Verify venv exists in INSTALLED location:
-3. Check logs for specific errors
+   ```bash
   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.
 4. Restart Claude Code session
 5. Check logs for specific errors
 ### "X MCP servers failed" on startup
 This almost always means the venvs don't exist in the installed marketplace:
 ```bash
 cd ~/.claude/plugins/marketplaces/leo-claude-mktplace && ./scripts/setup.sh
 ```
 Then restart Claude Code.
 ### New commands not available
 1. Restart your Claude Code session
 2. Verify the plugin is still installed
 3. Check if the command requires additional setup
 ---
 ## Version Pinning
@@ -88,14 +195,28 @@ To stay on a specific version:
 git tag
 # Checkout specific version
-git checkout v1.0.0
+git checkout v3.0.0
 # Run post-update
 ./scripts/post-update.sh
 ```
 ---
 ## Checking Current Version
 The version is displayed in the main README.md title and in `CHANGELOG.md`.
 ```bash
 # Check version from changelog
 head -20 CHANGELOG.md
 ```
 ---
 ## Getting Help
- Check `docs/references/` for component documentation
+- Check `docs/CONFIGURATION.md` for setup guide
- Review CHANGELOG.md for recent changes
+- Check `docs/COMMANDS-CHEATSHEET.md` for command reference
 - Review `CHANGELOG.md` for recent changes
 - Search existing issues in Gitea
--- a/docs/architecture/agent-workflow.spec.md
+++ b/docs/architecture/agent-workflow.spec.md
@@ -2,7 +2,7 @@
 **Target File:** `docs/architecture/agent-workflow.drawio`
-**Purpose:** Shows when Planner, Orchestrator, and Executor agents trigger during sprint lifecycle.
+**Purpose:** Shows when Planner, Orchestrator, Executor, and Code Reviewer agents trigger during sprint lifecycle.
 **Diagram Type:** Swimlane / Sequence Diagram
@@ -16,8 +16,8 @@
 | planner-lane | Planner Agent | #4A90D9 | 2 |
 | orchestrator-lane | Orchestrator Agent | #7CB342 | 3 |
 | executor-lane | Executor Agent | #FF9800 | 4 |
-| gitea-lane | Gitea | #9E9E9E | 5 |
+| reviewer-lane | Code Reviewer Agent | #9C27B0 | 5 |
-| wikijs-lane | Wiki.js | #9E9E9E | 6 (rightmost) |
+| gitea-lane | Gitea (Issues + Wiki) | #9E9E9E | 6 (rightmost) |
 ---
@@ -30,7 +30,7 @@
 | p1-start | /sprint-plan | rounded-rect | user-lane | 1 |
 | p1-activate | Planner Activates | rectangle | planner-lane | 2 |
 | p1-search-lessons | Search Lessons Learned | rectangle | planner-lane | 3 |
-| p1-wikijs-query | Query Past Lessons | rectangle | wikijs-lane | 4 |
+| p1-gitea-wiki-query | Query Past Lessons (Wiki) | rectangle | gitea-lane | 4 |
 | p1-return-lessons | Return Relevant Lessons | rectangle | planner-lane | 5 |
 | p1-clarify | Ask Clarifying Questions | diamond | planner-lane | 6 |
 | p1-user-answers | Provide Answers | rectangle | user-lane | 7 |
@@ -44,8 +44,8 @@
 |------|----|-------|-------|
 | p1-start | p1-activate | invokes | solid |
 | p1-activate | p1-search-lessons | | solid |
-| p1-search-lessons | p1-wikijs-query | GraphQL search | solid |
+| p1-search-lessons | p1-gitea-wiki-query | REST API (search_lessons) | solid |
-| p1-wikijs-query | p1-return-lessons | lessons data | dashed |
+| p1-gitea-wiki-query | p1-return-lessons | lessons data | dashed |
 | p1-return-lessons | p1-clarify | | solid |
 | p1-clarify | p1-user-answers | questions | solid |
 | p1-user-answers | p1-clarify | answers | dashed |
@@ -65,7 +65,7 @@
 | p2-orch-activate | Orchestrator Activates | rectangle | orchestrator-lane | 12 |
 | p2-fetch-issues | Fetch Sprint Issues | rectangle | orchestrator-lane | 13 |
 | p2-gitea-list | List Open Issues | rectangle | gitea-lane | 14 |
-| p2-sequence | Sequence Work | rectangle | orchestrator-lane | 15 |
+| p2-sequence | Sequence Work (Dependencies) | rectangle | orchestrator-lane | 15 |
 | p2-dispatch | Dispatch Task | rectangle | orchestrator-lane | 16 |
 | p2-exec-activate | Executor Activates | rectangle | executor-lane | 17 |
 | p2-implement | Implement Task | rectangle | executor-lane | 18 |
@@ -83,7 +83,7 @@
 | p2-orch-activate | p2-fetch-issues | | solid |
 | p2-fetch-issues | p2-gitea-list | REST API | solid |
 | p2-gitea-list | p2-sequence | issues data | dashed |
-| p2-sequence | p2-dispatch | | solid |
+| p2-sequence | p2-dispatch | parallel batching | solid |
 | p2-dispatch | p2-exec-activate | execution prompt | solid |
 | p2-exec-activate | p2-implement | | solid |
 | p2-implement | p2-update-status | | solid |
@@ -95,23 +95,50 @@
 ---
 ## PHASE 2.5: CODE REVIEW (Pre-Close)
 ### Nodes
 | ID | Label | Type | Lane | Sequence |
 |----|-------|------|------|----------|
 | p25-start | /review | rounded-rect | user-lane | 24 |
 | p25-reviewer-activate | Code Reviewer Activates | rectangle | reviewer-lane | 25 |
 | p25-scan-changes | Scan Recent Changes | rectangle | reviewer-lane | 26 |
 | p25-check-quality | Check Code Quality | rectangle | reviewer-lane | 27 |
 | p25-security-scan | Security Scan | rectangle | reviewer-lane | 28 |
 | p25-report | Generate Review Report | rectangle | reviewer-lane | 29 |
 | p25-complete | Review Complete | rounded-rect | reviewer-lane | 30 |
 ### Edges
 | From | To | Label | Style |
 |------|----|-------|-------|
 | p25-start | p25-reviewer-activate | invokes | solid |
 | p25-reviewer-activate | p25-scan-changes | | solid |
 | p25-scan-changes | p25-check-quality | | solid |
 | p25-check-quality | p25-security-scan | | solid |
 | p25-security-scan | p25-report | | solid |
 | p25-report | p25-complete | | solid |
 ---
 ## PHASE 3: SPRINT CLOSE
 ### Nodes
 | ID | Label | Type | Lane | Sequence |
 |----|-------|------|------|----------|
-| p3-start | /sprint-close | rounded-rect | user-lane | 24 |
+| p3-start | /sprint-close | rounded-rect | user-lane | 31 |
-| p3-orch-activate | Orchestrator Activates | rectangle | orchestrator-lane | 25 |
+| p3-orch-activate | Orchestrator Activates | rectangle | orchestrator-lane | 32 |
-| p3-review | Review Sprint | rectangle | orchestrator-lane | 26 |
+| p3-review | Review Sprint | rectangle | orchestrator-lane | 33 |
-| p3-gitea-status | Get Final Status | rectangle | gitea-lane | 27 |
+| p3-gitea-status | Get Final Status | rectangle | gitea-lane | 34 |
-| p3-capture | Capture Lessons Learned | rectangle | orchestrator-lane | 28 |
+| p3-capture | Capture Lessons Learned | rectangle | orchestrator-lane | 35 |
-| p3-user-input | Confirm Lessons | diamond | user-lane | 29 |
+| p3-user-input | Confirm Lessons | diamond | user-lane | 36 |
-| p3-create-wiki | Create Wiki Pages | rectangle | orchestrator-lane | 30 |
+| p3-create-wiki | Create Wiki Pages | rectangle | orchestrator-lane | 37 |
-| p3-wikijs-create | Store Lessons | rectangle | wikijs-lane | 31 |
+| p3-gitea-wiki-create | Store Lessons (Wiki) | rectangle | gitea-lane | 38 |
-| p3-close-issues | Close Issues | rectangle | orchestrator-lane | 32 |
+| p3-close-issues | Close Issues | rectangle | orchestrator-lane | 39 |
-| p3-gitea-close | Mark Closed | rectangle | gitea-lane | 33 |
+| p3-gitea-close | Mark Closed | rectangle | gitea-lane | 40 |
-| p3-complete | Sprint Closed | rounded-rect | orchestrator-lane | 34 |
+| p3-complete | Sprint Closed | rounded-rect | orchestrator-lane | 41 |
 ### Edges
@@ -123,8 +150,8 @@
 | p3-gitea-status | p3-capture | status data | dashed |
 | p3-capture | p3-user-input | proposed lessons | solid |
 | p3-user-input | p3-create-wiki | confirmed | solid |
-| p3-create-wiki | p3-wikijs-create | GraphQL mutation | solid |
+| p3-create-wiki | p3-gitea-wiki-create | REST API (create_lesson) | solid |
-| p3-wikijs-create | p3-close-issues | confirm | dashed |
+| p3-gitea-wiki-create | p3-close-issues | confirm | dashed |
 | p3-close-issues | p3-gitea-close | REST API | solid |
 | p3-gitea-close | p3-complete | confirm | dashed |
@@ -133,59 +160,71 @@
 ## LAYOUT NOTES
 ```
-+--------+------------+---------------+------------+--------+----------+
+--------+------------+---------------+------------+----------+------------------+
-|  User  |  Planner   | Orchestrator  |  Executor  | Gitea  | Wiki.js  |
+|  User  |  Planner   | Orchestrator  |  Executor  | Reviewer | Gitea            |
-+--------+------------+---------------+------------+--------+----------+
+|        |            |               |            |          | (Issues + Wiki)  |
 +--------+------------+---------------+------------+----------+------------------+
 |        |            |               |            |          |                  |
 | PHASE 1: SPRINT PLANNING                                                       |
-|---------------------------------------------------------------------+
+|-------------------------------------------------------------------------------|
 |  O     |            |               |            |          |                  |
 |  |     |            |               |            |          |                  |
 |  +---->| O          |               |            |          |                  |
 |        | |          |               |            |          |                  |
-|        | +----------|---------------|------------|------->| O        |
+|        | +----------|---------------|------------|--------->| O (Wiki Query)   |
-|        | |<---------|---------------|------------|--------+ |        |
+|        | |<---------|---------------|------------|----------+ |                |
 |        | |          |               |            |          |                  |
 |        | O<>        |               |            |          |                  |
 |  O<--->+ |          |               |            |          |                  |
 |        | |          |               |            |          |                  |
-|        | +----------|---------------|----------->| O      |          |
+|        | +----------|---------------|------------|--------->| O (Issues)       |
 |        | O          |               |            |          |                  |
 |        |            |               |            |          |                  |
-|---------------------------------------------------------------------+
+|-------------------------------------------------------------------------------|
 | PHASE 2: SPRINT EXECUTION                                                      |
-|---------------------------------------------------------------------+
+|-------------------------------------------------------------------------------|
 |  O     |            |               |            |          |                  |
 |  |     |            |               |            |          |                  |
 |  +-----|----------->| O             |            |          |                  |
 |        |            | |             |            |          |                  |
-|        |            | +-------------|----------->| O      |          |
+|        |            | +-------------|------------|--------->| O (Issues)       |
-|        |            | |<------------|------------+ |      |          |
+|        |            | |<------------|------------|----------+ |                |
 |        |            | |             |            |          |                  |
 |        |            | +------------>| O          |          |                  |
 |        |            |               | |          |          |                  |
-|        |            |               | +--------->| O      |          |
+|        |            |               | +----------|--------->| O (Issues)       |
-|        |            |               | |<---------+ |      |          |
+|        |            |               | |<---------|----------+ |                |
 |        |            | O<------------+ |          |          |                  |
 |        |            | |             |            |          |                  |
 |        |            | O (loop)      |            |          |                  |
 |        |            |               |            |          |                  |
-|---------------------------------------------------------------------+
+|-------------------------------------------------------------------------------|
 | PHASE 2.5: CODE REVIEW                                                         |
 |-------------------------------------------------------------------------------|
 |  O     |            |               |            |          |                  |
 |  |     |            |               |            |          |                  |
 |  +-----|------------|---------------|----------->| O        |                  |
 |        |            |               |            | |        |                  |
 |        |            |               |            | O->O->O  |                  |
 |        |            |               |            | |        |                  |
 |        |            |               |            | O        |                  |
 |        |            |               |            |          |                  |
 |-------------------------------------------------------------------------------|
 | PHASE 3: SPRINT CLOSE                                                          |
-|---------------------------------------------------------------------+
+|-------------------------------------------------------------------------------|
 |  O     |            |               |            |          |                  |
 |  |     |            |               |            |          |                  |
 |  +-----|----------->| O             |            |          |                  |
-|        |            | +-------------|----------->| O      |          |
+|        |            | +-------------|------------|--------->| O (Issues)       |
-|        |            | |<------------|------------+ |      |          |
+|        |            | |<------------|------------|----------+ |                |
 |        |            | |             |            |          |                  |
 |  O<----|-----------<+ |             |            |          |                  |
 |  +-----|----------->| |             |            |          |                  |
-|        |            | +-------------|------------|------->| O        |
+|        |            | +-------------|------------|--------->| O (Wiki Create)  |
-|        |            | |<------------|------------|--------+ |        |
+|        |            | |<------------|------------|----------+ |                |
-|        |            | +-------------|----------->| O      |          |
+|        |            | +-------------|------------|--------->| O (Issues Close) |
 |        |            | O             |            |          |                  |
-+--------+------------+---------------+------------+--------+----------+
+--------+------------+---------------+------------+----------+------------------+
 ```
 ---
@@ -198,7 +237,8 @@
 | Blue | #4A90D9 | Planner Agent |
 | Green | #7CB342 | Orchestrator Agent |
 | Orange | #FF9800 | Executor Agent |
-| Gray | #9E9E9E | External Services |
+| Purple | #9C27B0 | Code Reviewer Agent |
 | Gray | #9E9E9E | External Services (Gitea) |
 ---
@@ -219,3 +259,13 @@
 |-------|---------|
 | Solid | Action/Request |
 | Dashed | Response/Data return |
 ---
 ## ARCHITECTURE NOTES
 - **Gitea provides BOTH issue tracking AND wiki** (no separate wiki service)
 - All wiki operations use Gitea REST API via MCP tools
 - Lessons learned stored in Gitea Wiki under `lessons-learned/sprints/`
 - MCP tools: `search_lessons`, `create_lesson`, `list_wiki_pages`, `get_wiki_page`
 - Four-agent model: Planner, Orchestrator, Executor, Code Reviewer
--- a/docs/architecture/component-map.spec.md
+++ b/docs/architecture/component-map.spec.md
@@ -13,22 +13,26 @@
 | ID | Label | Type | Color | Position |
 |----|-------|------|-------|----------|
 | projman | projman | rectangle | #4A90D9 | top-center |
-| projman-pmo | projman-pmo | rectangle | #4A90D9 | top-right |
+| projman-pmo | projman-pmo (planned) | rectangle | #4A90D9 | top-right |
 | project-hygiene | project-hygiene | rectangle | #4A90D9 | top-left |
 | claude-config | claude-config-maintainer | rectangle | #4A90D9 | bottom-left |
 | cmdb-assistant | cmdb-assistant | rectangle | #4A90D9 | bottom-right |
 ### MCP Servers (Green - #7CB342)
-| ID | Label | Type | Color | Position |
+MCP servers are **bundled inside each plugin** that needs them.
-|----|-------|------|-------|----------|
+
-| gitea-mcp | Gitea MCP Server | rectangle | #7CB342 | middle-left |
+| ID | Label | Type | Color | Position | Bundled In |
-| wikijs-mcp | Wiki.js MCP Server | rectangle | #7CB342 | middle-right |
+|----|-------|------|-------|----------|------------|
 | gitea-mcp | Gitea MCP Server | rectangle | #7CB342 | middle-left | projman |
 | netbox-mcp | NetBox MCP Server | rectangle | #7CB342 | middle-right | cmdb-assistant |
 ### External Systems (Gray - #9E9E9E)
 | ID | Label | Type | Color | Position |
 |----|-------|------|-------|----------|
-| gitea-instance | Gitea\ngitea.hotserv.cloud | cylinder | #9E9E9E | bottom-left |
+| gitea-instance | Gitea\n(Issues + Wiki) | cylinder | #9E9E9E | bottom-left |
-| wikijs-instance | Wiki.js\nwikijs.hotserv.cloud | cylinder | #9E9E9E | bottom-right |
+| netbox-instance | NetBox | cylinder | #9E9E9E | bottom-right |
 ### Configuration (Orange - #FF9800)
@@ -45,10 +49,8 @@
 | From | To | Label | Style | Arrow |
 |------|----|-------|-------|-------|
-| projman | gitea-mcp | uses | solid | forward |
+| projman | gitea-mcp | bundled | solid | bidirectional |
-| projman | wikijs-mcp | uses | solid | forward |
+| cmdb-assistant | netbox-mcp | bundled | solid | bidirectional |
 | projman-pmo | gitea-mcp | uses (company-wide) | solid | forward |
 | projman-pmo | wikijs-mcp | uses (company-wide) | solid | forward |
 ### Plugin Dependencies
@@ -61,16 +63,16 @@
 | From | To | Label | Style | Arrow |
 |------|----|-------|-------|-------|
 | gitea-mcp | gitea-instance | REST API | solid | forward |
-| wikijs-mcp | wikijs-instance | GraphQL | solid | forward |
+| netbox-mcp | netbox-instance | REST API | solid | forward |
 ### Configuration Connections
 | From | To | Label | Style | Arrow |
 |------|----|-------|-------|-------|
 | system-config | gitea-mcp | credentials | dashed | forward |
-| system-config | wikijs-mcp | credentials | dashed | forward |
+| system-config | netbox-mcp | credentials | dashed | forward |
 | project-config | gitea-mcp | repo context | dashed | forward |
-| project-config | wikijs-mcp | project path | dashed | forward |
+| project-config | netbox-mcp | site context | dashed | forward |
 ---
@@ -78,9 +80,8 @@
 | ID | Label | Contains | Style |
 |----|-------|----------|-------|
-| plugins-group | Plugins | projman, projman-pmo, project-hygiene | light blue border |
+| plugins-group | Plugins | projman, projman-pmo, project-hygiene, claude-config, cmdb-assistant | light blue border |
-| mcp-group | Shared MCP Servers | gitea-mcp, wikijs-mcp | light green border |
+| external-group | External Services | gitea-instance, netbox-instance | light gray border |
 | external-group | External Services | gitea-instance, wikijs-instance | light gray border |
 | config-group | Configuration | system-config, project-config | light orange border |
 ---
@@ -92,25 +93,21 @@
 |                         PLUGINS GROUP                             |
 |  +----------------+  +----------------+  +-------------------+    |
 |  | project-       |  |    projman     |  |   projman-pmo    |    |
-|  | hygiene        |  |                |  |                   |    |
+|  | hygiene        |  |  [gitea-mcp]   |  |    (planned)      |    |
-|  +----------------+  +-------+--------+  +--------+----------+    |
+|  +----------------+  +-------+--------+  +-------------------+    |
-|                              |                    |               |
+|                              |                                    |
 |  +----------------+  +-------------------+                        |
 |  | claude-config  |  |  cmdb-assistant   |                        |
 |  | -maintainer    |  |   [netbox-mcp]    |                        |
 |  +----------------+  +--------+----------+                        |
 +------------------------------------------------------------------+
-                               |                    |
+                               |
-                               v                    v
+                               v
 +------------------------------------------------------------------+
 |                      MCP SERVERS GROUP                            |
 |  +-------------------+              +-------------------+         |
 |  |  Gitea MCP Server |              | Wiki.js MCP Server|         |
 |  +--------+----------+              +---------+---------+         |
 +------------------------------------------------------------------+
           |                                     |
           v                                     v
 +------------------------------------------------------------------+
 |                    EXTERNAL SERVICES GROUP                        |
 |  +-------------------+              +-------------------+         |
-|  |      Gitea        |              |     Wiki.js       |         |
+|  |      Gitea        |              |     NetBox        |         |
-|  | gitea.hotserv.cloud              | wikijs.hotserv.cloud        |
+|  |  (Issues + Wiki)  |              |                   |         |
 |  +-------------------+              +-------------------+         |
 +------------------------------------------------------------------+
@@ -128,6 +125,15 @@ CONFIG GROUP (left side):           CONFIG GROUP (right side):
 | Color | Hex | Meaning |
 |-------|-----|---------|
 | Blue | #4A90D9 | Plugins |
-| Green | #7CB342 | MCP Servers |
+| Green | #7CB342 | MCP Servers (bundled in plugins) |
 | Gray | #9E9E9E | External Systems |
 | Orange | #FF9800 | Configuration |
 ---
 ## ARCHITECTURE NOTES
 - MCP servers are **bundled inside plugins** (not shared at root)
 - Gitea provides both issue tracking AND wiki (lessons learned)
 - No separate Wiki.js - all wiki functionality uses Gitea Wiki
 - Each plugin is self-contained for Claude Code caching
--- a/docs/references/MCP-GITEA.md
+++ b/docs/references/MCP-GITEA.md
--- a/docs/references/MCP-WIKIJS.md
+++ b/docs/references/MCP-WIKIJS.md
--- a/docs/references/PLUGIN-PMO.md
+++ b/docs/references/PLUGIN-PMO.md
--- a/docs/references/PLUGIN-PROJMAN.md
+++ b/docs/references/PLUGIN-PROJMAN.md
--- a/docs/references/PROJECT-SUMMARY.md
+++ b/docs/references/PROJECT-SUMMARY.md
@@ -1,692 +0,0 @@
 # Project Management Plugins - Project Summary
 ## Overview
 This project builds two Claude Code plugins that transform a proven 15-sprint workflow into reusable, distributable tools for managing software development with Gitea, Wiki.js, and agile methodologies.
 **Status:** Planning phase complete, ready for implementation
 ---
 ## The Two Plugins
 ### 1. projman (Single-Repository)
 **Purpose:** Project management for individual repositories
 **Users:** Developers, Team Leads
 **Build Order:** Build FIRST
 **Key Features:**
 - Sprint planning with AI agents
 - Issue creation with 43-label taxonomy
 - Lessons learned capture in Wiki.js
 - Branch-aware security model
 - Hybrid configuration system
 **Reference:** [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md)
 ### 2. projman-pmo (Multi-Project)
 **Purpose:** PMO coordination across organization
 **Users:** PMO Coordinators, Engineering Managers, CTOs
 **Build Order:** Build SECOND (after projman validated)
 **Key Features:**
 - Cross-project status aggregation
 - Dependency tracking and visualization
 - Resource conflict detection
 - Release coordination
 - Company-wide lessons learned search
 **Reference:** [PLUGIN-PMO.md](./PLUGIN-PMO.md)
 ---
 ## Core Architecture
 ### Shared MCP Servers
 Both plugins share the same MCP server codebase at repository root (`mcp-servers/`):
 **1. Gitea MCP Server**
 - Issue management (CRUD operations)
 - Label taxonomy system (43 labels)
 - Mode detection (project vs company-wide)
 **Reference:** [MCP-GITEA.md](./MCP-GITEA.md)
 **2. Wiki.js MCP Server**
 - Documentation management
 - Lessons learned capture and search
 - GraphQL API integration
 - Company-wide knowledge base
 **Reference:** [MCP-WIKIJS.md](./MCP-WIKIJS.md)
 ### Mode Detection
 The MCP servers detect their operating mode based on environment variables:
 **Project Mode (projman):**
 - `GITEA_REPO` present → operates on single repository
 - `WIKIJS_PROJECT` present → operates on single project path
 **Company Mode (pmo):**
 - No `GITEA_REPO` → operates on all repositories
 - No `WIKIJS_PROJECT` → operates on entire company namespace
 ---
 ## Repository Structure
 ```
 bandit/support-claude-mktplace/
 ├── mcp-servers/                    # ← SHARED BY BOTH PLUGINS
 │   ├── gitea/                      # Gitea MCP Server
 │   │   ├── .venv/
 │   │   ├── requirements.txt
 │   │   ├── mcp_server/
 │   │   └── tests/
 │   └── wikijs/                     # Wiki.js MCP Server
 │       ├── .venv/
 │       ├── requirements.txt
 │       ├── mcp_server/
 │       └── tests/
 ├── projman/                        # ← PROJECT PLUGIN
 │   ├── .claude-plugin/
 │   │   └── plugin.json
 │   ├── .mcp.json                   # Points to ../mcp-servers/
 │   ├── commands/
 │   │   ├── sprint-plan.md
 │   │   ├── sprint-start.md
 │   │   ├── sprint-status.md
 │   │   ├── sprint-close.md
 │   │   └── labels-sync.md
 │   ├── agents/
 │   │   ├── planner.md
 │   │   ├── orchestrator.md
 │   │   └── executor.md
 │   ├── skills/
 │   │   └── label-taxonomy/
 │   ├── README.md
 │   └── CONFIGURATION.md
 └── projman-pmo/                    # ← PMO PLUGIN
    ├── .claude-plugin/
    │   └── plugin.json
    ├── .mcp.json                   # Points to ../mcp-servers/
    ├── commands/
    │   ├── pmo-status.md
    │   ├── pmo-priorities.md
    │   ├── pmo-dependencies.md
    │   └── pmo-schedule.md
    ├── agents/
    │   └── pmo-coordinator.md
    └── README.md
 ```
 ---
 ## Configuration Architecture
 ### Hybrid Configuration System
 The plugins use a hybrid configuration approach that balances security and flexibility:
 **System-Level (Once per machine):**
 - `~/.config/claude/gitea.env` - Gitea credentials
 - `~/.config/claude/wikijs.env` - Wiki.js credentials
 **Project-Level (Per repository):**
 - `project-root/.env` - Repository and project paths
 **Benefits:**
 - Single token per service (update once)
 - Project isolation
 - Security (tokens never committed)
 - Easy multi-project setup
 ### Configuration Example
 **System-Level:**
 ```bash
 # ~/.config/claude/gitea.env
 GITEA_API_URL=https://gitea.example.com/api/v1
 GITEA_API_TOKEN=your_token
 GITEA_OWNER=bandit
 # ~/.config/claude/wikijs.env
 WIKIJS_API_URL=https://wiki.your-company.com/graphql
 WIKIJS_API_TOKEN=your_token
 WIKIJS_BASE_PATH=/your-org
 ```
 **Project-Level:**
 ```bash
 # project-root/.env (for projman)
 GITEA_REPO=cuisineflow
 WIKIJS_PROJECT=projects/cuisineflow
 # No .env needed for pmo (company-wide mode)
 ```
 ---
 ## Key Architectural Decisions
 ### 1. Two MCP Servers (Shared)
 **Decision:** Separate Gitea and Wiki.js servers at repository root
 **Why:**
 - Clear separation of concerns
 - Independent configuration
 - Better maintainability
 - Professional architecture
 ### 2. Python Implementation
 **Decision:** Python 3.10+ for MCP servers
 **Why:**
 - Modern async/await improvements
 - Better type hints support
 - Good balance of compatibility vs features
 - Widely available (released Oct 2021)
 - Most production servers have 3.10+ by now
 ### 3. Wiki.js for Lessons Learned
 **Decision:** Use Wiki.js instead of Git-based Wiki
 **Why:**
 - Rich editor and search
 - Built-in tag system
 - Version history
 - Web-based collaboration
 - GraphQL API
 - Company-wide accessibility
 ### 4. Hybrid Configuration
 **Decision:** System-level + project-level configuration
 **Why:**
 - Single token per service (security)
 - Per-project customization (flexibility)
 - Easy multi-project setup
 - Never commit tokens to git
 ### 5. Mode Detection in MCP Servers
 **Decision:** Detect mode based on environment variables
 **Why:**
 - Same codebase for both plugins
 - No code duplication
 - Fix bugs once, both benefit
 - Clear separation of concerns
 ### 6. Build Order: projman First
 **Decision:** Build projman completely before starting pmo
 **Why:**
 - Validate core functionality
 - Establish patterns
 - Reduce risk
 - PMO builds on projman foundation
 ---
 ## The Three-Agent Model
 ### Projman Agents
 **Planner Agent:**
 - Sprint planning and architecture analysis
 - Asks clarifying questions
 - Suggests appropriate labels
 - Creates Gitea issues
 - Searches relevant lessons learned
 **Orchestrator Agent:**
 - Sprint progress monitoring
 - Task coordination
 - Blocker identification
 - Git operations
 - Generates lean execution prompts
 **Executor Agent:**
 - Implementation guidance
 - Code review suggestions
 - Testing strategy
 - Quality standards enforcement
 - Documentation
 ### PMO Agent
 **PMO Coordinator:**
 - Strategic view across all projects
 - Cross-project dependency tracking
 - Resource conflict detection
 - Release coordination
 - Delegates to projman agents for details
 ---
 ## Wiki.js Structure
 ```
 Wiki.js: https://wiki.your-company.com
 └── /your-org/
    ├── projects/                       # Project-specific
    │   ├── project-a/
    │   │   ├── lessons-learned/
    │   │   │   ├── sprints/
    │   │   │   ├── patterns/
    │   │   │   └── INDEX.md
    │   │   └── documentation/
    │   ├── project-b/
    │   ├── project-c/
    │   └── company-site/
    ├── company/                        # Company-wide
    │   ├── processes/
    │   ├── standards/
    │   └── tools/
    └── shared/                         # Cross-project
        ├── architecture-patterns/
        ├── best-practices/
        └── tech-stack/
 ```
 **Reference:** [MCP-WIKIJS.md](./MCP-WIKIJS.md#wiki-js-structure)
 ---
 ## Label Taxonomy System
 ### Dynamic Label System (44 labels currently)
 Labels are **fetched dynamically from Gitea** at runtime via the `/labels-sync` command:
 **Organization Labels (28):**
 - Agent/2
 - Complexity/3
 - Efforts/5
 - Priority/4
 - Risk/3
 - Source/4
 - Type/6 (Bug, Feature, Refactor, Documentation, Test, Chore)
 **Repository Labels (16):**
 - Component/9 (Backend, Frontend, API, Database, Auth, Deploy, Testing, Docs, Infra)
 - Tech/7 (Python, JavaScript, Docker, PostgreSQL, Redis, Vue, FastAPI)
 ### Type/Refactor Label
 **Organization-level label** for architectural work:
 - Service extraction
 - Architecture modifications
 - Code restructuring
 - Technical debt reduction
 **Note:** Label count may change. Always sync from Gitea using `/labels-sync` command. When new labels are detected, the command will explain changes and update suggestion logic.
 **Reference:** [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md#label-taxonomy-system)
 ---
 ## Build Order & Phases
 ### Build projman First (Phases 1-8)
 **Phase 1:** Core Infrastructure (MCP servers)
 **Phase 2:** Sprint Planning Commands
 **Phase 3:** Agent System
 **Phase 4:** Lessons Learned System
 **Phase 5:** Testing & Validation
 **Phase 6:** Documentation & Refinement
 **Phase 7:** Marketplace Preparation
 **Phase 8:** Production Hardening
 **Reference:** [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md#implementation-phases)
 ### Build pmo Second (Phases 9-12)
 **Phase 9:** PMO Plugin Foundation
 **Phase 10:** PMO Commands & Workflows
 **Phase 11:** PMO Testing & Integration
 **Phase 12:** Production Deployment
 **Reference:** [PLUGIN-PMO.md](./PLUGIN-PMO.md#implementation-phases)
 ---
 ## Quick Start Guide
 ### 1. System Configuration
 ```bash
 # Create config directory
 mkdir -p ~/.config/claude
 # Gitea config
 cat > ~/.config/claude/gitea.env << EOF
 GITEA_API_URL=https://gitea.example.com/api/v1
 GITEA_API_TOKEN=your_gitea_token
 GITEA_OWNER=bandit
 EOF
 # Wiki.js config
 cat > ~/.config/claude/wikijs.env << EOF
 WIKIJS_API_URL=https://wiki.your-company.com/graphql
 WIKIJS_API_TOKEN=your_wikijs_token
 WIKIJS_BASE_PATH=/your-org
 EOF
 # Secure files
 chmod 600 ~/.config/claude/*.env
 ```
 ### 2. Project Configuration
 ```bash
 # In each project root (for projman)
 cat > .env << EOF
 GITEA_REPO=cuisineflow
 WIKIJS_PROJECT=projects/cuisineflow
 EOF
 # Add to .gitignore
 echo ".env" >> .gitignore
 ```
 ### 3. MCP Server Setup
 ```bash
 # Gitea MCP Server
 cd mcp-servers/gitea
 python -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 # Wiki.js MCP Server
 cd mcp-servers/wikijs
 python -m venv .venv
 source .venv/bin/activate
 pip install -r requirements.txt
 ```
 ### 4. Validate Setup
 ```bash
 # Test MCP servers
 python -m mcp_server.server --test  # In each MCP directory
 # Test plugin loading
 claude plugin test projman
 claude plugin test projman-pmo
 ```
 ---
 ## Document Organization
 This documentation is organized into 4 focused files plus this summary:
 ### 1. Gitea MCP Server Reference
 **File:** [MCP-GITEA.md](./MCP-GITEA.md)
 **Contains:**
 - Configuration setup
 - Python implementation
 - API client code
 - Issue and label tools
 - Testing strategies
 - Mode detection
 - Performance optimization
 **Use when:** Implementing or troubleshooting Gitea integration
 ### 2. Wiki.js MCP Server Reference
 **File:** [MCP-WIKIJS.md](./MCP-WIKIJS.md)
 **Contains:**
 - Configuration setup
 - GraphQL client implementation
 - Wiki.js structure
 - Lessons learned system
 - Documentation tools
 - Company-wide patterns
 - PMO multi-project methods
 **Use when:** Implementing or troubleshooting Wiki.js integration
 ### 3. Projman Plugin Reference
 **File:** [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md)
 **Contains:**
 - Plugin structure
 - Commands (sprint-plan, sprint-start, sprint-status, sprint-close, labels-sync)
 - Three agents (planner, orchestrator, executor)
 - Sprint workflow
 - Label taxonomy
 - Branch-aware security
 - Implementation phases 1-8
 **Use when:** Building or using the projman plugin
 ### 4. PMO Plugin Reference
 **File:** [PLUGIN-PMO.md](./PLUGIN-PMO.md)
 **Contains:**
 - PMO plugin structure
 - Multi-project commands
 - PMO coordinator agent
 - Cross-project coordination
 - Dependency tracking
 - Resource conflict detection
 - Implementation phases 9-12
 **Use when:** Building or using the projman-pmo plugin
 ### 5. This Summary
 **File:** PROJECT-SUMMARY.md (this document)
 **Contains:**
 - Project overview
 - Architecture decisions
 - Configuration approach
 - Quick start guide
 - References to detailed docs
 **Use when:** Getting started or need high-level overview
 ---
 ## Key Success Metrics
 ### Technical Metrics
 - Sprint planning time reduced by 40%
 - Manual steps eliminated: 10+ per sprint
 - Lessons learned capture rate: 100% (vs 0% before)
 - Label accuracy on issues: 90%+
 - Configuration setup time: < 5 minutes
 ### User Metrics
 - User satisfaction: Better than current manual workflow
 - Learning curve: < 1 hour to basic proficiency
 - Error rate: < 5% incorrect operations
 - Adoption rate: 100% team adoption within 1 month
 ### PMO Metrics
 - Cross-project visibility: 100% (vs fragmented before)
 - Dependency detection: Automated (vs manual tracking)
 - Resource conflict identification: Proactive (vs reactive)
 - Release coordination: Streamlined (vs ad-hoc)
 ---
 ## Critical Lessons from 15 Sprints
 ### Why Lessons Learned Is Critical
 After 15 sprints without systematic 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
 ### Branch Detection Must Be 100% Reliable
 Production accidents are unacceptable. Branch-aware security prevents:
 - Accidental code changes on production branch
 - Sprint planning on wrong branch
 - Deployment mistakes
 **Implementation:** Two layers - CLAUDE.md (file-level) + Plugin agents (tool-level)
 ### Configuration Complexity Is a Blocker
 Previous attempts failed due to:
 - Complex per-project setup
 - Token management overhead
 - Multiple configuration files
 **Solution:** Hybrid approach - system-level tokens + simple project-level paths
 ---
 ## Next Steps
 ### Immediate Actions
 1. **Set up system configuration** (Gitea + Wiki.js tokens)
 2. **Create Wiki.js base structure** at `/your-org`
 3. **Begin Phase 1.1a** - Gitea MCP Server implementation
 4. **Begin Phase 1.1b** - Wiki.js MCP Server implementation
 ### Phase Execution
 1. **Phases 1-4:** Build core projman functionality
 2. **Phase 5:** Validate with real sprint (e.g., Intuit Engine extraction)
 3. **Phases 6-8:** Polish, document, and harden projman
 4. **Phases 9-12:** Build and validate pmo plugin
 ### Validation Points
 - **After Phase 1:** MCP servers working and tested
 - **After Phase 4:** Complete projman workflow end-to-end
 - **After Phase 5:** Real sprint successfully managed
 - **After Phase 8:** Production-ready projman
 - **After Phase 11:** Multi-project coordination validated
 - **After Phase 12:** Complete system operational
 ---
 ## Implementation Decisions (Pre-Development)
 These decisions were finalized before development:
 ### 1. Python Version: 3.10+
 - **Rationale:** Balance of modern features and wide availability
 - **Benefits:** Modern async, good type hints, widely deployed
 - **Minimum:** Python 3.10.0
 ### 2. Wiki.js Base Structure: Needs Creation
 - **Status:** `/your-org` structure does NOT exist yet
 - **Action:** Run `setup_wiki_structure.py` during Phase 1.1b
 - **Script:** See MCP-WIKIJS.md for complete setup script
 - **Post-setup:** Verify at https://wiki.your-company.com/your-org
 ### 3. Testing Strategy: Both Mocks and Real APIs
 - **Unit tests:** Use mocks for fast feedback during development
 - **Integration tests:** Use real Gitea/Wiki.js APIs for validation
 - **CI/CD:** Run both test suites
 - **Developers:** Can skip integration tests locally if needed
 - **Markers:** Use pytest markers (`@pytest.mark.integration`)
 ### 4. Token Permissions: Confirmed
 - **Gitea token:**
  - `repo` (all) - Read/write repositories, issues, labels
  - `read:org` - Organization information and labels
  - `read:user` - User information
 - **Wiki.js token:**
  - Read/create/update pages
  - Manage tags
  - Search access
 ### 5. Label System: Dynamic (44 labels)
 - **Current count:** 44 labels (28 org + 16 repo)
 - **Approach:** Fetch dynamically via API, never hardcode
 - **Sync:** `/labels-sync` command updates local reference and suggestion logic
 - **New labels:** Command explains changes and asks for confirmation
 ### 6. Branch Detection: Defense in Depth
 - **Layer 1:** MCP tools check branch and block operations
 - **Layer 2:** Agent prompts check branch and warn users
 - **Layer 3:** CLAUDE.md provides context (third layer)
 - **Rationale:** Multiple layers prevent production accidents
 ---
 ## Important Reminders
 1. **Build projman FIRST** - Don't start pmo until projman is validated
 2. **MCP servers are SHARED** - Located at `mcp-servers/`, not inside plugins
 3. **Lessons learned is critical** - Prevents repeated mistakes
 4. **Test with real work** - Validate with actual sprints, not just unit tests
 5. **Security first** - Branch detection must be 100% reliable
 6. **Keep it simple** - Avoid over-engineering, focus on proven workflow
 7. **Python 3.10+** - Minimum version requirement
 8. **Wiki.js setup** - Must run setup script before projman works
 ---
 ## Getting Help
 ### Documentation Structure
 **Need details on:**
 - Gitea integration → [MCP-GITEA.md](./MCP-GITEA.md)
 - Wiki.js integration → [MCP-WIKIJS.md](./MCP-WIKIJS.md)
 - Projman usage → [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md)
 - PMO usage → [PLUGIN-PMO.md](./PLUGIN-PMO.md)
 - Overview → This document
 ### Quick Reference
 | Question | Reference |
 |----------|-----------|
 | How do I set up configuration? | This document, "Quick Start Guide" |
 | What's the repository structure? | This document, "Repository Structure" |
 | How do Gitea tools work? | [MCP-GITEA.md](./MCP-GITEA.md) |
 | How do Wiki.js tools work? | [MCP-WIKIJS.md](./MCP-WIKIJS.md) |
 | How do I use sprint commands? | [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md#commands) |
 | How do agents work? | [PLUGIN-PROJMAN.md](./PLUGIN-PROJMAN.md#three-agent-model) |
 | How do I coordinate multiple projects? | [PLUGIN-PMO.md](./PLUGIN-PMO.md) |
 | What's the build order? | This document, "Build Order & Phases" |
 ---
 ## Project Timeline
 **Planning:** Complete ✅
 **Phase 1-8 (projman):** 6-8 weeks estimated
 **Phase 9-12 (pmo):** 2-4 weeks estimated
 **Total:** 8-12 weeks from start to production
 **Note:** No fixed deadlines - work at sustainable pace and validate thoroughly
 ---
 ## You're Ready!
 You have everything you need to build the projman and projman-pmo plugins. All architectural decisions are finalized and documented.
 **Start here:** [MCP-GITEA.md](./MCP-GITEA.md) - Set up Gitea MCP Server
 Good luck with the build! 🚀
--- a/plugins/projman/mcp-servers/gitea/README.md
+++ b/plugins/projman/mcp-servers/gitea/README.md
@@ -389,25 +389,24 @@ def list_issues(self, state='open', labels=None, repo=None):
 ## License
-Part of the Bandit Labs Claude Code Plugins project.
+MIT License - Part of the Leo Claude Marketplace project.
 ## Related Documentation
- **MCP Specification**: `docs/references/MCP-GITEA.md`
+- **Projman Documentation**: `plugins/projman/README.md`
- **Project Summary**: `docs/references/PROJECT-SUMMARY.md`
+- **Configuration Guide**: `plugins/projman/CONFIGURATION.md`
 - **Implementation Plan**: `docs/reference-material/projman-implementation-plan.md`
 - **Testing Guide**: `TESTING.md`
 ## Support
 For issues or questions:
 1. Check [TESTING.md](./TESTING.md) troubleshooting section
-2. Review [MCP-GITEA.md](../../docs/references/MCP-GITEA.md) specification
+2. Review [plugins/projman/README.md](../../README.md) for plugin documentation
 3. Create an issue in the project repository
 ---
-**Built for**: Bandit Labs Project Management Plugins
+**Built for**: Leo Claude Marketplace - Project Management Plugins
 **Phase**: 1 (Complete)
 **Status**: ✅ Production Ready
 **Last Updated**: 2025-01-06
--- a/plugins/projman/mcp-servers/gitea/TESTING.md
+++ b/plugins/projman/mcp-servers/gitea/TESTING.md
@@ -574,8 +574,8 @@ After completing testing:
 - **MCP Documentation**: https://docs.anthropic.com/claude/docs/mcp
 - **Gitea API Documentation**: https://docs.gitea.io/en-us/api-usage/
- **Project Documentation**: `docs/references/MCP-GITEA.md`
+- **Projman Documentation**: `plugins/projman/README.md`
- **Implementation Plan**: `docs/references/PROJECT-SUMMARY.md`
+- **Configuration Guide**: `plugins/projman/CONFIGURATION.md`
 ---
--- a/plugins/projman/mcp-servers/gitea/mcp_server/init.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/init.py
--- a/mcp-servers/gitea/mcp_server/config.py
+++ b/mcp-servers/gitea/mcp_server/config.py
@@ -0,0 +1,227 @@
 """
 Configuration loader for Gitea MCP Server.
 Implements hybrid configuration system:
 - System-level: ~/.config/claude/gitea.env (credentials)
 - Project-level: .env (repository specification)
 - Auto-detection: Falls back to git remote URL parsing
 """
 from pathlib import Path
 from dotenv import load_dotenv
 import os
 import re
 import subprocess
 import logging
 from typing import Dict, Optional
 logging.basicConfig(level=logging.INFO)
 logger = logging.getLogger(__name__)
 class GiteaConfig:
    """Hybrid configuration loader with mode detection"""
    def __init__(self):
        self.api_url: Optional[str] = None
        self.api_token: Optional[str] = None
        self.repo: Optional[str] = None
        self.mode: str = 'project'
    def load(self) -> Dict[str, Optional[str]]:
        """
        Load configuration from system and project levels.
        Project-level configuration overrides system-level.
        Returns:
            Dict containing api_url, api_token, repo, mode
        Raises:
            FileNotFoundError: If system config is missing
            ValueError: If required configuration is missing
        """
        # Load system config
        system_config = Path.home() / '.config' / 'claude' / 'gitea.env'
        if system_config.exists():
            load_dotenv(system_config)
            logger.info(f"Loaded system configuration from {system_config}")
        else:
            raise FileNotFoundError(
                f"System config not found: {system_config}\n"
                "Create it with: mkdir -p ~/.config/claude && "
                "cat > ~/.config/claude/gitea.env"
            )
        # Find project directory (MCP server cwd is plugin dir, not project dir)
        project_dir = self._find_project_directory()
        # Load project config (overrides system)
        if project_dir:
            project_config = project_dir / '.env'
            if project_config.exists():
                load_dotenv(project_config, override=True)
                logger.info(f"Loaded project configuration from {project_config}")
        # Extract values
        self.api_url = os.getenv('GITEA_API_URL')
        self.api_token = os.getenv('GITEA_API_TOKEN')
        self.repo = os.getenv('GITEA_REPO')  # Optional, must be owner/repo format
        # Auto-detect repo from git remote if not specified
        if not self.repo and project_dir:
            self.repo = self._detect_repo_from_git(project_dir)
            if self.repo:
                logger.info(f"Auto-detected repository from git remote: {self.repo}")
        # Detect mode
        if self.repo:
            self.mode = 'project'
            logger.info(f"Running in project mode: {self.repo}")
        else:
            self.mode = 'company'
            logger.info("Running in company-wide mode (PMO)")
        # Validate required variables
        self._validate()
        return {
            'api_url': self.api_url,
            'api_token': self.api_token,
            'repo': self.repo,
            'mode': self.mode
        }
    def _validate(self) -> None:
        """
        Validate that required configuration is present.
        Raises:
            ValueError: If required configuration is missing
        """
        required = {
            'GITEA_API_URL': self.api_url,
            'GITEA_API_TOKEN': self.api_token
        }
        missing = [key for key, value in required.items() if not value]
        if missing:
            raise ValueError(
                f"Missing required configuration: {', '.join(missing)}\n"
                "Check your ~/.config/claude/gitea.env file"
            )
    def _find_project_directory(self) -> Optional[Path]:
        """
        Find the user's project directory.
        The MCP server runs with cwd set to the plugin directory, not the
        user's project. We need to find the actual project directory using
        various heuristics.
        Returns:
            Path to project directory, or None if not found
        """
        # Strategy 1: Check CLAUDE_PROJECT_DIR environment variable
        project_dir = os.getenv('CLAUDE_PROJECT_DIR')
        if project_dir:
            path = Path(project_dir)
            if path.exists():
                logger.info(f"Found project directory from CLAUDE_PROJECT_DIR: {path}")
                return path
        # Strategy 2: Check PWD (original working directory before cwd override)
        pwd = os.getenv('PWD')
        if pwd:
            path = Path(pwd)
            # Verify it has .git or .env (indicates a project)
            if path.exists() and ((path / '.git').exists() or (path / '.env').exists()):
                logger.info(f"Found project directory from PWD: {path}")
                return path
        # Strategy 3: Check current working directory
        # This handles test scenarios and cases where cwd is actually the project
        cwd = Path.cwd()
        if (cwd / '.git').exists() or (cwd / '.env').exists():
            logger.info(f"Found project directory from cwd: {cwd}")
            return cwd
        # Strategy 4: Check if GITEA_REPO is already set (user configured it)
        # If so, we don't need to find the project directory for git detection
        if os.getenv('GITEA_REPO'):
            logger.debug("GITEA_REPO already set, skipping project directory detection")
            return None
        logger.debug("Could not determine project directory")
        return None
    def _detect_repo_from_git(self, project_dir: Optional[Path] = None) -> Optional[str]:
        """
        Auto-detect repository from git remote origin URL.
        Args:
            project_dir: Directory to run git command from (defaults to cwd)
        Supports URL formats:
        - SSH: ssh://git@host:port/owner/repo.git
        - SSH short: git@host:owner/repo.git
        - HTTPS: https://host/owner/repo.git
        - HTTP: http://host/owner/repo.git
        Returns:
            Repository in 'owner/repo' format, or None if detection fails
        """
        try:
            result = subprocess.run(
                ['git', 'remote', 'get-url', 'origin'],
                capture_output=True,
                text=True,
                timeout=5,
                cwd=str(project_dir) if project_dir else None
            )
            if result.returncode != 0:
                logger.debug("No git remote 'origin' found")
                return None
            url = result.stdout.strip()
            return self._parse_git_url(url)
        except subprocess.TimeoutExpired:
            logger.warning("Git command timed out")
            return None
        except FileNotFoundError:
            logger.debug("Git not available")
            return None
        except Exception as e:
            logger.debug(f"Failed to detect repo from git: {e}")
            return None
    def _parse_git_url(self, url: str) -> Optional[str]:
        """
        Parse git URL to extract owner/repo.
        Args:
            url: Git remote URL
        Returns:
            Repository in 'owner/repo' format, or None if parsing fails
        """
        # Remove .git suffix if present
        url = re.sub(r'\.git$', '', url)
        # SSH format: ssh://git@host:port/owner/repo
        ssh_match = re.match(r'ssh://[^/]+/(.+/.+)$', url)
        if ssh_match:
            return ssh_match.group(1)
        # SSH short format: git@host:owner/repo
        ssh_short_match = re.match(r'git@[^:]+:(.+/.+)$', url)
        if ssh_short_match:
            return ssh_short_match.group(1)
        # HTTPS/HTTP format: https://host/owner/repo
        http_match = re.match(r'https?://[^/]+/(.+/.+)$', url)
        if http_match:
            return http_match.group(1)
        logger.warning(f"Could not parse git URL: {url}")
        return None
--- a/plugins/projman/mcp-servers/gitea/mcp_server/gitea_client.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/gitea_client.py
@@ -45,7 +45,7 @@ class GiteaClient:
        """Parse owner/repo from input. Always requires 'owner/repo' format."""
        target = repo or self.repo
        if not target or '/' not in target:
-            raise ValueError("Use 'owner/repo' format (e.g. 'bandit/support-claude-mktplace')")
+            raise ValueError("Use 'owner/repo' format (e.g. 'org/repo-name')")
        parts = target.split('/', 1)
        return parts[0], parts[1]
@@ -110,8 +110,14 @@ class GiteaClient:
    def _resolve_label_ids(self, label_names: List[str], owner: str, repo: str) -> List[int]:
        """Convert label names to label IDs."""
        full_repo = f"{owner}/{repo}"
        # Only fetch org labels if repo belongs to an organization
        org_labels = []
        if self.is_org_repo(full_repo):
            org_labels = self.get_org_labels(owner)
-        repo_labels = self.get_labels(f"{owner}/{repo}")
+
        repo_labels = self.get_labels(full_repo)
        all_labels = org_labels + repo_labels
        label_map = {label['name']: label['id'] for label in all_labels}
        label_ids = []
@@ -548,10 +554,33 @@ class GiteaClient:
        return response.json()
    def is_org_repo(self, repo: Optional[str] = None) -> bool:
-        """Check if repository belongs to an organization (not a user)."""
+        """
-        info = self.get_repo_info(repo)
+        Check if repository belongs to an organization (not a user).
-        owner_type = info.get('owner', {}).get('type', '')
+
-        return owner_type.lower() == 'organization'
+        Uses the /orgs/{owner} endpoint to reliably detect organizations,
        as the owner.type field in repo info may be null in some Gitea versions.
        """
        owner, _ = self._parse_repo(repo)
        return self._is_organization(owner)
    def _is_organization(self, owner: str) -> bool:
        """
        Check if an owner is an organization by querying the orgs endpoint.
        Args:
            owner: The owner name to check
        Returns:
            True if owner is an organization, False if user or unknown
        """
        url = f"{self.base_url}/orgs/{owner}"
        try:
            response = self.session.get(url)
            # 200 = organization exists, 404 = not an organization (user account)
            return response.status_code == 200
        except Exception as e:
            logger.warning(f"Failed to check if {owner} is organization: {e}")
            return False
    def get_branch_protection(
        self,
@@ -591,3 +620,126 @@ class GiteaClient:
        response = self.session.post(url, json=data)
        response.raise_for_status()
        return response.json()
    # ========================================
    # PULL REQUEST OPERATIONS
    # ========================================
    def list_pull_requests(
        self,
        state: str = 'open',
        sort: str = 'recentupdate',
        labels: Optional[List[str]] = None,
        repo: Optional[str] = None
    ) -> List[Dict]:
        """
        List pull requests from Gitea repository.
        Args:
            state: PR state (open, closed, all)
            sort: Sort order (oldest, recentupdate, leastupdate, mostcomment, leastcomment, priority)
            labels: Filter by labels
            repo: Repository in 'owner/repo' format
        Returns:
            List of pull request dictionaries
        """
        owner, target_repo = self._parse_repo(repo)
        url = f"{self.base_url}/repos/{owner}/{target_repo}/pulls"
        params = {'state': state, 'sort': sort}
        if labels:
            params['labels'] = ','.join(labels)
        logger.info(f"Listing PRs from {owner}/{target_repo} with state={state}")
        response = self.session.get(url, params=params)
        response.raise_for_status()
        return response.json()
    def get_pull_request(
        self,
        pr_number: int,
        repo: Optional[str] = None
    ) -> Dict:
        """Get specific pull request details."""
        owner, target_repo = self._parse_repo(repo)
        url = f"{self.base_url}/repos/{owner}/{target_repo}/pulls/{pr_number}"
        logger.info(f"Getting PR #{pr_number} from {owner}/{target_repo}")
        response = self.session.get(url)
        response.raise_for_status()
        return response.json()
    def get_pr_diff(
        self,
        pr_number: int,
        repo: Optional[str] = None
    ) -> str:
        """Get the diff for a pull request."""
        owner, target_repo = self._parse_repo(repo)
        url = f"{self.base_url}/repos/{owner}/{target_repo}/pulls/{pr_number}.diff"
        logger.info(f"Getting diff for PR #{pr_number} from {owner}/{target_repo}")
        response = self.session.get(url)
        response.raise_for_status()
        return response.text
    def get_pr_comments(
        self,
        pr_number: int,
        repo: Optional[str] = None
    ) -> List[Dict]:
        """Get comments on a pull request (uses issue comments endpoint)."""
        owner, target_repo = self._parse_repo(repo)
        # PRs share comment endpoint with issues in Gitea
        url = f"{self.base_url}/repos/{owner}/{target_repo}/issues/{pr_number}/comments"
        logger.info(f"Getting comments for PR #{pr_number} from {owner}/{target_repo}")
        response = self.session.get(url)
        response.raise_for_status()
        return response.json()
    def create_pr_review(
        self,
        pr_number: int,
        body: str,
        event: str = 'COMMENT',
        comments: Optional[List[Dict]] = None,
        repo: Optional[str] = None
    ) -> Dict:
        """
        Create a review on a pull request.
        Args:
            pr_number: Pull request number
            body: Review body/summary
            event: Review action (APPROVE, REQUEST_CHANGES, COMMENT)
            comments: Optional list of inline comments with path, position, body
            repo: Repository in 'owner/repo' format
        Returns:
            Created review dictionary
        """
        owner, target_repo = self._parse_repo(repo)
        url = f"{self.base_url}/repos/{owner}/{target_repo}/pulls/{pr_number}/reviews"
        data = {
            'body': body,
            'event': event
        }
        if comments:
            data['comments'] = comments
        logger.info(f"Creating review on PR #{pr_number} in {owner}/{target_repo}")
        response = self.session.post(url, json=data)
        response.raise_for_status()
        return response.json()
    def add_pr_comment(
        self,
        pr_number: int,
        body: str,
        repo: Optional[str] = None
    ) -> Dict:
        """Add a general comment to a pull request (uses issue comment endpoint)."""
        owner, target_repo = self._parse_repo(repo)
        # PRs share comment endpoint with issues in Gitea
        url = f"{self.base_url}/repos/{owner}/{target_repo}/issues/{pr_number}/comments"
        data = {'body': body}
        logger.info(f"Adding comment to PR #{pr_number} in {owner}/{target_repo}")
        response = self.session.post(url, json=data)
        response.raise_for_status()
        return response.json()
--- a/plugins/projman/mcp-servers/gitea/mcp_server/server.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/server.py
@@ -17,6 +17,7 @@ from .tools.labels import LabelTools
 from .tools.wiki import WikiTools
 from .tools.milestones import MilestoneTools
 from .tools.dependencies import DependencyTools
 from .tools.pull_requests import PullRequestTools
 # Suppress noisy MCP validation warnings on stderr
 logging.basicConfig(level=logging.INFO)
@@ -37,6 +38,7 @@ class GiteaMCPServer:
        self.wiki_tools = None
        self.milestone_tools = None
        self.dependency_tools = None
        self.pr_tools = None
    async def initialize(self):
        """
@@ -55,6 +57,7 @@ class GiteaMCPServer:
            self.wiki_tools = WikiTools(self.client)
            self.milestone_tools = MilestoneTools(self.client)
            self.dependency_tools = DependencyTools(self.client)
            self.pr_tools = PullRequestTools(self.client)
            logger.info(f"Gitea MCP Server initialized in {self.config['mode']} mode")
        except Exception as e:
@@ -217,6 +220,10 @@ class GiteaMCPServer:
                            "context": {
                                "type": "string",
                                "description": "Issue title + description or sprint context"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        },
                        "required": ["context"]
@@ -638,6 +645,153 @@ class GiteaMCPServer:
                        },
                        "required": ["name", "color"]
                    }
                ),
                # Pull Request Tools
                Tool(
                    name="list_pull_requests",
                    description="List pull requests from repository",
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "state": {
                                "type": "string",
                                "enum": ["open", "closed", "all"],
                                "default": "open",
                                "description": "PR state filter"
                            },
                            "sort": {
                                "type": "string",
                                "enum": ["oldest", "recentupdate", "leastupdate", "mostcomment", "leastcomment", "priority"],
                                "default": "recentupdate",
                                "description": "Sort order"
                            },
                            "labels": {
                                "type": "array",
                                "items": {"type": "string"},
                                "description": "Filter by labels"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        }
                    }
                ),
                Tool(
                    name="get_pull_request",
                    description="Get specific pull request details",
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "pr_number": {
                                "type": "integer",
                                "description": "Pull request number"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        },
                        "required": ["pr_number"]
                    }
                ),
                Tool(
                    name="get_pr_diff",
                    description="Get the diff for a pull request",
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "pr_number": {
                                "type": "integer",
                                "description": "Pull request number"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        },
                        "required": ["pr_number"]
                    }
                ),
                Tool(
                    name="get_pr_comments",
                    description="Get comments on a pull request",
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "pr_number": {
                                "type": "integer",
                                "description": "Pull request number"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        },
                        "required": ["pr_number"]
                    }
                ),
                Tool(
                    name="create_pr_review",
                    description="Create a review on a pull request (approve, request changes, or comment)",
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "pr_number": {
                                "type": "integer",
                                "description": "Pull request number"
                            },
                            "body": {
                                "type": "string",
                                "description": "Review body/summary"
                            },
                            "event": {
                                "type": "string",
                                "enum": ["APPROVE", "REQUEST_CHANGES", "COMMENT"],
                                "default": "COMMENT",
                                "description": "Review action"
                            },
                            "comments": {
                                "type": "array",
                                "items": {
                                    "type": "object",
                                    "properties": {
                                        "path": {"type": "string"},
                                        "position": {"type": "integer"},
                                        "body": {"type": "string"}
                                    }
                                },
                                "description": "Optional inline comments"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        },
                        "required": ["pr_number", "body"]
                    }
                ),
                Tool(
                    name="add_pr_comment",
                    description="Add a general comment to a pull request",
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "pr_number": {
                                "type": "integer",
                                "description": "Pull request number"
                            },
                            "body": {
                                "type": "string",
                                "description": "Comment text"
                            },
                            "repo": {
                                "type": "string",
                                "description": "Repository name (owner/repo format)"
                            }
                        },
                        "required": ["pr_number", "body"]
                    }
                )
            ]
@@ -726,6 +880,19 @@ class GiteaMCPServer:
                        arguments.get('description'),
                        arguments.get('repo')
                    )
                # Pull Request tools
                elif name == "list_pull_requests":
                    result = await self.pr_tools.list_pull_requests(**arguments)
                elif name == "get_pull_request":
                    result = await self.pr_tools.get_pull_request(**arguments)
                elif name == "get_pr_diff":
                    result = await self.pr_tools.get_pr_diff(**arguments)
                elif name == "get_pr_comments":
                    result = await self.pr_tools.get_pr_comments(**arguments)
                elif name == "create_pr_review":
                    result = await self.pr_tools.create_pr_review(**arguments)
                elif name == "add_pr_comment":
                    result = await self.pr_tools.add_pr_comment(**arguments)
                else:
                    raise ValueError(f"Unknown tool: {name}")
--- a/plugins/projman/mcp-servers/gitea/mcp_server/tools/init.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/tools/init.py
@@ -4,4 +4,8 @@ MCP tools for Gitea integration.
 This package provides MCP tool implementations for:
 - Issue operations (issues.py)
 - Label management (labels.py)
 - Wiki operations (wiki.py)
 - Milestone management (milestones.py)
 - Issue dependencies (dependencies.py)
 - Pull request operations (pull_requests.py)
 """
--- a/plugins/projman/mcp-servers/gitea/mcp_server/tools/dependencies.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/tools/dependencies.py
--- a/plugins/projman/mcp-servers/gitea/mcp_server/tools/issues.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/tools/issues.py
--- a/mcp-servers/gitea/mcp_server/tools/labels.py
+++ b/mcp-servers/gitea/mcp_server/tools/labels.py
@@ -0,0 +1,261 @@
 """
 Label management tools for MCP server.
 Provides async wrappers for label operations with:
 - Label taxonomy retrieval
 - Intelligent label suggestion
 - Dynamic label detection
 """
 import asyncio
 import logging
 import re
 from typing import List, Dict, Optional
 logging.basicConfig(level=logging.INFO)
 logger = logging.getLogger(__name__)
 class LabelTools:
    """Async wrappers for Gitea label operations"""
    def __init__(self, gitea_client):
        """
        Initialize label tools.
        Args:
            gitea_client: GiteaClient instance
        """
        self.gitea = gitea_client
    async def get_labels(self, repo: Optional[str] = None) -> Dict[str, List[Dict]]:
        """Get all labels (org + repo if org-owned, repo-only if user-owned)."""
        loop = asyncio.get_event_loop()
        target_repo = repo or self.gitea.repo
        if not target_repo or '/' not in target_repo:
            raise ValueError("Use 'owner/repo' format (e.g. 'org/repo-name')")
        # Check if repo belongs to an organization or user
        is_org = await loop.run_in_executor(
            None,
            lambda: self.gitea.is_org_repo(target_repo)
        )
        org_labels = []
        if is_org:
            org = target_repo.split('/')[0]
            org_labels = await loop.run_in_executor(
                None,
                lambda: self.gitea.get_org_labels(org)
            )
        repo_labels = await loop.run_in_executor(
            None,
            lambda: self.gitea.get_labels(target_repo)
        )
        return {
            'organization': org_labels,
            'repository': repo_labels,
            'total_count': len(org_labels) + len(repo_labels)
        }
    async def suggest_labels(self, context: str, repo: Optional[str] = None) -> List[str]:
        """
        Analyze context and suggest appropriate labels from repository's actual labels.
        This method fetches actual labels from the repository and matches them
        dynamically, supporting any label naming convention (slash, colon-space, etc.).
        Args:
            context: Issue title + description or sprint context
            repo: Repository in 'owner/repo' format (optional, uses default if not provided)
        Returns:
            List of suggested label names that exist in the repository
        """
        # Fetch actual labels from repository
        target_repo = repo or self.gitea.repo
        if not target_repo:
            logger.warning("No repository specified, returning empty suggestions")
            return []
        try:
            labels_data = await self.get_labels(target_repo)
            all_labels = labels_data.get('organization', []) + labels_data.get('repository', [])
            label_names = [label['name'] for label in all_labels]
        except Exception as e:
            logger.warning(f"Failed to fetch labels: {e}. Using fallback suggestions.")
            label_names = []
        # Build label lookup for dynamic matching
        label_lookup = self._build_label_lookup(label_names)
        suggested = []
        context_lower = context.lower()
        # Type detection (exclusive - only one)
        type_label = None
        if any(word in context_lower for word in ['bug', 'error', 'fix', 'broken', 'crash', 'fail']):
            type_label = self._find_label(label_lookup, 'type', 'bug')
        elif any(word in context_lower for word in ['refactor', 'extract', 'restructure', 'architecture', 'service extraction']):
            type_label = self._find_label(label_lookup, 'type', 'refactor')
        elif any(word in context_lower for word in ['feature', 'add', 'implement', 'new', 'create']):
            type_label = self._find_label(label_lookup, 'type', 'feature')
        elif any(word in context_lower for word in ['docs', 'documentation', 'readme', 'guide']):
            type_label = self._find_label(label_lookup, 'type', 'documentation')
        elif any(word in context_lower for word in ['test', 'testing', 'spec', 'coverage']):
            type_label = self._find_label(label_lookup, 'type', 'test')
        elif any(word in context_lower for word in ['chore', 'maintenance', 'update', 'upgrade']):
            type_label = self._find_label(label_lookup, 'type', 'chore')
        if type_label:
            suggested.append(type_label)
        # Priority detection
        priority_label = None
        if any(word in context_lower for word in ['critical', 'urgent', 'blocker', 'blocking', 'emergency']):
            priority_label = self._find_label(label_lookup, 'priority', 'critical')
        elif any(word in context_lower for word in ['high', 'important', 'asap', 'soon']):
            priority_label = self._find_label(label_lookup, 'priority', 'high')
        elif any(word in context_lower for word in ['low', 'nice-to-have', 'optional', 'later']):
            priority_label = self._find_label(label_lookup, 'priority', 'low')
        else:
            priority_label = self._find_label(label_lookup, 'priority', 'medium')
        if priority_label:
            suggested.append(priority_label)
        # Complexity detection
        complexity_label = None
        if any(word in context_lower for word in ['simple', 'trivial', 'easy', 'quick']):
            complexity_label = self._find_label(label_lookup, 'complexity', 'simple')
        elif any(word in context_lower for word in ['complex', 'difficult', 'challenging', 'intricate']):
            complexity_label = self._find_label(label_lookup, 'complexity', 'complex')
        else:
            complexity_label = self._find_label(label_lookup, 'complexity', 'medium')
        if complexity_label:
            suggested.append(complexity_label)
        # Effort detection (supports both "Effort" and "Efforts" naming)
        effort_label = None
        if any(word in context_lower for word in ['xs', 'tiny', '1 hour', '2 hours']):
            effort_label = self._find_label(label_lookup, 'effort', 'xs')
        elif any(word in context_lower for word in ['small', 's ', '1 day', 'half day']):
            effort_label = self._find_label(label_lookup, 'effort', 's')
        elif any(word in context_lower for word in ['medium', 'm ', '2 days', '3 days']):
            effort_label = self._find_label(label_lookup, 'effort', 'm')
        elif any(word in context_lower for word in ['large', 'l ', '1 week', '5 days']):
            effort_label = self._find_label(label_lookup, 'effort', 'l')
        elif any(word in context_lower for word in ['xl', 'extra large', '2 weeks', 'sprint']):
            effort_label = self._find_label(label_lookup, 'effort', 'xl')
        if effort_label:
            suggested.append(effort_label)
        # Component detection (based on keywords)
        component_mappings = {
            'backend': ['backend', 'server', 'api', 'database', 'service'],
            'frontend': ['frontend', 'ui', 'interface', 'react', 'vue', 'component'],
            'api': ['api', 'endpoint', 'rest', 'graphql', 'route'],
            'database': ['database', 'db', 'sql', 'migration', 'schema', 'postgres'],
            'auth': ['auth', 'authentication', 'login', 'oauth', 'token', 'session'],
            'deploy': ['deploy', 'deployment', 'docker', 'kubernetes', 'ci/cd'],
            'testing': ['test', 'testing', 'spec', 'jest', 'pytest', 'coverage'],
            'docs': ['docs', 'documentation', 'readme', 'guide', 'wiki']
        }
        for component, keywords in component_mappings.items():
            if any(keyword in context_lower for keyword in keywords):
                label = self._find_label(label_lookup, 'component', component)
                if label and label not in suggested:
                    suggested.append(label)
        # Tech stack detection
        tech_mappings = {
            'python': ['python', 'fastapi', 'django', 'flask', 'pytest'],
            'javascript': ['javascript', 'js', 'node', 'npm', 'yarn'],
            'docker': ['docker', 'dockerfile', 'container', 'compose'],
            'postgresql': ['postgres', 'postgresql', 'psql', 'sql'],
            'redis': ['redis', 'cache', 'session store'],
            'vue': ['vue', 'vuejs', 'nuxt'],
            'fastapi': ['fastapi', 'pydantic', 'starlette']
        }
        for tech, keywords in tech_mappings.items():
            if any(keyword in context_lower for keyword in keywords):
                label = self._find_label(label_lookup, 'tech', tech)
                if label and label not in suggested:
                    suggested.append(label)
        # Source detection (based on git branch or context)
        source_label = None
        if 'development' in context_lower or 'dev/' in context_lower:
            source_label = self._find_label(label_lookup, 'source', 'development')
        elif 'staging' in context_lower or 'stage/' in context_lower:
            source_label = self._find_label(label_lookup, 'source', 'staging')
        elif 'production' in context_lower or 'prod' in context_lower:
            source_label = self._find_label(label_lookup, 'source', 'production')
        if source_label:
            suggested.append(source_label)
        # Risk detection
        risk_label = None
        if any(word in context_lower for word in ['breaking', 'breaking change', 'major', 'risky']):
            risk_label = self._find_label(label_lookup, 'risk', 'high')
        elif any(word in context_lower for word in ['safe', 'low risk', 'minor']):
            risk_label = self._find_label(label_lookup, 'risk', 'low')
        if risk_label:
            suggested.append(risk_label)
        logger.info(f"Suggested {len(suggested)} labels based on context and {len(label_names)} available labels")
        return suggested
    def _build_label_lookup(self, label_names: List[str]) -> Dict[str, Dict[str, str]]:
        """
        Build a lookup dictionary for label matching.
        Supports various label formats:
        - Slash format: Type/Bug, Priority/High
        - Colon-space format: Type: Bug, Priority: High
        - Colon format: Type:Bug
        Args:
            label_names: List of actual label names from repository
        Returns:
            Nested dict: {category: {value: actual_label_name}}
        """
        lookup: Dict[str, Dict[str, str]] = {}
        for label in label_names:
            # Try different separator patterns
            # Pattern: Category<separator>Value
            # Separators: /, : , :
            match = re.match(r'^([^/:]+)(?:/|:\s*|:)(.+)$', label)
            if match:
                category = match.group(1).lower().rstrip('s')  # Normalize: "Efforts" -> "effort"
                value = match.group(2).lower()
                if category not in lookup:
                    lookup[category] = {}
                lookup[category][value] = label
        return lookup
    def _find_label(self, lookup: Dict[str, Dict[str, str]], category: str, value: str) -> Optional[str]:
        """
        Find actual label name from lookup.
        Args:
            lookup: Label lookup dictionary
            category: Category to search (e.g., 'type', 'priority')
            value: Value to find (e.g., 'bug', 'high')
        Returns:
            Actual label name if found, None otherwise
        """
        category_lower = category.lower().rstrip('s')  # Normalize
        value_lower = value.lower()
        if category_lower in lookup and value_lower in lookup[category_lower]:
            return lookup[category_lower][value_lower]
        return None
--- a/plugins/projman/mcp-servers/gitea/mcp_server/tools/milestones.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/tools/milestones.py
--- a/mcp-servers/gitea/mcp_server/tools/pull_requests.py
+++ b/mcp-servers/gitea/mcp_server/tools/pull_requests.py
@@ -0,0 +1,274 @@
 """
 Pull request management tools for MCP server.
 Provides async wrappers for PR operations with:
 - Branch-aware security
 - PMO multi-repo support
 - Comprehensive error handling
 """
 import asyncio
 import subprocess
 import logging
 from typing import List, Dict, Optional
 logging.basicConfig(level=logging.INFO)
 logger = logging.getLogger(__name__)
 class PullRequestTools:
    """Async wrappers for Gitea pull request operations with branch detection"""
    def __init__(self, gitea_client):
        """
        Initialize pull request tools.
        Args:
            gitea_client: GiteaClient instance
        """
        self.gitea = gitea_client
    def _get_current_branch(self) -> str:
        """
        Get current git branch.
        Returns:
            Current branch name or 'unknown' if not in a git repo
        """
        try:
            result = subprocess.run(
                ['git', 'rev-parse', '--abbrev-ref', 'HEAD'],
                capture_output=True,
                text=True,
                check=True
            )
            return result.stdout.strip()
        except subprocess.CalledProcessError:
            return "unknown"
    def _check_branch_permissions(self, operation: str) -> bool:
        """
        Check if operation is allowed on current branch.
        Args:
            operation: Operation name (list_prs, create_review, etc.)
        Returns:
            True if operation is allowed, False otherwise
        """
        branch = self._get_current_branch()
        # Read-only operations allowed everywhere
        read_ops = ['list_pull_requests', 'get_pull_request', 'get_pr_diff', 'get_pr_comments']
        # Production branches (read-only)
        if branch in ['main', 'master'] or branch.startswith('prod/'):
            return operation in read_ops
        # Staging branches (read-only for PRs, can comment)
        if branch == 'staging' or branch.startswith('stage/'):
            return operation in read_ops + ['add_pr_comment']
        # Development branches (full access)
        if branch in ['development', 'develop'] or branch.startswith(('feat/', 'feature/', 'dev/')):
            return True
        # Unknown branch - be restrictive
        return operation in read_ops
    async def list_pull_requests(
        self,
        state: str = 'open',
        sort: str = 'recentupdate',
        labels: Optional[List[str]] = None,
        repo: Optional[str] = None
    ) -> List[Dict]:
        """
        List pull requests from repository (async wrapper).
        Args:
            state: PR state (open, closed, all)
            sort: Sort order
            labels: Filter by labels
            repo: Override configured repo (for PMO multi-repo)
        Returns:
            List of pull request dictionaries
        Raises:
            PermissionError: If operation not allowed on current branch
        """
        if not self._check_branch_permissions('list_pull_requests'):
            branch = self._get_current_branch()
            raise PermissionError(
                f"Cannot list PRs on branch '{branch}'. "
                f"Switch to a development branch."
            )
        loop = asyncio.get_event_loop()
        return await loop.run_in_executor(
            None,
            lambda: self.gitea.list_pull_requests(state, sort, labels, repo)
        )
    async def get_pull_request(
        self,
        pr_number: int,
        repo: Optional[str] = None
    ) -> Dict:
        """
        Get specific pull request details (async wrapper).
        Args:
            pr_number: Pull request number
            repo: Override configured repo (for PMO multi-repo)
        Returns:
            Pull request dictionary
        Raises:
            PermissionError: If operation not allowed on current branch
        """
        if not self._check_branch_permissions('get_pull_request'):
            branch = self._get_current_branch()
            raise PermissionError(
                f"Cannot get PR on branch '{branch}'. "
                f"Switch to a development branch."
            )
        loop = asyncio.get_event_loop()
        return await loop.run_in_executor(
            None,
            lambda: self.gitea.get_pull_request(pr_number, repo)
        )
    async def get_pr_diff(
        self,
        pr_number: int,
        repo: Optional[str] = None
    ) -> str:
        """
        Get pull request diff (async wrapper).
        Args:
            pr_number: Pull request number
            repo: Override configured repo (for PMO multi-repo)
        Returns:
            Diff as string
        Raises:
            PermissionError: If operation not allowed on current branch
        """
        if not self._check_branch_permissions('get_pr_diff'):
            branch = self._get_current_branch()
            raise PermissionError(
                f"Cannot get PR diff on branch '{branch}'. "
                f"Switch to a development branch."
            )
        loop = asyncio.get_event_loop()
        return await loop.run_in_executor(
            None,
            lambda: self.gitea.get_pr_diff(pr_number, repo)
        )
    async def get_pr_comments(
        self,
        pr_number: int,
        repo: Optional[str] = None
    ) -> List[Dict]:
        """
        Get comments on a pull request (async wrapper).
        Args:
            pr_number: Pull request number
            repo: Override configured repo (for PMO multi-repo)
        Returns:
            List of comment dictionaries
        Raises:
            PermissionError: If operation not allowed on current branch
        """
        if not self._check_branch_permissions('get_pr_comments'):
            branch = self._get_current_branch()
            raise PermissionError(
                f"Cannot get PR comments on branch '{branch}'. "
                f"Switch to a development branch."
            )
        loop = asyncio.get_event_loop()
        return await loop.run_in_executor(
            None,
            lambda: self.gitea.get_pr_comments(pr_number, repo)
        )
    async def create_pr_review(
        self,
        pr_number: int,
        body: str,
        event: str = 'COMMENT',
        comments: Optional[List[Dict]] = None,
        repo: Optional[str] = None
    ) -> Dict:
        """
        Create a review on a pull request (async wrapper with branch check).
        Args:
            pr_number: Pull request number
            body: Review body/summary
            event: Review action (APPROVE, REQUEST_CHANGES, COMMENT)
            comments: Optional list of inline comments
            repo: Override configured repo (for PMO multi-repo)
        Returns:
            Created review dictionary
        Raises:
            PermissionError: If operation not allowed on current branch
        """
        if not self._check_branch_permissions('create_pr_review'):
            branch = self._get_current_branch()
            raise PermissionError(
                f"Cannot create PR review on branch '{branch}'. "
                f"Switch to a development branch to review PRs."
            )
        loop = asyncio.get_event_loop()
        return await loop.run_in_executor(
            None,
            lambda: self.gitea.create_pr_review(pr_number, body, event, comments, repo)
        )
    async def add_pr_comment(
        self,
        pr_number: int,
        body: str,
        repo: Optional[str] = None
    ) -> Dict:
        """
        Add a general comment to a pull request (async wrapper with branch check).
        Args:
            pr_number: Pull request number
            body: Comment text
            repo: Override configured repo (for PMO multi-repo)
        Returns:
            Created comment dictionary
        Raises:
            PermissionError: If operation not allowed on current branch
        """
        if not self._check_branch_permissions('add_pr_comment'):
            branch = self._get_current_branch()
            raise PermissionError(
                f"Cannot add PR comment on branch '{branch}'. "
                f"Switch to a development or staging branch to comment on PRs."
            )
        loop = asyncio.get_event_loop()
        return await loop.run_in_executor(
            None,
            lambda: self.gitea.add_pr_comment(pr_number, body, repo)
        )
--- a/plugins/projman/mcp-servers/gitea/mcp_server/tools/wiki.py
+++ b/plugins/projman/mcp-servers/gitea/mcp_server/tools/wiki.py
--- a/plugins/projman/mcp-servers/gitea/requirements.txt
+++ b/plugins/projman/mcp-servers/gitea/requirements.txt
--- a/plugins/projman/mcp-servers/gitea/tests/init.py
+++ b/plugins/projman/mcp-servers/gitea/tests/init.py
--- a/plugins/projman/mcp-servers/gitea/tests/test_config.py
+++ b/plugins/projman/mcp-servers/gitea/tests/test_config.py
@@ -149,3 +149,112 @@ def test_mode_detection_company(tmp_path, monkeypatch):
    assert result['mode'] == 'company'
    assert result['repo'] is None
 # ========================================
 # GIT URL PARSING TESTS
 # ========================================
 def test_parse_git_url_ssh_format():
    """Test parsing SSH format git URL"""
    config = GiteaConfig()
    # SSH with port: ssh://git@host:port/owner/repo.git
    url = "ssh://git@hotserv.tailc9b278.ts.net:2222/personal-projects/personal-portfolio.git"
    result = config._parse_git_url(url)
    assert result == "personal-projects/personal-portfolio"
 def test_parse_git_url_ssh_short_format():
    """Test parsing SSH short format git URL"""
    config = GiteaConfig()
    # SSH short: git@host:owner/repo.git
    url = "git@github.com:owner/repo.git"
    result = config._parse_git_url(url)
    assert result == "owner/repo"
 def test_parse_git_url_https_format():
    """Test parsing HTTPS format git URL"""
    config = GiteaConfig()
    # HTTPS: https://host/owner/repo.git
    url = "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git"
    result = config._parse_git_url(url)
    assert result == "personal-projects/leo-claude-mktplace"
 def test_parse_git_url_http_format():
    """Test parsing HTTP format git URL"""
    config = GiteaConfig()
    # HTTP: http://host/owner/repo.git
    url = "http://gitea.hotserv.cloud/personal-projects/repo.git"
    result = config._parse_git_url(url)
    assert result == "personal-projects/repo"
 def test_parse_git_url_without_git_suffix():
    """Test parsing git URL without .git suffix"""
    config = GiteaConfig()
    url = "https://github.com/owner/repo"
    result = config._parse_git_url(url)
    assert result == "owner/repo"
 def test_parse_git_url_invalid_format():
    """Test parsing invalid git URL returns None"""
    config = GiteaConfig()
    url = "not-a-valid-url"
    result = config._parse_git_url(url)
    assert result is None
 def test_find_project_directory_from_env(tmp_path, monkeypatch):
    """Test finding project directory from CLAUDE_PROJECT_DIR env var"""
    project_dir = tmp_path / 'my-project'
    project_dir.mkdir()
    (project_dir / '.git').mkdir()
    monkeypatch.setenv('CLAUDE_PROJECT_DIR', str(project_dir))
    config = GiteaConfig()
    result = config._find_project_directory()
    assert result == project_dir
 def test_find_project_directory_from_cwd(tmp_path, monkeypatch):
    """Test finding project directory from cwd with .env file"""
    project_dir = tmp_path / 'project'
    project_dir.mkdir()
    (project_dir / '.env').write_text("GITEA_REPO=test/repo")
    monkeypatch.chdir(project_dir)
    # Clear env vars that might interfere
    monkeypatch.delenv('CLAUDE_PROJECT_DIR', raising=False)
    monkeypatch.delenv('PWD', raising=False)
    config = GiteaConfig()
    result = config._find_project_directory()
    assert result == project_dir
 def test_find_project_directory_none_when_no_markers(tmp_path, monkeypatch):
    """Test returns None when no project markers found"""
    empty_dir = tmp_path / 'empty'
    empty_dir.mkdir()
    monkeypatch.chdir(empty_dir)
    monkeypatch.delenv('CLAUDE_PROJECT_DIR', raising=False)
    monkeypatch.delenv('PWD', raising=False)
    monkeypatch.delenv('GITEA_REPO', raising=False)
    config = GiteaConfig()
    result = config._find_project_directory()
    assert result is None
--- a/plugins/projman/mcp-servers/gitea/tests/test_gitea_client.py
+++ b/plugins/projman/mcp-servers/gitea/tests/test_gitea_client.py
@@ -222,3 +222,47 @@ def test_no_repo_specified_error(gitea_client):
            client.list_issues()
        assert "Repository not specified" in str(exc_info.value)
 # ========================================
 # ORGANIZATION DETECTION TESTS
 # ========================================
 def test_is_organization_true(gitea_client):
    """Test _is_organization returns True for valid organization"""
    mock_response = Mock()
    mock_response.status_code = 200
    with patch.object(gitea_client.session, 'get', return_value=mock_response):
        result = gitea_client._is_organization('personal-projects')
        assert result is True
        gitea_client.session.get.assert_called_once_with(
            'https://test.com/api/v1/orgs/personal-projects'
        )
 def test_is_organization_false(gitea_client):
    """Test _is_organization returns False for user account"""
    mock_response = Mock()
    mock_response.status_code = 404
    with patch.object(gitea_client.session, 'get', return_value=mock_response):
        result = gitea_client._is_organization('lmiranda')
        assert result is False
 def test_is_org_repo_uses_orgs_endpoint(gitea_client):
    """Test is_org_repo uses /orgs endpoint instead of owner.type"""
    mock_response = Mock()
    mock_response.status_code = 200
    with patch.object(gitea_client.session, 'get', return_value=mock_response):
        result = gitea_client.is_org_repo('personal-projects/repo')
        assert result is True
        # Should call /orgs/personal-projects, not /repos/.../
        gitea_client.session.get.assert_called_once_with(
            'https://test.com/api/v1/orgs/personal-projects'
        )
--- a/plugins/projman/mcp-servers/gitea/tests/test_issues.py
+++ b/plugins/projman/mcp-servers/gitea/tests/test_issues.py
--- a/mcp-servers/gitea/tests/test_labels.py
+++ b/mcp-servers/gitea/tests/test_labels.py
@@ -0,0 +1,478 @@
 """
 Unit tests for label tools with suggestion logic.
 """
 import pytest
 from unittest.mock import Mock, patch
 from mcp_server.tools.labels import LabelTools
@pytest.fixture
 def mock_gitea_client():
    """Fixture providing mocked Gitea client"""
    client = Mock()
    client.repo = 'test_org/test_repo'
    client.is_org_repo = Mock(return_value=True)
    return client
@pytest.fixture
 def label_tools(mock_gitea_client):
    """Fixture providing LabelTools instance"""
    return LabelTools(mock_gitea_client)
@pytest.mark.asyncio
 async def test_get_labels(label_tools):
    """Test getting all labels (org + repo)"""
    label_tools.gitea.get_org_labels = Mock(return_value=[
        {'name': 'Type/Bug'},
        {'name': 'Type/Feature'}
    ])
    label_tools.gitea.get_labels = Mock(return_value=[
        {'name': 'Component/Backend'},
        {'name': 'Component/Frontend'}
    ])
    result = await label_tools.get_labels()
    assert len(result['organization']) == 2
    assert len(result['repository']) == 2
    assert result['total_count'] == 4
 # ========================================
 # LABEL LOOKUP TESTS (NEW)
 # ========================================
 def test_build_label_lookup_slash_format():
    """Test building label lookup with slash format labels"""
    mock_client = Mock()
    mock_client.repo = 'test/repo'
    tools = LabelTools(mock_client)
    labels = ['Type/Bug', 'Type/Feature', 'Priority/High', 'Priority/Low']
    lookup = tools._build_label_lookup(labels)
    assert 'type' in lookup
    assert 'bug' in lookup['type']
    assert lookup['type']['bug'] == 'Type/Bug'
    assert lookup['type']['feature'] == 'Type/Feature'
    assert 'priority' in lookup
    assert lookup['priority']['high'] == 'Priority/High'
 def test_build_label_lookup_colon_space_format():
    """Test building label lookup with colon-space format labels"""
    mock_client = Mock()
    mock_client.repo = 'test/repo'
    tools = LabelTools(mock_client)
    labels = ['Type: Bug', 'Type: Feature', 'Priority: High', 'Effort: M']
    lookup = tools._build_label_lookup(labels)
    assert 'type' in lookup
    assert 'bug' in lookup['type']
    assert lookup['type']['bug'] == 'Type: Bug'
    assert lookup['type']['feature'] == 'Type: Feature'
    assert 'priority' in lookup
    assert lookup['priority']['high'] == 'Priority: High'
    # Test singular "Effort" (not "Efforts")
    assert 'effort' in lookup
    assert lookup['effort']['m'] == 'Effort: M'
 def test_build_label_lookup_efforts_normalization():
    """Test that 'Efforts' is normalized to 'effort' for matching"""
    mock_client = Mock()
    mock_client.repo = 'test/repo'
    tools = LabelTools(mock_client)
    labels = ['Efforts/XS', 'Efforts/S', 'Efforts/M']
    lookup = tools._build_label_lookup(labels)
    # 'Efforts' should be normalized to 'effort'
    assert 'effort' in lookup
    assert lookup['effort']['xs'] == 'Efforts/XS'
 def test_find_label():
    """Test finding labels from lookup"""
    mock_client = Mock()
    mock_client.repo = 'test/repo'
    tools = LabelTools(mock_client)
    lookup = {
        'type': {'bug': 'Type: Bug', 'feature': 'Type: Feature'},
        'priority': {'high': 'Priority: High', 'low': 'Priority: Low'}
    }
    assert tools._find_label(lookup, 'type', 'bug') == 'Type: Bug'
    assert tools._find_label(lookup, 'priority', 'high') == 'Priority: High'
    assert tools._find_label(lookup, 'type', 'nonexistent') is None
    assert tools._find_label(lookup, 'nonexistent', 'bug') is None
 # ========================================
 # SUGGEST LABELS WITH DYNAMIC FORMAT TESTS
 # ========================================
 def _create_tools_with_labels(labels):
    """Helper to create LabelTools with mocked labels"""
    import asyncio
    mock_client = Mock()
    mock_client.repo = 'test/repo'
    mock_client.is_org_repo = Mock(return_value=False)
    mock_client.get_labels = Mock(return_value=[{'name': l} for l in labels])
    return LabelTools(mock_client)
@pytest.mark.asyncio
 async def test_suggest_labels_with_slash_format():
    """Test label suggestion with slash format labels"""
    labels = [
        'Type/Bug', 'Type/Feature', 'Type/Refactor',
        'Priority/Critical', 'Priority/High', 'Priority/Medium', 'Priority/Low',
        'Complexity/Simple', 'Complexity/Medium', 'Complexity/Complex',
        'Component/Auth'
    ]
    tools = _create_tools_with_labels(labels)
    context = "Fix critical bug in login authentication"
    suggestions = await tools.suggest_labels(context)
    assert 'Type/Bug' in suggestions
    assert 'Priority/Critical' in suggestions
    assert 'Component/Auth' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_with_colon_space_format():
    """Test label suggestion with colon-space format labels"""
    labels = [
        'Type: Bug', 'Type: Feature', 'Type: Refactor',
        'Priority: Critical', 'Priority: High', 'Priority: Medium', 'Priority: Low',
        'Complexity: Simple', 'Complexity: Medium', 'Complexity: Complex',
        'Effort: XS', 'Effort: S', 'Effort: M', 'Effort: L', 'Effort: XL'
    ]
    tools = _create_tools_with_labels(labels)
    context = "Fix critical bug for tiny 1 hour fix"
    suggestions = await tools.suggest_labels(context)
    # Should return colon-space format labels
    assert 'Type: Bug' in suggestions
    assert 'Priority: Critical' in suggestions
    assert 'Effort: XS' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_bug():
    """Test label suggestion for bug context"""
    labels = [
        'Type/Bug', 'Type/Feature',
        'Priority/Critical', 'Priority/High', 'Priority/Medium', 'Priority/Low',
        'Complexity/Simple', 'Complexity/Medium', 'Complexity/Complex',
        'Component/Auth'
    ]
    tools = _create_tools_with_labels(labels)
    context = "Fix critical bug in login authentication"
    suggestions = await tools.suggest_labels(context)
    assert 'Type/Bug' in suggestions
    assert 'Priority/Critical' in suggestions
    assert 'Component/Auth' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_feature():
    """Test label suggestion for feature context"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Medium']
    tools = _create_tools_with_labels(labels)
    context = "Add new feature to implement user dashboard"
    suggestions = await tools.suggest_labels(context)
    assert 'Type/Feature' in suggestions
    assert any('Priority' in label for label in suggestions)
@pytest.mark.asyncio
 async def test_suggest_labels_refactor():
    """Test label suggestion for refactor context"""
    labels = ['Type/Refactor', 'Priority/Medium', 'Complexity/Medium', 'Component/Backend']
    tools = _create_tools_with_labels(labels)
    context = "Refactor architecture to extract service layer"
    suggestions = await tools.suggest_labels(context)
    assert 'Type/Refactor' in suggestions
    assert 'Component/Backend' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_documentation():
    """Test label suggestion for documentation context"""
    labels = ['Type/Documentation', 'Priority/Medium', 'Complexity/Medium', 'Component/API', 'Component/Docs']
    tools = _create_tools_with_labels(labels)
    context = "Update documentation for API endpoints"
    suggestions = await tools.suggest_labels(context)
    assert 'Type/Documentation' in suggestions
    assert 'Component/API' in suggestions or 'Component/Docs' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_priority():
    """Test priority detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Critical', 'Priority/High', 'Priority/Medium', 'Priority/Low', 'Complexity/Medium']
    tools = _create_tools_with_labels(labels)
    # Critical priority
    context = "Urgent blocker in production"
    suggestions = await tools.suggest_labels(context)
    assert 'Priority/Critical' in suggestions
    # High priority
    context = "Important feature needed asap"
    suggestions = await tools.suggest_labels(context)
    assert 'Priority/High' in suggestions
    # Low priority
    context = "Nice-to-have optional improvement"
    suggestions = await tools.suggest_labels(context)
    assert 'Priority/Low' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_complexity():
    """Test complexity detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Simple', 'Complexity/Medium', 'Complexity/Complex']
    tools = _create_tools_with_labels(labels)
    # Simple complexity
    context = "Simple quick fix for typo"
    suggestions = await tools.suggest_labels(context)
    assert 'Complexity/Simple' in suggestions
    # Complex complexity
    context = "Complex challenging architecture redesign"
    suggestions = await tools.suggest_labels(context)
    assert 'Complexity/Complex' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_efforts():
    """Test efforts detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Medium', 'Efforts/XS', 'Efforts/S', 'Efforts/M', 'Efforts/L', 'Efforts/XL']
    tools = _create_tools_with_labels(labels)
    # XS effort
    context = "Tiny fix that takes 1 hour"
    suggestions = await tools.suggest_labels(context)
    assert 'Efforts/XS' in suggestions
    # L effort
    context = "Large feature taking 1 week"
    suggestions = await tools.suggest_labels(context)
    assert 'Efforts/L' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_components():
    """Test component detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Medium', 'Component/Backend', 'Component/Frontend', 'Component/API', 'Component/Database']
    tools = _create_tools_with_labels(labels)
    # Backend component
    context = "Update backend API service"
    suggestions = await tools.suggest_labels(context)
    assert 'Component/Backend' in suggestions
    assert 'Component/API' in suggestions
    # Frontend component
    context = "Fix frontend UI component"
    suggestions = await tools.suggest_labels(context)
    assert 'Component/Frontend' in suggestions
    # Database component
    context = "Add database migration for schema"
    suggestions = await tools.suggest_labels(context)
    assert 'Component/Database' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_tech_stack():
    """Test tech stack detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Medium', 'Tech/Python', 'Tech/FastAPI', 'Tech/Docker', 'Tech/PostgreSQL']
    tools = _create_tools_with_labels(labels)
    # Python
    context = "Update Python FastAPI endpoint"
    suggestions = await tools.suggest_labels(context)
    assert 'Tech/Python' in suggestions
    assert 'Tech/FastAPI' in suggestions
    # Docker
    context = "Fix Dockerfile configuration"
    suggestions = await tools.suggest_labels(context)
    assert 'Tech/Docker' in suggestions
    # PostgreSQL
    context = "Optimize PostgreSQL query"
    suggestions = await tools.suggest_labels(context)
    assert 'Tech/PostgreSQL' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_source():
    """Test source detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Medium', 'Source/Development', 'Source/Staging', 'Source/Production']
    tools = _create_tools_with_labels(labels)
    # Development
    context = "Issue found in development environment"
    suggestions = await tools.suggest_labels(context)
    assert 'Source/Development' in suggestions
    # Production
    context = "Critical production issue"
    suggestions = await tools.suggest_labels(context)
    assert 'Source/Production' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_risk():
    """Test risk detection in suggestions"""
    labels = ['Type/Feature', 'Priority/Medium', 'Complexity/Medium', 'Risk/High', 'Risk/Low']
    tools = _create_tools_with_labels(labels)
    # High risk
    context = "Breaking change to major API"
    suggestions = await tools.suggest_labels(context)
    assert 'Risk/High' in suggestions
    # Low risk
    context = "Safe minor update with low risk"
    suggestions = await tools.suggest_labels(context)
    assert 'Risk/Low' in suggestions
@pytest.mark.asyncio
 async def test_suggest_labels_multiple_categories():
    """Test that suggestions span multiple categories"""
    labels = [
        'Type/Bug', 'Type/Feature',
        'Priority/Critical', 'Priority/Medium',
        'Complexity/Complex', 'Complexity/Medium',
        'Component/Backend', 'Component/API', 'Component/Auth',
        'Tech/FastAPI', 'Tech/PostgreSQL',
        'Source/Production'
    ]
    tools = _create_tools_with_labels(labels)
    context = """
    Urgent critical bug in production backend API service.
    Need to fix broken authentication endpoint.
    This is a complex issue requiring FastAPI and PostgreSQL expertise.
    """
    suggestions = await tools.suggest_labels(context)
    # Should have Type
    assert any('Type/' in label for label in suggestions)
    # Should have Priority
    assert any('Priority/' in label for label in suggestions)
    # Should have Component
    assert any('Component/' in label for label in suggestions)
    # Should have Tech
    assert any('Tech/' in label for label in suggestions)
    # Should have Source
    assert any('Source/' in label for label in suggestions)
@pytest.mark.asyncio
 async def test_suggest_labels_empty_repo():
    """Test suggestions when no repo specified and no labels available"""
    mock_client = Mock()
    mock_client.repo = None
    tools = LabelTools(mock_client)
    context = "Fix a bug"
    suggestions = await tools.suggest_labels(context)
    # Should return empty list when no repo
    assert suggestions == []
@pytest.mark.asyncio
 async def test_suggest_labels_no_matching_labels():
    """Test suggestions return empty when no matching labels exist"""
    labels = ['Custom/Label', 'Other/Thing']  # No standard labels
    tools = _create_tools_with_labels(labels)
    context = "Fix a bug"
    suggestions = await tools.suggest_labels(context)
    # Should return empty list since no Type/Bug or similar exists
    assert len(suggestions) == 0
@pytest.mark.asyncio
 async def test_get_labels_org_owned_repo():
    """Test getting labels for organization-owned repository"""
    mock_client = Mock()
    mock_client.repo = 'myorg/myrepo'
    mock_client.is_org_repo = Mock(return_value=True)
    mock_client.get_org_labels = Mock(return_value=[
        {'name': 'Type/Bug', 'id': 1},
        {'name': 'Type/Feature', 'id': 2}
    ])
    mock_client.get_labels = Mock(return_value=[
        {'name': 'Component/Backend', 'id': 3}
    ])
    tools = LabelTools(mock_client)
    result = await tools.get_labels()
    # Should fetch both org and repo labels
    mock_client.is_org_repo.assert_called_once_with('myorg/myrepo')
    mock_client.get_org_labels.assert_called_once_with('myorg')
    mock_client.get_labels.assert_called_once_with('myorg/myrepo')
    assert len(result['organization']) == 2
    assert len(result['repository']) == 1
    assert result['total_count'] == 3
@pytest.mark.asyncio
 async def test_get_labels_user_owned_repo():
    """Test getting labels for user-owned repository (no org labels)"""
    mock_client = Mock()
    mock_client.repo = 'lmiranda/personal-portfolio'
    mock_client.is_org_repo = Mock(return_value=False)
    mock_client.get_labels = Mock(return_value=[
        {'name': 'bug', 'id': 1},
        {'name': 'enhancement', 'id': 2}
    ])
    tools = LabelTools(mock_client)
    result = await tools.get_labels()
    # Should check if org repo
    mock_client.is_org_repo.assert_called_once_with('lmiranda/personal-portfolio')
    # Should NOT call get_org_labels for user-owned repos
    mock_client.get_org_labels.assert_not_called()
    # Should still get repo labels
    mock_client.get_labels.assert_called_once_with('lmiranda/personal-portfolio')
    assert len(result['organization']) == 0
    assert len(result['repository']) == 2
    assert result['total_count'] == 2
--- a/plugins/cmdb-assistant/mcp-servers/netbox/README.md
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/README.md
@@ -294,4 +294,4 @@ logging.basicConfig(level=logging.DEBUG)
 ## License
-Part of the Bandit Labs Claude Code Plugins project (`support-claude-mktplace`).
+MIT License - Part of the Leo Claude Marketplace.
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/init.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/init.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/config.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/config.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/netbox_client.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/netbox_client.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/server.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/server.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/init.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/init.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/circuits.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/circuits.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/dcim.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/dcim.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/extras.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/extras.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/ipam.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/ipam.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/tenancy.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/tenancy.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/virtualization.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/virtualization.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/vpn.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/vpn.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/wireless.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/mcp_server/tools/wireless.py
--- a/plugins/cmdb-assistant/mcp-servers/netbox/requirements.txt
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/requirements.txt
--- a/plugins/cmdb-assistant/mcp-servers/netbox/tests/init.py
+++ b/plugins/cmdb-assistant/mcp-servers/netbox/tests/init.py
--- a/plugins/clarity-assist/.claude-plugin/plugin.json
+++ b/plugins/clarity-assist/.claude-plugin/plugin.json
@@ -0,0 +1,20 @@
 {
  "name": "clarity-assist",
  "version": "1.0.0",
  "description": "Prompt optimization and requirement clarification with ND-friendly accommodations",
  "author": {
    "name": "Leo Miranda",
    "email": "leobmiranda@gmail.com"
  },
  "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/clarity-assist/README.md",
  "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
  "license": "MIT",
  "keywords": [
    "prompt-optimization",
    "clarification",
    "neurodivergent",
    "requirements",
    "methodology"
  ],
  "commands": ["./commands/"]
 }
--- a/plugins/clarity-assist/README.md
+++ b/plugins/clarity-assist/README.md
@@ -0,0 +1,99 @@
 # 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]
 ```
 ## Integration
 For CLAUDE.md integration instructions, see `claude-md-integration.md`.
 ## License
 MIT
--- a/plugins/clarity-assist/agents/clarity-coach.md
+++ b/plugins/clarity-assist/agents/clarity-coach.md
@@ -0,0 +1,140 @@
 # Clarity Coach Agent
 ## Role
 You are a patient, structured coach specializing in helping users articulate their requirements clearly. You are trained in neurodivergent-friendly communication patterns and use evidence-based techniques for effective requirement gathering.
 ## Core Principles
 ### 1. Never Open-Ended Questions Alone
 Bad: "What do you want the button to do?"
 Good: "What should happen when the button is clicked?
 1. Navigate to another page
 2. Submit a form
 3. Open a modal/popup
 4. Other (please describe)"
 ### 2. Chunked Questions (1-2 at a Time)
 Bad: "What color, size, position, and behavior should the button have?"
 Good: "Let's start with the basics. Where should this button appear?
 1. In the header
 2. In the main content area
 3. In a sidebar
 4. Floating/fixed position"
 Then after answer: "Now for the appearance - should it match your existing button style or stand out?"
 ### 3. Provide Context for Questions
 Always explain why you're asking:
 "I'm asking about error handling because it affects whether we need to build a retry mechanism."
 ### 4. Conflict Detection
 Before each new question, mentally review:
 - What has the user already said?
 - Does this question potentially contradict earlier answers?
 - If yes, acknowledge it: "Earlier you mentioned X, so when thinking about Y..."
 ### 5. Progress Acknowledgment
 After every 2-3 questions, summarize progress:
 "Great, so far we've established:
 - The feature is for [X]
 - It should [Y]
 - And integrate with [Z]
 A couple more questions and we'll have everything we need."
 ## Communication Style
 ### Tone
 - Patient, never rushing
 - Validating ("That makes sense", "Good point")
 - Non-judgmental about vague initial requests
 ### Pacing
 - Respect user's energy levels
 - Offer breaks: "This is good progress. Want to continue or pick this up later?"
 - Notice signs of overwhelm and simplify
 ### Clarity
 - Use concrete examples, not abstract descriptions
 - Prefer "For example..." over "Consider..."
 - Visual when possible: "Picture a button in the top-right corner that..."
 ## Handling Uncertainty
 When user says "I don't know":
 ```
 "That's totally fine - let's approach it differently.
 If I showed you two versions:
 - Version A: [concrete description]
 - Version B: [concrete description]
 Which feels closer to what you're imagining? Or neither?"
 ```
 When user is overwhelmed:
 ```
 "There's a lot to decide here. Let me suggest we focus on just
 the [most critical aspect] for now. The other details can be
 figured out as we build. What matters most to you right now?"
 ```
 ## Output Artifacts
 ### During Clarification
 Track gathered information in a mental model:
 - Requirements (explicit)
 - Preferences (implicit)
 - Constraints (technical/business)
 - Open questions
 ### After Clarification
 Produce a clear specification (see /clarify command for format).
 ## Example Session
 **User:** I need a dashboard
 **Coach:**
 ```
 A dashboard can mean many things - let me help narrow it down.
 **What's the primary purpose of this dashboard?**
 1. Monitor system health/metrics
 2. View business KPIs and analytics
 3. Manage tasks or workflows
 4. Combination / Other
 [Knowing this helps me understand what data and visualizations you'll need]
 ```
 **User:** Option 2, business analytics
 **Coach:**
 ```
 Business analytics dashboard - got it.
 **Who will be using this dashboard?**
 1. Just you / personal use
 2. Your team (5-20 people)
 3. Company-wide (many departments)
 4. External clients
 [This affects permissions, performance requirements, and how customizable it needs to be]
 ```
 And so on, building toward a complete picture.
--- a/plugins/clarity-assist/claude-md-integration.md
+++ b/plugins/clarity-assist/claude-md-integration.md
@@ -0,0 +1,58 @@
 # clarity-assist - CLAUDE.md Integration
 Add the following section to your project's CLAUDE.md file to enable clarity-assist.
 ---
 ## Prompt Clarification
 This project uses the clarity-assist plugin for requirement gathering.
 ### When to Use
 - Complex or vague requests
 - Multi-step implementations
 - When requirements seem incomplete
 ### Commands
 | Command | Use Case |
 |---------|----------|
 | `/clarify` | Full 4-D methodology for complex requests |
 | `/quick-clarify` | Rapid mode for simple disambiguation |
 ### Communication Style
 When gathering requirements:
 - Present 2-4 concrete options (never open-ended alone)
 - Ask 1-2 questions at a time
 - Explain why you're asking each question
 - Check for conflicts with previous answers
 - Summarize progress frequently
 ### Output Format
 After clarification, produce a structured specification:
 ```markdown
 ## Clarified Request
 ### Summary
 [1-2 sentence description]
 ### Scope
 **In Scope:** [items]
 **Out of Scope:** [items]
 ### Requirements
 | # | Requirement | Priority | Notes |
 |---|-------------|----------|-------|
 | 1 | ... | Must | ... |
 ### Assumptions
 [List made during conversation]
 ```
 ---
 Copy the section between the horizontal rules into your CLAUDE.md.
--- a/plugins/clarity-assist/commands/clarify.md
+++ b/plugins/clarity-assist/commands/clarify.md
@@ -0,0 +1,137 @@
 # /clarify - Full Prompt Optimization
 ## Purpose
 Transform vague, incomplete, or ambiguous requests into clear, actionable specifications using the 4-D methodology with neurodivergent-friendly accommodations.
 ## When to Use
 - Complex multi-step requests
 - Requirements with multiple possible interpretations
 - Tasks requiring significant context gathering
 - When user seems uncertain about what they want
 ## 4-D Methodology
 ### Phase 1: Deconstruct
 Break down the user's request into components:
 1. **Extract explicit requirements** - What was directly stated
 2. **Identify implicit assumptions** - What seems assumed but not stated
 3. **Note ambiguities** - Points that could go multiple ways
 4. **List dependencies** - External factors that might affect implementation
 ### Phase 2: Diagnose
 Analyze gaps and potential issues:
 1. **Missing information** - What do we need to know?
 2. **Conflicting requirements** - Do any stated goals contradict?
 3. **Scope boundaries** - What's in/out of scope?
 4. **Technical constraints** - Platform, language, architecture limits
 ### Phase 3: Develop
 Gather clarifications through structured questioning:
 **ND-Friendly Question Rules:**
 - Present 2-4 concrete options (never open-ended alone)
 - Include "Other" for custom responses
 - Ask 1-2 questions at a time maximum
 - Provide brief context for why you're asking
 - Check for conflicts with previous answers
 **Example Format:**
 ```
 To help me understand the scope better:
 **How should errors be handled?**
 1. Silent logging (user sees nothing)
 2. Toast notifications (brief, dismissible)
 3. Modal dialogs (requires user action)
 4. Other
 [Context: This affects both UX and how much error-handling code we need]
 ```
 ### Phase 4: Deliver
 Produce the refined specification:
 ```markdown
 ## Clarified Request
 ### Summary
 [1-2 sentence description of what will be built]
 ### Scope
 **In Scope:**
 - [Item 1]
 - [Item 2]
 **Out of Scope:**
 - [Item 1]
 ### Requirements
 | # | Requirement | Priority | Notes |
 |---|-------------|----------|-------|
 | 1 | ... | Must | ... |
 | 2 | ... | Should | ... |
 ### Assumptions
 - [Assumption made based on conversation]
 ### Open Questions
 - [Any remaining ambiguities, if any]
 ```
 ## Conflict Detection
 Before each question, review previous answers for conflicts:
 ```
 [Internal check]
 Previous: User said "keep it simple"
 Current question about: Adding configuration options
 Potential conflict: More options = more complexity
 → Acknowledge: "Earlier you mentioned keeping it simple. With that in mind..."
 ```
 ## Escalation Protocol
 If the request is particularly messy or the user seems overwhelmed:
 1. Acknowledge the complexity
 2. Offer to start with just ONE aspect
 3. Build incrementally
 ```
 "This touches a lot of areas. Rather than tackle everything at once,
 let's start with [most critical piece]. Once that's clear, we can
 add the other parts. Sound good?"
 ```
 ## Example Interaction
 **User:** Make the app faster
 **Clarify Response:**
 ```
 Let me help clarify what kind of performance improvements you're looking for.
 **What type of slowness are you experiencing?**
 1. Initial page load takes too long
 2. Interactions feel sluggish (clicking, typing)
 3. API calls are slow
 4. All of the above
 5. Other
 [I'm asking because each has very different solutions]
 ```
 ## Output Format
 After gathering all necessary information, use the Deliver phase format to present the clarified specification for user confirmation.
--- a/plugins/clarity-assist/commands/quick-clarify.md
+++ b/plugins/clarity-assist/commands/quick-clarify.md
@@ -0,0 +1,84 @@
 # /quick-clarify - Rapid Clarification Mode
 ## Purpose
 Single-pass clarification for requests that are mostly clear but need minor disambiguation.
 ## When to Use
 - Request is fairly clear, just one or two ambiguities
 - User is in a hurry
 - Follow-up to an already-clarified request
 - Simple feature additions or bug fixes
 ## Process
 ### Step 1: Echo Understanding
 Restate what you understood in a single sentence:
 ```
 "I understand you want [X] that does [Y]."
 ```
 ### Step 2: Quick Disambiguation
 If needed, ask ONE multiple-choice question:
 ```
 **Just to confirm:** Should this [A] or [B]?
 1. [Option A with brief description]
 2. [Option B with brief description]
 3. Both
 4. Neither / Other approach
 ```
 ### Step 3: Proceed or Confirm
 If confident (>90%), proceed with a brief confirmation:
 ```
 "Got it. I'll implement [X with chosen option]. Starting now."
 ```
 If less confident, offer a micro-summary:
 ```
 "Quick summary before I start:
 - [Key point 1]
 - [Key point 2]
 - [Assumption made]
 Proceed? (Or clarify anything)"
 ```
 ## Example Interaction
 **User:** Add a delete button to the user list
 **Quick-Clarify Response:**
 ```
 I'll add a delete button to each row in the user list.
 **Should deletion require confirmation?**
 1. Yes - show confirmation dialog (Recommended)
 2. No - delete immediately
 3. Soft delete - mark as deleted but keep data
 [Asking because accidental deletions can be problematic]
 ```
 ## Escalation to Full /clarify
 If quick-clarify reveals complexity:
 ```
 "This is more involved than it first appeared - there are
 several decisions to make. Want me to switch to a more
 thorough clarification process? (Just say 'yes' or 'clarify')"
 ```
 ## Output Format
 For quick-clarify, no formal specification document is needed. Just proceed with the task after brief confirmation, documenting assumptions inline with the work.
--- a/plugins/clarity-assist/skills/prompt-patterns/optimization-rules.md
+++ b/plugins/clarity-assist/skills/prompt-patterns/optimization-rules.md
@@ -0,0 +1,134 @@
 # Prompt Optimization Rules
 ## Core Rules
 ### Rule 1: Specificity Over Generality
 | Instead of | Use |
 |------------|-----|
 | "Make it better" | "Reduce load time to under 2 seconds" |
 | "Add some validation" | "Validate email format and require 8+ char password" |
 | "Handle errors" | "Show toast notification on API failure, log to console" |
 ### Rule 2: Include Context
 Every good prompt includes:
 - **What**: The action/feature/fix needed
 - **Where**: Location in codebase or UI
 - **Why**: Purpose or problem being solved
 - **Constraints**: Technical limits, compatibility, standards
 ### Rule 3: Define Success
 Specify how to know when the task is done:
 - Acceptance criteria
 - Test cases to pass
 - Behavior to verify
 ### Rule 4: Scope Boundaries
 Explicitly state:
 - What IS in scope
 - What is NOT in scope
 - What MIGHT be in scope (user's call)
 ## Anti-Patterns to Detect
 ### Vague Requests
 Triggers: "improve", "fix", "update", "change", "better", "faster", "cleaner"
 Response: Ask for specific metrics or outcomes
 ### Scope Creep Signals
 Triggers: "while you're at it", "also", "might as well", "and another thing"
 Response: Acknowledge, then isolate: "I'll note that for after the main task"
 ### Assumption Gaps
 Triggers: References to "the" thing (which thing?), "it" (what's it?), "there" (where?)
 Response: Echo back specific understanding
 ### Conflicting Requirements
 Triggers: "Simple but comprehensive", "Fast but thorough", "Minimal but complete"
 Response: Prioritize: "Which matters more: simplicity or completeness?"
 ## Question Templates
 ### For Unclear Purpose
 ```
 **What problem does this solve?**
 1. [Specific problem A]
 2. [Specific problem B]
 3. Combination
 4. Different problem: ____
 ```
 ### For Missing Scope
 ```
 **What should this include?**
 - [ ] Feature A
 - [ ] Feature B
 - [ ] Feature C
 - [ ] Other: ____
 ```
 ### For Ambiguous Behavior
 ```
 **When [trigger event], what should happen?**
 1. [Behavior option A]
 2. [Behavior option B]
 3. Nothing (ignore)
 4. Depends on: ____
 ```
 ### For Technical Decisions
 ```
 **Implementation approach:**
 1. [Approach A] - pros: X, cons: Y
 2. [Approach B] - pros: X, cons: Y
 3. Let me decide based on codebase
 4. Need more info about: ____
 ```
 ## Optimization Checklist
 Before proceeding with any task, verify:
 - [ ] **Specific outcome** - Can measure success
 - [ ] **Clear location** - Know where changes go
 - [ ] **Defined scope** - Know what's in/out
 - [ ] **Error handling** - Know what happens on failure
 - [ ] **Edge cases** - Major scenarios covered
 - [ ] **Dependencies** - Know what this affects/relies on
 ## ND-Friendly Adaptations
 ### Reduce Cognitive Load
 - Maximum 4 options per question
 - Always include "Other" escape hatch
 - Provide examples, not just descriptions
 ### Support Working Memory
 - Summarize frequently
 - Reference earlier decisions explicitly
 - Don't assume user remembers context
 ### Allow Processing Time
 - Don't rapid-fire questions
 - Validate answers before moving on
 - Offer to revisit/change earlier answers
 ### Manage Overwhelm
 - Offer to break into smaller sessions
 - Prioritize must-haves vs nice-to-haves
 - Provide "good enough for now" options
--- a/plugins/claude-config-maintainer/.claude-plugin/plugin.json
+++ b/plugins/claude-config-maintainer/.claude-plugin/plugin.json
@@ -2,29 +2,19 @@
  "name": "claude-config-maintainer",
  "version": "1.0.0",
  "description": "Maintains and optimizes CLAUDE.md configuration files for Claude Code projects",
-  "entryPoint": "agents/maintainer.md",
+  "author": {
-  "commands": [
+    "name": "Leo Miranda",
-    {
+    "email": "leobmiranda@gmail.com"
      "name": "config-analyze",
      "description": "Analyze CLAUDE.md for optimization opportunities",
      "entryPoint": "commands/analyze.md"
  },
-    {
+  "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/claude-config-maintainer/README.md",
-      "name": "config-optimize",
+  "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
-      "description": "Optimize CLAUDE.md structure and content",
+  "license": "MIT",
-      "entryPoint": "commands/optimize.md"
+  "keywords": [
-    },
+    "claude-code",
-    {
+    "configuration",
-      "name": "config-init",
+    "optimization",
-      "description": "Initialize a new CLAUDE.md file for a project",
+    "claude-md",
-      "entryPoint": "commands/init.md"
+    "developer-tools"
    }
  ],
-  "agents": [
+  "commands": ["./commands/"]
    {
      "name": "maintainer",
      "description": "CLAUDE.md optimization and maintenance agent",
      "entryPoint": "agents/maintainer.md"
    }
  ]
 }
--- a/plugins/claude-config-maintainer/README.md
+++ b/plugins/claude-config-maintainer/README.md
@@ -12,7 +12,7 @@ CLAUDE.md files provide instructions to Claude Code when working with a project.
 ## Installation
-This plugin is part of the support-claude-mktplace collection. Install the marketplace and the plugin will be available.
+This plugin is part of the Leo Claude Marketplace. Install the marketplace and the plugin will be available.
 ## Commands
@@ -96,4 +96,4 @@ Target score: **70+** for effective Claude Code usage.
 ## Contributing
-This plugin is part of the bandit/support-claude-mktplace repository.
+This plugin is part of the personal-projects/leo-claude-mktplace repository.
--- a/plugins/claude-config-maintainer/agents/maintainer.md
+++ b/plugins/claude-config-maintainer/agents/maintainer.md
@@ -31,7 +31,11 @@ You are the **Maintainer Agent** - a specialist in creating and optimizing CLAUD
 ### 1. Analyze CLAUDE.md Files
-When analyzing a CLAUDE.md file, evaluate:
+When analyzing a CLAUDE.md file, perform two types of analysis:
 #### A. Content Analysis
 Evaluate:
 **Structure:**
 - Is the file well-organized?
@@ -57,6 +61,49 @@ When analyzing a CLAUDE.md file, evaluate:
 - Are there verbose explanations that could be shortened?
 - Is the file too long for effective use?
 #### B. Plugin Integration Analysis
 After content analysis, check for marketplace plugin integration:
 **Step 1: Detect Active Plugins**
 Read `.claude/settings.local.json` and identify enabled MCP servers:
 ```json
 {
  "mcpServers": {
    "gitea": { ... },      // → projman plugin
    "netbox": { ... }      // → cmdb-assistant plugin
  }
 }
 ```
 Use this mapping to identify active plugins:
 | MCP Server | Plugin |
 |------------|--------|
 | `gitea` | projman |
 | `netbox` | cmdb-assistant |
 Also check for hook-based plugins (project-hygiene uses `PostToolUse` hooks).
 **Step 2: Check CLAUDE.md for Plugin References**
 For each detected plugin, search CLAUDE.md for:
 - Plugin name mention (e.g., "projman", "cmdb-assistant")
 - Command references (e.g., `/sprint-plan`, `/cmdb-search`)
 - MCP tool mentions (e.g., `list_issues`, `dcim_list_devices`)
 **Step 3: Load Integration Snippets**
 For plugins not referenced in CLAUDE.md, load their integration snippet from:
 `plugins/{plugin-name}/claude-md-integration.md`
 **Step 4: Report and Offer Integration**
 Report plugin coverage percentage and offer to add missing integrations:
 - Show which plugins are detected but not referenced
 - Display the integration content that would be added
 - Ask user for confirmation before modifying CLAUDE.md
 ### 2. Optimize CLAUDE.md Structure
 **Recommended Structure:**
@@ -145,7 +192,42 @@ Suggested Actions:
 Would you like me to implement these improvements?
 ```
-### 5. Create New CLAUDE.md Files
+### 5. Insert Plugin Integrations
 When adding plugin integration content to CLAUDE.md:
 **Placement:**
 - Add plugin sections after the main project documentation
 - Group all plugin integrations together under a clear header
 - Use consistent formatting across all plugin sections
 **Process:**
 1. Read the plugin's `claude-md-integration.md` file
 2. Show the content to the user for review
 3. Ask for confirmation: "Add this plugin integration? [Y/n]"
 4. If confirmed, insert at appropriate location in CLAUDE.md
 5. Repeat for each missing plugin
 **User Confirmation Flow:**
 ```
 Plugin Integration: projman
 --------------------------
 [Show content from plugins/projman/claude-md-integration.md]
 Add this integration to CLAUDE.md?
  [1] Yes, add this integration
  [2] Skip this plugin
  [3] Add all remaining plugins
  [4] Cancel
 ```
 **Best Practices:**
 - Never modify CLAUDE.md without user confirmation
 - Show exactly what will be added before making changes
 - Allow users to skip specific plugins they don't want documented
 - Preserve existing CLAUDE.md structure and content
 ### 6. Create New CLAUDE.md Files
 When creating a new CLAUDE.md:
--- a/plugins/claude-config-maintainer/claude-md-integration.md
+++ b/plugins/claude-config-maintainer/claude-md-integration.md
@@ -0,0 +1,30 @@
 ## CLAUDE.md Maintenance (claude-config-maintainer)
 This project uses the **claude-config-maintainer** plugin to analyze and optimize CLAUDE.md configuration files.
 ### Available Commands
 | Command | Description |
 |---------|-------------|
 | `/config-analyze` | Analyze CLAUDE.md for optimization opportunities with 100-point scoring |
 | `/config-optimize` | Automatically optimize CLAUDE.md structure and content |
 | `/config-init` | Initialize a new CLAUDE.md file for a project |
 ### Scoring System
 The analysis uses a 100-point scoring system across four categories:
 | Category | Points | What It Measures |
 |----------|--------|------------------|
 | Structure | 25 | Organization, headers, navigation, grouping |
 | Clarity | 25 | Instructions, examples, language, detail level |
 | Completeness | 25 | Overview, quick start, critical rules, workflows |
 | Conciseness | 25 | Efficiency, no repetition, appropriate length |
 ### Usage Guidelines
 - Run `/config-analyze` periodically to assess CLAUDE.md quality
 - Target a score of **70+/100** for effective Claude Code operation
 - Address HIGH priority issues first when optimizing
 - Use `/config-init` when setting up new projects to start with best practices
 - Re-analyze after making changes to verify improvements
--- a/plugins/claude-config-maintainer/commands/analyze.md
+++ b/plugins/claude-config-maintainer/commands/analyze.md
@@ -1,10 +1,10 @@
 ---
-description: Analyze CLAUDE.md for optimization opportunities
+description: Analyze CLAUDE.md for optimization opportunities and plugin integration
 ---
 # Analyze CLAUDE.md
-This command analyzes your project's CLAUDE.md file and provides a detailed report on optimization opportunities.
+This command analyzes your project's CLAUDE.md file and provides a detailed report on optimization opportunities and plugin integration status.
 ## What This Command Does
@@ -12,7 +12,9 @@ This command analyzes your project's CLAUDE.md file and provides a detailed repo
 2. **Analyze Structure** - Evaluates organization, headers, and flow
 3. **Check Content** - Reviews clarity, completeness, and conciseness
 4. **Identify Issues** - Finds redundancy, verbosity, and missing sections
-5. **Generate Report** - Provides scored assessment with recommendations
+5. **Detect Active Plugins** - Identifies marketplace plugins enabled in the project
 6. **Check Plugin Integration** - Verifies CLAUDE.md references active plugins
 7. **Generate Report** - Provides scored assessment with recommendations
 ## Usage
@@ -52,6 +54,29 @@ Analyze the CLAUDE.md file in this project
 - Appropriate length for project size
 - No generic filler content
 ## Plugin Integration Analysis
 After the content analysis, the command detects and analyzes marketplace plugin integration:
 ### Detection Method
 1. **Read `.claude/settings.local.json`** - Check for enabled MCP servers
 2. **Map MCP servers to plugins** - Use marketplace registry to identify active plugins:
   - `gitea` → projman
   - `netbox` → cmdb-assistant
 3. **Check for hooks** - Identify hook-based plugins (project-hygiene)
 4. **Scan CLAUDE.md** - Look for plugin integration content
 ### Plugin Coverage Scoring
 For each detected plugin, verify CLAUDE.md contains:
 - Plugin section header or mention
 - Available commands documentation
 - MCP tools reference (if applicable)
 - Usage guidelines
 Coverage is reported as percentage: `(plugins referenced / plugins detected) * 100`
 ## Expected Output
 ```
@@ -101,10 +126,37 @@ Recommendations:
 Estimated improvement: 15-20 points after changes
 ---
 Plugin Integration Analysis
 ===========================
 Detected Active Plugins:
  ✓ projman (via gitea MCP server)
  ✓ cmdb-assistant (via netbox MCP server)
  ✓ project-hygiene (via PostToolUse hook)
 Plugin Coverage: 33% (1/3 plugins referenced)
  ✓ projman - Referenced in CLAUDE.md
  ✗ cmdb-assistant - NOT referenced
  ✗ project-hygiene - NOT referenced
 Missing Integration Content:
 1. cmdb-assistant
   Add infrastructure management commands and NetBox MCP tools reference.
 2. project-hygiene
   Add cleanup hook documentation and configuration options.
 ---
 Would you like me to:
-[1] Implement all recommended changes
+[1] Implement all content recommendations
-[2] Show before/after for specific section
+[2] Add missing plugin integrations to CLAUDE.md
-[3] Generate optimized version for review
+[3] Do both (recommended)
 [4] Show preview of changes first
 ```
 ## When to Use
@@ -115,6 +167,8 @@ Run `/config-analyze` when:
 - Claude seems to miss instructions
 - Before major project changes
 - Periodic maintenance (quarterly)
 - After installing new marketplace plugins
 - When Claude doesn't seem to use available plugin tools
 ## Follow-Up Actions
--- a/plugins/cmdb-assistant/.claude-plugin/plugin.json
+++ b/plugins/cmdb-assistant/.claude-plugin/plugin.json
@@ -3,10 +3,11 @@
  "version": "1.0.0",
  "description": "NetBox CMDB integration for infrastructure management - query, create, update, and manage network devices, IP addresses, sites, and more",
  "author": {
-    "name": "Bandit Labs",
+    "name": "Leo Miranda",
-    "email": "dev@banditlabs.io"
+    "email": "leobmiranda@gmail.com"
  },
-  "homepage": "https://github.com/bandit-labs/cmdb-assistant",
+  "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/cmdb-assistant/README.md",
  "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
  "license": "MIT",
  "keywords": [
    "netbox",
@@ -15,5 +16,7 @@
    "network",
    "ipam",
    "dcim"
-  ]
+  ],
  "commands": ["./commands/"],
  "mcpServers": ["./.mcp.json"]
 }
--- a/plugins/cmdb-assistant/README.md
+++ b/plugins/cmdb-assistant/README.md
@@ -167,4 +167,4 @@ The plugin uses the shared NetBox MCP server at `../mcp-servers/netbox/`.
 ## License
-MIT License - Part of the Bandit Labs plugin collection.
+MIT License - Part of the Leo Claude Marketplace.
--- a/plugins/cmdb-assistant/claude-md-integration.md
+++ b/plugins/cmdb-assistant/claude-md-integration.md
@@ -0,0 +1,58 @@
 ## Infrastructure Management (cmdb-assistant)
 This project uses the **cmdb-assistant** plugin for NetBox CMDB integration to manage network infrastructure.
 ### Available Commands
 | Command | Description |
 |---------|-------------|
 | `/cmdb-search` | Search across all NetBox objects |
 | `/cmdb-device` | Manage devices (create, update, list) |
 | `/cmdb-ip` | Manage IP addresses and prefixes |
 | `/cmdb-site` | Manage sites and locations |
 ### MCP Tools Available
 The following NetBox MCP tools are available for infrastructure management:
 **DCIM (Data Center Infrastructure Management):**
 - `dcim_list_devices`, `dcim_get_device`, `dcim_create_device`, `dcim_update_device` - Device management
 - `dcim_list_sites`, `dcim_get_site`, `dcim_create_site` - Site management
 - `dcim_list_racks`, `dcim_get_rack`, `dcim_create_rack` - Rack management
 - `dcim_list_interfaces`, `dcim_create_interface` - Interface management
 - `dcim_list_cables`, `dcim_create_cable` - Cable management
 - `dcim_list_device_types`, `dcim_list_device_roles`, `dcim_list_manufacturers` - Reference data
 - `dcim_list_regions`, `dcim_list_locations` - Location hierarchy
 **IPAM (IP Address Management):**
 - `ipam_list_ip_addresses`, `ipam_create_ip_address`, `ipam_get_ip_address` - IP address management
 - `ipam_list_prefixes`, `ipam_create_prefix`, `ipam_list_available_prefixes` - Prefix management
 - `ipam_list_vlans`, `ipam_create_vlan` - VLAN management
 - `ipam_list_vrfs`, `ipam_create_vrf` - VRF management
 - `ipam_list_available_ips`, `ipam_create_available_ip` - IP allocation
 **Virtualization:**
 - `virtualization_list_virtual_machines`, `virtualization_create_virtual_machine` - VM management
 - `virtualization_list_clusters`, `virtualization_create_cluster` - Cluster management
 - `virtualization_list_vm_interfaces` - VM interface management
 **Circuits:**
 - `circuits_list_circuits`, `circuits_create_circuit` - Circuit management
 - `circuits_list_providers`, `circuits_create_provider` - Provider management
 **Tenancy:**
 - `tenancy_list_tenants`, `tenancy_create_tenant` - Tenant management
 - `tenancy_list_contacts`, `tenancy_create_contact` - Contact management
 **Extras:**
 - `extras_list_tags`, `extras_create_tag` - Tag management
 - `extras_list_journal_entries`, `extras_create_journal_entry` - Audit journal
 - `extras_list_object_changes` - Change tracking
 ### Usage Guidelines
 - Use NetBox MCP tools for all infrastructure queries and modifications
 - Always verify device/IP existence before creating duplicates
 - Use tags for categorization and filtering
 - Create journal entries for significant changes to maintain audit trail
 - Check available IPs in a prefix before manual allocation
--- a/plugins/cmdb-assistant/commands/initial-setup.md
+++ b/plugins/cmdb-assistant/commands/initial-setup.md
@@ -0,0 +1,160 @@
 ---
 description: Interactive setup wizard for cmdb-assistant plugin - configures NetBox MCP server
 ---
 # CMDB Assistant Setup Wizard
 This command sets up the cmdb-assistant plugin with NetBox integration.
 ## Important Context
 - **This command uses Bash, Read, Write, and AskUserQuestion tools** - NOT MCP tools
 - **MCP tools won't work until after setup + session restart**
 - **Uses NetBox MCP server (separate from Gitea MCP)**
 ---
 ## Phase 1: Environment Validation
 ### Step 1.1: Check Python Version
 ```bash
 python3 --version
 ```
 If below 3.10, stop setup and inform user.
 ---
 ## Phase 2: MCP Server Setup
 ### Step 2.1: Locate NetBox MCP Server
 ```bash
 find ~/.claude ~/.config/claude -name "mcp_server" -path "*netbox*" 2>/dev/null | head -5
 ```
 If not found, ask user for marketplace location.
 ### Step 2.2: Check Virtual Environment
 ```bash
 ls -la /path/to/mcp-servers/netbox/.venv/bin/python 2>/dev/null && echo "VENV_EXISTS" || echo "VENV_MISSING"
 ```
 ### Step 2.3: Create Virtual Environment (if missing)
 ```bash
 cd /path/to/mcp-servers/netbox && python3 -m venv .venv && source .venv/bin/activate && pip install --upgrade pip && pip install -r requirements.txt && deactivate
 ```
 ---
 ## Phase 3: System Configuration
 ### Step 3.1: Create Config Directory
 ```bash
 mkdir -p ~/.config/claude
 ```
 ### Step 3.2: Check NetBox Configuration
 ```bash
 cat ~/.config/claude/netbox.env 2>/dev/null || echo "FILE_NOT_FOUND"
 ```
 **If file exists with valid values:** Skip to Phase 4.
 **If missing or has placeholders:** Continue.
 ### Step 3.3: Gather NetBox Information
 Use AskUserQuestion:
 - Question: "What is your NetBox server URL? (e.g., https://netbox.company.com)"
 - Header: "NetBox URL"
 - Options:
  - "Other (I'll provide the URL)"
 Ask user to provide the URL.
 ### Step 3.4: Create Configuration File
 ```bash
 cat > ~/.config/claude/netbox.env << 'EOF'
 # NetBox API Configuration
 # Generated by cmdb-assistant /initial-setup
 NETBOX_API_URL=<USER_PROVIDED_URL>
 NETBOX_API_TOKEN=PASTE_YOUR_TOKEN_HERE
 EOF
 chmod 600 ~/.config/claude/netbox.env
 ```
 ### Step 3.5: Token Instructions
 ---
 **Action Required: Add Your NetBox API Token**
 I've created `~/.config/claude/netbox.env` but you need to add your API token manually.
 **Steps:**
 1. Open: `nano ~/.config/claude/netbox.env`
 2. Generate token in NetBox: Admin → API Tokens → Add Token
 3. Replace `PASTE_YOUR_TOKEN_HERE` with your token
 4. Save the file
 ---
 Use AskUserQuestion:
 - Question: "Have you added your NetBox token?"
 - Header: "Token"
 - Options:
  - "Yes, I've added the token"
  - "Skip for now"
 ---
 ## Phase 4: Validation
 ### Step 4.1: Test Configuration (if token was added)
 ```bash
 source ~/.config/claude/netbox.env && curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Token $NETBOX_API_TOKEN" "$NETBOX_API_URL/api/"
 ```
 Report result:
 - 200: Success
 - 403: Invalid token
 - Other: Connection issue
 ### Step 4.2: Summary
 ```
 ╔════════════════════════════════════════════════════════════╗
 ║              CMDB-ASSISTANT SETUP COMPLETE                 ║
 ╠════════════════════════════════════════════════════════════╣
 ║ MCP Server (NetBox):   ✓ Ready                             ║
 ║ System Config:         ✓ ~/.config/claude/netbox.env       ║
 ╚════════════════════════════════════════════════════════════╝
 ```
 ### Step 4.3: Session Restart Notice
 ---
 **⚠️ Session Restart Required**
 Restart your Claude Code session for MCP tools to become available.
 **After restart, you can:**
 - Run `/cmdb-device <hostname>` to look up a device
 - Run `/cmdb-ip <address>` to look up an IP address
 - Run `/cmdb-site <name>` to look up a site
 - Run `/cmdb-search <query>` for general search
 ---
 ## Note on Project Configuration
 cmdb-assistant does not require project-level configuration. The NetBox connection is system-wide and not tied to specific repositories.
--- a/plugins/cmdb-assistant/mcp-servers/netbox
+++ b/plugins/cmdb-assistant/mcp-servers/netbox
@@ -0,0 +1 @@
 ../../../mcp-servers/netbox
--- a/plugins/code-sentinel/.claude-plugin/plugin.json
+++ b/plugins/code-sentinel/.claude-plugin/plugin.json
@@ -0,0 +1,13 @@
 {
  "name": "code-sentinel",
  "description": "Security scanning and code refactoring tools",
  "version": "1.0.0",
  "author": {
    "name": "Leo Miranda",
    "email": "leobmiranda@gmail.com"
  },
  "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/code-sentinel/README.md",
  "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
  "license": "MIT",
  "keywords": ["security", "refactoring", "code-quality", "static-analysis", "hooks"]
 }
--- a/plugins/code-sentinel/README.md
+++ b/plugins/code-sentinel/README.md
@@ -0,0 +1,47 @@
 # 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/code-sentinel/agents/refactor-advisor.md
+++ b/plugins/code-sentinel/agents/refactor-advisor.md
@@ -0,0 +1,48 @@
 ---
 description: Code structure and refactoring specialist
 ---
 # Refactor Advisor Agent
 You are a software architect specializing in code quality, design patterns, and refactoring.
 ## Expertise
 - Martin Fowler's refactoring catalog
 - SOLID principles
 - Design patterns (GoF, enterprise, functional)
 - Code smells detection
 - Cyclomatic complexity analysis
 - Technical debt assessment
 ## Analysis Approach
 When analyzing code:
 1. **Identify Code Smells**
   - Long methods (>20 lines)
   - Large classes (>200 lines)
   - Long parameter lists (>3 params)
   - Duplicate code
   - Feature envy
   - Data clumps
 2. **Assess Structure**
   - Single responsibility adherence
   - Coupling between modules
   - Cohesion within modules
   - Abstraction levels
 3. **Recommend Refactorings**
   - Match smells to appropriate refactorings
   - Consider dependencies and side effects
   - Prioritize by impact and risk
   - Provide step-by-step approach
 ## Output Style
 Be practical:
 - Focus on high-impact improvements
 - Explain the "why" behind recommendations
 - Provide concrete before/after examples
 - Consider testing implications
--- a/plugins/code-sentinel/agents/security-reviewer.md
+++ b/plugins/code-sentinel/agents/security-reviewer.md
@@ -0,0 +1,50 @@
 ---
 description: Security-focused code review agent
 ---
 # Security Reviewer Agent
 You are a security engineer specializing in application security and secure coding practices.
 ## Expertise
 - OWASP Top 10 vulnerabilities
 - Language-specific security pitfalls (Python, JavaScript, Go, etc.)
 - Authentication and authorization flaws
 - Cryptographic misuse
 - Input validation and output encoding
 - Secure configuration
 ## Review Approach
 When reviewing code:
 1. **Identify Trust Boundaries**
   - Where does user input enter?
   - Where does data leave the system?
   - What operations are privileged?
 2. **Trace Data Flow**
   - Follow user input through the code
   - Check for sanitization at each boundary
   - Verify output encoding
 3. **Check Security Controls**
   - Authentication present where needed?
   - Authorization checked before actions?
   - Secrets properly managed?
   - Errors handled without leaking info?
 4. **Language-Specific Checks**
   Python: eval, pickle, yaml.load, subprocess
   JavaScript: innerHTML, eval, prototype pollution
   SQL: parameterized queries, ORM usage
   Shell: quoting, input validation
 ## Output Style
 Be specific and actionable:
 - Quote the vulnerable line
 - Explain the attack vector
 - Provide the secure alternative
 - Rate severity (Critical/High/Medium/Low)
--- a/plugins/code-sentinel/claude-md-integration.md
+++ b/plugins/code-sentinel/claude-md-integration.md
@@ -0,0 +1,26 @@
 # Code Sentinel Integration
 Add to your project's CLAUDE.md:
 ## Security & Code Quality
 This project uses code-sentinel for security scanning and refactoring.
 ### Automatic Security Checks
 PreToolUse hooks scan all code changes for:
 - SQL/Command/Code injection
 - XSS vulnerabilities
 - Hardcoded secrets
 - Unsafe deserialization
 Critical issues are blocked. Warnings are noted but allowed.
 ### Commands
 - `/security-scan` - Full project security audit
 - `/refactor <target>` - Apply refactoring pattern
 - `/refactor-dry <target>` - Preview refactoring opportunities
 ### Severity Levels
 - 🔴 Critical: Must fix immediately
 - 🟠 High: Fix before release
 - 🟡 Medium: Improve when possible
--- a/plugins/code-sentinel/commands/refactor-dry.md
+++ b/plugins/code-sentinel/commands/refactor-dry.md
@@ -0,0 +1,57 @@
 ---
 description: Preview refactoring changes without applying them
 ---
 # Refactor Dry Run
 Analyze and preview refactoring opportunities without making changes.
 ## Usage
 ```
 /refactor-dry <target> [--all]
 ```
 **Target:** File path, function name, or "." for current file
 **--all:** Show all opportunities, not just recommended
 ## Process
 1. **Scan Target**
   Analyze code for refactoring opportunities.
 2. **Score Opportunities**
   Each opportunity rated by:
   - Impact (how much it improves code)
   - Risk (likelihood of breaking something)
   - Effort (complexity of the refactoring)
 3. **Output**
 ```
 ## Refactoring Opportunities: src/handlers.py
 ### Recommended (High Impact, Low Risk)
 1. **extract-method** at lines 45-67
   - Extract order validation logic
   - Impact: High (reduces complexity from 12 to 4)
   - Risk: Low (pure function, no side effects)
   - Run: `/refactor src/handlers.py:45 --pattern=extract-method`
 2. **use-dataclass** for OrderInput class
   - Convert to dataclass with validation
   - Impact: Medium (reduces boilerplate)
   - Risk: Low
   - Run: `/refactor src/models.py:OrderInput --pattern=use-dataclass`
 ### Optional (Consider Later)
 3. **use-fstring** at 12 locations
   - Modernize string formatting
   - Impact: Low (readability only)
   - Risk: None
 ### Summary
 - 2 recommended refactorings
 - 1 optional improvement
 - Estimated complexity reduction: 35%
 ```
--- a/plugins/code-sentinel/commands/refactor.md
+++ b/plugins/code-sentinel/commands/refactor.md
@@ -0,0 +1,81 @@
 ---
 description: Apply refactoring patterns to improve code structure and maintainability
 ---
 # Refactor
 Apply refactoring transformations to specified code.
 ## Usage
 ```
 /refactor <target> [--pattern=<pattern>]
 ```
 **Target:** File path, function name, or "." for current context
 **Pattern:** Specific refactoring pattern (optional)
 ## Available Patterns
 ### Structure
 | Pattern | Description |
 |---------|-------------|
 | `extract-method` | Extract code block into named function |
 | `extract-class` | Move related methods to new class |
 | `inline` | Inline trivial function/variable |
 | `rename` | Rename with all references updated |
 | `move` | Move function/class to different module |
 ### Simplification
 | Pattern | Description |
 |---------|-------------|
 | `simplify-conditional` | Flatten nested if/else |
 | `remove-dead-code` | Delete unreachable code |
 | `consolidate-duplicate` | Merge duplicate code blocks |
 | `decompose-conditional` | Break complex conditions into named parts |
 ### Modernization
 | Pattern | Description |
 |---------|-------------|
 | `use-comprehension` | Convert loops to list/dict comprehensions |
 | `use-pathlib` | Replace os.path with pathlib |
 | `use-fstring` | Convert .format() to f-strings |
 | `use-typing` | Add type hints |
 | `use-dataclass` | Convert class to dataclass |
 ## Process
 1. **Analyze Target**
   - Parse code structure
   - Identify refactoring opportunities
   - Check for side effects and dependencies
 2. **Propose Changes**
   - Show before/after diff
   - Explain the improvement
   - List affected files/references
 3. **Apply (with confirmation)**
   - Make changes
   - Update all references
   - Run existing tests if available
 4. **Output**
 ```
 ## Refactoring: extract-method
 ### Target
 src/handlers.py:create_order (lines 45-89)
 ### Changes
 - Extracted validation logic → validate_order_input()
 - Extracted pricing logic → calculate_order_total()
 - Original function now 15 lines (was 44)
 ### Files Modified
 - src/handlers.py
 - tests/test_handlers.py (updated calls)
 ### Metrics
 - Cyclomatic complexity: 12 → 4
 - Function length: 44 → 15 lines
 ```
--- a/plugins/code-sentinel/commands/security-scan.md
+++ b/plugins/code-sentinel/commands/security-scan.md
@@ -0,0 +1,64 @@
 ---
 description: Full security audit of codebase - scans all files for vulnerability patterns
 ---
 # Security Scan
 Comprehensive security audit of the project.
 ## Process
 1. **File Discovery**
   Scan all code files: .py, .js, .ts, .jsx, .tsx, .go, .rs, .java, .rb, .php, .sh
 2. **Pattern Detection**
   ### Critical Vulnerabilities
   | Pattern | Risk | Detection |
   |---------|------|-----------|
   | SQL Injection | High | String concat in SQL queries |
   | Command Injection | High | shell=True, os.system with vars |
   | XSS | High | innerHTML with user input |
   | Code Injection | Critical | eval/exec with external input |
   | Deserialization | Critical | pickle.loads, yaml.load unsafe |
   | Path Traversal | High | File ops without sanitization |
   | Hardcoded Secrets | High | API keys, passwords in code |
   | SSRF | Medium | URL from user input in requests |
   ### Code Quality Issues
   | Pattern | Risk | Detection |
   |---------|------|-----------|
   | Broad Exceptions | Low | `except:` or `except Exception:` |
   | Debug Statements | Low | print/console.log with data |
   | TODO/FIXME Security | Medium | Comments mentioning security |
   | Deprecated Functions | Medium | Known insecure functions |
 3. **Output Format**
 ```
 ## Security Scan Report
 ### Critical (Immediate Action Required)
 🔴 src/db.py:45 - SQL Injection
   Code: `f"SELECT * FROM users WHERE id = {user_id}"`
   Fix: Use parameterized query: `cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))`
 ### High
 🟠 config.py:12 - Hardcoded Secret
   Code: `API_KEY = "sk-1234..."`
   Fix: Use environment variable: `API_KEY = os.environ.get("API_KEY")`
 ### Medium
 🟡 utils.py:78 - Broad Exception
   Code: `except:`
   Fix: Catch specific exceptions
 ### Summary
 - Critical: X (must fix before deploy)
 - High: X (fix soon)
 - Medium: X (improve when possible)
 ```
 4. **Exit Code Guidance**
   - Critical findings: Recommend blocking merge/deploy
   - High findings: Recommend fixing before release
   - Medium/Low: Informational
--- a/plugins/code-sentinel/hooks/hooks.json
+++ b/plugins/code-sentinel/hooks/hooks.json
@@ -0,0 +1,15 @@
 {
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "[code-sentinel] SECURITY CHECK - Before writing this code, scan for these patterns:\n\n**Critical (BLOCK if found):**\n- eval(), exec() with user input\n- SQL string concatenation (SQL injection)\n- shell=True with user input (command injection)\n- Hardcoded secrets (API keys, passwords, tokens)\n- Pickle/marshal deserialization of untrusted data\n- innerHTML/dangerouslySetInnerHTML with user content (XSS)\n\n**Warning (WARN but allow):**\n- subprocess without input validation\n- File operations without path sanitization\n- HTTP requests without timeout\n- Broad exception catches (except:)\n- Debug/print statements with sensitive data\n\n**Response:**\n- If CRITICAL found: STOP with '[code-sentinel] BLOCKED:', explain the issue, suggest safe alternative\n- If WARNING found: Note briefly with '[code-sentinel] WARNING:', proceed with suggestion\n- If clean: Proceed silently (say nothing)\n\nDo NOT announce clean scans. Only speak if issues found."
          }
        ]
      }
    ]
  }
 }
--- a/plugins/code-sentinel/skills/security-patterns/SKILL.md
+++ b/plugins/code-sentinel/skills/security-patterns/SKILL.md
@@ -0,0 +1,111 @@
 ---
 description: Security vulnerability patterns and detection rules
 ---
 # Security Patterns Skill
 ## Critical Patterns (Always Block)
 ### SQL Injection
 ```python
 # VULNERABLE
 query = f"SELECT * FROM users WHERE id = {user_id}"
 query = "SELECT * FROM users WHERE id = " + user_id
 # SAFE
 cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
 User.objects.filter(id=user_id)
 ```
 ### Command Injection
 ```python
 # VULNERABLE
 os.system(f"convert {filename} output.png")
 subprocess.run(cmd, shell=True)
 # SAFE
 subprocess.run(["convert", filename, "output.png"], shell=False)
 shlex.quote(filename)
 ```
 ### Code Injection
 ```python
 # VULNERABLE
 eval(user_input)
 exec(user_code)
 # SAFE
 ast.literal_eval(user_input)  # Only for literals
 # Use sandboxed execution environment
 ```
 ### XSS
 ```javascript
 // VULNERABLE
 element.innerHTML = userContent;
 dangerouslySetInnerHTML={{__html: userData}}
 // SAFE
 element.textContent = userContent;
 DOMPurify.sanitize(userContent)
 ```
 ### Hardcoded Secrets
 ```python
 # VULNERABLE
 API_KEY = "sk-1234567890abcdef"
 password = "admin123"
 # SAFE
 API_KEY = os.environ.get("API_KEY")
 password = get_secret("db_password")
 ```
 ### Unsafe Deserialization
 ```python
 # VULNERABLE
 data = pickle.loads(user_data)
 config = yaml.load(file)  # yaml.load without Loader
 # SAFE
 data = json.loads(user_data)
 config = yaml.safe_load(file)
 ```
 ## Warning Patterns (Flag but Allow)
 ### Broad Exception Handling
 ```python
 # WARNING
 try:
    risky_operation()
 except:
    pass
 # BETTER
 try:
    risky_operation()
 except SpecificError as e:
    logger.error(f"Operation failed: {e}")
    raise
 ```
 ### Missing Timeout
 ```python
 # WARNING
 response = requests.get(url)
 # BETTER
 response = requests.get(url, timeout=30)
 ```
 ### Path Traversal Risk
 ```python
 # WARNING
 file_path = os.path.join(base_dir, user_filename)
 # BETTER
 file_path = os.path.join(base_dir, os.path.basename(user_filename))
 if not file_path.startswith(os.path.abspath(base_dir)):
    raise ValueError("Invalid path")
 ```
--- a/plugins/doc-guardian/.claude-plugin/plugin.json
+++ b/plugins/doc-guardian/.claude-plugin/plugin.json
@@ -0,0 +1,13 @@
 {
  "name": "doc-guardian",
  "description": "Automatic documentation drift detection and synchronization",
  "version": "1.0.0",
  "author": {
    "name": "Leo Miranda",
    "email": "leobmiranda@gmail.com"
  },
  "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/doc-guardian/README.md",
  "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
  "license": "MIT",
  "keywords": ["documentation", "sync", "drift-detection", "automation", "hooks"]
 }
--- a/plugins/doc-guardian/README.md
+++ b/plugins/doc-guardian/README.md
@@ -0,0 +1,48 @@
 # 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 |
 ## 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
 ## 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/doc-guardian/agents/doc-analyzer.md
+++ b/plugins/doc-guardian/agents/doc-analyzer.md
@@ -0,0 +1,41 @@
 ---
 description: Specialized agent for documentation analysis and drift detection
 ---
 # Documentation Analyzer Agent
 You are an expert technical writer and documentation analyst. Your role is to detect discrepancies between code and documentation.
 ## Capabilities
 1. **Pattern Recognition**
   - Identify documentation references to code elements
   - Parse docstrings, markdown, and inline comments
   - Understand common documentation structures (README, API docs, man pages)
 2. **Cross-Reference Analysis**
   - Map documentation claims to actual code
   - Detect renamed, moved, or deleted code still referenced in docs
   - Identify undocumented public interfaces
 3. **Semantic Understanding**
   - Recognize when documentation meaning is correct but wording is outdated
   - Distinguish between cosmetic issues and functional inaccuracies
   - Prioritize user-facing documentation over internal notes
 ## Analysis Approach
 When analyzing drift:
 1. Parse the changed file to understand what was modified
 2. Search for documentation files that might reference the changed code
 3. Extract specific references (function names, class names, config keys)
 4. Verify each reference against current code state
 5. Categorize findings by severity (broken, stale, missing)
 ## Output Style
 Be precise and actionable:
 - Quote the exact line in documentation
 - Show the exact discrepancy
 - Suggest the specific fix
 - Never report vague or uncertain findings
--- a/plugins/doc-guardian/claude-md-integration.md
+++ b/plugins/doc-guardian/claude-md-integration.md
@@ -0,0 +1,22 @@
 # Doc Guardian Integration
 Add to your project's CLAUDE.md:
 ## Documentation Management
 This project uses doc-guardian for automatic documentation synchronization.
 ### Behavior
 - Documentation drift is detected automatically when files change
 - Pending updates are queued silently during work
 - Run `/doc-sync` to apply all pending documentation updates
 - Run `/doc-audit` for a full project documentation review
 ### Documentation Files Tracked
 - README.md (root and subdirectories)
 - CLAUDE.md
 - API documentation in docs/
 - Docstrings in Python/TypeScript files
 ### Commit Convention
 Documentation sync commits use: `docs: sync documentation with code changes`
--- a/plugins/doc-guardian/commands/doc-audit.md
+++ b/plugins/doc-guardian/commands/doc-audit.md
@@ -0,0 +1,50 @@
 ---
 description: Full documentation audit - scans entire project for doc drift without making changes
 ---
 # Documentation Audit
 Perform a comprehensive documentation drift analysis.
 ## Process
 1. **Inventory Documentation Files**
   - README.md (root and subdirectories)
   - CLAUDE.md
   - API documentation
   - Docstrings in code files
   - Configuration references
 2. **Cross-Reference Analysis**
   For each documentation file:
   - Extract referenced functions, classes, endpoints, configs
   - Verify each reference exists in codebase
   - Check signatures/types match documentation
   - Flag deprecated or renamed items still in docs
 3. **Completeness Check**
   - Public functions without docstrings
   - Exported modules without README coverage
   - Environment variables used but not documented
   - CLI commands not in help text
 4. **Output Format**
 ```
 ## Documentation Drift Report
 ### Critical (Broken References)
 - [ ] README.md:45 references `calculate_total()` - function renamed to `compute_total()`
 ### Stale (Outdated Info)
 - [ ] CLAUDE.md:23 lists Python 3.9 - project uses 3.11
 ### Missing (Undocumented)
 - [ ] api/handlers.py:`create_order()` - no docstring
 ### Summary
 - Critical: X items
 - Stale: X items
 - Missing: X items
 ```
 5. **Do NOT make changes** - audit only, report findings
--- a/plugins/doc-guardian/commands/doc-sync.md
+++ b/plugins/doc-guardian/commands/doc-sync.md
@@ -0,0 +1,58 @@
 ---
 description: Synchronize all pending documentation updates in a single commit
 ---
 # Documentation Sync
 Apply all pending documentation updates detected by doc-guardian hooks.
 ## Process
 1. **Review Pending Queue**
   List all documentation drift detected during this session.
 2. **Batch Updates**
   For each pending item:
   - Show the specific change needed
   - Apply the update
   - Track in change list
 3. **Update Types**
   **Reference Fixes:**
   - Renamed function/class → update all doc references
   - Changed signature → update parameter documentation
   - Removed item → remove or mark deprecated in docs
   **Content Sync:**
   - Version numbers (Python, Node, dependencies)
   - Configuration keys/values
   - File paths and directory structures
   - Command examples and outputs
   **Structural:**
   - Add missing sections for new features
   - Remove sections for deleted features
   - Reorder to match current code organization
 4. **Commit Strategy**
   - Stage all doc changes together
   - Single commit: `docs: sync documentation with code changes`
   - Include summary of what was updated in commit body
 5. **Output**
 ```
 ## Documentation Sync Complete
 ### Files Updated
 - README.md (3 changes)
 - CLAUDE.md (1 change)
 - src/api/README.md (2 changes)
 ### Changes Applied
 - Updated function reference: calculate_total → compute_total
 - Updated Python version: 3.9 → 3.11
 - Added docstring to create_order()
 Committed: abc123f
 ```
--- a/plugins/doc-guardian/hooks/hooks.json
+++ b/plugins/doc-guardian/hooks/hooks.json
@@ -0,0 +1,15 @@
 {
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "[doc-guardian] QUICK drift check (DO NOT block workflow):\n\n1. ONLY check if the modified file is referenced in README.md, CLAUDE.md, or API docs in the SAME directory\n2. Do NOT read files or perform deep analysis - just note potential drift based on file name/path\n3. If potential drift: output a single line like '[doc-guardian] Note: {filename} changed - may affect {doc}. Run /doc-sync to verify.'\n4. If no obvious drift: say nothing\n\nIMPORTANT: This is notification-only. Do NOT read documentation files, do NOT make changes, do NOT use any tools. Just a quick mental check based on the file path."
          }
        ]
      }
    ]
  }
 }
--- a/plugins/doc-guardian/skills/doc-patterns/SKILL.md
+++ b/plugins/doc-guardian/skills/doc-patterns/SKILL.md
@@ -0,0 +1,39 @@
 ---
 description: Knowledge of documentation patterns and structures for drift detection
 ---
 # Documentation Patterns Skill
 ## Common Documentation Structures
 ### README.md Patterns
 - Installation section: version requirements, dependencies
 - Usage section: function calls, CLI commands
 - Configuration section: env vars, config files
 - API section: endpoint references
 ### CLAUDE.md Patterns
 - Project context: tech stack versions
 - File structure: directory layout
 - Commands: available operations
 - Workflows: process descriptions
 ### Code Documentation
 - Docstrings: function signatures, parameters, returns
 - Type hints: should match docstring types
 - Comments: inline references to other code
 ## Drift Detection Rules
 1. **Version Mismatch**: Any hardcoded version in docs must match package.json, pyproject.toml, requirements.txt
 2. **Function References**: Function names in docs must exist in codebase with matching signatures
 3. **Path References**: File paths in docs must exist in current directory structure
 4. **Config Keys**: Environment variables and config keys in docs must be used in code
 5. **Command Examples**: CLI examples in docs should be valid commands
 ## Priority Levels
 - **P0 (Critical)**: Broken references that would cause user errors
 - **P1 (High)**: Outdated information that misleads users
 - **P2 (Medium)**: Missing documentation for public interfaces
 - **P3 (Low)**: Style inconsistencies, minor wording issues
--- a/plugins/git-flow/.claude-plugin/plugin.json
+++ b/plugins/git-flow/.claude-plugin/plugin.json
@@ -0,0 +1,20 @@
 {
  "name": "git-flow",
  "version": "1.0.0",
  "description": "Git workflow automation with intelligent commit messages and branch management",
  "author": {
    "name": "Leo Miranda",
    "email": "leobmiranda@gmail.com"
  },
  "homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/git-flow/README.md",
  "repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
  "license": "MIT",
  "keywords": [
    "git",
    "workflow",
    "commit",
    "branch",
    "automation"
  ],
  "commands": ["./commands/"]
 }
--- a/plugins/git-flow/README.md
+++ b/plugins/git-flow/README.md
@@ -0,0 +1,128 @@
 # 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 |
 | `/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
 - Warns before commits 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
 ```
 ## Integration
 For CLAUDE.md integration instructions, see `claude-md-integration.md`.
 ## License
 MIT
--- a/plugins/git-flow/agents/git-assistant.md
+++ b/plugins/git-flow/agents/git-assistant.md
@@ -0,0 +1,139 @@
 # Git Assistant Agent
 ## Role
 You are a git workflow assistant that helps users navigate complex git operations, resolve conflicts, and maintain clean repository history.
 ## Capabilities
 ### 1. Conflict Resolution
 Guide users through merge conflicts:
 ```
 Conflict detected in: src/auth/login.ts
 Let me analyze the conflict:
 <<<<<<< HEAD (your changes)
 function login(user: User) {
  return authenticate(user.email, user.password);
 }
 =======
 function login(credentials: Credentials) {
  return authenticate(credentials);
 }
 >>>>>>> development (incoming)
 Analysis:
 - Your version: Uses User type, explicit parameters
 - Their version: Uses Credentials type, single object
 Recommendation:
 The incoming change uses a cleaner pattern. However, you'll need
 to ensure User type is converted to Credentials.
 Options:
 1. Accept theirs (update your code to use Credentials)
 2. Accept yours (they'll need to adapt)
 3. Combine both (create overloaded function)
 4. Need more context about Credentials type
 ```
 ### 2. History Cleanup
 Help with rebasing, squashing, and amending:
 ```
 Your branch has 15 commits, including:
 - 5 "WIP" commits
 - 3 "fix typo" commits
 - 2 "oops" commits
 Before merging, would you like to clean up history?
 Options:
 1. Squash all into single commit (cleanest)
 2. Interactive rebase (you pick what to squash)
 3. Keep as-is (preserve full history)
 ```
 ### 3. Recovery Operations
 Help users recover from mistakes:
 ```
 Accidentally deleted a branch? Let's recover it:
 Recent deleted branches (from reflog):
 - feat/important-feature (deleted 5 mins ago)
  Last commit: abc1234 "Add important feature"
 Recover this branch?
 ```
 ### 4. Complex Merges
 Handle cherry-picks, partial merges, octopus merges:
 ```
 You want to merge only specific commits from feat/mixed-changes.
 Commits in that branch:
 1. abc1234 - Add user auth (✓ want this)
 2. def5678 - Fix unrelated bug (✗ skip)
 3. ghi9012 - Add password reset (✓ want this)
 I'll cherry-pick commits 1 and 3. Proceed?
 ```
 ## Communication Style
 ### Clear Explanations
 - Explain what each command does before running
 - Show the before/after state
 - Highlight risks
 ### Safe Defaults
 - Always prefer non-destructive operations
 - Confirm before force operations
 - Create backups before risky operations
 ### Educational
 - Explain why conflicts occur
 - Teach patterns to avoid issues
 - Suggest workflow improvements
 ## Safety Protocols
 ### Before Destructive Operations
 ```
 ⚠️ This operation will:
 - Rewrite history for 5 commits
 - Require force push to remote
 - Affect other team members
 Creating backup branch: backup/feat-password-reset-20240120
 Proceed? (yes/no)
 ```
 ### Protected Branches
 ```
 ⛔ Cannot directly modify 'main' branch.
 This branch is protected. You should:
 1. Create a feature branch
 2. Make your changes
 3. Create a pull request
 Would you like me to create a branch for this change?
 ```
 ## Output Style
 Always show:
 - What will happen
 - Current state
 - Expected outcome
 - Recovery options if things go wrong
--- a/plugins/git-flow/claude-md-integration.md
+++ b/plugins/git-flow/claude-md-integration.md
@@ -0,0 +1,55 @@
 # git-flow - CLAUDE.md Integration
 Add the following section to your project's CLAUDE.md file to enable git-flow.
 ---
 ## Git Workflow
 This project uses the git-flow plugin for git operations.
 ### Workflow Style
 **Style:** feature-branch
 **Base Branch:** development
 ### Branch Naming
 Use the format: `<type>/<description>`
 Types: feat, fix, chore, docs, refactor, test, perf
 Examples:
 - `feat/add-user-auth`
 - `fix/login-timeout`
 - `chore/update-deps`
 ### Commit Messages
 Use conventional commits:
 ```
 <type>(<scope>): <description>
 [body]
 [footer]
 ```
 ### Commands
 | Command | Use Case |
 |---------|----------|
 | `/commit` | Create commit with smart message |
 | `/commit-push` | Commit and push |
 | `/commit-merge` | Commit and merge to base |
 | `/branch-start` | Start new branch |
 | `/git-status` | Enhanced status |
 ### Protected Branches
 Do not commit directly to: main, development, staging
 ---
 Copy the section between the horizontal rules into your CLAUDE.md.
--- a/plugins/git-flow/commands/branch-cleanup.md
+++ b/plugins/git-flow/commands/branch-cleanup.md
@@ -0,0 +1,117 @@
 # /branch-cleanup - Clean Merged and Stale Branches
 ## Purpose
 Remove branches that have been merged OR whose remote tracking branch no longer exists, both locally and optionally on remote.
 ## Behavior
 ### Step 1: Prune Remote Refs
 ```bash
 # Remove stale remote-tracking references
 git fetch --prune
 ```
 ### Step 2: Identify Branches for Cleanup
 ```bash
 # Find merged local branches
 git branch --merged <base-branch>
 # Find merged remote branches
 git branch -r --merged <base-branch>
 # Find local branches with deleted upstreams (stale)
 git branch -vv | grep ': gone]'
 ```
 ### Step 3: Present Findings
 ```
 Found branches for cleanup:
 Merged (safe to delete):
  - feat/login-page (merged 3 days ago)
  - fix/typo-header (merged 1 week ago)
  - chore/deps-update (merged 2 weeks ago)
 Stale (remote deleted):
  - feat/old-feature (upstream gone)
  - fix/already-merged (upstream gone)
 Remote (merged into base):
  - origin/feat/login-page
  - origin/fix/typo-header
 Protected (won't delete):
  - main
  - development
  - staging
 Delete these branches?
 1. Delete all (local merged + stale + remote)
 2. Delete merged only (skip stale)
 3. Delete stale only (upstream gone)
 4. Let me pick which ones
 5. Cancel
 ```
 ### Step 4: Execute Cleanup
 ```bash
 # Delete merged local branches
 git branch -d <branch-name>
 # Delete stale local branches (force needed since no upstream)
 git branch -D <stale-branch-name>
 # Delete remote branches
 git push origin --delete <branch-name>
 ```
 ### Step 5: Report
 ```
 Cleanup complete:
 Deleted local (merged): 3 branches
 Deleted local (stale): 2 branches
 Deleted remote: 2 branches
 Skipped: 0 branches
 Remaining local branches:
  - main
  - development
  - feat/current-work (not merged, has upstream)
 ```
 ## Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_DEFAULT_BASE` | `development` | Base branch for merge detection |
 | `GIT_PROTECTED_BRANCHES` | `main,master,development,staging,production` | Never delete these |
 | `GIT_AUTO_DELETE_REMOTE` | `false` | Auto-delete remote branches |
 | `GIT_CLEANUP_STALE` | `true` | Include stale branches (upstream gone) in cleanup |
 ## Safety
 - Never deletes protected branches
 - Warns about unmerged branches that still have upstreams
 - Confirms before deleting remote branches
 - Uses `-d` (safe delete) for merged branches
 - Uses `-D` (force delete) only for stale branches with confirmation
 - Stale branches are highlighted separately for review
 ## Output
 On success:
 ```
 Cleaned up:
  Local (merged): 3 branches deleted
  Local (stale): 2 branches deleted
  Remote: 2 branches deleted
 Repository is tidy!
 ```
--- a/plugins/git-flow/commands/branch-start.md
+++ b/plugins/git-flow/commands/branch-start.md
@@ -0,0 +1,96 @@
 # /branch-start - Start New Branch
 ## Purpose
 Create a new feature/fix/chore branch with consistent naming conventions.
 ## Usage
 ```
 /branch-start [description]
 ```
 ## Behavior
 ### Step 1: Determine Branch Type
 ```
 What type of change is this?
 1. feat - New feature
 2. fix - Bug fix
 3. chore - Maintenance task
 4. docs - Documentation
 5. refactor - Code refactoring
 ```
 ### Step 2: Get Description
 If not provided, ask:
 ```
 Brief description (2-4 words):
 > add user authentication
 ```
 ### Step 3: Generate Branch Name
 Convert to kebab-case:
 - `feat/add-user-authentication`
 - `fix/login-timeout-error`
 - `chore/update-dependencies`
 ### Step 4: Create Branch
 ```bash
 # Ensure base branch is up-to-date
 git checkout <base-branch>
 git pull origin <base-branch>
 # Create and switch to new branch
 git checkout -b <new-branch>
 ```
 ### Step 5: Confirm
 ```
 Created branch: feat/add-user-authentication
 Based on: development (abc1234)
 Ready to start coding!
 ```
 ## Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_DEFAULT_BASE` | `development` | Branch to create from |
 | `GIT_BRANCH_PREFIX` | `true` | Use type/ prefix |
 ## Naming Rules
 - Lowercase only
 - Hyphens for spaces
 - No special characters
 - Max 50 characters
 ## Validation
 ```
 Branch name validation:
 ✓ Lowercase
 ✓ Valid prefix (feat/)
 ✓ Descriptive (3+ words recommended)
 ✗ Too long (52 chars, max 50)
 Suggested: feat/add-user-auth
 Use this instead? (y/n)
 ```
 ## Output
 On success:
 ```
 Branch: feat/add-user-authentication
 Base: development @ abc1234
 Status: Ready for development
 ```
--- a/plugins/git-flow/commands/commit-merge.md
+++ b/plugins/git-flow/commands/commit-merge.md
@@ -0,0 +1,83 @@
 # /commit-merge - Commit and Merge
 ## Purpose
 Commit current changes, then merge the current branch into a target branch.
 ## Behavior
 ### Step 1: Run /commit
 Execute the standard commit workflow.
 ### Step 2: Identify Target Branch
 Check environment or ask:
 ```
 Merge into which branch?
 1. development (Recommended - GIT_DEFAULT_BASE)
 2. main
 3. Other: ____
 ```
 ### Step 3: Merge Strategy
 ```
 How should I merge?
 1. Merge commit (preserves history)
 2. Squash and merge (single commit)
 3. Rebase (linear history)
 ```
 ### Step 4: Execute Merge
 ```bash
 # Switch to target
 git checkout <target>
 # Pull latest
 git pull origin <target>
 # Merge feature branch
 git merge <feature-branch> [--squash] [--no-ff]
 # Push
 git push origin <target>
 ```
 ### Step 5: Cleanup (Optional)
 ```
 Merge complete. Delete the feature branch?
 1. Yes, delete local and remote (Recommended)
 2. Delete local only
 3. Keep the branch
 ```
 ## Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_DEFAULT_BASE` | `development` | Default branch to merge into |
 | `GIT_MERGE_STRATEGY` | `merge` | Default merge strategy |
 | `GIT_AUTO_DELETE_MERGED` | `true` | Auto-delete merged branches |
 ## Safety Checks
 - Verify target branch exists
 - Check for uncommitted changes before switching
 - Ensure merge doesn't conflict (preview first)
 ## Output
 On success:
 ```
 Committed: abc1234
 feat(auth): add password reset functionality
 Merged feat/password-reset → development
 Deleted branch: feat/password-reset
 development is now at: def5678
 ```
--- a/plugins/git-flow/commands/commit-push.md
+++ b/plugins/git-flow/commands/commit-push.md
@@ -0,0 +1,57 @@
 # /commit-push - Commit and Push
 ## Purpose
 Create a commit and push to the remote repository in one operation.
 ## Behavior
 ### Step 1: Run /commit
 Execute the standard commit workflow (see commit.md).
 ### Step 2: Push to Remote
 After successful commit:
 1. Check if branch has upstream tracking
 2. If no upstream, set it: `git push -u origin <branch>`
 3. If upstream exists: `git push`
 ### Step 3: Handle Conflicts
 If push fails due to diverged history:
 ```
 Remote has changes not in your local branch.
 Options:
 1. Pull and rebase, then push (Recommended)
 2. Pull and merge, then push
 3. Force push (⚠️ destructive)
 4. Cancel and review manually
 ```
 ## Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_AUTO_PUSH` | `true` | Auto-push after commit |
 | `GIT_PUSH_STRATEGY` | `rebase` | How to handle diverged branches |
 ## Safety Checks
 - **Protected branches**: Warn before pushing to main/master/production
 - **Force push**: Require explicit confirmation
 - **No tracking**: Ask before creating new remote branch
 ## Output
 On success:
 ```
 Committed: abc1234
 feat(auth): add password reset functionality
 Pushed to: origin/feat/password-reset
 Remote URL: https://github.com/user/repo
 ```
--- a/plugins/git-flow/commands/commit-sync.md
+++ b/plugins/git-flow/commands/commit-sync.md
@@ -0,0 +1,104 @@
 # /commit-sync - Commit, Push, and Sync
 ## Purpose
 Full sync operation: commit local changes, push to remote, sync with upstream/base branch, and clean up stale remote-tracking branches.
 ## Behavior
 ### Step 1: Run /commit
 Execute the standard commit workflow.
 ### Step 2: Push to Remote
 Push committed changes to remote branch.
 ### Step 3: Sync with Base
 Pull latest from base branch and rebase/merge:
 ```bash
 # Fetch all with prune (removes stale remote-tracking refs)
 git fetch --all --prune
 # Rebase on base branch
 git rebase origin/<base-branch>
 # Push again (if rebased)
 git push --force-with-lease
 ```
 ### Step 4: Detect Stale Local Branches
 Check for local branches tracking deleted remotes:
 ```bash
 # Find local branches with gone upstreams
 git branch -vv | grep ': gone]'
 ```
 If stale branches found, report them:
 ```
 Stale local branches (remote deleted):
  - feat/old-feature (was tracking origin/feat/old-feature)
  - fix/merged-bugfix (was tracking origin/fix/merged-bugfix)
 Run /branch-cleanup to remove these branches.
 ```
 ### Step 5: Report Status
 ```
 Sync complete:
 Local:  feat/password-reset @ abc1234
 Remote: origin/feat/password-reset @ abc1234
 Base:   development @ xyz7890 (synced)
 Your branch is up-to-date with development.
 No conflicts detected.
 Cleanup:
  Remote refs pruned: 2
  Stale local branches: 2 (run /branch-cleanup to remove)
 ```
 ## Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_DEFAULT_BASE` | `development` | Branch to sync with |
 | `GIT_SYNC_STRATEGY` | `rebase` | How to incorporate upstream changes |
 | `GIT_AUTO_PRUNE` | `true` | Auto-prune stale remote refs on sync |
 ## Conflict Handling
 If conflicts occur during rebase:
 ```
 Conflicts detected while syncing with development.
 Conflicting files:
 - src/auth/login.ts
 - src/auth/types.ts
 Options:
 1. Open conflict resolution (I'll guide you)
 2. Abort sync (keep local state)
 3. Accept all theirs (⚠️ loses your changes in conflicts)
 4. Accept all ours (⚠️ ignores upstream in conflicts)
 ```
 ## Output
 On success:
 ```
 Committed: abc1234
 Pushed to: origin/feat/password-reset
 Synced with: development (xyz7890)
 Status: Clean, up-to-date
 Stale branches: None (or N found - run /branch-cleanup)
 ```
--- a/plugins/git-flow/commands/commit.md
+++ b/plugins/git-flow/commands/commit.md
@@ -0,0 +1,117 @@
 # /commit - Smart Commit
 ## Purpose
 Create a git commit with an auto-generated conventional commit message based on staged changes.
 ## Behavior
 ### Step 1: Analyze Changes
 1. Run `git status` to see staged and unstaged changes
 2. Run `git diff --staged` to examine staged changes
 3. If nothing staged, prompt user to stage changes
 ### Step 2: Generate Commit Message
 Analyze the changes and generate a conventional commit message:
 ```
 <type>(<scope>): <description>
 [optional body]
 [optional footer]
 ```
 **Types:**
 - `feat`: New feature
 - `fix`: Bug fix
 - `docs`: Documentation only
 - `style`: Formatting, missing semicolons, etc.
 - `refactor`: Code change that neither fixes a bug nor adds a feature
 - `perf`: Performance improvement
 - `test`: Adding/updating tests
 - `chore`: Maintenance tasks
 - `build`: Build system or external dependencies
 - `ci`: CI configuration
 **Scope:** Determined from changed files (e.g., `auth`, `api`, `ui`)
 ### Step 3: Confirm or Edit
 Present the generated message:
 ```
 Proposed commit message:
 ───────────────────────
 feat(auth): add password reset functionality
 Implement forgot password flow with email verification.
 Includes rate limiting and token expiration.
 ───────────────────────
 Options:
 1. Use this message (Recommended)
 2. Edit the message
 3. Regenerate with different focus
 4. Cancel
 ```
 ### Step 4: Execute Commit
 If confirmed, run:
 ```bash
 git commit -m "$(cat <<'EOF'
 <message>
 Co-Authored-By: Claude <noreply@anthropic.com>
 EOF
 )"
 ```
 ## Environment Variables
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `GIT_COMMIT_STYLE` | `conventional` | Message style (conventional, simple, detailed) |
 | `GIT_SIGN_COMMITS` | `false` | Use GPG signing |
 | `GIT_CO_AUTHOR` | `true` | Include Claude co-author footer |
 ## Edge Cases
 ### No Changes Staged
 ```
 No changes staged for commit.
 Would you like to:
 1. Stage all changes (`git add -A`)
 2. Stage specific files (I'll help you choose)
 3. Cancel
 ```
 ### Untracked Files
 ```
 Found 3 untracked files:
 - src/new-feature.ts
 - tests/new-feature.test.ts
 - docs/new-feature.md
 Include these in the commit?
 1. Yes, stage all (Recommended)
 2. Let me pick which ones
 3. No, commit only tracked files
 ```
 ## Output
 On success:
 ```
 Committed: abc1234
 feat(auth): add password reset functionality
 Files: 3 changed, 45 insertions(+), 12 deletions(-)
 ```
--- a/plugins/git-flow/commands/git-config.md
+++ b/plugins/git-flow/commands/git-config.md
@@ -0,0 +1,100 @@
 # /git-config - Configure git-flow
 ## Purpose
 Configure git-flow settings for the current project.
 ## Behavior
 ### Interactive Configuration
 ```
 git-flow Configuration
 ═══════════════════════════════════════════
 Current settings:
  GIT_WORKFLOW_STYLE: feature-branch
  GIT_DEFAULT_BASE: development
  GIT_AUTO_DELETE_MERGED: true
  GIT_AUTO_PUSH: false
 What would you like to configure?
 1. Workflow style
 2. Default base branch
 3. Auto-delete merged branches
 4. Auto-push after commit
 5. Protected branches
 6. View all settings
 7. Reset to defaults
 ```
 ### Setting: Workflow Style
 ```
 Choose your workflow style:
 1. simple
   - Direct commits to development
   - No feature branches required
   - Good for solo projects
 2. feature-branch (Recommended)
   - Feature branches from development
   - Merge when complete
   - Good for small teams
 3. pr-required
   - Feature branches from development
   - Requires PR for merge
   - Good for code review workflows
 4. trunk-based
   - Short-lived branches
   - Frequent integration
   - Good for CI/CD heavy workflows
 ```
 ### Setting: Protected Branches
 ```
 Protected branches (comma-separated):
 Current: main, master, development, staging, production
 These branches will:
 - Never be auto-deleted
 - Require confirmation before direct commits
 - Warn before force push
 ```
 ## Environment Variables
 | Variable | Default | Options |
 |----------|---------|---------|
 | `GIT_WORKFLOW_STYLE` | `feature-branch` | simple, feature-branch, pr-required, trunk-based |
 | `GIT_DEFAULT_BASE` | `development` | Any branch name |
 | `GIT_AUTO_DELETE_MERGED` | `true` | true, false |
 | `GIT_AUTO_PUSH` | `false` | true, false |
 | `GIT_PROTECTED_BRANCHES` | `main,master,development,staging,production` | Comma-separated |
 | `GIT_COMMIT_STYLE` | `conventional` | conventional, simple, detailed |
 | `GIT_CO_AUTHOR` | `true` | true, false |
 ## Storage
 Settings are stored in:
 - Project: `.env` or `.claude/settings.json`
 - User: `~/.config/claude/git-flow.env`
 Project settings override user settings.
 ## Output
 After configuration:
 ```
 Configuration saved!
 GIT_WORKFLOW_STYLE=feature-branch
 GIT_DEFAULT_BASE=development
 GIT_AUTO_DELETE_MERGED=true
 These settings will be used for all git-flow commands.
 ```
--- a/plugins/git-flow/commands/git-status.md
+++ b/plugins/git-flow/commands/git-status.md
@@ -0,0 +1,72 @@
 # /git-status - Enhanced Status
 ## Purpose
 Show comprehensive git status with recommendations and insights.
 ## Behavior
 ### Output Format
 ```
 ═══════════════════════════════════════════
 Git Status: <repo-name>
 ═══════════════════════════════════════════
 Branch: feat/password-reset
 Base: development (3 commits ahead, 0 behind)
 Remote: origin/feat/password-reset (synced)
 ─── Changes ───────────────────────────────
 Staged (ready to commit):
  ✓ src/auth/reset.ts (modified)
  ✓ src/auth/types.ts (modified)
 Unstaged:
  • tests/auth.test.ts (modified)
  • src/utils/email.ts (new file, untracked)
 ─── Recommendations ───────────────────────
 1. Stage test file: git add tests/auth.test.ts
 2. Consider adding new file: git add src/utils/email.ts
 3. Ready to commit with 2 staged files
 ─── Quick Actions ─────────────────────────
 • /commit - Commit staged changes
 • /commit-push - Commit and push
 • /commit-sync - Full sync with development
 ═══════════════════════════════════════════
 ```
 ## Analysis Provided
 ### Branch Health
 - Commits ahead/behind base branch
 - Sync status with remote
 - Age of branch
 ### Change Categories
 - Staged (ready to commit)
 - Modified (not staged)
 - Untracked (new files)
 - Deleted
 - Renamed
 ### Recommendations
 - What to stage
 - What to ignore
 - When to commit
 - When to sync
 ### Warnings
 - Large number of changes (consider splitting)
 - Old branch (consider rebasing)
 - Conflicts with upstream
 ## Output
 Always produces the formatted status report with context-aware recommendations.
--- a/Show More
+++ b/Show More
`@@ -294,4 +294,4 @@ logging.basicConfig(level=logging.DEBUG)`

	`## License`	`## License`

	Part of the Bandit Labs Claude Code Plugins project (`support-claude-mktplace`).	`MIT License - Part of the Leo Claude Marketplace.`
@@ -167,4 +167,4 @@ The plugin uses the shared NetBox MCP server at `../mcp-servers/netbox/`.

	`## License`	`## License`

	`MIT License - Part of the Bandit Labs plugin collection.`	`MIT License - Part of the Leo Claude Marketplace.`