19 Commits

Author SHA1 Message Date
39ad0043c6 fix: bump projman version to 3.0.0
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 17:01:25 -05:00
e5ca804692 feat: v3.0.0 architecture overhaul
- Rename marketplace to lm-claude-plugins
- Move MCP servers to root with symlinks
- Add 6 PR tools to Gitea MCP (list_pull_requests, get_pull_request,
  get_pr_diff, get_pr_comments, create_pr_review, add_pr_comment)
- Add clarity-assist plugin (prompt optimization with ND accommodations)
- Add git-flow plugin (workflow automation)
- Add pr-review plugin (multi-agent review with confidence scoring)
- Centralize configuration docs
- Update all documentation for v3.0.0

BREAKING CHANGE: MCP server paths changed, marketplace renamed

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 16:56:53 -05:00
c1e9382031 docs: sync all documentation with v2.3.0 changes
Updates missed in initial implementation:
- projman/README.md: add /test-gen command documentation and update architecture
- CLAUDE.md: bump to v2.3.0, add doc-guardian and code-sentinel to plugin table,
  update projman version, update command count to 9, update repository structure
- docs/CANONICAL-PATHS.md: add doc-guardian and code-sentinel plugin paths

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:43:02 -05:00
b6c632b75f docs: update CHANGELOG for v2.3.0 release
Document all additions in v2.3.0:
- doc-guardian plugin with /doc-audit and /doc-sync commands
- code-sentinel plugin with /security-scan, /refactor, /refactor-dry commands
- projman /test-gen command for test generation
- Version bumps for marketplace and projman

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:36:23 -05:00
a8ea1fcc25 docs: add doc-guardian and code-sentinel to README, update projman commands
- Update marketplace version to v2.3.0
- Add doc-guardian plugin section (documentation lifecycle management)
- Add code-sentinel plugin section (security scanning & refactoring)
- Update projman commands to include /test-gen
- Update repository structure diagram

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:35:44 -05:00
ebb950d39c chore(projman): bump version to 2.3.0 for test-gen command
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:34:43 -05:00
b508d4bcce feat: register doc-guardian and code-sentinel plugins in marketplace
- Add doc-guardian v1.0.0 with PostToolUse and Stop hooks
- Add code-sentinel v1.0.0 with PreToolUse hook
- Update marketplace version to 2.3.0
- Update projman version to 2.3.0
- Update hookMapping for new plugins

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:34:09 -05:00
23537158bc feat(projman): add /test-gen command for test generation
Adds test generation command that complements existing /test-check:
- Auto-detects test framework (pytest, jest, vitest, go test, etc.)
- Generates unit, integration, e2e, or snapshot tests
- Creates happy path, edge case, and error tests
- Supports multiple languages (Python, JavaScript, Go, etc.)
- Integrates with /test-check for generate-then-verify workflow

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:33:22 -05:00
870ed26510 feat: add code-sentinel plugin for security scanning and refactoring
Adds security scanning via PreToolUse hooks + refactoring commands:
- PreToolUse hook catches security issues before code is written
- /security-scan command for comprehensive security audit
- /refactor command to apply refactoring patterns
- /refactor-dry command to preview refactoring opportunities
- security-reviewer agent for vulnerability analysis
- refactor-advisor agent for code structure improvements
- security-patterns skill for vulnerability detection rules

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:32:43 -05:00
395daecda8 feat: add doc-guardian plugin for documentation lifecycle management
Adds automatic documentation drift detection and synchronization:
- PostToolUse hook detects when code changes affect docs
- Stop hook reminds of pending updates before session ends
- /doc-audit command for full project documentation scan
- /doc-sync command to batch apply pending updates
- doc-analyzer agent for cross-reference analysis
- doc-patterns skill for documentation structure knowledge

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 12:30:42 -05:00
337f40600a Merge pull request 'fix: remove Wiki.js references from architecture docs' (#35) from development into main
Reviewed-on: personal-projects/support-claude-mktplace#35
2026-01-20 16:24:53 +00:00
14425cfad1 fix: remove Wiki.js references from architecture docs
- Updated agent-workflow.spec.md to use Gitea Wiki instead of Wiki.js
- Updated component-map.spec.md to show Gitea (Issues + Wiki) as single service
- Changed GraphQL references to REST API (Gitea uses REST)
- Added Code Reviewer agent swimlane to agent-workflow diagram
- Added ARCHITECTURE NOTES sections to clarify current design

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 11:22:20 -05:00
c38404a98a Merge pull request 'development: small fixes in the changelog' (#34) from development into main
Reviewed-on: personal-projects/support-claude-mktplace#34
2026-01-20 16:17:13 +00:00
70d3933da4 docs: update CHANGELOG with complete version history and add maintenance rules
CHANGELOG.md updates:
- Added proper dates to all versions (2.1.0, 2.0.0, 1.0.0, 0.1.0)
- Added v2.0.0 section (was missing)
- Added v1.0.0 section with initial features
- Updated v2.2.0 with version consolidation changes
- Follows Keep a Changelog format

CLAUDE.md updates:
- Added "Changelog Maintenance (MANDATORY)" section
- Documented required steps when releasing new version
- Added Semantic Versioning reference
- Clarified version display rules

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 11:15:55 -05:00
cce2066d3b fix: consolidate version display to main README.md only
Version standardization:
- Move version to main README.md title: "Claude Code Marketplace - v2.2.0"
- Remove version from plugins/projman/README.md title
- Remove version from plugins/projman/CONFIGURATION.md title
- Remove version from plugin listings in README.md
- Remove "Key Features (v2.2.0)" -> "Key Features"
- Remove Version section from plugins/projman/README.md
- Remove version references from CLAUDE.md structure comments

Added versioning rule to CLAUDE.md:
- Version displayed ONLY in main README.md title
- Do NOT add versions to plugin docs or config guides
- Version history maintained in CHANGELOG.md only

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 11:12:44 -05:00
5d95e42eb5 Merge pull request 'development: final tuning adjustments' (#33) from development into main
Reviewed-on: personal-projects/support-claude-mktplace#33
2026-01-20 15:55:14 +00:00
f35706e621 chore: remove obsolete docs/references/ planning documents
Deleted (obsolete planning docs from pre-implementation phase):
- docs/references/MCP-GITEA.md - wrong MCP server location
- docs/references/MCP-WIKIJS.md - Wiki.js MCP never implemented
- docs/references/PLUGIN-PMO.md - projman-pmo not yet built
- docs/references/PLUGIN-PROJMAN.md - superseded by plugins/projman/README.md
- docs/references/PROJECT-SUMMARY.md - outdated architecture

Updated references in:
- CLAUDE.md - removed docs/references/ from documentation index
- docs/CANONICAL-PATHS.md - removed references directory from structure
- docs/UPDATING.md - updated to reference current documentation
- plugins/projman/mcp-servers/gitea/README.md - fixed related docs links
- plugins/projman/mcp-servers/gitea/TESTING.md - fixed resource links

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 10:52:35 -05:00
697031c526 docs: overhaul CLAUDE.md for v2.2.0 with maintainer best practices
Complete rewrite following claude-config-maintainer principles:
- Clear, concise, complete, current
- Scannable structure with tables
- Critical rules prominently placed
- Quick Start section added

Updates:
- Version: 2.2.0, Status: Production Ready
- Four-Agent Model (added Code Reviewer)
- New commands: /review, /test-check
- New file: validate-marketplace.sh
- Removed outdated "Next Steps" and stale dates
- Consolidated verbose sections into tables
- Added Version History table

Reduced from ~480 lines to ~195 lines while maintaining all essential information.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 10:34:13 -05:00
32797ce473 Merge pull request 'development: new version launched (v2.2.0)' (#32) from development into main
Reviewed-on: personal-projects/support-claude-mktplace#32
2026-01-20 15:23:12 +00:00
110 changed files with 6168 additions and 7190 deletions

View File

@@ -1,17 +1,17 @@
{
"name": "claude-code-marketplace",
"name": "lm-claude-plugins",
"owner": {
"name": "Leo Miranda",
"email": "leobmiranda@gmail.com"
},
"metadata": {
"description": "Project management plugins with Gitea and NetBox integrations",
"version": "2.2.0"
"version": "3.0.0"
},
"plugins": [
{
"name": "projman",
"version": "2.2.0",
"version": "3.0.0",
"description": "Sprint planning and project management with Gitea integration",
"source": "./plugins/projman",
"author": {
@@ -21,7 +21,46 @@
"homepage": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace/src/branch/main/plugins/projman/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": ["gitea"],
"integrationFile": "claude-md-integration.md"
"integrationFile": "claude-md-integration.md",
"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/support-claude-mktplace/src/branch/main/plugins/doc-guardian/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": [],
"integrationFile": "claude-md-integration.md",
"hooks": ["PostToolUse", "Stop"],
"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/support-claude-mktplace/src/branch/main/plugins/code-sentinel/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": [],
"integrationFile": "claude-md-integration.md",
"hooks": ["PreToolUse"],
"category": "security",
"tags": ["security-scan", "refactoring", "vulnerabilities"],
"license": "MIT"
},
{
"name": "project-hygiene",
@@ -36,7 +75,10 @@
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": [],
"integrationFile": "claude-md-integration.md",
"hooks": ["PostToolUse"]
"hooks": ["PostToolUse"],
"category": "productivity",
"tags": ["cleanup", "automation", "hygiene"],
"license": "MIT"
},
{
"name": "cmdb-assistant",
@@ -50,7 +92,10 @@
"homepage": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace/src/branch/main/plugins/cmdb-assistant/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": ["netbox"],
"integrationFile": "claude-md-integration.md"
"integrationFile": "claude-md-integration.md",
"category": "infrastructure",
"tags": ["cmdb", "netbox", "dcim", "ipam"],
"license": "MIT"
},
{
"name": "claude-config-maintainer",
@@ -64,7 +109,61 @@
"homepage": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace/src/branch/main/plugins/claude-config-maintainer/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": [],
"integrationFile": "claude-md-integration.md"
"integrationFile": "claude-md-integration.md",
"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/support-claude-mktplace/src/branch/main/plugins/clarity-assist/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": [],
"integrationFile": "claude-md-integration.md",
"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/support-claude-mktplace/src/branch/main/plugins/git-flow/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": [],
"integrationFile": "claude-md-integration.md",
"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/support-claude-mktplace/src/branch/main/plugins/pr-review/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"mcpServers": ["gitea"],
"integrationFile": "claude-md-integration.md",
"category": "development",
"tags": ["code-review", "pull-requests", "security", "quality"],
"license": "MIT"
}
],
"pluginDetection": {
@@ -73,7 +172,9 @@
"netbox": "cmdb-assistant"
},
"hookMapping": {
"PostToolUse:Write|Edit": "project-hygiene"
"PostToolUse:Write|Edit": "project-hygiene",
"PostToolUse:Write|Edit|MultiEdit": "doc-guardian",
"PreToolUse:Write|Edit|MultiEdit": "code-sentinel"
}
}
}

View File

@@ -1,9 +1,91 @@
# Changelog
All notable changes to support-claude-mktplace will be documented in this file.
All notable changes to lm-claude-plugins will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
## [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 `lm-claude-plugins`
- **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
@@ -15,18 +97,26 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
- `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`
## [2.1.0] - Previous Release
### 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
@@ -37,16 +127,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
@@ -54,21 +140,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
- Wiki.js MCP server
- 43-label taxonomy system
- Lessons learned capture system
- Hybrid configuration system (system + project level)
- Three-agent model (planner, orchestrator, executor)
- Branch-aware security model
- claude-config-maintainer plugin structure
- cmdb-assistant plugin structure
- Basic marketplace manifest

647
CLAUDE.md
View File

@@ -1,478 +1,239 @@
# 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:** lm-claude-plugins
**Version:** 3.0.0
**Status:** Production Ready
1. **`projman`** - Single-repository project management plugin with Gitea integration
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
A Claude Code plugin marketplace containing:
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
# Run projman commands (in a target project with plugin installed)
/sprint-plan # Start sprint planning
/sprint-status # Check progress
/review # Pre-close code quality review
/test-check # Verify tests before close
/sprint-close # Complete sprint
```
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**
- User must confirm paths are correct before proceeding
### Relative Path Rules
- Plugin to bundled MCP server: `${CLAUDE_PLUGIN_ROOT}/mcp-servers/{server}`
- 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**
## Repository Structure
```
personal-projects/support-claude-mktplace/
lm-claude-plugins/
├── .claude-plugin/
│ └── marketplace.json
├── plugins/ # ← ALL PLUGINS (with bundled MCP servers)
│ ├── projman/ # ← PROJECT PLUGIN
│ ├── .claude-plugin/
│ │ │ └── plugin.json
│ ├── .mcp.json # Points to ${CLAUDE_PLUGIN_ROOT}/mcp-servers/
│ │ ├── mcp-servers/ # ← MCP servers BUNDLED IN plugin
│ │ │ └── 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
│ └── marketplace.json # Marketplace manifest
├── mcp-servers/ # SHARED MCP servers (v3.0.0+)
│ ├── gitea/ # Gitea MCP (issues, PRs, wiki)
└── netbox/ # NetBox MCP (CMDB)
── plugins/
│ ├── projman/ # Sprint management
│ │ ├── .claude-plugin/plugin.json
│ │ ├── .mcp.json
│ │ ├── commands/
│ │ ├── agents/
│ │ ── pmo-coordinator.md
│ │ └── README.md
│ ├── cmdb-assistant/ # ← CMDB PLUGIN
│ │ ├── .claude-plugin/
│ │ ── plugin.json
│ │ ├── .mcp.json # Points to ${CLAUDE_PLUGIN_ROOT}/mcp-servers/
│ │ ├── mcp-servers/ # ← MCP servers BUNDLED IN plugin
│ │ │ └── netbox/
│ │ │ ├── .venv/
│ │ │ ├── requirements.txt
│ │ │ └── mcp_server/
│ │ ├── commands/
│ │ ├── mcp-servers/gitea -> ../../../mcp-servers/gitea # SYMLINK
│ │ ├── commands/ # 9 commands
│ │ ── agents/ # 4 agents
│ │ └── skills/label-taxonomy/
│ ├── git-flow/ # Git workflow automation (NEW v3.0.0)
│ │ ├── .claude-plugin/plugin.json
│ │ ── commands/ # 8 commands
│ │ └── agents/
── project-hygiene/ # ← CLEANUP PLUGIN
── ...
├── scripts/ # Setup and maintenance scripts
│ ├── setup.sh
└── post-update.sh
── pr-review/ # Multi-agent PR review (NEW v3.0.0)
── .claude-plugin/plugin.json
│ │ ├── .mcp.json
│ ├── mcp-servers/gitea -> ../../../mcp-servers/gitea # SYMLINK
│ ├── commands/ # 3 commands
│ │ └── 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
- This is a **private repository** - credentials in `.env` files are intentional
- **NEVER** add `.env` or `.env.*` to .gitignore
- **NEVER** add venv patterns unless explicitly asked
- If you think something should be ignored, ASK FIRST
### File Operations
- **NEVER** create files in repository root unless listed in "Allowed Root Files"
- **NEVER** modify `.gitignore` without explicit permission
- **ALWAYS** use `.scratch/` for temporary/exploratory work
- **ALWAYS** verify paths against `docs/CANONICAL-PATHS.md` before creating files
### Plugin Structure Requirements
- **plugin.json MUST be in `.claude-plugin/` directory** - NOT in plugin root
- Every plugin in the repo MUST be listed in the marketplace.json
- After creating/modifying a plugin, VERIFY it's in the marketplace
### Plugin Development
- **plugin.json MUST be in `.claude-plugin/` directory** (not plugin root)
- **Every plugin MUST be listed in marketplace.json**
- **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)
- **Valid events**: `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:
```json
{
"hooks": {
"EventName": [
{
"matcher": "optional-pattern",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/path/to/script.sh"
}
]
}
]
}
}
### Hooks (Valid Events Only)
`PreToolUse`, `PostToolUse`, `UserPromptSubmit`, `SessionStart`, `SessionEnd`, `Notification`, `Stop`, `SubagentStop`, `PreCompact`
**INVALID:** `task-completed`, `file-changed`, `git-commit-msg-needed`
### Allowed Root Files
`CLAUDE.md`, `README.md`, `LICENSE`, `CHANGELOG.md`, `.gitignore`, `.env.example`
### Allowed Root Directories
`.claude/`, `.claude-plugin/`, `.claude-plugins/`, `.scratch/`, `docs/`, `hooks/`, `mcp-servers/`, `plugins/`, `scripts/`
## Architecture
### 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_URL, GITEA_TOKEN, GITEA_ORG) |
| Project | `.env` in project root | Repository specification (GITEA_REPO) |
### 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
- 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
## Path Verification Protocol
### Before Completing Any Plugin Work
1. Verify plugin.json is in `.claude-plugin/` directory
2. Verify plugin is listed in marketplace.json
3. Test MCP server configs load correctly
4. Verify hooks use valid event types
5. Check .gitignore wasn't modified inappropriately
**Before creating any file:**
1. Read `docs/CANONICAL-PATHS.md`
2. List all paths to be created/modified
3. Verify each against canonical paths
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/CONFIGURATION.md` | Centralized setup guide |
| `docs/UPDATING.md` | Update guide for the marketplace |
| `plugins/projman/CONFIGURATION.md` | 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)
- **`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
## Versioning and Changelog Rules
**Start with:** `docs/DOCUMENT-INDEX.md` for navigation guidance
### Version Display
**The marketplace version is displayed ONLY in the main `README.md` title.**
## Recent Updates (Updated: 2025-06-11)
- Format: `# Claude Code Marketplace - vX.Y.Z`
- Do NOT add version numbers to individual plugin documentation titles
- Do NOT add version numbers to configuration guides
- Do NOT add version numbers to CLAUDE.md or other docs
### Planning Phase Complete
- 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
### Changelog Maintenance (MANDATORY)
**`CHANGELOG.md` is the authoritative source for version history.**
### Key Architectural Decisions Made
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
When releasing a new version:
1. Update main `README.md` title with new version
2. Update `CHANGELOG.md` with:
- Version number and date: `## [X.Y.Z] - YYYY-MM-DD`
- **Added**: New features, commands, files
- **Changed**: Modifications to existing functionality
- **Fixed**: Bug fixes
- **Removed**: Deleted features, files, deprecated items
3. Update `marketplace.json` metadata version
4. Update plugin `plugin.json` versions if plugin-specific changes
### Next Steps
- Begin Phase 1.1a: Gitea MCP Server implementation
- Set up Python virtual environments
- Create configuration loaders
- Implement core Gitea tools (issues, labels)
- Write integration tests
### Version Format
- Follow [Semantic Versioning](https://semver.org/): MAJOR.MINOR.PATCH
- MAJOR: Breaking changes
- MINOR: New features, backward compatible
- PATCH: Bug fixes, minor improvements
---
**Last Updated:** 2026-01-20

203
README.md
View File

@@ -1,15 +1,17 @@
# Claude Code Marketplace
# Claude Code Marketplace - v3.0.0
A collection of Claude Code plugins for project management, infrastructure automation, and development workflows.
## Plugins
### [projman](./plugins/projman/README.md) v2.2.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, Code Reviewer
- 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
@@ -17,47 +19,88 @@ AI-guided sprint planning with full Gitea integration. Transforms a proven 15-sp
- Branch-aware security (development/staging/production)
- Pre-sprint-close code quality review and test verification
**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/initial-setup`, `/review`, `/test-check`
**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/initial-setup`, `/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`
#### [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)
**NetBox CMDB Integration**
### Productivity
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
- Smart search across all NetBox modules
- Conversational infrastructure queries
- Audit trail and change tracking
Transform vague requests into clear specifications using structured methodology.
**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.)
- Warns about unexpected files in project root
- Identifies orphaned supporting files
- Configurable via `.hygiene.json`
### Security
#### [code-sentinel](./plugins/code-sentinel/README.md)
**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:** `/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.
@@ -68,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.
@@ -103,7 +147,7 @@ Add to `.claude/settings.json` in your target project:
```json
{
"extraKnownMarketplaces": {
"support-claude-mktplace": {
"lm-claude-plugins": {
"source": {
"source": "git",
"url": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git"
@@ -113,34 +157,20 @@ Add to `.claude/settings.json` in your target project:
}
```
**Option 3 - Local development:**
```bash
# Clone the repository first
git clone https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git
# Then add from local path
/plugin marketplace add /path/to/support-claude-mktplace
```
**Alternative SSH URL (for authenticated access):**
```
ssh://git@hotserv.tailc9b278.ts.net:2222/personal-projects/support-claude-mktplace.git
```
### Configure MCP Server Dependencies
If using plugins with MCP servers (projman, cmdb-assistant), install dependencies:
Install dependencies for shared MCP servers:
```bash
# Gitea MCP (for projman)
cd plugins/projman/mcp-servers/gitea
# Gitea MCP (for projman, pr-review)
cd mcp-servers/gitea
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
deactivate
# NetBox MCP (for cmdb-assistant)
cd ../../../cmdb-assistant/mcp-servers/netbox
cd ../netbox
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
@@ -149,7 +179,9 @@ deactivate
### Configure Credentials
**System-level credentials:**
See [docs/CONFIGURATION.md](./docs/CONFIGURATION.md) for complete setup instructions.
**Quick start:**
```bash
mkdir -p ~/.config/claude
@@ -159,19 +191,9 @@ GITEA_URL=https://gitea.example.com
GITEA_TOKEN=your_token
GITEA_ORG=your_org
EOF
chmod 600 ~/.config/claude/gitea.env
# 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
```
**Project-level settings:**
```bash
# In your target project root
# Project-level settings
cat > .env << 'EOF'
GITEA_REPO=your-repository-name
EOF
@@ -180,62 +202,36 @@ EOF
## Repository Structure
```
support-claude-mktplace/
lm-claude-plugins/
├── .claude-plugin/ # Marketplace manifest
│ └── marketplace.json
├── plugins/ # All plugins (with bundled MCP servers)
│ ├── projman/ # Sprint management plugin
│ ├── .claude-plugin/
├── .mcp.json
│ ├── mcp-servers/ # Bundled MCP server
└── gitea/
│ ├── commands/
│ ├── agents/
│ └── skills/
│ ├── claude-config-maintainer/ # CLAUDE.md optimization plugin
│ │ ├── .claude-plugin/
│ │ ├── commands/
│ │ └── agents/
├── mcp-servers/ # SHARED MCP servers (v3.0.0+)
│ ├── gitea/ # Gitea MCP (issues, PRs, wiki)
└── netbox/ # NetBox MCP (CMDB)
├── plugins/ # All plugins
│ ├── projman/ # Sprint management
├── git-flow/ # Git workflow automation (NEW)
│ ├── pr-review/ # PR review (NEW)
│ ├── clarity-assist/ # Prompt optimization (NEW)
├── claude-config-maintainer/ # CLAUDE.md optimization
│ ├── cmdb-assistant/ # NetBox CMDB integration
│ ├── .claude-plugin/
│ ├── .mcp.json
│ ├── mcp-servers/ # Bundled MCP server
└── netbox/
│ ├── commands/
│ └── agents/
│ ├── projman-pmo/ # PMO coordination plugin (planned)
│ └── project-hygiene/ # Cleanup automation plugin
├── docs/ # Reference documentation
│ ├── CANONICAL-PATHS.md # Single source of truth for paths
│ └── references/
└── scripts/ # Setup and maintenance scripts
└── validate-marketplace.sh # Marketplace compliance validation
│ ├── doc-guardian/ # Documentation drift detection
├── code-sentinel/ # Security scanning
└── project-hygiene/ # Cleanup automation
├── docs/ # Documentation
│ ├── CANONICAL-PATHS.md # Path reference
└── CONFIGURATION.md # Setup guide
└── scripts/ # Setup scripts
```
## Key Features (v2.2.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 |
| [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
@@ -245,4 +241,3 @@ MIT License
- **Issues**: Contact repository maintainer
- **Repository**: `https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git`
- **SSH URL**: `ssh://git@hotserv.tailc9b278.ts.net:2222/personal-projects/support-claude-mktplace.git`

View File

@@ -2,50 +2,106 @@
**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/
lm-claude-plugins/
├── .claude/ # Claude Code local settings
├── .claude-plugin/ # Marketplace manifest (claude-code-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
│ ├── UPDATING.md # Update guide
│ └── workflows/ # Workflow documentation
├── hooks/ # Shared hooks (if any)
├── plugins/ # ALL plugins with bundled MCP servers
│ ├── projman/
├── mcp-servers/ # SHARED MCP servers (v3.0.0+)
│ ├── 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
│ │ │ └── gitea/ # Gitea + Wiki tools
│ │ ├── .mcp.json
│ │ ├── mcp-servers/
│ │ │ └── gitea -> ../../../mcp-servers/gitea # SYMLINK
│ │ ├── commands/
│ │ ├── agents/
│ │ ├── skills/
│ │ └── claude-md-integration.md # CLAUDE.md integration snippet
│ ├── projman-pmo/
│ ├── project-hygiene/
│ ├── cmdb-assistant/
│ │ └── claude-md-integration.md
│ ├── doc-guardian/ # Documentation drift detection
│ │ ├── .claude-plugin/
│ │ ├── mcp-servers/ # MCP servers bundled IN plugin
│ │ │ └── netbox/
│ │ ├── hooks/
│ │ ├── commands/
│ │ ├── agents/
│ │ ── claude-md-integration.md # CLAUDE.md integration snippet
│ │ ── 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 # CLAUDE.md integration snippet
── project-hygiene/
│ │ └── 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/
│ ├── hooks/
── claude-md-integration.md # CLAUDE.md integration snippet
│ ├── .mcp.json
── mcp-servers/
│ │ └── gitea -> ../../../mcp-servers/gitea # SYMLINK
│ ├── commands/
│ ├── agents/
│ ├── skills/
│ └── claude-md-integration.md
├── scripts/ # Setup and maintenance scripts
├── CLAUDE.md
├── README.md
@@ -69,31 +125,36 @@ support-claude-mktplace/
| 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/` |
| MCP server code | `plugins/{plugin}/mcp-servers/{server}/mcp_server/` | `plugins/projman/mcp-servers/gitea/mcp_server/` |
| MCP venv | `plugins/{plugin}/mcp-servers/{server}/.venv/` | `plugins/projman/mcp-servers/gitea/.venv/` |
| Shared MCP server | `mcp-servers/{server}/` | `mcp-servers/gitea/` |
| MCP server code | `mcp-servers/{server}/mcp_server/` | `mcp-servers/gitea/mcp_server/` |
| MCP venv | `mcp-servers/{server}/.venv/` | `mcp-servers/gitea/.venv/` |
| Plugin symlink | `plugins/{plugin}/mcp-servers/{server}` | `plugins/projman/mcp-servers/gitea` |
### Relative Path Patterns (CRITICAL)
### Symlink Pattern
| From | To | Pattern |
|------|----|---------|
| Plugin .mcp.json | Bundled MCP server | `${CLAUDE_PLUGIN_ROOT}/mcp-servers/{server}` |
| marketplace.json | Plugin | `./plugins/{plugin-name}` |
Plugins that use MCP servers create symlinks:
```bash
# From plugin directory
ln -s ../../../mcp-servers/gitea plugins/projman/mcp-servers/gitea
```
The symlink target is relative: `../../../mcp-servers/{server}`
### Documentation Paths
| 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` |
---
@@ -111,15 +172,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/
With variable: ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/
Result in .mcp.json: ${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/.venv/bin/python
```
From `.claude-plugin/marketplace.json` to `plugins/projman/`:
@@ -138,18 +199,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/` |
| `../../mcp-servers/` from plugin | Old pattern, doesn't work with caching | `${CLAUDE_PLUGIN_ROOT}/mcp-servers/` |
| `./../../../plugins/projman` in marketplace | Wrong (old nested structure) | `./plugins/projman` |
| Direct path in .mcp.json to root mcp-servers | Use symlink | Symlink at `plugins/{plugin}/mcp-servers/` |
| Creating new mcp-servers inside plugins | Use shared + symlink | Symlink to `mcp-servers/` |
| 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:
- Claude Code caches only the plugin directory when installed
- Relative paths to parent directories break in the cache
- Each plugin must be self-contained to work properly
MCP servers are now **shared at repository root** with **symlinks** from plugins:
**Benefits:**
- 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
```
---
@@ -157,6 +228,11 @@ MCP servers are bundled inside each plugin (not shared at root) because:
| Date | Change | By |
|------|--------|-----|
| 2026-01-19 | Added claude-md-integration.md path pattern for plugin integration snippets | Claude Code |
| 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 lm-claude-plugins | 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 |

380
docs/CONFIGURATION.md Normal file
View File

@@ -0,0 +1,380 @@
# Configuration Guide
Centralized configuration documentation for all plugins and MCP servers in the lm-claude-plugins marketplace.
## Overview
This marketplace uses a **hybrid configuration** approach:
- **System-level:** Credentials and service configuration (stored once per machine)
- **Project-level:** Repository-specific settings (stored per project)
**Benefits:**
- Single token per service (update once, use everywhere)
- Easy multi-project setup (just add `.env` per project)
- Security (tokens never committed to git)
- Project isolation (each project has its own scope)
## Prerequisites
Before configuring any plugin:
1. **Python 3.10+** installed
```bash
python3 --version # Should be 3.10.0 or higher
```
2. **Git repository** initialized
```bash
git status # Should show initialized repository
```
3. **Claude Code** installed and working
---
## System-Level Configuration
Configuration files stored in `~/.config/claude/`:
```bash
mkdir -p ~/.config/claude
```
### Gitea Configuration
Required by: `projman`, `pr-review`
```bash
cat > ~/.config/claude/gitea.env << 'EOF'
# Gitea API Configuration
GITEA_URL=https://gitea.example.com
GITEA_TOKEN=your_gitea_token_here
GITEA_ORG=your_organization
EOF
# Secure the file
chmod 600 ~/.config/claude/gitea.env
```
**Variables:**
| Variable | Description | Example |
|----------|-------------|---------|
| `GITEA_URL` | Gitea base URL (no `/api/v1`) | `https://gitea.example.com` |
| `GITEA_TOKEN` | Personal access token | `glpat-xxx...` |
| `GITEA_ORG` | Organization name | `bandit` |
**Generating 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)
4. Copy token immediately (shown only once)
### NetBox Configuration
Required by: `cmdb-assistant`
```bash
cat > ~/.config/claude/netbox.env << 'EOF'
# NetBox API Configuration
NETBOX_URL=https://netbox.example.com
NETBOX_TOKEN=your_netbox_token_here
EOF
chmod 600 ~/.config/claude/netbox.env
```
**Variables:**
| Variable | Description | Example |
|----------|-------------|---------|
| `NETBOX_URL` | NetBox base URL | `https://netbox.example.com` |
| `NETBOX_TOKEN` | API token | `abc123...` |
### Git-Flow Configuration
Optional system defaults for: `git-flow`
```bash
cat > ~/.config/claude/git-flow.env << 'EOF'
# Git-Flow Default Configuration
GIT_WORKFLOW_STYLE=feature-branch
GIT_DEFAULT_BASE=development
GIT_AUTO_DELETE_MERGED=true
GIT_AUTO_PUSH=false
GIT_PROTECTED_BRANCHES=main,master,development,staging,production
GIT_COMMIT_STYLE=conventional
GIT_CO_AUTHOR=true
EOF
```
---
## Project-Level Configuration
Create `.env` in each project root:
### Gitea Repository (projman, pr-review)
```bash
# .env in project root
GITEA_REPO=your-repo-name
```
### Git-Flow (project overrides)
```bash
# .env in project root
GIT_WORKFLOW_STYLE=pr-required
GIT_DEFAULT_BASE=main
```
### PR Review
```bash
# .env in project root
PR_REVIEW_CONFIDENCE_THRESHOLD=0.5
PR_REVIEW_AUTO_SUBMIT=false
```
---
## MCP Server Installation
MCP servers are located at repository root: `mcp-servers/`
### Gitea MCP Server
```bash
cd mcp-servers/gitea
# Create virtual environment
python3 -m venv .venv
# Activate
source .venv/bin/activate
# Install dependencies
pip install -r requirements.txt
# Verify
python -c "from mcp_server import server; print('OK')"
deactivate
```
### NetBox MCP Server
```bash
cd mcp-servers/netbox
# Create virtual environment
python3 -m venv .venv
# Activate
source .venv/bin/activate
# Install dependencies
pip install -r requirements.txt
# Verify
python -c "from mcp_server import server; print('OK')"
deactivate
```
---
## Plugin Configuration Reference
### projman
| Level | Variable | Default | Description |
|-------|----------|---------|-------------|
| System | `GITEA_URL` | (required) | Gitea API base URL |
| System | `GITEA_TOKEN` | (required) | API token |
| System | `GITEA_ORG` | (required) | Organization name |
| Project | `GITEA_REPO` | (required) | Repository name |
**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/initial-setup`, `/review`, `/test-check`, `/test-gen`
### pr-review
| Level | Variable | Default | Description |
|-------|----------|---------|-------------|
| System | `GITEA_URL` | (required) | Gitea API base URL |
| System | `GITEA_TOKEN` | (required) | API token |
| Project | `GITEA_REPO` | (required) | Repository name |
| Project | `PR_REVIEW_CONFIDENCE_THRESHOLD` | `0.5` | Minimum confidence |
| Project | `PR_REVIEW_AUTO_SUBMIT` | `false` | Auto-submit reviews |
**Commands:** `/pr-review`, `/pr-summary`, `/pr-findings`
### git-flow
| Level | Variable | Default | Description |
|-------|----------|---------|-------------|
| System/Project | `GIT_WORKFLOW_STYLE` | `feature-branch` | Branching strategy |
| System/Project | `GIT_DEFAULT_BASE` | `development` | Default base branch |
| System/Project | `GIT_AUTO_DELETE_MERGED` | `true` | Delete merged branches |
| System/Project | `GIT_AUTO_PUSH` | `false` | Auto-push after commit |
| System/Project | `GIT_PROTECTED_BRANCHES` | `main,master,...` | Protected branches |
| System/Project | `GIT_COMMIT_STYLE` | `conventional` | Commit message style |
| System/Project | `GIT_CO_AUTHOR` | `true` | Include Claude co-author |
**Commands:** `/commit`, `/commit-push`, `/commit-merge`, `/commit-sync`, `/branch-start`, `/branch-cleanup`, `/git-status`, `/git-config`
### clarity-assist
No configuration required. Uses sensible defaults.
**Commands:** `/clarify`, `/quick-clarify`
### cmdb-assistant
| Level | Variable | Default | Description |
|-------|----------|---------|-------------|
| System | `NETBOX_URL` | (required) | NetBox API base URL |
| System | `NETBOX_TOKEN` | (required) | API token |
### doc-guardian
No configuration required. Hook-based plugin.
### code-sentinel
No configuration required. Hook-based plugin.
### project-hygiene
No configuration required. Hook-based plugin.
### claude-config-maintainer
No configuration required.
---
## Multi-Project Setup
1. **System config:** Set up once (credentials)
2. **Project config:** Create `.env` in each project root
**Example:**
```bash
# ~/projects/my-app/.env
GITEA_REPO=my-app
# ~/projects/another-app/.env
GITEA_REPO=another-app
GIT_WORKFLOW_STYLE=trunk-based
```
---
## Verification
### Test Gitea Connection
```bash
curl -H "Authorization: token YOUR_TOKEN" \
https://gitea.example.com/api/v1/user
```
### Test MCP Server
```bash
cd mcp-servers/gitea
source .venv/bin/activate
python -c "from mcp_server import server; print('OK')"
```
### Run Plugin Setup
```bash
# For projman
/initial-setup
/labels-sync
```
---
## Troubleshooting
### Configuration not found
```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
curl -H "Authorization: token YOUR_TOKEN" \
https://gitea.example.com/api/v1/user
# Regenerate if invalid
```
### MCP server not starting
```bash
# Check venv exists
ls mcp-servers/gitea/.venv
# Reinstall if missing
cd mcp-servers/gitea
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```
### Wrong repository
```bash
# Check project .env
cat .env
# Verify GITEA_REPO matches 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. **Rotate tokens periodically**
- Every 6-12 months
- Immediately if compromised
4. **Minimum permissions**
- Only grant required token permissions
- Use separate tokens for different environments
---
## Quick Setup Checklist
- [ ] Python 3.10+ installed
- [ ] `~/.config/claude/` directory created
- [ ] Service credentials configured (gitea.env, netbox.env)
- [ ] Configuration files secured (chmod 600)
- [ ] MCP servers installed with venv
- [ ] Project `.env` created with repository settings
- [ ] Connections tested
- [ ] Plugin commands verified

View File

@@ -15,7 +15,7 @@ git pull origin main
## What the Post-Update Script Does
1. **Updates Python dependencies** for Gitea and Wiki.js MCP servers
1. **Updates Python dependencies** for MCP servers
2. **Shows recent changelog entries** so you know what changed
3. **Validates your configuration** is still compatible
@@ -30,7 +30,6 @@ 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`
- Wiki.js variables → `~/.config/claude/wikijs.env`
- Project variables → `.env` in your project root
### New MCP Server Features
@@ -38,7 +37,7 @@ 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 `plugins/projman/README.md` for usage documentation
3. New tools are available immediately after update
### Breaking Changes
@@ -51,15 +50,7 @@ Breaking changes will be clearly marked in CHANGELOG.md with migration instructi
```bash
# Rebuild virtual environment
cd mcp-servers/gitea
rm -rf .venv
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
deactivate
# Repeat for wikijs
cd ../wikijs
cd plugins/projman/mcp-servers/gitea
rm -rf .venv
python3 -m venv .venv
source .venv/bin/activate
@@ -76,7 +67,7 @@ deactivate
### MCP server won't start
1. Check Python version: `python3 --version` (requires 3.10+)
2. Verify venv exists: `ls mcp-servers/gitea/.venv`
2. Verify venv exists: `ls plugins/projman/mcp-servers/gitea/.venv`
3. Check logs for specific errors
## Version Pinning
@@ -88,7 +79,7 @@ To stay on a specific version:
git tag
# Checkout specific version
git checkout v1.0.0
git checkout v2.2.0
# Run post-update
./scripts/post-update.sh
@@ -96,6 +87,7 @@ git checkout v1.0.0
## Getting Help
- Check `docs/references/` for component documentation
- Check `plugins/projman/README.md` for projman documentation
- Check `plugins/projman/CONFIGURATION.md` for setup guide
- Review CHANGELOG.md for recent changes
- Search existing issues in Gitea

View File

@@ -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 |
| wikijs-lane | Wiki.js | #9E9E9E | 6 (rightmost) |
| reviewer-lane | Code Reviewer Agent | #9C27B0 | 5 |
| 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-wikijs-query | p1-return-lessons | lessons data | dashed |
| p1-search-lessons | p1-gitea-wiki-query | REST API (search_lessons) | solid |
| 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-orch-activate | Orchestrator Activates | rectangle | orchestrator-lane | 25 |
| p3-review | Review Sprint | rectangle | orchestrator-lane | 26 |
| p3-gitea-status | Get Final Status | rectangle | gitea-lane | 27 |
| p3-capture | Capture Lessons Learned | rectangle | orchestrator-lane | 28 |
| p3-user-input | Confirm Lessons | diamond | user-lane | 29 |
| p3-create-wiki | Create Wiki Pages | rectangle | orchestrator-lane | 30 |
| p3-wikijs-create | Store Lessons | rectangle | wikijs-lane | 31 |
| p3-close-issues | Close Issues | rectangle | orchestrator-lane | 32 |
| p3-gitea-close | Mark Closed | rectangle | gitea-lane | 33 |
| p3-complete | Sprint Closed | rounded-rect | orchestrator-lane | 34 |
| p3-start | /sprint-close | rounded-rect | user-lane | 31 |
| p3-orch-activate | Orchestrator Activates | rectangle | orchestrator-lane | 32 |
| p3-review | Review Sprint | rectangle | orchestrator-lane | 33 |
| p3-gitea-status | Get Final Status | rectangle | gitea-lane | 34 |
| p3-capture | Capture Lessons Learned | rectangle | orchestrator-lane | 35 |
| p3-user-input | Confirm Lessons | diamond | user-lane | 36 |
| p3-create-wiki | Create Wiki Pages | rectangle | orchestrator-lane | 37 |
| p3-gitea-wiki-create | Store Lessons (Wiki) | rectangle | gitea-lane | 38 |
| p3-close-issues | Close Issues | rectangle | orchestrator-lane | 39 |
| p3-gitea-close | Mark Closed | rectangle | gitea-lane | 40 |
| 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-wikijs-create | p3-close-issues | confirm | dashed |
| p3-create-wiki | p3-gitea-wiki-create | REST API (create_lesson) | solid |
| 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 |
+--------+------------+---------------+------------+--------+----------+
| | | | | | |
| PHASE 1: SPRINT PLANNING |
|---------------------------------------------------------------------+
| O | | | | | |
| | | | | | | |
| +---->| O | | | | |
| | | | | | | |
| | +----------|---------------|------------|------->| O |
| | |<---------|---------------|------------|--------+ | |
| | | | | | | |
| | O<> | | | | |
| O<--->+ | | | | | |
| | | | | | | |
| | +----------|---------------|----------->| O | |
| | O | | | | |
| | | | | | |
|---------------------------------------------------------------------+
| PHASE 2: SPRINT EXECUTION |
|---------------------------------------------------------------------+
| O | | | | | |
| | | | | | | |
| +-----|----------->| O | | | |
| | | | | | | |
| | | +-------------|----------->| O | |
| | | |<------------|------------+ | | |
| | | | | | | |
| | | +------------>| O | | |
| | | | | | | |
| | | | +--------->| O | |
| | | | |<---------+ | | |
| | | O<------------+ | | | |
| | | | | | | |
| | | O (loop) | | | |
| | | | | | |
|---------------------------------------------------------------------+
| PHASE 3: SPRINT CLOSE |
|---------------------------------------------------------------------+
| O | | | | | |
| | | | | | | |
| +-----|----------->| O | | | |
| | | +-------------|----------->| O | |
| | | |<------------|------------+ | | |
| | | | | | | |
| O<----|-----------<+ | | | | |
| +-----|----------->| | | | | |
| | | +-------------|------------|------->| O |
| | | |<------------|------------|--------+ | |
| | | +-------------|----------->| O | |
| | | O | | | |
+--------+------------+---------------+------------+--------+----------+
+--------+------------+---------------+------------+----------+------------------+
| User | Planner | Orchestrator | Executor | Reviewer | Gitea |
| | | | | | (Issues + Wiki) |
+--------+------------+---------------+------------+----------+------------------+
| | | | | | |
| PHASE 1: SPRINT PLANNING |
|-------------------------------------------------------------------------------|
| O | | | | | |
| | | | | | | |
| +---->| O | | | | |
| | | | | | | |
| | +----------|---------------|------------|--------->| O (Wiki Query) |
| | |<---------|---------------|------------|----------+ | |
| | | | | | | |
| | O<> | | | | |
| O<--->+ | | | | | |
| | | | | | | |
| | +----------|---------------|------------|--------->| O (Issues) |
| | O | | | | |
| | | | | | |
|-------------------------------------------------------------------------------|
| PHASE 2: SPRINT EXECUTION |
|-------------------------------------------------------------------------------|
| O | | | | | |
| | | | | | | |
| +-----|----------->| O | | | |
| | | | | | | |
| | | +-------------|------------|--------->| O (Issues) |
| | | |<------------|------------|----------+ | |
| | | | | | | |
| | | +------------>| O | | |
| | | | | | | |
| | | | +----------|--------->| O (Issues) |
| | | | |<---------|----------+ | |
| | | O<------------+ | | | |
| | | | | | | |
| | | O (loop) | | | |
| | | | | | |
|-------------------------------------------------------------------------------|
| PHASE 2.5: CODE REVIEW |
|-------------------------------------------------------------------------------|
| O | | | | | |
| | | | | | | |
| +-----|------------|---------------|----------->| O | |
| | | | | | | |
| | | | | O->O->O | |
| | | | | | | |
| | | | | O | |
| | | | | | |
|-------------------------------------------------------------------------------|
| PHASE 3: SPRINT CLOSE |
|-------------------------------------------------------------------------------|
| O | | | | | |
| | | | | | | |
| +-----|----------->| O | | | |
| | | +-------------|------------|--------->| O (Issues) |
| | | |<------------|------------|----------+ | |
| | | | | | | |
| O<----|-----------<+ | | | | |
| +-----|----------->| | | | | |
| | | +-------------|------------|--------->| O (Wiki Create) |
| | | |<------------|------------|----------+ | |
| | | +-------------|------------|--------->| 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

View File

@@ -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 |
|----|-------|------|-------|----------|
| gitea-mcp | Gitea MCP Server | rectangle | #7CB342 | middle-left |
| wikijs-mcp | Wiki.js MCP Server | rectangle | #7CB342 | middle-right |
MCP servers are **bundled inside each plugin** that needs them.
| ID | Label | Type | Color | Position | Bundled In |
|----|-------|------|-------|----------|------------|
| 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 |
| wikijs-instance | Wiki.js\nwikijs.hotserv.cloud | cylinder | #9E9E9E | bottom-right |
| gitea-instance | Gitea\n(Issues + Wiki) | cylinder | #9E9E9E | bottom-left |
| 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 | wikijs-mcp | uses | solid | forward |
| projman-pmo | gitea-mcp | uses (company-wide) | solid | forward |
| projman-pmo | wikijs-mcp | uses (company-wide) | solid | forward |
| projman | gitea-mcp | bundled | solid | bidirectional |
| cmdb-assistant | netbox-mcp | bundled | solid | bidirectional |
### 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 |
| mcp-group | Shared MCP Servers | gitea-mcp, wikijs-mcp | light green border |
| external-group | External Services | gitea-instance, wikijs-instance | light gray border |
| plugins-group | Plugins | projman, projman-pmo, project-hygiene, claude-config, cmdb-assistant | light blue border |
| external-group | External Services | gitea-instance, netbox-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
+------------------------------------------------------------------+
| MCP SERVERS GROUP |
| +-------------------+ +-------------------+ |
| | Gitea MCP Server | | Wiki.js MCP Server| |
| +--------+----------+ +---------+---------+ |
+------------------------------------------------------------------+
| |
v v
|
v
+------------------------------------------------------------------+
| EXTERNAL SERVICES GROUP |
| +-------------------+ +-------------------+ |
| | Gitea | | Wiki.js | |
| | gitea.hotserv.cloud | wikijs.hotserv.cloud |
| | Gitea | | NetBox | |
| | (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

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -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
```
personal-projects/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! 🚀

View File

@@ -393,16 +393,15 @@ MIT License - Part of the Claude Code Marketplace project.
## Related Documentation
- **MCP Specification**: `docs/references/MCP-GITEA.md`
- **Project Summary**: `docs/references/PROJECT-SUMMARY.md`
- **Implementation Plan**: `docs/reference-material/projman-implementation-plan.md`
- **Projman Documentation**: `plugins/projman/README.md`
- **Configuration Guide**: `plugins/projman/CONFIGURATION.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
---

View File

@@ -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`
- **Implementation Plan**: `docs/references/PROJECT-SUMMARY.md`
- **Projman Documentation**: `plugins/projman/README.md`
- **Configuration Guide**: `plugins/projman/CONFIGURATION.md`
---

View File

@@ -591,3 +591,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()

View File

@@ -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:
@@ -638,6 +641,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 +876,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}")

View File

@@ -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)
"""

View File

@@ -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)
)

View File

@@ -0,0 +1,45 @@
{
"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/support-claude-mktplace/src/branch/main/plugins/clarity-assist/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"license": "MIT",
"keywords": [
"prompt-optimization",
"clarification",
"neurodivergent",
"requirements",
"methodology"
],
"commands": [
{
"name": "clarify",
"description": "Full 4-D prompt optimization (Deconstruct, Diagnose, Develop, Deliver)",
"file": "commands/clarify.md"
},
{
"name": "quick-clarify",
"description": "Rapid mode - single-pass clarification for simple requests",
"file": "commands/quick-clarify.md"
}
],
"agents": [
{
"name": "clarity-coach",
"description": "ND-friendly coach for structured requirement gathering",
"file": "agents/clarity-coach.md"
}
],
"skills": [
{
"name": "prompt-patterns",
"description": "Optimization rules and patterns for effective prompts",
"path": "skills/prompt-patterns"
}
]
}

View File

@@ -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

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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

View File

@@ -0,0 +1 @@
../../../mcp-servers/netbox

View File

@@ -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/support-claude-mktplace/src/branch/main/plugins/code-sentinel/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"license": "MIT",
"keywords": ["security", "refactoring", "code-quality", "static-analysis", "hooks"]
}

View File

@@ -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/support-claude-mktplace.git
/plugin install code-sentinel
```
## Integration
See claude-md-integration.md for CLAUDE.md additions.

View File

@@ -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

View File

@@ -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)

View File

@@ -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

View File

@@ -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%
```

View File

@@ -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
```

View File

@@ -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

View File

@@ -0,0 +1,15 @@
{
"hooks": {
"PreToolUse": [
{
"matcher": "Write|Edit|MultiEdit",
"hooks": [
{
"type": "prompt",
"prompt": "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, explain the issue, suggest safe alternative\n- If WARNING found: Note it briefly, proceed with suggestion\n- If clean: Proceed silently (say nothing)\n\nDo NOT announce clean scans. Only speak if issues found."
}
]
}
]
}
}

View File

@@ -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")
```

View File

@@ -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/support-claude-mktplace/src/branch/main/plugins/doc-guardian/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"license": "MIT",
"keywords": ["documentation", "sync", "drift-detection", "automation", "hooks"]
}

View File

@@ -0,0 +1,49 @@
# 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 watches your code changes and automatically:
1. Detects when changes affect documentation
2. Queues updates silently (doesn't interrupt your flow)
3. Syncs all doc changes in a single commit 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
- **Stop**: Reminds you of pending doc updates before session ends
## 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 claude-code-marketplace.
```bash
/plugin marketplace add https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git
/plugin install doc-guardian
```
## Integration
See claude-md-integration.md for CLAUDE.md additions.

View File

@@ -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

View File

@@ -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`

View File

@@ -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

View File

@@ -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
```

View File

@@ -0,0 +1,26 @@
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit|MultiEdit",
"hooks": [
{
"type": "prompt",
"prompt": "A file was just modified. Silently check if this change affects any documentation:\n\n1. If a code file changed: check if README, CLAUDE.md, docstrings, or API docs reference the modified functions/classes/configs\n2. If drift detected: add to internal queue (do NOT interrupt user flow)\n3. At natural breakpoints or when user runs /doc-sync: report pending doc updates\n\nDo NOT announce this check unless drift is found. Work silently."
}
]
}
],
"Stop": [
{
"matcher": ".*",
"hooks": [
{
"type": "prompt",
"prompt": "Before ending, check if there are pending documentation updates queued by doc-guardian. If yes, ask user: 'I detected documentation drift in X files. Run /doc-sync to update, or skip for now?'"
}
]
}
]
}
}

View File

@@ -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

View File

@@ -0,0 +1,75 @@
{
"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/support-claude-mktplace/src/branch/main/plugins/git-flow/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"license": "MIT",
"keywords": [
"git",
"workflow",
"commit",
"branch",
"automation"
],
"commands": [
{
"name": "commit",
"description": "Create a commit with auto-generated conventional message",
"file": "commands/commit.md"
},
{
"name": "commit-push",
"description": "Commit and push to remote in one operation",
"file": "commands/commit-push.md"
},
{
"name": "commit-merge",
"description": "Commit current changes and merge into target branch",
"file": "commands/commit-merge.md"
},
{
"name": "commit-sync",
"description": "Commit, push, and sync with upstream",
"file": "commands/commit-sync.md"
},
{
"name": "branch-start",
"description": "Start a new feature/fix/chore branch with naming convention",
"file": "commands/branch-start.md"
},
{
"name": "branch-cleanup",
"description": "Clean up merged branches locally and optionally remotely",
"file": "commands/branch-cleanup.md"
},
{
"name": "git-status",
"description": "Enhanced git status with recommendations",
"file": "commands/git-status.md"
},
{
"name": "git-config",
"description": "Configure git-flow settings for this project",
"file": "commands/git-config.md"
}
],
"agents": [
{
"name": "git-assistant",
"description": "Git workflow assistant for complex operations",
"file": "agents/git-assistant.md"
}
],
"skills": [
{
"name": "workflow-patterns",
"description": "Git branching strategies and workflow patterns",
"path": "skills/workflow-patterns"
}
]
}

128
plugins/git-flow/README.md Normal file
View File

@@ -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

View File

@@ -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

View File

@@ -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.

View File

@@ -0,0 +1,94 @@
# /branch-cleanup - Clean Merged Branches
## Purpose
Remove branches that have been merged, both locally and optionally on remote.
## Behavior
### Step 1: Identify Merged Branches
```bash
# Find merged local branches
git branch --merged <base-branch>
# Find merged remote branches
git branch -r --merged <base-branch>
```
### Step 2: Present Findings
```
Found 5 merged branches:
Local:
- feat/login-page (merged 3 days ago)
- fix/typo-header (merged 1 week ago)
- chore/deps-update (merged 2 weeks ago)
Remote:
- origin/feat/login-page
- origin/fix/typo-header
Protected (won't delete):
- main
- development
- staging
Delete these branches?
1. Delete all (local + remote)
2. Delete local only
3. Let me pick which ones
4. Cancel
```
### Step 3: Execute Cleanup
```bash
# Delete local
git branch -d <branch-name>
# Delete remote
git push origin --delete <branch-name>
```
### Step 4: Report
```
Cleanup complete:
Deleted local: 3 branches
Deleted remote: 2 branches
Skipped: 0 branches
Remaining local branches:
- main
- development
- feat/current-work (not merged)
```
## 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 |
## Safety
- Never deletes protected branches
- Warns about unmerged branches
- Confirms before deleting remote branches
- Uses `-d` (safe delete) not `-D` (force delete)
## Output
On success:
```
Cleaned up:
Local: 3 branches deleted
Remote: 2 branches deleted
Repository is tidy!
```

View File

@@ -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
```

View File

@@ -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
```

View File

@@ -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
```

View File

@@ -0,0 +1,79 @@
# /commit-sync - Commit, Push, and Sync
## Purpose
Full sync operation: commit local changes, push to remote, and sync with upstream/base branch.
## 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
git fetch --all
# Rebase on base branch
git rebase origin/<base-branch>
# Push again (if rebased)
git push --force-with-lease
```
### Step 4: 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.
```
## Environment Variables
| Variable | Default | Description |
|----------|---------|-------------|
| `GIT_DEFAULT_BASE` | `development` | Branch to sync with |
| `GIT_SYNC_STRATEGY` | `rebase` | How to incorporate upstream changes |
## 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
```

View File

@@ -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(-)
```

View File

@@ -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.
```

View File

@@ -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.

View File

@@ -0,0 +1,183 @@
# Git Branching Strategies
## Supported Workflow Styles
### 1. Simple
```
main ─────●─────●─────●─────●─────●
↑ ↑ ↑ ↑ ↑
commit commit commit commit commit
```
**Best for:**
- Solo projects
- Small scripts/utilities
- Documentation repos
**Rules:**
- Direct commits to main/development
- No feature branches required
- Linear history
### 2. Feature Branch (Default)
```
main ─────────────────●───────────●───────────
↑ ↑
development ────●────●────●────●────●────●────
↑ ↑ ↑ ↑
feat/a ─────●───●────┘ │ │
│ │
feat/b ──────────●────●───┘ │
fix/c ────────────────●────●───┘
```
**Best for:**
- Small teams (2-5 developers)
- Projects without formal review process
- Rapid development cycles
**Rules:**
- Feature branches from development
- Merge when complete
- Delete branches after merge
- development → main for releases
### 3. PR Required
```
main ─────────────────────────────●───────────
development ────●────●────●────●────●────●────
↑ ↑ ↑ ↑
PR PR PR PR
↑ ↑ ↑ ↑
feat/a ─────●───● │ │ │
│ │ │
feat/b ──────────●───● │ │
│ │
feat/c ───────────────●───● │
fix/d ────────────────────●────●
```
**Best for:**
- Teams with code review requirements
- Open source projects
- Projects with CI/CD gates
**Rules:**
- All changes via pull request
- At least one approval required
- CI must pass before merge
- Squash commits on merge
### 4. Trunk-Based
```
main ────●────●────●────●────●────●────●────●
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
│ │ │ │ │ │ │ │
short branches (< 1 day)
```
**Best for:**
- CI/CD heavy workflows
- Experienced teams
- High deployment frequency
**Rules:**
- Very short-lived branches (hours, not days)
- Frequent integration to main
- Feature flags for incomplete work
- Continuous deployment
## Branch Naming Convention
```
<type>/<description>
```
### Types
| Type | Purpose | Example |
|------|---------|---------|
| `feat` | New feature | `feat/user-authentication` |
| `fix` | Bug fix | `fix/login-timeout` |
| `chore` | Maintenance | `chore/update-deps` |
| `docs` | Documentation | `docs/api-reference` |
| `refactor` | Code restructure | `refactor/auth-module` |
| `test` | Test additions | `test/auth-coverage` |
| `perf` | Performance | `perf/query-optimization` |
### Naming Rules
1. Lowercase only
2. Hyphens for word separation
3. No special characters
4. Descriptive (2-4 words)
5. Max 50 characters
### Examples
```
✓ feat/add-password-reset
✓ fix/null-pointer-login
✓ chore/upgrade-typescript-5
✗ Feature/Add_Password_Reset (wrong case, underscores)
✗ fix-bug (too vague)
✗ my-branch (no type prefix)
```
## Protected Branches
Default protected branches:
- `main` / `master`
- `development` / `develop`
- `staging`
- `production`
Protection rules:
- No direct commits
- No force push
- Require PR for changes
- No deletion
## Commit Message Convention
```
<type>(<scope>): <description>
[optional body]
[optional footer]
```
### Examples
```
feat(auth): add password reset flow
Implement forgot password functionality with email verification.
Includes rate limiting (5 attempts/hour) and 24h token expiration.
Closes #123
```
```
fix(ui): resolve button alignment on mobile
The submit button was misaligned on screens < 768px.
Added responsive flex rules.
```
```
chore(deps): update dependencies
- typescript 5.3 → 5.4
- react 18.2 → 18.3
- node 18 → 20 (LTS)
```

View File

@@ -0,0 +1,71 @@
{
"name": "pr-review",
"version": "1.0.0",
"description": "Multi-agent pull request review with confidence scoring and actionable feedback",
"author": {
"name": "Leo Miranda",
"email": "leobmiranda@gmail.com"
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace/src/branch/main/plugins/pr-review/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/support-claude-mktplace.git",
"license": "MIT",
"keywords": [
"pull-request",
"code-review",
"security",
"performance",
"multi-agent"
],
"commands": [
{
"name": "pr-review",
"description": "Full multi-agent PR review (security, performance, maintainability, tests)",
"file": "commands/pr-review.md"
},
{
"name": "pr-summary",
"description": "Quick summary of PR changes without full review",
"file": "commands/pr-summary.md"
},
{
"name": "pr-findings",
"description": "List and filter review findings by category or confidence",
"file": "commands/pr-findings.md"
}
],
"agents": [
{
"name": "coordinator",
"description": "Orchestrates the multi-agent review process",
"file": "agents/coordinator.md"
},
{
"name": "security-reviewer",
"description": "Analyzes code for security vulnerabilities",
"file": "agents/security-reviewer.md"
},
{
"name": "performance-analyst",
"description": "Identifies performance issues and optimization opportunities",
"file": "agents/performance-analyst.md"
},
{
"name": "maintainability-auditor",
"description": "Reviews code quality, patterns, and maintainability",
"file": "agents/maintainability-auditor.md"
},
{
"name": "test-validator",
"description": "Validates test coverage and test quality",
"file": "agents/test-validator.md"
}
],
"skills": [
{
"name": "review-patterns",
"description": "Code review patterns and confidence scoring rules",
"path": "skills/review-patterns"
}
],
"mcpServers": ["gitea"]
}

View File

@@ -0,0 +1,9 @@
{
"mcpServers": {
"gitea": {
"command": "${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea/.venv/bin/python",
"args": ["-m", "mcp_server.server"],
"cwd": "${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea"
}
}
}

126
plugins/pr-review/README.md Normal file
View File

@@ -0,0 +1,126 @@
# pr-review
Multi-agent pull request review with confidence scoring and actionable feedback.
## Overview
pr-review conducts comprehensive code reviews using specialized agents for security, performance, maintainability, and test coverage. Each finding includes a confidence score to reduce noise and focus on real issues.
## Commands
| Command | Description |
|---------|-------------|
| `/pr-review <pr#>` | Full multi-agent review |
| `/pr-summary <pr#>` | Quick summary without full review |
| `/pr-findings <pr#>` | Filter findings by category/confidence |
## Review Agents
| Agent | Focus |
|-------|-------|
| **Security Reviewer** | Injections, auth, data exposure, crypto |
| **Performance Analyst** | N+1 queries, complexity, memory, caching |
| **Maintainability Auditor** | Complexity, duplication, naming, coupling |
| **Test Validator** | Coverage, test quality, flaky tests |
## Confidence Scoring
Findings are scored 0.0 - 1.0:
| Range | Label | Action |
|-------|-------|--------|
| 0.9 - 1.0 | HIGH | Must address |
| 0.7 - 0.89 | MEDIUM | Should address |
| 0.5 - 0.69 | LOW | Consider addressing |
| < 0.5 | (suppressed) | Not reported |
## Installation
Add to your project's `.claude/settings.json`:
```json
{
"plugins": ["pr-review"]
}
```
Requires Gitea MCP server configuration.
## Configuration
```bash
# Minimum confidence to report (default: 0.5)
PR_REVIEW_CONFIDENCE_THRESHOLD=0.5
# Auto-submit review to Gitea (default: false)
PR_REVIEW_AUTO_SUBMIT=false
```
## Usage Examples
### Full Review
```
/pr-review 123
═══════════════════════════════════════════════════
PR Review Report: #123
═══════════════════════════════════════════════════
Summary:
Files changed: 12
Lines: +234 / -45
Findings: 8 total
🔴 Critical: 1
🟠 Major: 2
🟡 Minor: 3
💡 Suggestions: 2
[Detailed findings...]
VERDICT: REQUEST_CHANGES
═══════════════════════════════════════════════════
```
### Filter Findings
```
/pr-findings 123 --category security
# Shows only security-related findings
```
### Quick Summary
```
/pr-summary 123
# Shows change overview without full analysis
```
## Output
Review reports include:
- Summary statistics
- Findings grouped by severity
- Code snippets with context
- Suggested fixes
- Overall verdict (APPROVE/COMMENT/REQUEST_CHANGES)
## Verdict Logic
| Condition | Verdict |
|-----------|---------|
| Any critical finding | REQUEST_CHANGES |
| 2+ major findings | REQUEST_CHANGES |
| Only minor/suggestions | COMMENT |
| No significant findings | APPROVE |
## Integration
For CLAUDE.md integration instructions, see `claude-md-integration.md`.
## License
MIT

View File

@@ -0,0 +1,133 @@
# Coordinator Agent
## Role
You are the review coordinator that orchestrates the multi-agent PR review process. You dispatch tasks to specialized reviewers, aggregate their findings, and produce the final review report.
## Responsibilities
### 1. PR Analysis
Before dispatching to agents:
1. Fetch PR metadata and diff
2. Identify changed file types
3. Determine which agents are relevant
### 2. Agent Dispatch
Dispatch to appropriate agents based on changes:
| File Pattern | Agents to Dispatch |
|--------------|-------------------|
| `*.ts`, `*.js` | Security, Performance, Maintainability |
| `*.test.*`, `*_test.*` | Test Validator |
| `*.sql`, `*migration*` | Security (SQL injection) |
| `*.css`, `*.scss` | Maintainability only |
| `*.md`, `*.txt` | Skip (documentation) |
### 3. Finding Aggregation
Collect findings from all agents:
- Deduplicate similar findings
- Merge overlapping concerns
- Validate confidence scores
### 4. Report Generation
Produce structured report:
1. Summary statistics
2. Findings by severity (critical → suggestion)
3. Per-finding details
4. Overall verdict
### 5. Verdict Decision
Determine final verdict:
| Condition | Verdict |
|-----------|---------|
| Any critical finding | REQUEST_CHANGES |
| 2+ major findings | REQUEST_CHANGES |
| Only minor/suggestions | COMMENT |
| No significant findings | APPROVE |
## Communication Protocol
### To Sub-Agents
```
REVIEW_TASK:
pr_number: 123
files: [list of relevant files]
diff: [relevant diff sections]
context: [PR description, existing comments]
EXPECTED_RESPONSE:
findings: [
{
id: string,
category: string,
severity: critical|major|minor|suggestion,
confidence: 0.0-1.0,
file: string,
line: number,
title: string,
description: string,
fix: string (optional)
}
]
```
### Report Template
```
═══════════════════════════════════════════════════
PR Review Report: #<number>
═══════════════════════════════════════════════════
Summary:
Files changed: <n>
Lines: +<added> / -<removed>
Agents consulted: <list>
Findings: <total>
🔴 Critical: <n>
🟠 Major: <n>
🟡 Minor: <n>
💡 Suggestions: <n>
[Findings grouped by severity]
───────────────────────────────────────────────────
VERDICT: <APPROVE|COMMENT|REQUEST_CHANGES>
───────────────────────────────────────────────────
<Justification>
```
## Behavior Guidelines
### Be Decisive
Provide clear verdict with justification. Don't hedge.
### Prioritize Actionability
Focus on findings that:
- Have clear fixes
- Impact security or correctness
- Are within author's control
### Respect Confidence Thresholds
Never report findings below 0.5 confidence. Be transparent about uncertainty:
- 0.9+ → "This is definitely an issue"
- 0.7-0.89 → "This is likely an issue"
- 0.5-0.69 → "This might be an issue"
### Avoid Noise
Don't report:
- Style preferences (unless egregious)
- Minor naming issues
- Theoretical problems with no practical impact

View File

@@ -0,0 +1,99 @@
# Maintainability Auditor Agent
## Role
You are a code quality reviewer that identifies maintainability issues, code smells, and opportunities to improve code clarity and long-term health.
## Focus Areas
### 1. Code Complexity
- **Long Functions**: >50 lines, too many responsibilities
- **Deep Nesting**: >3 levels of conditionals
- **Complex Conditionals**: Hard to follow boolean logic
- **God Objects**: Classes/modules doing too much
### 2. Code Duplication
- **Copy-Paste Code**: Repeated blocks that should be abstracted
- **Similar Patterns**: Logic that could be generalized
### 3. Naming & Clarity
- **Unclear Names**: Variables like `x`, `data`, `temp`
- **Misleading Names**: Names that don't match behavior
- **Inconsistent Naming**: Mixed conventions
### 4. Architecture Concerns
- **Tight Coupling**: Components too interdependent
- **Missing Abstraction**: Concrete details leaking
- **Broken Patterns**: Violating established patterns in codebase
### 5. Error Handling
- **Swallowed Errors**: Empty catch blocks
- **Generic Errors**: Losing error context
- **Missing Error Handling**: No handling for expected failures
## Finding Format
```json
{
"id": "MAINT-001",
"category": "maintainability",
"subcategory": "complexity",
"severity": "minor",
"confidence": 0.75,
"file": "src/services/orderProcessor.ts",
"line": 45,
"title": "Function Too Long",
"description": "The processOrder function is 120 lines with 5 distinct responsibilities: validation, pricing, inventory, notification, and logging.",
"impact": "Difficult to test, understand, and modify. Changes risk unintended side effects.",
"fix": "Extract each responsibility into a separate function: validateOrder(), calculatePricing(), updateInventory(), sendNotification(), logOrder()."
}
```
## Severity Guidelines
| Severity | Criteria |
|----------|----------|
| Critical | Makes code dangerous to modify |
| Major | Significantly impacts readability/maintainability |
| Minor | Noticeable but manageable issue |
| Suggestion | Nice to have, not blocking |
## Confidence Calibration
Maintainability is subjective. Be measured:
HIGH confidence when:
- Clear violation of established patterns
- Obvious duplication or complexity
- Measurable metrics exceed thresholds
MEDIUM confidence when:
- Judgment call on complexity
- Could be intentional design choice
- Depends on team conventions
Suppress when:
- Style preference not shared by team
- Generated or third-party code
- Temporary code with TODO
## Special Considerations
### Context Awareness
Check existing patterns before flagging:
- If codebase uses X pattern, don't suggest Y
- If similar code exists elsewhere, ensure consistency
- Respect team conventions over personal preference
### Constructive Feedback
Always provide:
- Why it matters
- Concrete improvement suggestion
- Example if complex

View File

@@ -0,0 +1,93 @@
# Performance Analyst Agent
## Role
You are a performance-focused code reviewer that identifies performance issues, inefficiencies, and optimization opportunities in pull request changes.
## Focus Areas
### 1. Database Performance
- **N+1 Queries**: Loop with query inside
- **Missing Indexes**: Queries on unindexed columns
- **Over-fetching**: SELECT * when specific columns needed
- **Unbounded Queries**: No LIMIT on potentially large result sets
Confidence scoring:
- Clear N+1 in loop: 0.9
- Possible N+1 with unclear iteration: 0.7
- Query without visible index: 0.5
### 2. Algorithm Complexity
- **Nested Loops**: O(n²) when O(n) possible
- **Repeated Calculations**: Same computation in loop
- **Inefficient Data Structures**: Array search vs Set/Map lookup
### 3. Memory Issues
- **Memory Leaks**: Unclosed resources, growing caches
- **Large Allocations**: Loading entire files/datasets into memory
- **Unnecessary Copies**: Cloning when reference would work
### 4. Network/IO
- **Sequential Requests**: When parallel would work
- **Missing Caching**: Repeated fetches of same data
- **Large Payloads**: Sending unnecessary data
### 5. Frontend Performance
- **Unnecessary Re-renders**: Missing memoization
- **Large Bundle Impact**: Heavy imports
- **Blocking Operations**: Sync ops on main thread
## Finding Format
```json
{
"id": "PERF-001",
"category": "performance",
"subcategory": "database",
"severity": "major",
"confidence": 0.85,
"file": "src/services/orders.ts",
"line": 23,
"title": "N+1 Query Pattern",
"description": "For each order, a separate query fetches the user. With 100 orders, this executes 101 queries.",
"evidence": "orders.forEach(order => { const user = await db.users.find(order.userId); })",
"impact": "Linear increase in database load with order count. 1000 orders = 1001 queries.",
"fix": "Use eager loading or batch the user IDs: db.users.findMany({ id: { in: userIds } })"
}
```
## Severity Guidelines
| Severity | Criteria |
|----------|----------|
| Critical | Will cause outage or severe degradation at scale |
| Major | Significant impact on response time or resources |
| Minor | Measurable but tolerable impact |
| Suggestion | Optimization opportunity, premature if not hot path |
## Confidence Calibration
Be conservative about performance claims:
- Measure or cite benchmarks when possible
- Consider actual usage patterns
- Acknowledge when impact depends on scale
HIGH confidence when:
- Clear algorithmic issue (N+1, O(n²))
- Pattern known to cause problems
- Impact calculable from code
MEDIUM confidence when:
- Depends on data size
- Might be optimized elsewhere
- Theoretical improvement
Suppress when:
- Likely not a hot path
- Micro-optimization
- Depends heavily on runtime

View File

@@ -0,0 +1,93 @@
# Security Reviewer Agent
## Role
You are a security-focused code reviewer that identifies vulnerabilities, security anti-patterns, and potential exploits in pull request changes.
## Focus Areas
### 1. Injection Vulnerabilities
- **SQL Injection**: String concatenation in queries
- **Command Injection**: Unescaped user input in shell commands
- **XSS**: Unescaped output in HTML/templates
- **LDAP/XML Injection**: Similar patterns in other contexts
Confidence scoring:
- Direct user input → query string: 0.95
- Indirect path with possible taint: 0.7
- Theoretical with no clear path: 0.4
### 2. Authentication & Authorization
- Missing auth checks on endpoints
- Hardcoded credentials
- Weak password policies
- Session management issues
- JWT vulnerabilities (weak signing, no expiration)
### 3. Data Exposure
- Sensitive data in logs
- Unencrypted sensitive storage
- Excessive data in API responses
- Missing field-level permissions
### 4. Input Validation
- Missing validation on user input
- Type coercion vulnerabilities
- Path traversal possibilities
- File upload without validation
### 5. Cryptography
- Weak algorithms (MD5, SHA1 for passwords)
- Hardcoded keys/IVs
- Predictable random values
- Missing salt
## Finding Format
```json
{
"id": "SEC-001",
"category": "security",
"subcategory": "injection",
"severity": "critical",
"confidence": 0.95,
"file": "src/api/users.ts",
"line": 45,
"title": "SQL Injection Vulnerability",
"description": "User-provided 'id' parameter is directly interpolated into SQL query without parameterization.",
"evidence": "const query = `SELECT * FROM users WHERE id = ${userId}`;",
"impact": "Attacker can read, modify, or delete any data in the database.",
"fix": "Use parameterized queries: db.query('SELECT * FROM users WHERE id = ?', [userId])"
}
```
## Severity Guidelines
| Severity | Criteria |
|----------|----------|
| Critical | Exploitable with high impact (data breach, RCE) |
| Major | Exploitable with moderate impact, or high impact requiring specific conditions |
| Minor | Low impact or requires unlikely conditions |
| Suggestion | Best practice, defense in depth |
## Confidence Calibration
Be conservative. Only report HIGH confidence when:
- Clear data flow from untrusted source to sink
- No intervening validation visible
- Pattern matches known vulnerability
Report MEDIUM confidence when:
- Pattern looks suspicious but context unclear
- Validation might exist elsewhere
- Depends on configuration
Suppress (< 0.5) when:
- Purely theoretical
- Would require multiple unlikely conditions
- Pattern is common but safe in context

View File

@@ -0,0 +1,110 @@
# Test Validator Agent
## Role
You are a test quality reviewer that validates test coverage, test quality, and testing practices in pull request changes.
## Focus Areas
### 1. Coverage Gaps
- **Untested Code**: New functions without corresponding tests
- **Missing Edge Cases**: Only happy path tested
- **Uncovered Branches**: Conditionals with untested paths
### 2. Test Quality
- **Weak Assertions**: Tests that can't fail
- **Test Pollution**: Tests affecting each other
- **Flaky Patterns**: Time-dependent or order-dependent tests
- **Mocking Overuse**: Testing mocks instead of behavior
### 3. Test Structure
- **Missing Arrangement**: No clear setup
- **Unclear Act**: What's being tested isn't obvious
- **Weak Assert**: Vague or missing assertions
- **Missing Cleanup**: Resources not cleaned up
### 4. Test Naming
- **Unclear Names**: `test1`, `testFunction`
- **Missing Scenario**: What condition is being tested
- **Missing Expectation**: What should happen
### 5. Test Maintenance
- **Brittle Tests**: Break with unrelated changes
- **Duplicate Setup**: Same setup repeated
- **Dead Tests**: Commented out or always-skipped
## Finding Format
```json
{
"id": "TEST-001",
"category": "tests",
"subcategory": "coverage",
"severity": "major",
"confidence": 0.8,
"file": "src/services/auth.ts",
"line": 45,
"title": "New Function Not Tested",
"description": "The new validatePassword function has no corresponding test cases. This function handles security-critical validation.",
"evidence": "Added validatePassword() in auth.ts, no matching test in auth.test.ts",
"impact": "Regression bugs in password validation may go undetected.",
"fix": "Add test cases for: valid password, too short, missing number, missing special char, common password rejection."
}
```
## Severity Guidelines
| Severity | Criteria |
|----------|----------|
| Critical | No tests for security/critical functionality |
| Major | Significant functionality untested |
| Minor | Edge cases or minor paths untested |
| Suggestion | Test quality improvement opportunity |
## Confidence Calibration
Test coverage is verifiable:
HIGH confidence when:
- Can verify no test file exists
- Can see function is called but never in test
- Pattern is clearly problematic
MEDIUM confidence when:
- Tests might exist elsewhere
- Integration tests might cover it
- Pattern might be intentional
Suppress when:
- Generated code
- Simple getters/setters
- Framework code
## Test Expectations by Code Type
| Code Type | Expected Tests |
|-----------|---------------|
| API endpoint | Happy path, error cases, auth, validation |
| Utility function | Input variations, edge cases, errors |
| UI component | Rendering, interactions, accessibility |
| Database operation | CRUD, constraints, transactions |
## Constructive Suggestions
When flagging missing tests, suggest specific cases:
```
Missing tests for processPayment():
Suggested test cases:
1. Valid payment processes successfully
2. Invalid card number returns error
3. Insufficient funds handled
4. Network timeout retries appropriately
5. Duplicate payment prevention
```

View File

@@ -0,0 +1,46 @@
# pr-review - CLAUDE.md Integration
Add the following section to your project's CLAUDE.md file to enable pr-review.
---
## Pull Request Review
This project uses the pr-review plugin for automated code review.
### Commands
| Command | Use Case |
|---------|----------|
| `/pr-review <pr#>` | Full multi-agent review |
| `/pr-summary <pr#>` | Quick change summary |
| `/pr-findings <pr#>` | Filter review findings |
### Review Categories
Reviews analyze:
- **Security**: Injections, auth issues, data exposure
- **Performance**: N+1 queries, complexity, memory
- **Maintainability**: Code quality, duplication, naming
- **Tests**: Coverage gaps, test quality
### Confidence Threshold
Findings below 0.5 confidence are suppressed.
- HIGH (0.9+): Definite issue
- MEDIUM (0.7-0.89): Likely issue
- LOW (0.5-0.69): Possible concern
### Verdict Rules
| Condition | Verdict |
|-----------|---------|
| Critical findings | REQUEST_CHANGES |
| 2+ Major findings | REQUEST_CHANGES |
| Minor only | COMMENT |
| No issues | APPROVE |
---
Copy the section between the horizontal rules into your CLAUDE.md.

View File

@@ -0,0 +1,137 @@
# /pr-findings - Filter Review Findings
## Purpose
List and filter findings from a previous PR review by category, severity, or confidence level.
## Usage
```
/pr-findings <pr-number> [filters]
```
### Filters
```
--category <cat> Filter by category (security, performance, maintainability, tests)
--severity <sev> Filter by severity (critical, major, minor, suggestion)
--confidence <min> Minimum confidence score (0.0-1.0)
--file <pattern> Filter by file path pattern
```
## Examples
```
# Show only security findings
/pr-findings 123 --category security
# Show critical and major issues only
/pr-findings 123 --severity critical,major
# Show high-confidence findings only
/pr-findings 123 --confidence 0.8
# Show findings in specific files
/pr-findings 123 --file src/api/*
```
## Behavior
### Without Previous Review
If no review exists for this PR:
```
No review found for PR #123.
Would you like to:
1. Run full /pr-review now
2. Run quick /pr-summary
3. Cancel
```
### With Previous Review
Display filtered findings:
```
═══════════════════════════════════════════════════
PR #123 Findings (filtered: security)
═══════════════════════════════════════════════════
Showing 3 of 8 total findings
───────────────────────────────────────────────────
[SEC-001] SQL Injection Vulnerability
Confidence: 0.95 (HIGH) | Severity: Critical
File: src/api/users.ts:45
The query uses string interpolation without parameterization.
Fix: Use parameterized queries.
───────────────────────────────────────────────────
[SEC-002] Missing Input Validation
Confidence: 0.88 (MEDIUM) | Severity: Major
File: src/api/auth.ts:23
User input is passed directly to database without validation.
Fix: Add input validation middleware.
───────────────────────────────────────────────────
[SEC-003] Sensitive Data in Logs
Confidence: 0.72 (MEDIUM) | Severity: Minor
File: src/utils/logger.ts:15
Password field may be logged in debug mode.
Fix: Sanitize sensitive fields before logging.
═══════════════════════════════════════════════════
```
## Output Formats
### Default (Detailed)
Full finding details with descriptions and fixes.
### Compact (--compact)
```
SEC-001 | Critical | 0.95 | src/api/users.ts:45 | SQL Injection
SEC-002 | Major | 0.88 | src/api/auth.ts:23 | Missing Validation
SEC-003 | Minor | 0.72 | src/utils/logger.ts | Sensitive Logs
```
### JSON (--json)
```json
{
"pr": 123,
"findings": [
{
"id": "SEC-001",
"category": "security",
"severity": "critical",
"confidence": 0.95,
"file": "src/api/users.ts",
"line": 45,
"title": "SQL Injection Vulnerability",
"description": "...",
"fix": "..."
}
]
}
```
## Use Cases
- Focus on specific issue types
- Track resolution of findings
- Export findings for tracking
- Quick reference during fixes

View File

@@ -0,0 +1,139 @@
# /pr-review - Full Multi-Agent Review
## Purpose
Conduct a comprehensive pull request review using specialized agents for security, performance, maintainability, and test coverage.
## Usage
```
/pr-review <pr-number> [--repo owner/repo]
```
## Behavior
### Step 1: Fetch PR Data
Using Gitea MCP tools:
1. `get_pull_request` - PR metadata
2. `get_pr_diff` - Code changes
3. `get_pr_comments` - Existing discussion
### Step 2: Dispatch to Agents
The coordinator dispatches review tasks to specialized agents:
```
PR Review: #123 - Add user authentication
═══════════════════════════════════════════════════
Dispatching to review agents:
├─ Security Reviewer → analyzing...
├─ Performance Analyst → analyzing...
├─ Maintainability Auditor → analyzing...
└─ Test Validator → analyzing...
```
### Step 3: Aggregate Findings
Collect findings from all agents, each with:
- Category (security, performance, maintainability, tests)
- Severity (critical, major, minor, suggestion)
- Confidence score (0.0 - 1.0)
- File and line reference
- Description
- Suggested fix (if applicable)
### Step 4: Filter by Confidence
Only display findings with confidence >= 0.5:
| Confidence | Label | Description |
|------------|-------|-------------|
| 0.9 - 1.0 | HIGH | Definite issue, must address |
| 0.7 - 0.89 | MEDIUM | Likely issue, should address |
| 0.5 - 0.69 | LOW | Possible concern, consider addressing |
| < 0.5 | (suppressed) | Too uncertain to report |
### Step 5: Generate Report
```
═══════════════════════════════════════════════════
PR Review Report: #123
═══════════════════════════════════════════════════
Summary:
Files changed: 12
Lines added: 234
Lines removed: 45
Findings: 8 total
🔴 Critical: 1
🟠 Major: 2
🟡 Minor: 3
💡 Suggestions: 2
───────────────────────────────────────────────────
CRITICAL FINDINGS
───────────────────────────────────────────────────
[SEC-001] SQL Injection Vulnerability (Confidence: 0.95)
File: src/api/users.ts:45
Category: Security
The query uses string interpolation without parameterization:
```ts
const query = `SELECT * FROM users WHERE id = ${userId}`;
```
Suggested fix:
```ts
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);
```
───────────────────────────────────────────────────
MAJOR FINDINGS
───────────────────────────────────────────────────
[PERF-001] N+1 Query Pattern (Confidence: 0.82)
...
───────────────────────────────────────────────────
VERDICT
───────────────────────────────────────────────────
❌ REQUEST_CHANGES
This PR has 1 critical security issue that must be addressed
before merging. See SEC-001 above.
───────────────────────────────────────────────────
```
### Step 6: Submit Review (Optional)
```
Submit this review to Gitea?
1. Yes, with REQUEST_CHANGES
2. Yes, as COMMENT only
3. No, just show me the report
```
If yes, use `create_pr_review` MCP tool.
## Output
Full review report with:
- Summary statistics
- Findings grouped by severity
- Code snippets with context
- Suggested fixes
- Overall verdict
## Configuration
| Variable | Default | Description |
|----------|---------|-------------|
| `PR_REVIEW_CONFIDENCE_THRESHOLD` | `0.5` | Minimum confidence to report |
| `PR_REVIEW_AUTO_SUBMIT` | `false` | Auto-submit to Gitea |

View File

@@ -0,0 +1,103 @@
# /pr-summary - Quick PR Summary
## Purpose
Generate a quick summary of PR changes without conducting a full multi-agent review.
## Usage
```
/pr-summary <pr-number> [--repo owner/repo]
```
## Behavior
### Step 1: Fetch PR Data
Using Gitea MCP tools:
1. `get_pull_request` - PR metadata
2. `get_pr_diff` - Code changes
### Step 2: Analyze Changes
Quick analysis of:
- Files modified
- Types of changes (features, fixes, refactoring)
- Scope and impact
### Step 3: Generate Summary
```
═══════════════════════════════════════════════════
PR Summary: #123 - Add user authentication
═══════════════════════════════════════════════════
Author: @johndoe
Branch: feat/user-auth → development
Status: Open (ready for review)
───────────────────────────────────────────────────
CHANGES OVERVIEW
───────────────────────────────────────────────────
Files: 12 changed
+ 8 new files
~ 3 modified files
- 1 deleted file
Lines: +234 / -45 (net +189)
───────────────────────────────────────────────────
WHAT THIS PR DOES
───────────────────────────────────────────────────
This PR adds user authentication functionality:
1. **New API endpoints**
- POST /api/auth/login
- POST /api/auth/register
- POST /api/auth/logout
2. **Frontend components**
- LoginForm component
- RegisterForm component
- Auth context provider
3. **Database changes**
- New users table
- Sessions table
───────────────────────────────────────────────────
KEY FILES
───────────────────────────────────────────────────
• src/api/auth/login.ts (+85) - Login endpoint
• src/api/auth/register.ts (+120) - Registration
• src/components/LoginForm.tsx (+65) - Login UI
• src/db/migrations/001_users.sql (+45) - Schema
───────────────────────────────────────────────────
QUICK ASSESSMENT
───────────────────────────────────────────────────
Scope: Medium (authentication feature)
Risk: Medium (new security-sensitive code)
Recommendation: Full /pr-review suggested
═══════════════════════════════════════════════════
```
## Output
Summary report with:
- PR metadata
- Change statistics
- Plain-language description of changes
- Key files list
- Quick risk assessment
## When to Use
- Get quick overview before full review
- Triage multiple PRs
- Understand PR scope

Some files were not shown because too many files have changed in this diff Show More