Merge pull request 'development' (#456) from development into main
Reviewed-on: #456
This commit was merged in pull request #456.
This commit is contained in:
@@ -4,6 +4,22 @@ Quick reference for all commands in the Leo Claude Marketplace (v9.0.0+).
|
||||
|
||||
All commands follow the `/<noun> <action>` sub-command pattern.
|
||||
|
||||
## Invocation
|
||||
|
||||
Commands can be invoked in two ways:
|
||||
|
||||
1. **Via dispatch file:** `/doc audit` (routes through dispatch file to invoke `/doc-guardian:doc-audit`)
|
||||
2. **Direct plugin-prefixed:** `/doc-guardian:doc-audit` (invokes command directly)
|
||||
|
||||
Both methods work identically. The dispatch file provides a user-friendly interface with `$ARGUMENTS` parsing, while the direct format bypasses the dispatcher.
|
||||
|
||||
If dispatch routing fails, use the direct plugin-prefixed format: `/<plugin-name>:<command-name>`.
|
||||
|
||||
**Examples:**
|
||||
- `/sprint plan` → routes to `/projman:sprint-plan`
|
||||
- `/doc audit` → routes to `/doc-guardian:doc-audit`
|
||||
- `/pr review` → routes to `/pr-review:pr-review`
|
||||
|
||||
---
|
||||
|
||||
## Command Reference Table
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Purpose:** Systematic approach to diagnose and fix plugin loading issues.
|
||||
|
||||
Last Updated: 2026-01-28
|
||||
Last Updated: 2026-02-08
|
||||
|
||||
---
|
||||
|
||||
@@ -95,9 +95,9 @@ Manually test if the MCP server can start:
|
||||
```bash
|
||||
RUNTIME=~/.claude/plugins/marketplaces/leo-claude-mktplace
|
||||
|
||||
# Test Gitea MCP
|
||||
# Test Gitea MCP (uses gitea-mcp package from registry)
|
||||
cd $RUNTIME/mcp-servers/gitea
|
||||
PYTHONPATH=. .venv/bin/python -c "from mcp_server.server import main; print('OK')"
|
||||
.venv/bin/python -c "from gitea_mcp.server import main; print('OK')"
|
||||
|
||||
# Test NetBox MCP
|
||||
cd $RUNTIME/mcp-servers/netbox
|
||||
|
||||
@@ -8,6 +8,40 @@ v9.0.0 standardizes all commands to the `/<noun> <action>` sub-command pattern.
|
||||
|
||||
---
|
||||
|
||||
## Command Invocation
|
||||
|
||||
The `/<noun> <action>` pattern is a **display convention** for user-friendly command invocation. Under the hood, Claude Code resolves commands by filename using hyphens.
|
||||
|
||||
### How It Works
|
||||
|
||||
| You Type | What Happens | Actual Command Loaded |
|
||||
|----------|--------------|----------------------|
|
||||
| `/doc audit` | Dispatch file `doc.md` receives `$ARGUMENTS="audit"` | Routes to `/doc-guardian:doc-audit` (file: `doc-audit.md`) |
|
||||
| `/sprint plan` | Dispatch file `sprint.md` receives `$ARGUMENTS="plan"` | Routes to `/projman:sprint-plan` (file: `sprint-plan.md`) |
|
||||
| `/doc-guardian:doc-audit` | Direct invocation (bypasses dispatch) | Loads `doc-audit.md` directly |
|
||||
|
||||
### Two Invocation Methods
|
||||
|
||||
1. **User-friendly (via dispatch):** `/doc audit` — space-separated, routes through dispatch file
|
||||
2. **Direct (plugin-prefixed):** `/doc-guardian:doc-audit` — bypasses dispatch, invokes command directly
|
||||
|
||||
Both methods work identically. The dispatch file provides `$ARGUMENTS` parsing and a menu interface when invoked without arguments.
|
||||
|
||||
### Command Name Mapping
|
||||
|
||||
**Pattern:** Spaces in display names become hyphens in filenames.
|
||||
|
||||
| Display Name | Filename | Plugin-Prefixed |
|
||||
|--------------|----------|-----------------|
|
||||
| `/doc audit` | `doc-audit.md` | `/doc-guardian:doc-audit` |
|
||||
| `/sprint plan` | `sprint-plan.md` | `/projman:sprint-plan` |
|
||||
| `/pr review` | `pr-review.md` | `/pr-review:pr-review` |
|
||||
| `/gitflow commit` | `gitflow-commit.md` | `/git-flow:gitflow-commit` |
|
||||
|
||||
If dispatch routing fails, use the direct plugin-prefixed format.
|
||||
|
||||
---
|
||||
|
||||
## Complete Command Mapping
|
||||
|
||||
### projman
|
||||
|
||||
@@ -11,13 +11,21 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/clarity clarify` | Full 4-D methodology for complex requests |
|
||||
| `/clarity quick-clarify` | Rapid mode for simple disambiguation |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `clarify` | `/clarity-assist:clarity-clarify` | Full 4-D methodology for complex requests |
|
||||
| `quick-clarify` | `/clarity-assist:clarity-quick-clarify` | Rapid mode for simple disambiguation |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/clarity clarify`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/clarity-assist:clarity-clarify`)
|
||||
|
||||
@@ -11,19 +11,27 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/claude-config analyze` | Analyze CLAUDE.md for optimization opportunities |
|
||||
| `/claude-config optimize` | Optimize CLAUDE.md structure with preview/backup |
|
||||
| `/claude-config init` | Initialize new CLAUDE.md for a project |
|
||||
| `/claude-config diff` | Track CLAUDE.md changes over time with behavioral impact |
|
||||
| `/claude-config lint` | Lint CLAUDE.md for anti-patterns and best practices |
|
||||
| `/claude-config audit-settings` | Audit settings.local.json permissions (100-point score) |
|
||||
| `/claude-config optimize-settings` | Optimize permissions (profiles, consolidation, dry-run) |
|
||||
| `/claude-config permissions-map` | Visual review layer + permission coverage map |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `analyze` | `/claude-config-maintainer:claude-config-analyze` | Analyze CLAUDE.md for optimization opportunities |
|
||||
| `optimize` | `/claude-config-maintainer:claude-config-optimize` | Optimize CLAUDE.md structure with preview/backup |
|
||||
| `init` | `/claude-config-maintainer:claude-config-init` | Initialize new CLAUDE.md for a project |
|
||||
| `diff` | `/claude-config-maintainer:claude-config-diff` | Track CLAUDE.md changes over time with behavioral impact |
|
||||
| `lint` | `/claude-config-maintainer:claude-config-lint` | Lint CLAUDE.md for anti-patterns and best practices |
|
||||
| `audit-settings` | `/claude-config-maintainer:claude-config-audit-settings` | Audit settings.local.json permissions (100-point score) |
|
||||
| `optimize-settings` | `/claude-config-maintainer:claude-config-optimize-settings` | Optimize permissions (profiles, consolidation, dry-run) |
|
||||
| `permissions-map` | `/claude-config-maintainer:claude-config-permissions-map` | Visual review layer + permission coverage map |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/claude-config analyze`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/claude-config-maintainer:claude-config-analyze`)
|
||||
|
||||
@@ -10,22 +10,30 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|-------------|-------------|
|
||||
| `/cmdb search` | Search NetBox for devices, IPs, sites |
|
||||
| `/cmdb device` | Manage network devices (create, view, update, delete) |
|
||||
| `/cmdb ip` | Manage IP addresses and prefixes |
|
||||
| `/cmdb site` | Manage sites, locations, racks, and regions |
|
||||
| `/cmdb audit` | Data quality analysis (VMs, devices, naming, roles) |
|
||||
| `/cmdb register` | Register current machine into NetBox |
|
||||
| `/cmdb sync` | Sync machine state with NetBox (detect drift) |
|
||||
| `/cmdb topology` | Infrastructure topology diagrams |
|
||||
| `/cmdb change-audit` | NetBox audit trail queries with filtering |
|
||||
| `/cmdb ip-conflicts` | Detect IP conflicts and overlapping prefixes |
|
||||
| `/cmdb setup` | Setup wizard for NetBox MCP server |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `search` | `/cmdb-assistant:cmdb-search` | Search NetBox for devices, IPs, sites |
|
||||
| `device` | `/cmdb-assistant:cmdb-device` | Manage network devices (create, view, update, delete) |
|
||||
| `ip` | `/cmdb-assistant:cmdb-ip` | Manage IP addresses and prefixes |
|
||||
| `site` | `/cmdb-assistant:cmdb-site` | Manage sites, locations, racks, and regions |
|
||||
| `audit` | `/cmdb-assistant:cmdb-audit` | Data quality analysis (VMs, devices, naming, roles) |
|
||||
| `register` | `/cmdb-assistant:cmdb-register` | Register current machine into NetBox |
|
||||
| `sync` | `/cmdb-assistant:cmdb-sync` | Sync machine state with NetBox (detect drift) |
|
||||
| `topology` | `/cmdb-assistant:cmdb-topology` | Infrastructure topology diagrams |
|
||||
| `change-audit` | `/cmdb-assistant:cmdb-change-audit` | NetBox audit trail queries with filtering |
|
||||
| `ip-conflicts` | `/cmdb-assistant:cmdb-ip-conflicts` | Detect IP conflicts and overlapping prefixes |
|
||||
| `setup` | `/cmdb-assistant:cmdb-setup` | Setup wizard for NetBox MCP server |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/cmdb search`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/cmdb-assistant:cmdb-search`)
|
||||
|
||||
@@ -7,18 +7,26 @@ description: Security scanning and code refactoring — type /sentinel <action>
|
||||
|
||||
Security scanning and safe code refactoring tools.
|
||||
|
||||
When invoked without a sub-command, display available actions and ask which to run.
|
||||
When invoked without a sub-command or with `$ARGUMENTS`, handle as follows:
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/sentinel scan` | Full security audit (SQL injection, XSS, secrets, etc.) |
|
||||
| `/sentinel refactor` | Apply refactoring patterns to improve code |
|
||||
| `/sentinel refactor-dry` | Preview refactoring without applying changes |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `scan` | `/code-sentinel:sentinel-scan` | Full security audit (SQL injection, XSS, secrets, etc.) |
|
||||
| `refactor` | `/code-sentinel:sentinel-refactor` | Apply refactoring patterns to improve code |
|
||||
| `refactor-dry` | `/code-sentinel:sentinel-refactor-dry` | Preview refactoring without applying changes |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/sentinel scan`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/code-sentinel:sentinel-scan`)
|
||||
|
||||
@@ -10,17 +10,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|-------------|-------------|
|
||||
| `/cv validate` | Full marketplace compatibility validation |
|
||||
| `/cv check-agent` | Validate single agent definition |
|
||||
| `/cv list-interfaces` | Show all plugin interfaces |
|
||||
| `/cv dependency-graph` | Mermaid visualization of plugin dependencies |
|
||||
| `/cv setup` | Setup wizard for contract-validator MCP |
|
||||
| `/cv status` | Marketplace-wide health check |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `validate` | `/contract-validator:cv-validate` | Full marketplace compatibility validation |
|
||||
| `check-agent` | `/contract-validator:cv-check-agent` | Validate single agent definition |
|
||||
| `list-interfaces` | `/contract-validator:cv-list-interfaces` | Show all plugin interfaces |
|
||||
| `dependency-graph` | `/contract-validator:cv-dependency-graph` | Mermaid visualization of plugin dependencies |
|
||||
| `setup` | `/contract-validator:cv-setup` | Setup wizard for contract-validator MCP |
|
||||
| `status` | `/contract-validator:cv-status` | Marketplace-wide health check |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/cv validate`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/contract-validator:cv-validate`)
|
||||
|
||||
@@ -10,23 +10,31 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|-------------|-------------|
|
||||
| `/data ingest` | Load data from CSV, Parquet, JSON into DataFrame |
|
||||
| `/data profile` | Generate data profiling report with statistics |
|
||||
| `/data schema` | Explore database schemas, tables, columns |
|
||||
| `/data explain` | Explain query execution plan |
|
||||
| `/data lineage` | Show dbt model lineage and dependencies |
|
||||
| `/data lineage-viz` | dbt lineage visualization as Mermaid diagrams |
|
||||
| `/data run` | Run dbt models with validation |
|
||||
| `/data dbt-test` | Formatted dbt test runner with summary |
|
||||
| `/data quality` | DataFrame quality checks |
|
||||
| `/data review` | Comprehensive data integrity audits |
|
||||
| `/data gate` | Binary pass/fail data integrity gates |
|
||||
| `/data setup` | Setup wizard for data-platform MCP servers |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `ingest` | `/data-platform:data-ingest` | Load data from CSV, Parquet, JSON into DataFrame |
|
||||
| `profile` | `/data-platform:data-profile` | Generate data profiling report with statistics |
|
||||
| `schema` | `/data-platform:data-schema` | Explore database schemas, tables, columns |
|
||||
| `explain` | `/data-platform:data-explain` | Explain query execution plan |
|
||||
| `lineage` | `/data-platform:data-lineage` | Show dbt model lineage and dependencies |
|
||||
| `lineage-viz` | `/data-platform:data-lineage-viz` | dbt lineage visualization as Mermaid diagrams |
|
||||
| `run` | `/data-platform:data-run` | Run dbt models with validation |
|
||||
| `dbt-test` | `/data-platform:data-dbt-test` | Formatted dbt test runner with summary |
|
||||
| `quality` | `/data-platform:data-quality` | DataFrame quality checks |
|
||||
| `review` | `/data-platform:data-review` | Comprehensive data integrity audits |
|
||||
| `gate` | `/data-platform:data-gate` | Binary pass/fail data integrity gates |
|
||||
| `setup` | `/data-platform:data-setup` | Setup wizard for data-platform MCP servers |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/data ingest`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/data-platform:data-ingest`)
|
||||
|
||||
@@ -10,16 +10,24 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|-------------|-------------|
|
||||
| `/seed setup` | Setup wizard for data-seed configuration |
|
||||
| `/seed generate` | Generate seed data from schema or models |
|
||||
| `/seed apply` | Apply seed data to database or create fixture files |
|
||||
| `/seed profile` | Define reusable data profiles (small, medium, large) |
|
||||
| `/seed validate` | Validate seed data against schema constraints |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/data-seed:seed-setup` | Setup wizard for data-seed configuration |
|
||||
| `generate` | `/data-seed:seed-generate` | Generate seed data from schema or models |
|
||||
| `apply` | `/data-seed:seed-apply` | Apply seed data to database or create fixture files |
|
||||
| `profile` | `/data-seed:seed-profile` | Define reusable data profiles (small, medium, large) |
|
||||
| `validate` | `/data-seed:seed-validate` | Validate seed data against schema constraints |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/seed generate`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/data-seed:seed-generate`)
|
||||
|
||||
@@ -43,6 +43,9 @@ The `.mcp.json` file in the project root defines all MCP servers:
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
**Note:** Most servers use `mcp_server.server` (local source).
|
||||
Exception: gitea uses `gitea_mcp.server` (pip-installed package).
|
||||
```
|
||||
|
||||
### MCP Server Lifecycle
|
||||
|
||||
@@ -53,6 +53,9 @@ Execute `skills/visual-header.md` with context "Server Inspection".
|
||||
- Args: ["-m", "mcp_server.server"]
|
||||
- CWD: /path/to/mcp-servers/gitea
|
||||
- Env file: ~/.config/claude/gitea.env
|
||||
|
||||
**Note:** The gitea server uses `gitea_mcp.server` (installed from package).
|
||||
Other servers use `mcp_server.server` (local source).
|
||||
```
|
||||
|
||||
### Phase 2: Dependencies (--deps)
|
||||
|
||||
@@ -108,6 +108,9 @@ python-dotenv>=1.0.0
|
||||
"cwd": "mcp-servers/<server_name>"
|
||||
}
|
||||
```
|
||||
|
||||
**Note:** Use `mcp_server.server` for new servers being scaffolded.
|
||||
Exception: gitea uses `gitea_mcp.server` (pip-installed package).
|
||||
3. Show the change and ask user to confirm before writing
|
||||
|
||||
### Phase 5: Completion
|
||||
|
||||
@@ -10,16 +10,24 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|-------------|-------------|
|
||||
| `/debug-mcp status` | Show all MCP servers with health status |
|
||||
| `/debug-mcp test` | Test a specific MCP tool call |
|
||||
| `/debug-mcp logs` | View recent MCP server logs and errors |
|
||||
| `/debug-mcp inspect` | Inspect MCP server config and dependencies |
|
||||
| `/debug-mcp scaffold` | Generate MCP server skeleton project |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `status` | `/debug-mcp:debug-mcp-status` | Show all MCP servers with health status |
|
||||
| `test` | `/debug-mcp:debug-mcp-test` | Test a specific MCP tool call |
|
||||
| `logs` | `/debug-mcp:debug-mcp-logs` | View recent MCP server logs and errors |
|
||||
| `inspect` | `/debug-mcp:debug-mcp-inspect` | Inspect MCP server config and dependencies |
|
||||
| `scaffold` | `/debug-mcp:debug-mcp-scaffold` | Generate MCP server skeleton project |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/debug-mcp status`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/debug-mcp:debug-mcp-status`)
|
||||
|
||||
@@ -20,6 +20,9 @@ mcp-servers/<name>/
|
||||
└── README.md
|
||||
```
|
||||
|
||||
**Exception:** The gitea server uses the `gitea-mcp` package from Gitea PyPI
|
||||
instead of local source. Its module is `gitea_mcp`, not `mcp_server`.
|
||||
|
||||
## FastMCP Pattern (Recommended)
|
||||
|
||||
The FastMCP decorator pattern provides the simplest server implementation:
|
||||
|
||||
@@ -55,9 +55,13 @@ This reports broken dependencies (missing or incompatible versions).
|
||||
Verify the server's main module can be imported:
|
||||
|
||||
```bash
|
||||
cd <server_cwd> && .venv/bin/python -c "import mcp_server.server" 2>&1
|
||||
cd <server_cwd> && .venv/bin/python -c "import <module>.server" 2>&1
|
||||
```
|
||||
|
||||
Where `<module>` is the server's Python module:
|
||||
- gitea: `gitea_mcp` (pip-installed package)
|
||||
- All others: `mcp_server` (local source)
|
||||
|
||||
Common failures:
|
||||
| Error | Cause | Fix |
|
||||
|-------|-------|-----|
|
||||
|
||||
@@ -7,20 +7,28 @@ description: Documentation management and drift detection — type /doc <action>
|
||||
|
||||
Documentation management, drift detection, and synchronization.
|
||||
|
||||
When invoked without a sub-command, display available actions and ask which to run.
|
||||
When invoked without a sub-command or with `$ARGUMENTS`, handle as follows:
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/doc audit` | Full documentation audit - scans for doc drift |
|
||||
| `/doc sync` | Synchronize pending documentation updates |
|
||||
| `/doc changelog-gen` | Generate changelog from conventional commits |
|
||||
| `/doc coverage` | Documentation coverage metrics by function/class |
|
||||
| `/doc stale-docs` | Flag documentation behind code changes |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `audit` | `/doc-guardian:doc-audit` | Full documentation audit - scans for doc drift |
|
||||
| `sync` | `/doc-guardian:doc-sync` | Synchronize pending documentation updates |
|
||||
| `changelog-gen` | `/doc-guardian:doc-changelog-gen` | Generate changelog from conventional commits |
|
||||
| `coverage` | `/doc-guardian:doc-coverage` | Documentation coverage metrics by function/class |
|
||||
| `stale-docs` | `/doc-guardian:doc-stale-docs` | Flag documentation behind code changes |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/doc audit`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/doc-guardian:doc-audit`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/gitflow setup` | Configure git-flow for the current project |
|
||||
| `/gitflow commit` | Smart commit with optional --push, --merge, --sync |
|
||||
| `/gitflow branch-start` | Create a properly-named feature branch |
|
||||
| `/gitflow branch-cleanup` | Clean up merged/stale branches |
|
||||
| `/gitflow status` | Enhanced git status with recommendations |
|
||||
| `/gitflow config` | Configure git-flow settings |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/git-flow:gitflow-setup` | Configure git-flow for the current project |
|
||||
| `commit` | `/git-flow:gitflow-commit` | Smart commit with optional --push, --merge, --sync |
|
||||
| `branch-start` | `/git-flow:gitflow-branch-start` | Create a properly-named feature branch |
|
||||
| `branch-cleanup` | `/git-flow:gitflow-branch-cleanup` | Clean up merged/stale branches |
|
||||
| `status` | `/git-flow:gitflow-status` | Enhanced git status with recommendations |
|
||||
| `config` | `/git-flow:gitflow-config` | Configure git-flow settings |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/gitflow commit`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/git-flow:gitflow-commit`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/deploy setup` | Interactive setup wizard for deployment configuration |
|
||||
| `/deploy generate` | Generate docker-compose.yml, Caddyfile, and systemd units |
|
||||
| `/deploy validate` | Validate deployment configs for correctness and best practices |
|
||||
| `/deploy env` | Manage environment-specific config files (.env.development, .env.production) |
|
||||
| `/deploy check` | Pre-deployment health check (disk, memory, ports, DNS, Docker) |
|
||||
| `/deploy rollback` | Generate rollback plan for a deployment |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/ops-deploy-pipeline:deploy-setup` | Interactive setup wizard for deployment configuration |
|
||||
| `generate` | `/ops-deploy-pipeline:deploy-generate` | Generate docker-compose.yml, Caddyfile, and systemd units |
|
||||
| `validate` | `/ops-deploy-pipeline:deploy-validate` | Validate deployment configs for correctness and best practices |
|
||||
| `env` | `/ops-deploy-pipeline:deploy-env` | Manage environment-specific config files (.env.development, .env.production) |
|
||||
| `check` | `/ops-deploy-pipeline:deploy-check` | Pre-deployment health check (disk, memory, ports, DNS, Docker) |
|
||||
| `rollback` | `/ops-deploy-pipeline:deploy-rollback` | Generate rollback plan for a deployment |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/deploy generate`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/ops-deploy-pipeline:deploy-generate`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/release setup` | Setup wizard — detect version locations and release conventions |
|
||||
| `/release prepare` | Prepare release: bump versions, update changelog, create branch |
|
||||
| `/release validate` | Pre-release checks — verify versions, changelog, dependencies |
|
||||
| `/release tag` | Create and push git tag with release notes |
|
||||
| `/release rollback` | Revert a release — remove tag, revert version bump |
|
||||
| `/release status` | Show current version and unreleased changes |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/ops-release-manager:release-setup` | Setup wizard — detect version locations and release conventions |
|
||||
| `prepare` | `/ops-release-manager:release-prepare` | Prepare release: bump versions, update changelog, create branch |
|
||||
| `validate` | `/ops-release-manager:release-validate` | Pre-release checks — verify versions, changelog, dependencies |
|
||||
| `tag` | `/ops-release-manager:release-tag` | Create and push git tag with release notes |
|
||||
| `rollback` | `/ops-release-manager:release-rollback` | Revert a release — remove tag, revert version bump |
|
||||
| `status` | `/ops-release-manager:release-status` | Show current version and unreleased changes |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/release prepare`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/ops-release-manager:release-prepare`)
|
||||
|
||||
@@ -11,18 +11,26 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/pr review` | Full multi-agent PR review with confidence scoring |
|
||||
| `/pr summary` | Quick summary of PR changes |
|
||||
| `/pr findings` | List and filter review findings by category/severity |
|
||||
| `/pr diff` | Formatted diff with inline review comments |
|
||||
| `/pr init` | Quick project setup for PR reviews |
|
||||
| `/pr sync` | Sync config with git remote after repo move/rename |
|
||||
| `/pr setup` | Setup wizard for pr-review |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `review` | `/pr-review:pr-review` | Full multi-agent PR review with confidence scoring |
|
||||
| `summary` | `/pr-review:pr-summary` | Quick summary of PR changes |
|
||||
| `findings` | `/pr-review:pr-findings` | List and filter review findings by category/severity |
|
||||
| `diff` | `/pr-review:pr-diff` | Formatted diff with inline review comments |
|
||||
| `init` | `/pr-review:pr-init` | Quick project setup for PR reviews |
|
||||
| `sync` | `/pr-review:pr-sync` | Sync config with git remote after repo move/rename |
|
||||
| `setup` | `/pr-review:pr-setup` | Setup wizard for pr-review |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/pr review`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/pr-review:pr-review`)
|
||||
|
||||
@@ -11,12 +11,20 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/hygiene check` | Run project hygiene checks (temp files, misplaced files, empty dirs) |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `check` | `/project-hygiene:hygiene-check` | Run project hygiene checks (temp files, misplaced files, empty dirs) |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/hygiene check`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/project-hygiene:hygiene-check`)
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
2026-01-30T14:32:53 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/setup-workflows.md | README.md
|
||||
2026-01-30T14:32:53 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/setup.md | docs/COMMANDS-CHEATSHEET.md README.md
|
||||
2026-01-30T14:32:54 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/debug.md | docs/COMMANDS-CHEATSHEET.md README.md
|
||||
2026-01-30T14:32:54 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/test.md | docs/COMMANDS-CHEATSHEET.md README.md
|
||||
2026-01-30T14:33:13 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/sprint-status.md | docs/COMMANDS-CHEATSHEET.md README.md
|
||||
@@ -11,12 +11,12 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/adr create` | Create a new ADR wiki page |
|
||||
| `/adr list` | List all ADRs by status |
|
||||
| `/adr update` | Update an existing ADR |
|
||||
| `/adr supersede` | Mark an ADR as superseded by a new one |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `create` | `/projman:adr-create` | Create a new ADR wiki page |
|
||||
| `list` | `/projman:adr-list` | List all ADRs by status |
|
||||
| `update` | `/projman:adr-update` | Update an existing ADR |
|
||||
| `supersede` | `/projman:adr-supersede` | Mark an ADR as superseded by a new one |
|
||||
|
||||
## Usage
|
||||
|
||||
@@ -27,8 +27,16 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
/adr supersede <ADR-NNNN> --by <ADR-MMMM>
|
||||
```
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/adr create`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/projman:adr-create`)
|
||||
|
||||
@@ -11,12 +11,20 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/labels sync` | Sync label taxonomy to Gitea repository |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `sync` | `/projman:labels-sync` | Sync label taxonomy to Gitea repository |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/labels sync`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/projman:labels-sync`)
|
||||
|
||||
@@ -11,12 +11,12 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/project initiation` | Analyze source, create charter, decompose into epics |
|
||||
| `/project plan` | Create WBS, risk register, sprint roadmap |
|
||||
| `/project status` | Full project hierarchy view |
|
||||
| `/project close` | Retrospective, lessons learned, archive |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `initiation` | `/projman:project-initiation` | Analyze source, create charter, decompose into epics |
|
||||
| `plan` | `/projman:project-plan` | Create WBS, risk register, sprint roadmap |
|
||||
| `status` | `/projman:project-status` | Full project hierarchy view |
|
||||
| `close` | `/projman:project-close` | Retrospective, lessons learned, archive |
|
||||
|
||||
## Usage
|
||||
|
||||
@@ -27,8 +27,16 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
/project close <project-name>
|
||||
```
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/project initiation`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/projman:project-initiation`)
|
||||
|
||||
@@ -11,12 +11,20 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/projman setup` | Configure projman for a project |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/projman:projman-setup` | Configure projman for a project |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/projman setup`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/projman:projman-setup`)
|
||||
|
||||
@@ -16,7 +16,7 @@ agent: planner
|
||||
|
||||
Manage the full RFC lifecycle through sub-commands. RFCs provide a structured way to document, discuss, and approve changes before implementation.
|
||||
|
||||
When invoked without a sub-command, display available actions and ask which to run.
|
||||
When invoked without a sub-command or with `$ARGUMENTS`, handle sub-commands inline using the documentation below.
|
||||
|
||||
## Invocation
|
||||
|
||||
@@ -34,11 +34,19 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
| `approve` | `/rfc approve <number>` | Approve RFC in Review status |
|
||||
| `reject` | `/rfc reject <number>` | Reject RFC with documented reason |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/rfc create`):
|
||||
1. Match the first word of `$ARGUMENTS` against the Command column above
|
||||
2. Execute the corresponding sub-command using the inline documentation below
|
||||
3. Pass any remaining arguments to the sub-command handler
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
3. When the user responds, execute the matching sub-command using the inline documentation below
|
||||
|
||||
**Note:** RFC commands are handled inline in this file - there are no separate command files to invoke.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -7,21 +7,29 @@ description: Sprint lifecycle management — type /sprint <action> for commands
|
||||
|
||||
Sprint lifecycle management for projman.
|
||||
|
||||
When invoked without a sub-command, display available actions and ask which to run.
|
||||
When invoked without a sub-command or with `$ARGUMENTS`, handle as follows:
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/sprint plan` | Analyze requirements, create issues, request approval |
|
||||
| `/sprint start` | Begin execution, load context, dispatch tasks |
|
||||
| `/sprint status` | Check progress, blockers, completion percentage |
|
||||
| `/sprint close` | Capture lessons learned, close milestone |
|
||||
| `/sprint review` | Pre-close code quality review |
|
||||
| `/sprint test` | Run/generate tests for sprint scope |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `plan` | `/projman:sprint-plan` | Analyze requirements, create issues, request approval |
|
||||
| `start` | `/projman:sprint-start` | Begin execution, load context, dispatch tasks |
|
||||
| `status` | `/projman:sprint-status` | Check progress, blockers, completion percentage |
|
||||
| `close` | `/projman:sprint-close` | Capture lessons learned, close milestone |
|
||||
| `review` | `/projman:sprint-review` | Pre-close code quality review |
|
||||
| `test` | `/projman:sprint-test` | Run/generate tests for sprint scope |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/sprint plan`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/projman:sprint-plan`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/api setup` | Setup wizard for saas-api-platform |
|
||||
| `/api scaffold` | Generate routes, models, and schemas |
|
||||
| `/api validate` | Validate routes against OpenAPI spec |
|
||||
| `/api docs` | Generate or update OpenAPI specification |
|
||||
| `/api test-routes` | Generate test cases for API endpoints |
|
||||
| `/api middleware` | Add and configure middleware |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/saas-api-platform:api-setup` | Setup wizard for saas-api-platform |
|
||||
| `scaffold` | `/saas-api-platform:api-scaffold` | Generate routes, models, and schemas |
|
||||
| `validate` | `/saas-api-platform:api-validate` | Validate routes against OpenAPI spec |
|
||||
| `docs` | `/saas-api-platform:api-docs` | Generate or update OpenAPI specification |
|
||||
| `test-routes` | `/saas-api-platform:api-test-routes` | Generate test cases for API endpoints |
|
||||
| `middleware` | `/saas-api-platform:api-middleware` | Add and configure middleware |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/api scaffold`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/saas-api-platform:api-scaffold`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/db-migrate setup` | Setup wizard for migration tool detection |
|
||||
| `/db-migrate generate` | Generate migration from model diff |
|
||||
| `/db-migrate validate` | Check migration safety |
|
||||
| `/db-migrate plan` | Show execution plan with rollback strategy |
|
||||
| `/db-migrate history` | Display migration history |
|
||||
| `/db-migrate rollback` | Generate rollback migration |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/saas-db-migrate:db-migrate-setup` | Setup wizard for migration tool detection |
|
||||
| `generate` | `/saas-db-migrate:db-migrate-generate` | Generate migration from model diff |
|
||||
| `validate` | `/saas-db-migrate:db-migrate-validate` | Check migration safety |
|
||||
| `plan` | `/saas-db-migrate:db-migrate-plan` | Show execution plan with rollback strategy |
|
||||
| `history` | `/saas-db-migrate:db-migrate-history` | Display migration history |
|
||||
| `rollback` | `/saas-db-migrate:db-migrate-rollback` | Generate rollback migration |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/db-migrate generate`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/saas-db-migrate:db-migrate-generate`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/react setup` | Setup wizard for React project detection and configuration |
|
||||
| `/react component` | Scaffold component with props, types, and tests |
|
||||
| `/react route` | Add route with page component and error boundary |
|
||||
| `/react state` | Set up state management pattern (Context, Zustand, Redux Toolkit) |
|
||||
| `/react hook` | Generate custom hook with types and tests |
|
||||
| `/react lint` | Validate component tree and detect anti-patterns |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/saas-react-platform:react-setup` | Setup wizard for React project detection and configuration |
|
||||
| `component` | `/saas-react-platform:react-component` | Scaffold component with props, types, and tests |
|
||||
| `route` | `/saas-react-platform:react-route` | Add route with page component and error boundary |
|
||||
| `state` | `/saas-react-platform:react-state` | Set up state management pattern (Context, Zustand, Redux Toolkit) |
|
||||
| `hook` | `/saas-react-platform:react-hook` | Generate custom hook with types and tests |
|
||||
| `lint` | `/saas-react-platform:react-lint` | Validate component tree and detect anti-patterns |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/react component`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/saas-react-platform:react-component`)
|
||||
|
||||
@@ -11,17 +11,25 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/test setup` | Setup wizard — detect framework, configure test runner |
|
||||
| `/test generate` | Generate test cases for functions, classes, or modules |
|
||||
| `/test coverage` | Analyze coverage and identify untested paths |
|
||||
| `/test fixtures` | Generate or manage test fixtures and mocks |
|
||||
| `/test e2e` | Generate end-to-end test scenarios |
|
||||
| `/test run` | Run tests with formatted output |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `setup` | `/saas-test-pilot:test-setup` | Setup wizard — detect framework, configure test runner |
|
||||
| `generate` | `/saas-test-pilot:test-generate` | Generate test cases for functions, classes, or modules |
|
||||
| `coverage` | `/saas-test-pilot:test-coverage` | Analyze coverage and identify untested paths |
|
||||
| `fixtures` | `/saas-test-pilot:test-fixtures` | Generate or manage test fixtures and mocks |
|
||||
| `e2e` | `/saas-test-pilot:test-e2e` | Generate end-to-end test scenarios |
|
||||
| `run` | `/saas-test-pilot:test-run` | Run tests with formatted output |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/test generate`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/saas-test-pilot:test-generate`)
|
||||
|
||||
@@ -10,23 +10,31 @@ When invoked without a sub-command, display available actions and ask which to r
|
||||
|
||||
## Available Commands
|
||||
|
||||
| Command | Description |
|
||||
|-------------|-------------|
|
||||
| `/viz theme` | Apply existing theme to visualizations |
|
||||
| `/viz theme-new` | Create new custom theme with design tokens |
|
||||
| `/viz theme-css` | Export theme as CSS custom properties |
|
||||
| `/viz component` | Inspect DMC component props and validation |
|
||||
| `/viz dashboard` | Create dashboard layouts with filters and grids |
|
||||
| `/viz chart` | Create Plotly charts with theme integration |
|
||||
| `/viz chart-export` | Export charts to PNG, SVG, PDF via kaleido |
|
||||
| `/viz breakpoints` | Configure responsive layout breakpoints |
|
||||
| `/viz accessibility-check` | Color blind validation (WCAG contrast ratios) |
|
||||
| `/viz design-review` | Detailed design system audits |
|
||||
| `/viz design-gate` | Binary pass/fail design system validation |
|
||||
| `/viz setup` | Setup wizard for viz-platform MCP server |
|
||||
| Action | Command to Invoke | Description |
|
||||
|--------|-------------------|-------------|
|
||||
| `theme` | `/viz-platform:viz-theme` | Apply existing theme to visualizations |
|
||||
| `theme-new` | `/viz-platform:viz-theme-new` | Create new custom theme with design tokens |
|
||||
| `theme-css` | `/viz-platform:viz-theme-css` | Export theme as CSS custom properties |
|
||||
| `component` | `/viz-platform:viz-component` | Inspect DMC component props and validation |
|
||||
| `dashboard` | `/viz-platform:viz-dashboard` | Create dashboard layouts with filters and grids |
|
||||
| `chart` | `/viz-platform:viz-chart` | Create Plotly charts with theme integration |
|
||||
| `chart-export` | `/viz-platform:viz-chart-export` | Export charts to PNG, SVG, PDF via kaleido |
|
||||
| `breakpoints` | `/viz-platform:viz-breakpoints` | Configure responsive layout breakpoints |
|
||||
| `accessibility-check` | `/viz-platform:viz-accessibility-check` | Color blind validation (WCAG contrast ratios) |
|
||||
| `design-review` | `/viz-platform:viz-design-review` | Detailed design system audits |
|
||||
| `design-gate` | `/viz-platform:viz-design-gate` | Binary pass/fail design system validation |
|
||||
| `setup` | `/viz-platform:viz-setup` | Setup wizard for viz-platform MCP server |
|
||||
|
||||
## Workflow
|
||||
## Routing
|
||||
|
||||
1. Display the table above
|
||||
2. Ask: "Which command would you like to run?"
|
||||
3. Route to the selected sub-command
|
||||
If `$ARGUMENTS` is provided (e.g., user typed `/viz theme`):
|
||||
1. Match the first word of `$ARGUMENTS` against the **Action** column above
|
||||
2. **Invoke the corresponding command** from the "Command to Invoke" column using the Skill tool
|
||||
3. Pass any remaining arguments to the invoked command
|
||||
|
||||
If no arguments provided:
|
||||
1. Display the Available Commands table
|
||||
2. Ask: "Which action would you like to run?"
|
||||
3. When the user responds, invoke the matching command using the Skill tool
|
||||
|
||||
**Note:** Commands can also be invoked directly using their plugin-prefixed names (e.g., `/viz-platform:viz-theme`)
|
||||
|
||||
Reference in New Issue
Block a user