58 Commits

Author SHA1 Message Date
a034c12eb6 Merge pull request 'feat(projman): hardening sprint v5.8.0' (#387) from feat/projman-hardening into development
Reviewed-on: #387
2026-02-02 19:10:13 +00:00
636bd0af59 chore: bump version to 5.8.0, update CHANGELOG
- Added [5.8.0] section documenting all projman hardening changes
- Updated README.md title to v5.8.0
- Updated marketplace.json version to 5.8.0

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 14:07:15 -05:00
bf5029d6dc fix(contract-validator): update test for new contract INFO issue
Test fixture without gate_contract now correctly expects INFO issue
rather than zero issues.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 14:05:24 -05:00
e939af0689 docs(projman): expand /test command documentation
- Added sprint integration section (pre-close verification workflow)
- Added concrete usage examples for all modes
- Added edge cases table
- Added DO NOT rules for both modes

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 14:02:32 -05:00
eb6ce62a76 feat(projman): add sprint dispatch log for session recovery
- progress-tracking.md: new Sprint Dispatch Log section with event types
- orchestrator.md: new responsibility to maintain dispatch log
- Enables timeline reconstruction after interrupted sessions

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 14:00:24 -05:00
f7bcd48fc0 refactor(projman): create shared visual-output skill for DRY headers
- New skill: visual-output.md defines all header, progress, and verdict formats
- All 4 agent files now reference the skill instead of inline templates
- Phase Registry table maps agents to their emoji and phase name
- Single source of truth for visual branding changes

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:57:56 -05:00
72b3436a24 feat(contract-validator): add gate contract versioning
- design-gate.md and data-gate.md declare gate_contract: v1
- domain-consultation.md Gate Command Reference includes Contract column
- validate_workflow_integration now checks contract version compatibility
- Tests added for match, mismatch, and missing contract scenarios

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:54:19 -05:00
bea46d7689 feat(projman): add sprint lifecycle state machine via milestone metadata
- New skill: sprint-lifecycle.md defines states, transitions, and check protocol
- All sprint commands now check and set lifecycle state
- States tracked in milestone description metadata (Sprint/Planning, Sprint/Executing, Sprint/Reviewing)
- Out-of-order calls produce warnings with guidance
- --force override available for all lifecycle checks
- Added Sprint/* labels to label taxonomy documentation

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:48:13 -05:00
f2fddafca3 refactor(projman): normalize RFC to sub-command pattern, absorb clear-cache
- Created unified /rfc command with create|list|review|approve|reject sub-commands
- Deleted 5 individual rfc-*.md command files
- Moved /clear-cache into /setup --clear-cache
- Updated all cross-references in skills, docs, and integration files
- Command count: 17 -> 12 (net -5)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:43:29 -05:00
fdcb5d9874 feat(projman): harden sprint approval gate with --force override
- sprint-approval.md: approval is now a hard block, not a warning
- sprint-start.md: added --force flag documentation
- orchestrator.md: approval verification is now a hard stop
- docs: updated commands cheatsheet

BREAKING: /sprint-start now requires approval or --force flag

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:37:35 -05:00
45510b44c0 Merge pull request 'fix(marketplace): remove integrates_with field (schema violation)' (#384) from fix/marketplace-schema-hotfix into development
Reviewed-on: #384
2026-02-02 16:47:12 +00:00
79468f5d9e fix(marketplace): remove integrates_with field (schema violation)
Claude Code's marketplace schema does not support custom fields.
The `integrates_with` field on data-platform and viz-platform caused:
"Invalid schema: plugins.9: Unrecognized key: integrates_with"

This reverts the schema extension while keeping the validate_workflow_integration
MCP tool functional (it reads from plugin.json files directly, not marketplace.json).

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 11:46:29 -05:00
9148e21bc5 Merge pull request 'feat(contract-validator): add validate_workflow_integration tool (v5.7.1)' (#382) from feat/v5.7.1-domain-advisory-hardening into development
Reviewed-on: #382
2026-02-02 16:27:18 +00:00
2925ec4229 feat(contract-validator): add validate_workflow_integration tool (v5.7.1)
Domain Advisory Pattern Hardening - patch release to close gaps from v5.6.0/v5.7.0:

## Added
- New `validate_workflow_integration` MCP tool validates domain plugins expose
  required advisory interfaces (gate command, review command, advisory agent)
- New `MISSING_INTEGRATION` issue type for workflow integration validation
- New `WorkflowIntegrationResult` Pydantic model for structured validation output
- `integrates_with` field on viz-platform and data-platform in marketplace.json
  declaring projman integration metadata
- 4 new test cases for workflow integration validation

## Fixed
- scripts/setup.sh banner version updated from v5.1.0 to v5.7.1

## Documentation
- Updated mcp-tools-reference.md with new tool
- Updated validation-rules.md with Workflow Integration Checks section
- Added /design-gate, /design-review, /data-gate, /data-review to COMMANDS-CHEATSHEET
- Added contract-validator to CONFIGURATION.md plugin table
- Updated README.md Contract Validator tools table

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 11:24:51 -05:00
4340873f4e Merge pull request 'fix: update README.md version to 5.7.0' (#380) from fix/readme-version-5.7.0 into development
Reviewed-on: #380
2026-02-02 14:57:32 +00:00
98fd4e45e2 fix: update README.md version to 5.7.0
The README title was still showing v5.6.0 after the Sprint 10 release.
All other version references (CHANGELOG.md, marketplace.json) were correct.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 09:55:36 -05:00
793565aaaa Merge pull request 'feat: Sprint 10 - Data Platform Domain Advisory Pattern (v5.7.0)' (#378) from feat/sprint-10-data-platform-advisory into development
Reviewed-on: #378
2026-02-02 14:49:57 +00:00
27f3603f52 Merge feat/377-version-docs 2026-02-02 01:32:24 -05:00
2872092554 docs: bump version to 5.7.0 and update documentation
- marketplace.json: 5.6.0 → 5.7.0
- data-platform plugin.json: 1.1.0 → 1.3.0
- CHANGELOG.md: Add v5.7.0 entry with data-platform additions
- README.md: Update Domain Advisory table (Data: planned → active)

Domain Advisory Pattern now fully operational for both domains.

Closes #377

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 01:31:39 -05:00
4c857dde47 Merge feat/376-data-review-command 2026-02-02 01:30:26 -05:00
efe3808bd2 feat(data-platform): add /data-review command
Comprehensive data integrity audit for human review.

- Detailed report with FAIL/WARN/INFO severity levels
- Schema, lineage, dbt, and PostGIS validation
- Actionable recommendations for each finding
- Graceful degradation when components unavailable

Use cases: sprint planning, code review, post-migration,
periodic health checks, project onboarding.

Closes #376

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 01:29:41 -05:00
61c315a605 Merge feat/375-data-gate-command 2026-02-02 01:29:03 -05:00
56d3307cd3 feat(data-platform): add /data-gate command
Binary pass/fail gate command for projman orchestrator integration.

- Invoked when Domain/Data label present on issue
- Checks FAIL-level violations only (speed optimization)
- Returns compact PASS/FAIL output for automation
- Graceful degradation when database/dbt unavailable

Completes the Domain Advisory Pattern for data domain.

Closes #375

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 01:28:19 -05:00
ea9d501a5d Merge feat/374-data-advisor-agent 2026-02-02 01:27:38 -05:00
cd27b92b28 feat(data-platform): add data-advisor agent
Advisory agent for data integrity validation using existing MCP tools.

Features:
- Two operating modes: review (detailed) and gate (binary)
- PostgreSQL schema validation
- dbt project health checks (parse, compile, test, lineage)
- PostGIS spatial validation
- Python code pattern scanning
- Graceful degradation when components unavailable

Integrates with projman orchestrator for Domain/Data gates.

Closes #374

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 01:26:54 -05:00
61654057b8 Merge feat/373-data-integrity-audit-skill 2026-02-02 01:25:39 -05:00
2c998dff1d feat(data-platform): add data-integrity-audit skill
Define audit rules, severity classification, scanning strategies,
and report templates for data integrity validation.

Covers:
- Schema validity (PostgreSQL tables, columns, types)
- dbt project health (parse, compile, test, lineage)
- PostGIS compliance (SRID, geometry types, extent)
- Data type consistency (DataFrame dtypes)
- Query safety patterns

Closes #373

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 01:24:54 -05:00
192f808f48 Merge pull request 'feat: Domain Advisory Pattern - viz-platform integration (Sprint 9)' (#370) from feat/sprint-9-domain-advisory-pattern into development
Reviewed-on: #370
2026-02-01 23:46:53 +00:00
65574a03fb feat(projman): add domain-consultation skill and update orchestrator
- Create domain-consultation.md skill with detection rules and gate protocols
- Update orchestrator.md to load skill and run domain gates before completion
- Add critical reminder for domain gate enforcement

Closes #356
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:32:40 -05:00
571c713697 Merge feat/363-domain-labels-version-bump 2026-02-01 18:30:59 -05:00
5429f193b3 Merge feat/361-planner-domain-consultation 2026-02-01 18:30:59 -05:00
a866e0d43d Merge feat/359-design-review-command 2026-02-01 18:30:49 -05:00
2f5161675c Merge feat/360-design-gate-command 2026-02-01 18:30:49 -05:00
f95b7eb650 Merge feat/358-design-reviewer-agent 2026-02-01 18:30:49 -05:00
8095f16cd6 Merge feat/357-design-system-audit-skill 2026-02-01 18:30:43 -05:00
7d2705e3bf feat(labels): add Domain/Viz and Domain/Data labels for cross-plugin integration
Add new Domain category with 2 labels for domain-specific validation gates:
- Domain/Viz: triggers viz-platform design gates for frontend/visualization work
- Domain/Data: triggers data-platform data gates for data engineering work

Update version to 5.6.0 and document Domain Advisory Pattern feature.

Closes #363

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:23:27 -05:00
0d04c8703a feat(viz-platform): add /design-review command for design audits
Add standalone command that invokes the design-reviewer agent to
perform detailed design system compliance audits on target paths.
Returns comprehensive findings grouped by severity with file paths,
line numbers, and recommended fixes.

Closes #359

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:20:14 -05:00
407dd1b93b feat(viz-platform): add design-gate command for binary pass/fail validation
Add /design-gate command that provides binary pass/fail validation for
design system compliance. This command is used by projman orchestrator
during sprint execution to gate issue completion for Domain/Viz issues.

Features:
- Binary PASS/FAIL output for automation
- Checks only FAIL-level violations (invalid props, missing components)
- Integrates with projman sprint execution workflow
- Lightweight alternative to /design-review

Closes #360

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:18:09 -05:00
4614726350 feat(projman): add domain consultation step to planner agent
Integrate domain-consultation skill into the planner agent workflow:
- Add skills/domain-consultation.md to Skills to Load section
- Add new responsibility "7. Domain Consultation" between Task Sizing and Issue Creation
- Renumber subsequent sections (Issue Creation -> 8, Request Approval -> 9)
- Add critical reminder #8 to always check domain signals

The domain consultation step analyzes planned issues for domain-specific
signals (viz-platform, data-platform) and appends appropriate acceptance
criteria before issue creation.

Closes #361

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:15:15 -05:00
69358a78ba feat(viz-platform): add design-reviewer agent for design system compliance
Add design reviewer agent that uses viz-platform MCP tools to audit code
for design system compliance in Dash/DMC applications.

Features:
- Review mode: detailed report with FAIL/WARN/INFO severity levels
- Gate mode: binary PASS/FAIL for CI/CD integration
- Component validation using validate_component, get_component_props
- Theme compliance checking for hardcoded colors/sizes
- Accessibility validation using accessibility_validate_colors
- Structured output for projman orchestrator integration

Closes #358

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:13:15 -05:00
557bf6115b feat(viz-platform): add design-system-audit skill
Add comprehensive design system audit skill that provides:
- What to check: component prop validity, theme token usage,
  accessibility compliance, responsive design
- Common violation patterns at FAIL/WARN/INFO severity levels
- Scanning strategy for finding DMC components in Python files
- Report template for audit output
- MCP tool integration patterns

Closes #357

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:06:21 -05:00
6eeb4a4e9a feat(projman): add domain-consultation skill for cross-plugin integration
Add the core skill that enables projman agents to detect and consult
domain-specific plugins (viz-platform, data-platform) during sprint
lifecycle. Includes domain detection rules, planning protocol,
execution gate protocol, review protocol, and extensibility guidelines.

Closes #356

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 18:05:39 -05:00
fde61f5f73 Merge pull request 'chore: release v5.5.0' (#353) from chore/release-5.5.0 into development
Reviewed-on: #353
2026-02-01 19:33:20 +00:00
addfc9c1d5 chore: release v5.5.0
- RFC System for Feature Tracking
- 5 new commands: /rfc-create, /rfc-list, /rfc-review, /rfc-approve, /rfc-reject
- New MCP tool: allocate_rfc_number
- Sprint integration: /sprint-plan detects approved RFCs
- Clarity-assist integration: feature request detection

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 14:29:25 -05:00
733b8679c9 Merge pull request 'docs: add RFC commands to README and bump projman version' (#351) from feat/rfc-system into development
Reviewed-on: #351
2026-02-01 19:10:13 +00:00
5becd3d41c Merge pull request 'docs: add RFC commands to README and bump projman version' (#350) from fix/rfc-docs into development
Reviewed-on: #350
2026-02-01 19:08:56 +00:00
305c534402 docs: add RFC commands to README and bump projman version
- Add 5 RFC commands to projman Commands line in README.md
- Bump projman version 3.3.0 → 3.4.0 in marketplace.json

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 14:05:02 -05:00
7b7e7dce16 docs: add RFC commands to README and bump projman version
- Add 5 RFC commands to projman Commands line in README.md
- Bump projman version 3.3.0 → 3.4.0 in marketplace.json

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 13:58:59 -05:00
b9eaae5317 Merge pull request 'feat(projman): add RFC system for feature tracking' (#348) from feat/rfc-system into development
Reviewed-on: #348
2026-02-01 17:42:01 +00:00
16acc0609e feat(projman): add RFC system for feature tracking
Implement wiki-based Request for Comments system for capturing,
reviewing, and tracking feature ideas through their lifecycle.

New commands:
- /rfc-create: Create RFC from conversation or clarified spec
- /rfc-list: List RFCs grouped by status
- /rfc-review: Submit Draft RFC for review
- /rfc-approve: Approve RFC for sprint planning
- /rfc-reject: Reject RFC with documented reason

RFC lifecycle: Draft → Review → Approved → Implementing → Implemented

Integration:
- /sprint-plan detects approved RFCs and offers selection
- /sprint-close updates RFC status on completion
- clarity-assist suggests /rfc-create for feature ideas

New MCP tool: allocate_rfc_number

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 12:38:02 -05:00
f0f4369eac Merge pull request 'fix: correct hooks.json structure with nested matcher objects' (#346) from fix/hooks-json-structure into development
Reviewed-on: #346
2026-01-31 21:14:44 +00:00
89e841d448 fix: correct hooks.json structure with nested matcher objects
The hooks.json files had incorrect structure. Claude Code requires:
- Top-level "hooks" object
- Event names as keys containing arrays
- Each array element must have "matcher" and nested "hooks" array

Fixed 8 plugins:
- clarity-assist
- claude-config-maintainer
- cmdb-assistant
- contract-validator
- data-platform
- pr-review
- projman
- viz-platform

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 16:07:25 -05:00
b6b09c1754 Merge pull request 'fix: correct hooks.json structure per Claude Code documentation' (#344) from fix/hooks-json-structure into development
Reviewed-on: #344
2026-01-31 19:28:26 +00:00
94d8f03cf9 fix: correct hooks.json structure per Claude Code documentation
Three plugins had incorrect hooks.json structure that caused hooks to fail:

- pr-review: SessionStart used nested `hooks` array without matcher
- cmdb-assistant: SessionStart used nested `hooks` array without matcher
- git-flow: Used completely wrong format (array with `event` field)

Per Claude Code documentation:
- Without matcher: direct `type`/`command` in the event array
- With matcher: nested `hooks` array inside matcher object

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 14:26:51 -05:00
f23e047842 Merge pull request 'docs: add mandatory behavior rules to CLAUDE.md' (#342) from fix/revert-corrupted-hooks-and-update-rules into development
Reviewed-on: #342
2026-01-30 23:14:53 +00:00
dc59cb3713 docs: add mandatory behavior rules to CLAUDE.md
Add prominent behavior rules section at top of CLAUDE.md to ensure
thorough verification before claiming completion and believing user
reports of issues.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 18:13:28 -05:00
a78bde2e42 Merge pull request 'fix: address critical issues from codebase analysis' (#340) from fix/critical-issues-from-analysis into development
Reviewed-on: #340
2026-01-30 23:07:21 +00:00
f082b78c0b fix: address critical issues from codebase analysis
- Add hooks declarations to 9 plugins missing them in marketplace.json
- Change .mcp.json to use relative paths (portable across users)
- Fix pr-review hook schema to use standard nested hooks structure
- Fix token exposure in cmdb-assistant startup-check.sh (use curl -K)
- Update version to 5.4.1 in marketplace.json, README.md
- Fix CANONICAL-PATHS.md version (was incorrectly showing 5.5.0)

All 12 plugins now have hooks properly registered.
All validations pass.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 18:06:04 -05:00
68 changed files with 4449 additions and 157 deletions

View File

@@ -6,12 +6,12 @@
},
"metadata": {
"description": "Project management plugins with Gitea and NetBox integrations",
"version": "5.4.0"
"version": "5.8.0"
},
"plugins": [
{
"name": "projman",
"version": "3.3.0",
"version": "3.4.0",
"description": "Sprint planning and project management with Gitea integration",
"source": "./plugins/projman",
"author": {
@@ -20,6 +20,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/projman/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "development",
"tags": ["sprint", "agile", "gitea", "project-management"],
"license": "MIT"
@@ -42,7 +43,7 @@
},
{
"name": "code-sentinel",
"version": "1.0.0",
"version": "1.0.1",
"description": "Security scanning and code refactoring tools",
"source": "./plugins/code-sentinel",
"author": {
@@ -83,6 +84,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/cmdb-assistant/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "infrastructure",
"tags": ["cmdb", "netbox", "dcim", "ipam", "data-quality", "validation"],
"license": "MIT"
@@ -98,6 +100,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/claude-config-maintainer/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "development",
"tags": ["claude-md", "configuration", "optimization"],
"license": "MIT"
@@ -113,6 +116,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/clarity-assist/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "productivity",
"tags": ["prompts", "requirements", "clarification", "nd-friendly"],
"license": "MIT"
@@ -128,6 +132,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/git-flow/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "development",
"tags": ["git", "workflow", "commits", "branching"],
"license": "MIT"
@@ -143,13 +148,14 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/pr-review/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "development",
"tags": ["code-review", "pull-requests", "security", "quality"],
"license": "MIT"
},
{
"name": "data-platform",
"version": "1.2.0",
"version": "1.3.0",
"description": "Data engineering tools with pandas, PostgreSQL/PostGIS, and dbt integration",
"source": "./plugins/data-platform",
"author": {
@@ -158,6 +164,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/data-platform/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "data",
"tags": ["pandas", "postgresql", "postgis", "dbt", "data-engineering", "etl"],
"license": "MIT"
@@ -173,6 +180,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/viz-platform/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "visualization",
"tags": ["dash", "plotly", "mantine", "charts", "dashboards", "theming", "dmc"],
"license": "MIT"
@@ -188,6 +196,7 @@
},
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/contract-validator/README.md",
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
"hooks": ["./hooks/hooks.json"],
"category": "development",
"tags": ["validation", "contracts", "compatibility", "agents", "interfaces", "cross-plugin"],
"license": "MIT"

View File

@@ -0,0 +1,249 @@
# CLAUDE.md
This file provides guidance to Claude Code when working with code in this repository.
## Project Overview
**Repository:** leo-claude-mktplace
**Version:** 3.0.1
**Status:** Production Ready
A plugin marketplace for Claude Code containing:
| 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 |
## Quick Start
```bash
# Validate marketplace compliance
./scripts/validate-marketplace.sh
# Setup commands (in a target project with plugin installed)
/initial-setup # First time: full setup wizard
/project-init # New project: quick config
/project-sync # After repo move: sync config
# Run projman commands
/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
```
## Repository Structure
```
leo-claude-mktplace/
├── .claude-plugin/
│ └── 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
│ │ ├── mcp-servers/gitea -> ../../../mcp-servers/gitea # SYMLINK
│ │ ├── commands/ # 12 commands (incl. setup)
│ │ ├── hooks/ # SessionStart mismatch detection
│ │ ├── agents/ # 4 agents
│ │ └── skills/label-taxonomy/
│ ├── git-flow/ # Git workflow automation
│ │ ├── .claude-plugin/plugin.json
│ │ ├── commands/ # 8 commands
│ │ └── agents/
│ ├── pr-review/ # Multi-agent PR review
│ │ ├── .claude-plugin/plugin.json
│ │ ├── .mcp.json
│ │ ├── mcp-servers/gitea -> ../../../mcp-servers/gitea # SYMLINK
│ │ ├── commands/ # 6 commands (incl. setup)
│ │ ├── hooks/ # SessionStart mismatch detection
│ │ └── agents/ # 5 agents
│ ├── clarity-assist/ # Prompt optimization (NEW v3.0.0)
│ │ ├── .claude-plugin/plugin.json
│ │ ├── commands/ # 2 commands
│ │ └── agents/
│ ├── doc-guardian/ # Documentation drift detection
│ ├── code-sentinel/ # Security scanning & refactoring
│ ├── claude-config-maintainer/
│ ├── cmdb-assistant/
│ └── project-hygiene/
├── scripts/
│ ├── setup.sh, post-update.sh
│ └── validate-marketplace.sh # Marketplace compliance validation
└── docs/
├── CANONICAL-PATHS.md # Single source of truth for paths
└── CONFIGURATION.md # Centralized configuration guide
```
## CRITICAL: Rules You MUST Follow
### 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 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 (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_API_URL, GITEA_API_TOKEN) |
| Project | `.env` in project root | Repository specification (GITEA_ORG, GITEA_REPO) |
**Note:** `GITEA_ORG` is at project level since different projects may belong to different organizations.
### Branch-Aware Security
| Branch Pattern | Mode | Capabilities |
|----------------|------|--------------|
| `development`, `feat/*` | Development | Full access |
| `staging` | Staging | Read-only code, can create issues |
| `main`, `master` | Production | Read-only, emergency only |
## Label Taxonomy
43 labels total: 27 organization + 16 repository
**Organization:** Agent/2, Complexity/3, Efforts/5, Priority/4, Risk/3, Source/4, Type/6
**Repository:** Component/9, Tech/7
Sync with `/labels-sync` command.
## Lessons Learned System
Stored in Gitea Wiki under `lessons-learned/sprints/`.
**Workflow:**
1. Orchestrator captures at sprint close via MCP tools
2. Planner searches at sprint start using `search_lessons`
3. Tags enable cross-project discovery
## Common Operations
### Adding a New Plugin
1. Create `plugins/{name}/.claude-plugin/plugin.json`
2. Add entry to `.claude-plugin/marketplace.json` with category, tags, license
3. Create `README.md` and `claude-md-integration.md`
4. If using MCP server, create symlink: `ln -s ../../../mcp-servers/{server} plugins/{name}/mcp-servers/{server}`
5. Run `./scripts/validate-marketplace.sh`
6. Update `CHANGELOG.md`
### Adding a Command to projman
1. Create `plugins/projman/commands/{name}.md`
2. Update `plugins/projman/README.md`
3. Update marketplace description if significant
### Validation
```bash
./scripts/validate-marketplace.sh # Validates all manifests
```
## Path Verification Protocol
**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
| Document | Purpose |
|----------|---------|
| `docs/CANONICAL-PATHS.md` | **Single source of truth** for paths |
| `docs/COMMANDS-CHEATSHEET.md` | All commands quick reference with workflow examples |
| `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 |
## Versioning and Changelog Rules
### Version Display
**The marketplace version is displayed ONLY in the main `README.md` title.**
- Format: `# Leo Claude 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
### Changelog Maintenance (MANDATORY)
**`CHANGELOG.md` is the authoritative source for version history.**
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
### 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

27
.doc-guardian-queue Normal file
View File

@@ -0,0 +1,27 @@
# Doc Guardian Queue - cleared after sync on 2026-02-02
2026-02-02T11:41:00 | .claude-plugin | /home/lmiranda/claude-plugins-work/.claude-plugin/marketplace.json | CLAUDE.md .claude-plugin/marketplace.json
2026-02-02T13:35:48 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/sprint-approval.md | README.md
2026-02-02T13:36:03 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/sprint-start.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:36:16 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/orchestrator.md | README.md CLAUDE.md
2026-02-02T13:39:07 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/rfc.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:39:15 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/setup.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:39:32 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/rfc-workflow.md | README.md
2026-02-02T13:43:14 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/rfc-templates.md | README.md
2026-02-02T13:44:55 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/sprint-lifecycle.md | README.md
2026-02-02T13:45:04 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/label-taxonomy/labels-reference.md | README.md
2026-02-02T13:45:14 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/sprint-plan.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:45:48 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/review.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:46:07 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/sprint-close.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:46:21 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/sprint-status.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:46:38 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/planner.md | README.md CLAUDE.md
2026-02-02T13:46:57 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/code-reviewer.md | README.md CLAUDE.md
2026-02-02T13:49:13 | commands | /home/lmiranda/claude-plugins-work/plugins/viz-platform/commands/design-gate.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:49:24 | commands | /home/lmiranda/claude-plugins-work/plugins/data-platform/commands/data-gate.md | docs/COMMANDS-CHEATSHEET.md README.md
2026-02-02T13:49:35 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/domain-consultation.md | README.md
2026-02-02T13:50:04 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/validation_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-02-02T13:50:59 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/server.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-02-02T13:51:32 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/tests/test_validation_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-02-02T13:51:49 | skills | /home/lmiranda/claude-plugins-work/plugins/contract-validator/skills/validation-rules.md | README.md
2026-02-02T13:52:07 | skills | /home/lmiranda/claude-plugins-work/plugins/contract-validator/skills/mcp-tools-reference.md | README.md
2026-02-02T13:59:09 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/progress-tracking.md | README.md
2026-02-02T14:01:34 | commands | /home/lmiranda/claude-plugins-work/plugins/projman/commands/test.md | docs/COMMANDS-CHEATSHEET.md README.md

1
.env Normal file
View File

@@ -0,0 +1 @@
GITEA_REPO=personal-projects/leo-claude-mktplace

View File

@@ -1,23 +1,23 @@
{
"mcpServers": {
"gitea": {
"command": "/home/lmiranda/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/gitea/run.sh",
"command": "./mcp-servers/gitea/run.sh",
"args": []
},
"netbox": {
"command": "/home/lmiranda/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/netbox/run.sh",
"command": "./mcp-servers/netbox/run.sh",
"args": []
},
"viz-platform": {
"command": "/home/lmiranda/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/viz-platform/run.sh",
"command": "./mcp-servers/viz-platform/run.sh",
"args": []
},
"data-platform": {
"command": "/home/lmiranda/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/data-platform/run.sh",
"command": "./mcp-servers/data-platform/run.sh",
"args": []
},
"contract-validator": {
"command": "/home/lmiranda/.claude/plugins/marketplaces/leo-claude-mktplace/mcp-servers/contract-validator/run.sh",
"command": "./mcp-servers/contract-validator/run.sh",
"args": []
}
}

View File

@@ -4,7 +4,144 @@ All notable changes to the Leo Claude Marketplace will be documented in this fil
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
## [Unreleased]
## [5.8.0] - 2026-02-02
### Added
#### Projman Hardening Sprint
Targeted improvements to safety gates, command structure, lifecycle tracking, and cross-plugin contracts.
**Sprint Lifecycle State Machine:**
- New `skills/sprint-lifecycle.md` - defines valid states and transitions via milestone metadata
- States: idle -> Sprint/Planning -> Sprint/Executing -> Sprint/Reviewing -> idle
- All sprint commands check and set lifecycle state on entry/exit
- Out-of-order calls produce warnings with guidance, `--force` override available
**Sprint Dispatch Log:**
- Orchestrator now maintains a structured dispatch log during execution
- Records task dispatch, completion, failure, gate checks, and resume events
- Enables timeline reconstruction after interrupted sessions
**Gate Contract Versioning:**
- Gate commands (`/design-gate`, `/data-gate`) declare `gate_contract: v1` in frontmatter
- `domain-consultation.md` Gate Command Reference includes expected contract version
- `validate_workflow_integration` now checks contract version compatibility
- Mismatch produces WARNING, missing contract produces INFO suggestion
**Shared Visual Output Skill:**
- New `skills/visual-output.md` - single source of truth for projman visual headers
- All 4 agent files reference the skill instead of inline templates
- Phase Registry maps agents to emoji and phase names
### Changed
**Sprint Approval Gate Hardened:**
- Approval is now a hard block, not a warning (was "recommended", now required)
- `--force` flag added to bypass in emergencies (logged to milestone)
- Consistent language across sprint-approval.md, sprint-start.md, and orchestrator.md
**RFC Commands Normalized:**
- 5 individual commands (`/rfc-create`, `/rfc-list`, `/rfc-review`, `/rfc-approve`, `/rfc-reject`) consolidated into `/rfc create|list|review|approve|reject`
- `/clear-cache` absorbed into `/setup --clear-cache`
- Command count reduced from 17 to 12
**`/test` Command Documentation Expanded:**
- Sprint integration section (pre-close verification workflow)
- Concrete usage examples for all modes
- Edge cases table
- DO NOT rules for both modes
### Removed
- `plugins/projman/commands/rfc-create.md` (replaced by `/rfc create`)
- `plugins/projman/commands/rfc-list.md` (replaced by `/rfc list`)
- `plugins/projman/commands/rfc-review.md` (replaced by `/rfc review`)
- `plugins/projman/commands/rfc-approve.md` (replaced by `/rfc approve`)
- `plugins/projman/commands/rfc-reject.md` (replaced by `/rfc reject`)
- `plugins/projman/commands/clear-cache.md` (replaced by `/setup --clear-cache`)
---
## [5.7.1] - 2026-02-02
### Added
- **contract-validator**: New `validate_workflow_integration` MCP tool — validates domain plugins expose required advisory interfaces (gate command, review command, advisory agent)
- **contract-validator**: New `MISSING_INTEGRATION` issue type for workflow integration validation
### Fixed
- `scripts/setup.sh` banner version updated from v5.1.0 to v5.7.1
### Reverted
- **marketplace.json**: Removed `integrates_with` field — Claude Code schema does not support custom plugin fields (causes marketplace load failure)
---
## [5.7.0] - 2026-02-02
### Added
- **data-platform**: New `data-advisor` agent for data integrity, schema, and dbt compliance validation
- **data-platform**: New `data-integrity-audit.md` skill defining audit rules, severity levels, and scanning strategies
- **data-platform**: New `/data-gate` command for binary pass/fail data integrity gates (projman integration)
- **data-platform**: New `/data-review` command for comprehensive data integrity audits
### Changed
- Domain Advisory Pattern now fully operational for both Viz and Data domains
- projman orchestrator `Domain/Data` gates now resolve to live `/data-gate` command (previously fell through to "gate unavailable" warning)
---
## [5.6.0] - 2026-02-01
### Added
- **Domain Advisory Pattern**: Cross-plugin integration enabling projman to consult domain-specific plugins during sprint lifecycle
- **projman**: New `domain-consultation.md` skill for domain detection and gate protocols
- **viz-platform**: New `design-reviewer` agent for design system compliance auditing
- **viz-platform**: New `design-system-audit.md` skill defining audit rules and severity levels
- **viz-platform**: New `/design-review` command for detailed design system audits
- **viz-platform**: New `/design-gate` command for binary pass/fail validation gates
- **Labels**: New `Domain/Viz` and `Domain/Data` labels for domain routing
### Changed
- **projman planner**: Now loads domain-consultation skill and performs domain detection during planning
- **projman orchestrator**: Now runs domain gates before marking Domain/* labeled issues as complete
---
## [5.5.0] - 2026-02-01
### Added
#### RFC System for Feature Tracking
Wiki-based Request for Comments (RFC) system for capturing, reviewing, and tracking feature ideas through their lifecycle.
**New Commands (projman):**
- `/rfc-create` - Create new RFC from conversation or clarified specification
- `/rfc-list` - List all RFCs grouped by status (Draft, Review, Approved, Implementing, Implemented, Rejected, Stale)
- `/rfc-review` - Submit Draft RFC for maintainer review
- `/rfc-approve` - Approve RFC, making it available for sprint planning
- `/rfc-reject` - Reject RFC with documented reason
**RFC Lifecycle:**
- Draft → Review → Approved → Implementing → Implemented
- Terminal states: Rejected, Superseded
- Stale: Drafts with no activity >90 days
**Sprint Integration:**
- `/sprint-plan` now detects approved RFCs and offers selection
- `/sprint-close` updates RFC status to Implemented on completion
- RFC-Index wiki page auto-maintained with status sections
**Clarity-Assist Integration:**
- Vagueness hook now detects feature request patterns
- Suggests `/rfc-create` for feature ideas
- `/clarify` offers RFC creation after delivering clarified spec
**New MCP Tool:**
- `allocate_rfc_number` - Allocates next sequential RFC number
**New Skills:**
- `skills/rfc-workflow.md` - RFC lifecycle and state transitions
- `skills/rfc-templates.md` - RFC page template specifications
### Changed

View File

@@ -1,5 +1,37 @@
# CLAUDE.md
## ⛔ MANDATORY BEHAVIOR RULES - READ FIRST
**These rules are NON-NEGOTIABLE. Violating them wastes the user's time and money.**
### 1. WHEN USER ASKS YOU TO CHECK SOMETHING - CHECK EVERYTHING
- Search ALL locations, not just where you think it is
- Check cache directories: `~/.claude/plugins/cache/`
- Check installed: `~/.claude/plugins/marketplaces/`
- Check source directories
- **NEVER say "no" or "that's not the issue" without exhaustive verification**
### 2. WHEN USER SAYS SOMETHING IS WRONG - BELIEVE THEM
- The user knows their system better than you
- Investigate thoroughly before disagreeing
- **Your confidence is often wrong. User's instincts are often right.**
### 3. NEVER SAY "DONE" WITHOUT VERIFICATION
- Run the actual command/script to verify
- Show the output to the user
- **"Done" means VERIFIED WORKING, not "I made changes"**
### 4. SHOW EXACTLY WHAT USER ASKS FOR
- If user asks for messages, show the MESSAGES
- If user asks for code, show the CODE
- **Do not interpret or summarize unless asked**
**FAILURE TO FOLLOW THESE RULES = WASTED USER TIME = UNACCEPTABLE**
---
This file provides guidance to Claude Code when working with code in this repository.
## ⛔ RULES - READ FIRST
@@ -247,7 +279,7 @@ leo-claude-mktplace/
| Labels | `get_labels`, `suggest_labels`, `create_label`, `create_label_smart` |
| Milestones | `list_milestones`, `get_milestone`, `create_milestone`, `update_milestone`, `delete_milestone` |
| Dependencies | `list_issue_dependencies`, `create_issue_dependency`, `remove_issue_dependency`, `get_execution_order` |
| Wiki | `list_wiki_pages`, `get_wiki_page`, `create_wiki_page`, `update_wiki_page`, `create_lesson`, `search_lessons` |
| Wiki | `list_wiki_pages`, `get_wiki_page`, `create_wiki_page`, `update_wiki_page`, `create_lesson`, `search_lessons`, `allocate_rfc_number` |
| **Pull Requests** | `list_pull_requests`, `get_pull_request`, `get_pr_diff`, `get_pr_comments`, `create_pr_review`, `add_pr_comment` |
| Validation | `validate_repo_org`, `get_branch_protection` |
@@ -268,6 +300,20 @@ leo-claude-mktplace/
| `staging` | Staging | Read-only code, can create issues |
| `main`, `master` | Production | Read-only, emergency only |
### RFC System
Wiki-based Request for Comments system for tracking feature ideas from proposal through implementation.
**RFC Wiki Naming:**
- RFC pages: `RFC-NNNN: Short Title` (4-digit zero-padded)
- Index page: `RFC-Index` (auto-maintained)
**Lifecycle:** Draft → Review → Approved → Implementing → Implemented
**Integration with Sprint Planning:**
- `/sprint-plan` detects approved RFCs and offers selection
- `/sprint-close` updates RFC status on completion
## Label Taxonomy
43 labels total: 27 organization + 16 repository

View File

@@ -1,4 +1,4 @@
# Leo Claude Marketplace - v5.4.0
# Leo Claude Marketplace - v5.8.0
A collection of Claude Code plugins for project management, infrastructure automation, and development workflows.
@@ -19,7 +19,7 @@ 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`, `/setup`, `/review`, `/test`, `/debug`, `/suggest-version`, `/proposal-status`, `/clear-cache`
**Commands:** `/sprint-plan`, `/sprint-start`, `/sprint-status`, `/sprint-close`, `/labels-sync`, `/setup`, `/review`, `/test`, `/debug`, `/suggest-version`, `/proposal-status`, `/rfc`
#### [git-flow](./plugins/git-flow) *NEW in v3.0.0*
**Git Workflow Automation**
@@ -138,7 +138,22 @@ Visualization toolkit with version-locked component validation and design token
- 5 Page tools for multi-page app structure
- Dual theme storage: user-level and project-level
**Commands:** `/chart`, `/chart-export`, `/dashboard`, `/theme`, `/theme-new`, `/theme-css`, `/component`, `/accessibility-check`, `/breakpoints`, `/initial-setup`
**Commands:** `/chart`, `/chart-export`, `/dashboard`, `/theme`, `/theme-new`, `/theme-css`, `/component`, `/accessibility-check`, `/breakpoints`, `/design-review`, `/design-gate`, `/initial-setup`
## Domain Advisory Pattern
The marketplace supports cross-plugin domain advisory integration:
- **Domain Detection**: projman automatically detects when issues involve specialized domains (frontend/viz, data engineering)
- **Acceptance Criteria**: Domain-specific acceptance criteria are added to issues during planning
- **Execution Gates**: Domain validation gates (`/design-gate`, `/data-gate`) run before issue completion
- **Extensible**: New domains can be added by creating advisory agents and gate commands
**Current Domains:**
| Domain | Plugin | Gate Command |
|--------|--------|--------------|
| Visualization | viz-platform | `/design-gate` |
| Data | data-platform | `/data-gate` |
## MCP Servers
@@ -200,7 +215,7 @@ Cross-plugin compatibility validation tools.
| Category | Tools |
|----------|-------|
| Parse | `parse_plugin_interface`, `parse_claude_md_agents` |
| Validation | `validate_compatibility`, `validate_agent_refs`, `validate_data_flow` |
| Validation | `validate_compatibility`, `validate_agent_refs`, `validate_data_flow`, `validate_workflow_integration` |
| Report | `generate_compatibility_report`, `list_issues` |
## Installation

View File

@@ -2,7 +2,7 @@
**This file defines ALL valid paths in this repository. No exceptions. No inference. No assumptions.**
Last Updated: 2026-01-30 (v5.5.0)
Last Updated: 2026-01-30 (v5.4.1)
---

View File

@@ -9,18 +9,18 @@ Quick reference for all commands in the Leo Claude Marketplace.
| Plugin | Command | Auto | Manual | Description |
|--------|---------|:----:|:------:|-------------|
| **projman** | `/sprint-plan` | | X | Start sprint planning with AI-guided architecture analysis and issue creation |
| **projman** | `/sprint-start` | | X | Begin sprint execution with dependency analysis and parallel task coordination |
| **projman** | `/sprint-start` | | X | Begin sprint execution with dependency analysis and parallel task coordination (requires approval or `--force`) |
| **projman** | `/sprint-status` | | X | Check current sprint progress (add `--diagram` for Mermaid visualization) |
| **projman** | `/review` | | X | Pre-sprint-close code quality review (debug artifacts, security, error handling) |
| **projman** | `/test` | | X | Run tests (`/test run`) or generate tests (`/test gen <target>`) |
| **projman** | `/sprint-close` | | X | Complete sprint and capture lessons learned to Gitea Wiki |
| **projman** | `/labels-sync` | | X | Synchronize label taxonomy from Gitea |
| **projman** | `/setup` | | X | Auto-detect mode or use `--full`, `--quick`, `--sync` |
| **projman** | `/setup` | | X | Auto-detect mode or use `--full`, `--quick`, `--sync`, `--clear-cache` |
| **projman** | *SessionStart hook* | X | | Detects git remote vs .env mismatch, warns to run `/setup --sync` |
| **projman** | `/debug` | | X | Diagnostics (`/debug report`) or investigate (`/debug review`) |
| **projman** | `/suggest-version` | | X | Analyze CHANGELOG and recommend semantic version bump |
| **projman** | `/proposal-status` | | X | View proposal and implementation hierarchy with status |
| **projman** | `/clear-cache` | | X | Clear plugin cache to force fresh configuration reload |
| **projman** | `/rfc` | | X | RFC lifecycle management (`/rfc create\|list\|review\|approve\|reject`) |
| **git-flow** | `/commit` | | X | Create commit with auto-generated conventional message |
| **git-flow** | `/commit-push` | | X | Commit and push to remote in one operation |
| **git-flow** | `/commit-merge` | | X | Commit current changes, then merge into target branch |
@@ -87,7 +87,11 @@ Quick reference for all commands in the Leo Claude Marketplace.
| **viz-platform** | `/chart-export` | | X | Export charts to PNG, SVG, PDF via kaleido |
| **viz-platform** | `/accessibility-check` | | X | Color blind validation (WCAG contrast ratios) |
| **viz-platform** | `/breakpoints` | | X | Configure responsive layout breakpoints |
| **viz-platform** | `/design-review` | | X | Detailed design system audits |
| **viz-platform** | `/design-gate` | | X | Binary pass/fail design system validation gates |
| **viz-platform** | *SessionStart hook* | X | | Checks DMC version (non-blocking warning) |
| **data-platform** | `/data-review` | | X | Comprehensive data integrity audits |
| **data-platform** | `/data-gate` | | X | Binary pass/fail data integrity gates |
| **contract-validator** | `/validate-contracts` | | X | Full marketplace compatibility validation |
| **contract-validator** | `/check-agent` | | X | Validate single agent definition |
| **contract-validator** | `/list-interfaces` | | X | Show all plugin interfaces |
@@ -129,6 +133,22 @@ Quick reference for all commands in the Leo Claude Marketplace.
## Dev Workflow Examples
### Example 0: RFC-Driven Feature Development
Full workflow from idea to implementation using RFCs:
```
1. /clarify # Clarify the feature idea
2. /rfc create # Create RFC from clarified spec
... refine RFC content ...
3. /rfc review 0001 # Submit RFC for review
... review discussion ...
4. /rfc approve 0001 # Approve RFC for implementation
5. /sprint-plan # Select approved RFC for sprint
... implement feature ...
6. /sprint-close # Complete sprint, RFC marked Implemented
```
### Example 1: Starting a New Feature Sprint
A typical workflow for planning and executing a feature sprint:
@@ -273,4 +293,4 @@ Ensure credentials are configured in `~/.config/claude/gitea.env`, `~/.config/cl
---
*Last Updated: 2026-01-30*
*Last Updated: 2026-02-02*

View File

@@ -398,6 +398,7 @@ PR_REVIEW_AUTO_SUBMIT=false
| **code-sentinel** | None | None | None needed |
| **project-hygiene** | None | None | None needed |
| **claude-config-maintainer** | None | None | None needed |
| **contract-validator** | None | None | `/initial-setup` |
---

View File

@@ -0,0 +1,20 @@
2026-01-26T14:36:42 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T14:37:38 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T14:37:48 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T14:38:05 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T14:38:55 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T14:39:35 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T14:40:19 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T15:02:30 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/tests/test_parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T15:02:37 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/tests/test_parse_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T15:03:41 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/tests/test_report_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-02-02T10:56:19 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/mcp_server/validation_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-02-02T10:57:49 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/contract-validator/tests/test_validation_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-02-02T10:58:22 | skills | /home/lmiranda/claude-plugins-work/plugins/contract-validator/skills/mcp-tools-reference.md | README.md
2026-02-02T10:58:38 | skills | /home/lmiranda/claude-plugins-work/plugins/contract-validator/skills/validation-rules.md | README.md
2026-02-02T10:59:13 | .claude-plugin | /home/lmiranda/claude-plugins-work/.claude-plugin/marketplace.json | CLAUDE.md .claude-plugin/marketplace.json
2026-02-02T13:55:33 | skills | /home/lmiranda/claude-plugins-work/plugins/projman/skills/visual-output.md | README.md
2026-02-02T13:55:41 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/planner.md | README.md CLAUDE.md
2026-02-02T13:55:55 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/orchestrator.md | README.md CLAUDE.md
2026-02-02T13:56:14 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/executor.md | README.md CLAUDE.md
2026-02-02T13:56:34 | agents | /home/lmiranda/claude-plugins-work/plugins/projman/agents/code-reviewer.md | README.md CLAUDE.md

View File

@@ -131,6 +131,28 @@ class ContractValidatorMCPServer:
"required": ["agent_name", "claude_md_path"]
}
),
Tool(
name="validate_workflow_integration",
description="Validate that a domain plugin exposes the required advisory interfaces (gate command, review command, advisory agent) expected by projman's domain-consultation skill. Also checks gate contract version compatibility.",
inputSchema={
"type": "object",
"properties": {
"plugin_path": {
"type": "string",
"description": "Path to the domain plugin directory"
},
"domain_label": {
"type": "string",
"description": "The Domain/* label it claims to handle, e.g. Domain/Viz"
},
"expected_contract": {
"type": "string",
"description": "Expected contract version (e.g., 'v1'). If provided, validates the gate command's contract matches."
}
},
"required": ["plugin_path", "domain_label"]
}
),
# Report tools (to be implemented in #188)
Tool(
name="generate_compatibility_report",
@@ -198,6 +220,8 @@ class ContractValidatorMCPServer:
result = await self._validate_agent_refs(**arguments)
elif name == "validate_data_flow":
result = await self._validate_data_flow(**arguments)
elif name == "validate_workflow_integration":
result = await self._validate_workflow_integration(**arguments)
elif name == "generate_compatibility_report":
result = await self._generate_compatibility_report(**arguments)
elif name == "list_issues":
@@ -241,6 +265,17 @@ class ContractValidatorMCPServer:
"""Validate agent data flow"""
return await self.validation_tools.validate_data_flow(agent_name, claude_md_path)
async def _validate_workflow_integration(
self,
plugin_path: str,
domain_label: str,
expected_contract: str = None
) -> dict:
"""Validate domain plugin exposes required advisory interfaces"""
return await self.validation_tools.validate_workflow_integration(
plugin_path, domain_label, expected_contract
)
# Report tool implementations (Issue #188)
async def _generate_compatibility_report(self, marketplace_path: str, format: str = "markdown") -> dict:

View File

@@ -26,6 +26,7 @@ class IssueType(str, Enum):
OPTIONAL_DEPENDENCY = "optional_dependency"
UNDECLARED_OUTPUT = "undeclared_output"
INVALID_SEQUENCE = "invalid_sequence"
MISSING_INTEGRATION = "missing_integration"
class ValidationIssue(BaseModel):
@@ -65,6 +66,18 @@ class DataFlowResult(BaseModel):
issues: list[ValidationIssue] = []
class WorkflowIntegrationResult(BaseModel):
"""Result of workflow integration validation for domain plugins"""
plugin_name: str
domain_label: str
valid: bool
gate_command_found: bool
gate_contract: Optional[str] = None # Contract version declared by gate command
review_command_found: bool
advisory_agent_found: bool
issues: list[ValidationIssue] = []
class ValidationTools:
"""Tools for validating plugin compatibility and agent references"""
@@ -336,3 +349,145 @@ class ValidationTools:
)
return result.model_dump()
async def validate_workflow_integration(
self,
plugin_path: str,
domain_label: str,
expected_contract: Optional[str] = None
) -> dict:
"""
Validate that a domain plugin exposes required advisory interfaces.
Checks for:
- Gate command (e.g., /design-gate, /data-gate) - REQUIRED
- Gate contract version (gate_contract in frontmatter) - INFO if missing
- Review command (e.g., /design-review, /data-review) - recommended
- Advisory agent referencing the domain label - recommended
Args:
plugin_path: Path to the domain plugin directory
domain_label: The Domain/* label it claims to handle (e.g., Domain/Viz)
expected_contract: Expected contract version (e.g., 'v1'). If provided,
validates the gate command's contract matches.
Returns:
Validation result with found interfaces and issues
"""
import re
plugin_path_obj = Path(plugin_path)
issues = []
# Extract plugin name from path
plugin_name = plugin_path_obj.name
if not plugin_path_obj.exists():
return {
"error": f"Plugin directory not found: {plugin_path}",
"plugin_path": plugin_path,
"domain_label": domain_label
}
# Extract domain short name from label (e.g., "Domain/Viz" -> "viz", "Domain/Data" -> "data")
domain_short = domain_label.split("/")[-1].lower() if "/" in domain_label else domain_label.lower()
# Check for gate command
commands_dir = plugin_path_obj / "commands"
gate_command_found = False
gate_contract = None
gate_patterns = ["pass", "fail", "PASS", "FAIL", "Binary pass/fail", "gate"]
if commands_dir.exists():
for cmd_file in commands_dir.glob("*.md"):
if "gate" in cmd_file.name.lower():
# Verify it's actually a gate command by checking content
content = cmd_file.read_text()
if any(pattern in content for pattern in gate_patterns):
gate_command_found = True
# Parse frontmatter for gate_contract
frontmatter_match = re.match(r'^---\n(.*?)\n---', content, re.DOTALL)
if frontmatter_match:
frontmatter = frontmatter_match.group(1)
contract_match = re.search(r'gate_contract:\s*(\S+)', frontmatter)
if contract_match:
gate_contract = contract_match.group(1)
break
if not gate_command_found:
issues.append(ValidationIssue(
severity=IssueSeverity.ERROR,
issue_type=IssueType.MISSING_INTEGRATION,
message=f"Plugin '{plugin_name}' lacks a gate command for domain '{domain_label}'",
location=str(commands_dir),
suggestion=f"Create commands/{domain_short}-gate.md with binary PASS/FAIL output"
))
# Check for review command
review_command_found = False
if commands_dir.exists():
for cmd_file in commands_dir.glob("*.md"):
if "review" in cmd_file.name.lower() and "gate" not in cmd_file.name.lower():
review_command_found = True
break
if not review_command_found:
issues.append(ValidationIssue(
severity=IssueSeverity.WARNING,
issue_type=IssueType.MISSING_INTEGRATION,
message=f"Plugin '{plugin_name}' lacks a review command for domain '{domain_label}'",
location=str(commands_dir),
suggestion=f"Create commands/{domain_short}-review.md for detailed audits"
))
# Check for advisory agent
agents_dir = plugin_path_obj / "agents"
advisory_agent_found = False
if agents_dir.exists():
for agent_file in agents_dir.glob("*.md"):
content = agent_file.read_text()
# Check if agent references the domain label or gate command
if domain_label in content or f"{domain_short}-gate" in content.lower() or "advisor" in agent_file.name.lower() or "reviewer" in agent_file.name.lower():
advisory_agent_found = True
break
if not advisory_agent_found:
issues.append(ValidationIssue(
severity=IssueSeverity.WARNING,
issue_type=IssueType.MISSING_INTEGRATION,
message=f"Plugin '{plugin_name}' lacks an advisory agent for domain '{domain_label}'",
location=str(agents_dir) if agents_dir.exists() else str(plugin_path_obj),
suggestion=f"Create agents/{domain_short}-advisor.md referencing '{domain_label}'"
))
# Check gate contract version
if gate_command_found:
if not gate_contract:
issues.append(ValidationIssue(
severity=IssueSeverity.INFO,
issue_type=IssueType.MISSING_INTEGRATION,
message=f"Gate command does not declare a contract version",
location=str(commands_dir),
suggestion="Consider adding `gate_contract: v1` to frontmatter for version tracking"
))
elif expected_contract and gate_contract != expected_contract:
issues.append(ValidationIssue(
severity=IssueSeverity.WARNING,
issue_type=IssueType.INTERFACE_MISMATCH,
message=f"Contract version mismatch: gate declares {gate_contract}, projman expects {expected_contract}",
location=str(commands_dir),
suggestion=f"Update domain-consultation.md Gate Command Reference table to {gate_contract}, or update gate command to {expected_contract}"
))
result = WorkflowIntegrationResult(
plugin_name=plugin_name,
domain_label=domain_label,
valid=gate_command_found, # Only gate is required for validity
gate_command_found=gate_command_found,
gate_contract=gate_contract,
review_command_found=review_command_found,
advisory_agent_found=advisory_agent_found,
issues=issues
)
return result.model_dump()

View File

@@ -254,3 +254,261 @@ async def test_validate_data_flow_missing_producer(validation_tools, tmp_path):
# Should have warning about missing producer
warning_issues = [i for i in result["issues"] if i["severity"].value == "warning"]
assert len(warning_issues) > 0
# --- Workflow Integration Tests ---
@pytest.fixture
def domain_plugin_complete(tmp_path):
"""Create a complete domain plugin with gate, review, and advisory agent"""
plugin_dir = tmp_path / "viz-platform"
plugin_dir.mkdir()
(plugin_dir / ".claude-plugin").mkdir()
(plugin_dir / "commands").mkdir()
(plugin_dir / "agents").mkdir()
# Gate command with PASS/FAIL pattern
gate_cmd = plugin_dir / "commands" / "design-gate.md"
gate_cmd.write_text("""# /design-gate
Binary pass/fail validation gate for design system compliance.
## Output
- **PASS**: All design system checks passed
- **FAIL**: Design system violations detected
""")
# Review command
review_cmd = plugin_dir / "commands" / "design-review.md"
review_cmd.write_text("""# /design-review
Comprehensive design system audit.
""")
# Advisory agent
agent = plugin_dir / "agents" / "design-reviewer.md"
agent.write_text("""# design-reviewer
Design system compliance auditor.
Handles issues with `Domain/Viz` label.
""")
return str(plugin_dir)
@pytest.fixture
def domain_plugin_missing_gate(tmp_path):
"""Create domain plugin with review and agent but no gate command"""
plugin_dir = tmp_path / "data-platform"
plugin_dir.mkdir()
(plugin_dir / ".claude-plugin").mkdir()
(plugin_dir / "commands").mkdir()
(plugin_dir / "agents").mkdir()
# Review command (but no gate)
review_cmd = plugin_dir / "commands" / "data-review.md"
review_cmd.write_text("""# /data-review
Data integrity audit.
""")
# Advisory agent
agent = plugin_dir / "agents" / "data-advisor.md"
agent.write_text("""# data-advisor
Data integrity advisor for Domain/Data issues.
""")
return str(plugin_dir)
@pytest.fixture
def domain_plugin_minimal(tmp_path):
"""Create minimal plugin with no commands or agents"""
plugin_dir = tmp_path / "minimal-plugin"
plugin_dir.mkdir()
(plugin_dir / ".claude-plugin").mkdir()
readme = plugin_dir / "README.md"
readme.write_text("# Minimal Plugin\n\nNo commands or agents.")
return str(plugin_dir)
@pytest.mark.asyncio
async def test_validate_workflow_integration_complete(validation_tools, domain_plugin_complete):
"""Test complete domain plugin returns valid with all interfaces found"""
result = await validation_tools.validate_workflow_integration(
domain_plugin_complete,
"Domain/Viz"
)
assert "error" not in result
assert result["valid"] is True
assert result["gate_command_found"] is True
assert result["review_command_found"] is True
assert result["advisory_agent_found"] is True
# May have INFO issue about missing contract version (not an error/warning)
error_or_warning = [i for i in result["issues"]
if i["severity"].value in ("error", "warning")]
assert len(error_or_warning) == 0
@pytest.mark.asyncio
async def test_validate_workflow_integration_missing_gate(validation_tools, domain_plugin_missing_gate):
"""Test plugin missing gate command returns invalid with ERROR"""
result = await validation_tools.validate_workflow_integration(
domain_plugin_missing_gate,
"Domain/Data"
)
assert "error" not in result
assert result["valid"] is False
assert result["gate_command_found"] is False
assert result["review_command_found"] is True
assert result["advisory_agent_found"] is True
# Should have one ERROR for missing gate
error_issues = [i for i in result["issues"] if i["severity"].value == "error"]
assert len(error_issues) == 1
assert "gate" in error_issues[0]["message"].lower()
@pytest.mark.asyncio
async def test_validate_workflow_integration_minimal(validation_tools, domain_plugin_minimal):
"""Test minimal plugin returns invalid with multiple issues"""
result = await validation_tools.validate_workflow_integration(
domain_plugin_minimal,
"Domain/Test"
)
assert "error" not in result
assert result["valid"] is False
assert result["gate_command_found"] is False
assert result["review_command_found"] is False
assert result["advisory_agent_found"] is False
# Should have one ERROR (gate) and two WARNINGs (review, agent)
error_issues = [i for i in result["issues"] if i["severity"].value == "error"]
warning_issues = [i for i in result["issues"] if i["severity"].value == "warning"]
assert len(error_issues) == 1
assert len(warning_issues) == 2
@pytest.mark.asyncio
async def test_validate_workflow_integration_nonexistent_plugin(validation_tools, tmp_path):
"""Test error when plugin directory doesn't exist"""
result = await validation_tools.validate_workflow_integration(
str(tmp_path / "nonexistent"),
"Domain/Test"
)
assert "error" in result
assert "not found" in result["error"].lower()
# --- Gate Contract Version Tests ---
@pytest.fixture
def domain_plugin_with_contract(tmp_path):
"""Create domain plugin with gate_contract: v1 in frontmatter"""
plugin_dir = tmp_path / "viz-platform-versioned"
plugin_dir.mkdir()
(plugin_dir / ".claude-plugin").mkdir()
(plugin_dir / "commands").mkdir()
(plugin_dir / "agents").mkdir()
# Gate command with gate_contract in frontmatter
gate_cmd = plugin_dir / "commands" / "design-gate.md"
gate_cmd.write_text("""---
description: Design system compliance gate (pass/fail)
gate_contract: v1
---
# /design-gate
Binary pass/fail validation gate for design system compliance.
## Output
- **PASS**: All design system checks passed
- **FAIL**: Design system violations detected
""")
# Review command
review_cmd = plugin_dir / "commands" / "design-review.md"
review_cmd.write_text("""# /design-review
Comprehensive design system audit.
""")
# Advisory agent
agent = plugin_dir / "agents" / "design-reviewer.md"
agent.write_text("""# design-reviewer
Design system compliance auditor for Domain/Viz issues.
""")
return str(plugin_dir)
@pytest.mark.asyncio
async def test_validate_workflow_contract_match(validation_tools, domain_plugin_with_contract):
"""Test that matching expected_contract produces no warning"""
result = await validation_tools.validate_workflow_integration(
domain_plugin_with_contract,
"Domain/Viz",
expected_contract="v1"
)
assert "error" not in result
assert result["valid"] is True
assert result["gate_contract"] == "v1"
# Should have no warnings about contract mismatch
warning_issues = [i for i in result["issues"] if i["severity"].value == "warning"]
contract_warnings = [i for i in warning_issues if "contract" in i["message"].lower()]
assert len(contract_warnings) == 0
@pytest.mark.asyncio
async def test_validate_workflow_contract_mismatch(validation_tools, domain_plugin_with_contract):
"""Test that mismatched expected_contract produces WARNING"""
result = await validation_tools.validate_workflow_integration(
domain_plugin_with_contract,
"Domain/Viz",
expected_contract="v2" # Gate has v1
)
assert "error" not in result
assert result["valid"] is True # Contract mismatch doesn't affect validity
assert result["gate_contract"] == "v1"
# Should have warning about contract mismatch
warning_issues = [i for i in result["issues"] if i["severity"].value == "warning"]
contract_warnings = [i for i in warning_issues if "contract" in i["message"].lower()]
assert len(contract_warnings) == 1
assert "mismatch" in contract_warnings[0]["message"].lower()
assert "v1" in contract_warnings[0]["message"]
assert "v2" in contract_warnings[0]["message"]
@pytest.mark.asyncio
async def test_validate_workflow_no_contract(validation_tools, domain_plugin_complete):
"""Test that missing gate_contract produces INFO suggestion"""
result = await validation_tools.validate_workflow_integration(
domain_plugin_complete,
"Domain/Viz"
)
assert "error" not in result
assert result["valid"] is True
assert result["gate_contract"] is None
# Should have info issue about missing contract
info_issues = [i for i in result["issues"] if i["severity"].value == "info"]
contract_info = [i for i in info_issues if "contract" in i["message"].lower()]
assert len(contract_info) == 1
assert "does not declare" in contract_info[0]["message"].lower()

View File

@@ -435,6 +435,19 @@ class GiteaMCPServer:
}
}
),
Tool(
name="allocate_rfc_number",
description="Allocate the next available RFC number by scanning existing RFC wiki pages",
inputSchema={
"type": "object",
"properties": {
"repo": {
"type": "string",
"description": "Repository name (owner/repo format)"
}
}
}
),
# Milestone Tools
Tool(
name="list_milestones",
@@ -980,6 +993,10 @@ class GiteaMCPServer:
limit=arguments.get('limit', 20),
repo=arguments.get('repo')
)
elif name == "allocate_rfc_number":
result = await self.wiki_tools.allocate_rfc_number(
repo=arguments.get('repo')
)
# Milestone tools
elif name == "list_milestones":
result = await self.milestone_tools.list_milestones(**arguments)

View File

@@ -4,9 +4,11 @@ Wiki management tools for MCP server.
Provides async wrappers for wiki operations to support lessons learned:
- Page CRUD operations
- Lessons learned creation and search
- RFC number allocation
"""
import asyncio
import logging
import re
from typing import List, Dict, Optional
logging.basicConfig(level=logging.INFO)
@@ -147,3 +149,39 @@ class WikiTools:
lambda: self.gitea.search_lessons(query, tags, repo)
)
return results[:limit]
async def allocate_rfc_number(self, repo: Optional[str] = None) -> Dict:
"""
Allocate the next available RFC number.
Scans existing wiki pages for RFC-NNNN pattern and returns
the next sequential number.
Args:
repo: Repository in owner/repo format
Returns:
Dict with 'next_number' (int) and 'formatted' (str like 'RFC-0001')
"""
pages = await self.list_wiki_pages(repo)
# Extract RFC numbers from page titles
rfc_numbers = []
rfc_pattern = re.compile(r'^RFC-(\d{4})')
for page in pages:
title = page.get('title', '')
match = rfc_pattern.match(title)
if match:
rfc_numbers.append(int(match.group(1)))
# Calculate next number
if rfc_numbers:
next_num = max(rfc_numbers) + 1
else:
next_num = 1
return {
'next_number': next_num,
'formatted': f'RFC-{next_num:04d}'
}

View File

@@ -0,0 +1,5 @@
2026-01-26T11:40:11 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/viz-platform/registry/dmc_2_5.json | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T13:46:31 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/viz-platform/tests/test_chart_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T13:46:32 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/viz-platform/tests/test_theme_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T13:46:34 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/viz-platform/tests/test_theme_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md
2026-01-26T13:46:35 | mcp-servers | /home/lmiranda/claude-plugins-work/mcp-servers/viz-platform/tests/test_theme_tools.py | docs/COMMANDS-CHEATSHEET.md CLAUDE.md

View File

@@ -34,7 +34,31 @@ Load these skills before proceeding:
2. **Diagnose** - Identify gaps and conflicts
3. **Develop** - Gather clarifications via structured questions
4. **Deliver** - Present refined specification
5. **Offer RFC Creation** - For feature work, offer to save as RFC
## Output Format
Use the Deliver phase template from `skills/4d-methodology.md` to present the clarified specification for user confirmation.
## RFC Creation Offer (Step 5)
After presenting the clarified specification, if the request appears to be a feature or enhancement:
```
---
Would you like to save this as an RFC for formal tracking?
An RFC (Request for Comments) provides:
- Structured documentation of the proposal
- Review workflow before implementation
- Integration with sprint planning
[1] Yes, create RFC from this specification
[2] No, proceed with implementation directly
```
If user selects [1]:
- Pass clarified specification to `/rfc-create`
- The Summary, Motivation, and Design sections will be populated from the clarified spec
- User can then refine the RFC and submit for review

View File

@@ -2,8 +2,13 @@
"hooks": {
"UserPromptSubmit": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/vagueness-check.sh"
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/vagueness-check.sh"
}
]
}
]
}

View File

@@ -197,6 +197,38 @@ if (( $(echo "$SCORE > 1.0" | bc -l) )); then
SCORE="1.0"
fi
# ============================================================================
# Feature Request Detection (for RFC suggestion)
# ============================================================================
FEATURE_REQUEST=false
# Feature request phrases
FEATURE_PHRASES=(
"we should"
"it would be nice"
"feature request"
"idea:"
"suggestion:"
"what if we"
"wouldn't it be great"
"i think we need"
"we need to add"
"we could add"
"how about adding"
"can we add"
"new feature"
"enhancement"
"proposal"
)
for phrase in "${FEATURE_PHRASES[@]}"; do
if [[ "$PROMPT_LOWER" == *"$phrase"* ]]; then
FEATURE_REQUEST=true
break
fi
done
# ============================================================================
# Output suggestion if score exceeds threshold
# ============================================================================
@@ -208,8 +240,16 @@ if (( $(echo "$SCORE >= $THRESHOLD" | bc -l) )); then
# Gentle, non-blocking suggestion
echo "$PREFIX Your prompt could benefit from more clarity."
echo "$PREFIX Consider running /clarity-assist to refine your request."
echo "$PREFIX Consider running /clarify to refine your request."
echo "$PREFIX (Vagueness score: ${SCORE_PCT}% - this is a suggestion, not a block)"
# Additional RFC suggestion if feature request detected
if [[ "$FEATURE_REQUEST" == true ]]; then
echo "$PREFIX This looks like a feature idea. Consider /rfc-create to track it formally."
fi
elif [[ "$FEATURE_REQUEST" == true ]]; then
# Feature request detected but not vague - still suggest RFC
echo "$PREFIX This looks like a feature idea. Consider /rfc-create to track it formally."
fi
# Always exit 0 - this hook is non-blocking

View File

@@ -2,8 +2,13 @@
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-rules.sh"
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-rules.sh"
}
]
}
]
}

View File

@@ -2,6 +2,7 @@
"hooks": {
"SessionStart": [
{
"matcher": "",
"hooks": [
{
"type": "command",

View File

@@ -25,11 +25,24 @@ if [[ -z "${NETBOX_API_URL:-}" ]] || [[ -z "${NETBOX_API_TOKEN:-}" ]]; then
exit 0
fi
# Helper function to make authenticated API calls
# Token passed via curl config to avoid exposure in process listings
netbox_curl() {
local url="$1"
curl -s -K - <<EOF 2>/dev/null
-H "Authorization: Token ${NETBOX_API_TOKEN}"
-H "Accept: application/json"
url = "${url}"
EOF
}
# Quick API connectivity test (5s timeout)
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -m 5 \
-H "Authorization: Token $NETBOX_API_TOKEN" \
-H "Accept: application/json" \
"${NETBOX_API_URL}/" 2>/dev/null || echo "000")
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -m 5 -K - <<EOF 2>/dev/null || echo "000"
-H "Authorization: Token ${NETBOX_API_TOKEN}"
-H "Accept: application/json"
url = "${NETBOX_API_URL}/"
EOF
)
if [[ "$HTTP_CODE" == "000" ]]; then
echo "$PREFIX NetBox API unreachable (timeout/connection error)"
@@ -40,10 +53,12 @@ elif [[ "$HTTP_CODE" != "200" ]]; then
fi
# Check for VMs without site assignment (data quality)
VMS_RESPONSE=$(curl -s -m 5 \
-H "Authorization: Token $NETBOX_API_TOKEN" \
-H "Accept: application/json" \
"${NETBOX_API_URL}/virtualization/virtual-machines/?site__isnull=true&limit=1" 2>/dev/null || echo '{"count":0}')
VMS_RESPONSE=$(curl -s -m 5 -K - <<EOF 2>/dev/null || echo '{"count":0}'
-H "Authorization: Token ${NETBOX_API_TOKEN}"
-H "Accept: application/json"
url = "${NETBOX_API_URL}/virtualization/virtual-machines/?site__isnull=true&limit=1"
EOF
)
VMS_NO_SITE=$(echo "$VMS_RESPONSE" | grep -o '"count":[0-9]*' | cut -d: -f2 || echo "0")
@@ -52,10 +67,12 @@ if [[ "$VMS_NO_SITE" -gt 0 ]]; then
fi
# Check for devices without platform
DEVICES_RESPONSE=$(curl -s -m 5 \
-H "Authorization: Token $NETBOX_API_TOKEN" \
-H "Accept: application/json" \
"${NETBOX_API_URL}/dcim/devices/?platform__isnull=true&limit=1" 2>/dev/null || echo '{"count":0}')
DEVICES_RESPONSE=$(curl -s -m 5 -K - <<EOF 2>/dev/null || echo '{"count":0}'
-H "Authorization: Token ${NETBOX_API_TOKEN}"
-H "Accept: application/json"
url = "${NETBOX_API_URL}/dcim/devices/?platform__isnull=true&limit=1"
EOF
)
DEVICES_NO_PLATFORM=$(echo "$DEVICES_RESPONSE" | grep -o '"count":[0-9]*' | cut -d: -f2 || echo "0")

View File

@@ -30,6 +30,7 @@
- Use `validate_compatibility` for pairwise checks
- Use `validate_agent_refs` for CLAUDE.md agents
- Use `validate_data_flow` for data sequences
- Use `validate_workflow_integration` for domain plugin advisory interfaces
5. **Generate report**:
- Use `generate_compatibility_report` for full report

View File

@@ -2,8 +2,13 @@
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/auto-validate.sh"
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/auto-validate.sh"
}
]
}
],
"PostToolUse": [

View File

@@ -16,6 +16,7 @@ Available MCP tools for contract-validator operations.
| `validate_compatibility` | Check two plugins for conflicts |
| `validate_agent_refs` | Check agent tool references exist |
| `validate_data_flow` | Verify data flow through agent sequence |
| `validate_workflow_integration` | Check domain plugin exposes required advisory interfaces and gate contract version |
### Report Tools
| Tool | Description |
@@ -53,6 +54,14 @@ Available MCP tools for contract-validator operations.
3. Build Mermaid diagram from results
```
### Workflow Integration Check
```
1. validate_workflow_integration(plugin_path, domain_label) # Check single domain plugin
2. validate_workflow_integration(plugin_path, domain_label, expected_contract="v1") # With contract version check
3. For each domain in domain-consultation.md detection rules:
validate_workflow_integration(domain_plugin_path, domain_label, expected_contract)
```
## Error Handling
If MCP tools fail:

View File

@@ -30,6 +30,15 @@ Rules for validating plugin compatibility and agent definitions.
3. Check for orphaned data references
4. Ensure required data is available at each step
### Workflow Integration Checks
1. Gate command exists in plugin's commands/ directory
2. Gate command produces binary PASS/FAIL output
3. Review command exists (WARNING if missing, not ERROR)
4. Advisory agent exists referencing the domain label
5. Gate command declares `gate_contract` version in frontmatter
6. If expected version provided, gate contract version matches expected
- Severity: ERROR for missing gate, WARNING for missing review/agent or contract mismatch, INFO for missing contract
## Severity Levels
| Level | Meaning | Action |
@@ -46,6 +55,8 @@ Rules for validating plugin compatibility and agent definitions.
| Data flow gap | Producer not called before consumer | Reorder workflow steps |
| Name conflict | Two plugins use same command | Rename one command |
| Orphan reference | Data produced but never consumed | Remove or use the data |
| Missing gate command | Domain plugin lacks /X-gate command | Create commands/{domain}-gate.md |
| Missing advisory agent | Domain plugin has no reviewer agent | Create agents/{domain}-advisor.md |
## MCP Tools
@@ -54,4 +65,5 @@ Rules for validating plugin compatibility and agent definitions.
| `validate_compatibility` | Check two plugins for conflicts |
| `validate_agent_refs` | Check agent tool references |
| `validate_data_flow` | Verify data flow sequences |
| `validate_workflow_integration` | Check domain plugin advisory interfaces |
| `list_issues` | Filter issues by severity or type |

View File

@@ -1,6 +1,6 @@
{
"name": "data-platform",
"version": "1.1.0",
"version": "1.3.0",
"description": "Data engineering tools with pandas, PostgreSQL/PostGIS, and dbt integration",
"author": {
"name": "Leo Miranda",

View File

@@ -0,0 +1,320 @@
---
agent: data-advisor
description: Reviews code for data integrity, schema validity, and dbt compliance using data-platform MCP tools
triggers:
- /data-review command
- /data-gate command
- projman orchestrator domain gate
---
# Data Advisor Agent
You are a strict data integrity auditor. Your role is to review code for proper schema usage, dbt compliance, lineage integrity, and data quality standards.
## Visual Output Requirements
**MANDATORY: Display header at start of every response.**
```
+----------------------------------------------------------------------+
| DATA-PLATFORM - Data Advisor |
| [Target Path] |
+----------------------------------------------------------------------+
```
## Trigger Conditions
Activate this agent when:
- User runs `/data-review <path>`
- User runs `/data-gate <path>`
- Projman orchestrator requests data domain gate check
- Code review includes database operations, dbt models, or data pipelines
## Skills to Load
- skills/data-integrity-audit.md
- skills/mcp-tools-reference.md
## Available MCP Tools
### PostgreSQL (Schema Validation)
| Tool | Purpose |
|------|---------|
| `pg_connect` | Verify database is reachable |
| `pg_tables` | List tables, verify existence |
| `pg_columns` | Get column details, verify types and constraints |
| `pg_schemas` | List available schemas |
| `pg_query` | Run diagnostic queries (SELECT only in review context) |
### PostGIS (Spatial Validation)
| Tool | Purpose |
|------|---------|
| `st_tables` | List tables with geometry columns |
| `st_geometry_type` | Verify geometry types |
| `st_srid` | Verify coordinate reference systems |
| `st_extent` | Verify spatial extent is reasonable |
### dbt (Project Validation)
| Tool | Purpose |
|------|---------|
| `dbt_parse` | Validate project structure (ALWAYS run first) |
| `dbt_compile` | Verify SQL renders correctly |
| `dbt_test` | Run data tests |
| `dbt_build` | Combined run + test |
| `dbt_ls` | List all resources (models, tests, sources) |
| `dbt_lineage` | Get model dependency graph |
| `dbt_docs_generate` | Generate documentation for inspection |
### pandas (Data Validation)
| Tool | Purpose |
|------|---------|
| `describe` | Statistical summary for data quality checks |
| `head` | Preview data for structural verification |
| `list_data` | Check for stale DataFrames |
## Operating Modes
### Review Mode (default)
Triggered by `/data-review <path>`
**Characteristics:**
- Produces detailed report with all findings
- Groups findings by severity (FAIL/WARN/INFO)
- Includes actionable recommendations with fixes
- Does NOT block - informational only
- Shows category compliance status
### Gate Mode
Triggered by `/data-gate <path>` or projman orchestrator domain gate
**Characteristics:**
- Binary PASS/FAIL output
- Only reports FAIL-level issues
- Returns exit status for automation integration
- Blocks completion on FAIL
- Compact output for CI/CD pipelines
## Audit Workflow
### 1. Receive Target Path
Accept file or directory path from command invocation.
### 2. Determine Scope
Analyze target to identify what type of data work is present:
| Pattern | Type | Checks to Run |
|---------|------|---------------|
| `dbt_project.yml` present | dbt project | Full dbt validation |
| `*.sql` files in dbt path | dbt models | Model compilation, lineage |
| `*.py` with `pg_query`/`pg_execute` | Database operations | Schema validation |
| `schema.yml` files | dbt schemas | Schema drift detection |
| Migration files (`*_migration.sql`) | Schema changes | Full PostgreSQL + dbt checks |
### 3. Run Database Checks (if applicable)
```
1. pg_connect → verify database reachable
If fails: WARN, continue with file-based checks
2. pg_tables → verify expected tables exist
If missing: FAIL
3. pg_columns on affected tables → verify types
If mismatch: FAIL
```
### 4. Run dbt Checks (if applicable)
```
1. dbt_parse → validate project
If fails: FAIL immediately (project broken)
2. dbt_ls → catalog all resources
Record models, tests, sources
3. dbt_lineage on target models → check integrity
Orphaned refs: FAIL
4. dbt_compile on target models → verify SQL
Compilation errors: FAIL
5. dbt_test --select <targets> → run tests
Test failures: FAIL
6. Cross-reference tests → models without tests
Missing tests: WARN
```
### 5. Run PostGIS Checks (if applicable)
```
1. st_tables → list spatial tables
If none found: skip PostGIS checks
2. st_srid → verify SRID correct
Unexpected SRID: FAIL
3. st_geometry_type → verify expected types
Wrong type: WARN
4. st_extent → sanity check bounding box
Unreasonable extent: FAIL
```
### 6. Scan Python Code (manual patterns)
For Python files with database operations:
| Pattern | Issue | Severity |
|---------|-------|----------|
| `f"SELECT * FROM {table}"` | SQL injection risk | WARN |
| `f"INSERT INTO {table}"` | Unparameterized mutation | WARN |
| `pg_execute` without WHERE in DELETE/UPDATE | Dangerous mutation | WARN |
| Hardcoded connection strings | Credential exposure | WARN |
### 7. Generate Report
Output format depends on operating mode (see templates in `skills/data-integrity-audit.md`).
## Report Formats
### Gate Mode Output
**PASS:**
```
DATA GATE: PASS
No blocking data integrity violations found.
```
**FAIL:**
```
DATA GATE: FAIL
Blocking Issues (2):
1. dbt/models/staging/stg_census.sql - Compilation error: column 'census_yr' not found
Fix: Column was renamed to 'census_year' in source table. Update model.
2. portfolio_app/toronto/loaders/census.py:67 - References table 'census_raw' which does not exist
Fix: Table was renamed to 'census_demographics' in migration 003.
Run /data-review for full audit report.
```
### Review Mode Output
```
+----------------------------------------------------------------------+
| DATA-PLATFORM - Data Integrity Audit |
| /path/to/project |
+----------------------------------------------------------------------+
Target: /path/to/project
Scope: 12 files scanned, 8 models checked, 3 tables verified
FINDINGS
FAIL (2)
1. [dbt/models/staging/stg_census.sql] Compilation error
Error: column 'census_yr' does not exist
Fix: Column was renamed to 'census_year'. Update SELECT clause.
2. [portfolio_app/loaders/census.py:67] Missing table reference
Error: Table 'census_raw' does not exist
Fix: Table renamed to 'census_demographics' in migration 003.
WARN (3)
1. [dbt/models/marts/dim_neighbourhoods.sql] Missing dbt test
Issue: No unique test on neighbourhood_id
Suggestion: Add unique test to schema.yml
2. [portfolio_app/toronto/queries.py:45] Hardcoded SQL
Issue: f"SELECT * FROM {table_name}" without parameterization
Suggestion: Use parameterized queries
3. [dbt/models/staging/stg_legacy.sql] Orphaned model
Issue: No downstream consumers or exposures
Suggestion: Remove if unused or add to exposure
INFO (1)
1. [dbt/models/marts/fct_demographics.sql] Documentation gap
Note: Model description missing in schema.yml
Suggestion: Add description for discoverability
SUMMARY
Schema: 2 issues
Lineage: Intact
dbt: 1 failure
PostGIS: Not applicable
VERDICT: FAIL (2 blocking issues)
```
## Severity Definitions
| Level | Criteria | Action Required |
|-------|----------|-----------------|
| **FAIL** | dbt parse/compile fails, missing tables/columns, type mismatches, broken lineage, invalid SRID | Must fix before completion |
| **WARN** | Missing tests, hardcoded SQL, schema drift, orphaned models | Should fix |
| **INFO** | Documentation gaps, optimization opportunities | Consider for improvement |
## Error Handling
| Error | Response |
|-------|----------|
| Database not reachable | WARN: "PostgreSQL unavailable, skipping schema checks" - continue |
| No dbt_project.yml | Skip dbt checks silently - not an error |
| No PostGIS tables | Skip PostGIS checks silently - not an error |
| MCP tool fails | WARN: "Tool {name} failed: {error}" - continue with remaining |
| Empty path | PASS: "No data artifacts found in target path" |
| Invalid path | Error: "Path not found: {path}" |
## Integration with projman
When called as a domain gate by projman orchestrator:
1. Receive path from orchestrator (changed files for the issue)
2. Determine what type of data work changed
3. Run audit in gate mode
4. Return structured result:
```
Gate: data
Status: PASS | FAIL
Blocking: N issues
Summary: Brief description
```
5. Orchestrator decides whether to proceed based on gate status
## Example Interactions
**User**: `/data-review dbt/models/staging/`
**Agent**:
1. Scans all .sql files in staging/
2. Runs dbt_parse to validate project
3. Runs dbt_compile on each model
4. Checks lineage for orphaned refs
5. Cross-references test coverage
6. Returns detailed report
**User**: `/data-gate portfolio_app/toronto/`
**Agent**:
1. Scans for Python files with pg_query/pg_execute
2. Checks if referenced tables exist
3. Validates column types
4. Returns PASS if clean, FAIL with blocking issues if not
5. Compact output for automation
## Communication Style
Technical and precise. Report findings with exact locations, specific violations, and actionable fixes:
- "Table `census_demographics` column `population` is `varchar(50)` in PostgreSQL but referenced as `integer` in `stg_census.sql` line 14. This will cause a runtime cast error."
- "Model `dim_neighbourhoods` has no `unique` test on `neighbourhood_id`. Add to `schema.yml` to prevent duplicates."
- "Spatial extent for `toronto_boundaries` shows global coordinates (-180 to 180). Expected Toronto bbox (~-79.6 to -79.1 longitude). Likely missing ST_Transform or wrong SRID on import."

View File

@@ -0,0 +1,105 @@
---
description: Data integrity compliance gate (pass/fail) for sprint execution
gate_contract: v1
arguments:
- name: path
description: File or directory to validate
required: true
---
# /data-gate
Binary pass/fail validation for data integrity compliance. Used by projman orchestrator during sprint execution to gate issue completion.
## Usage
```
/data-gate <path>
```
**Examples:**
```
/data-gate ./dbt/models/staging/
/data-gate ./portfolio_app/toronto/parsers/
/data-gate ./dbt/
```
## What It Does
1. **Activates** the `data-advisor` agent in gate mode
2. **Loads** the `skills/data-integrity-audit.md` skill
3. **Determines scope** from target path:
- dbt project directory: full dbt validation (parse, compile, test, lineage)
- Python files with database operations: schema validation
- SQL files: dbt model validation
- Mixed: all applicable checks
4. **Checks only FAIL-level violations:**
- dbt parse failures (project broken)
- dbt compilation errors (SQL invalid)
- Missing tables/columns referenced in code
- Data type mismatches that cause runtime errors
- Broken lineage (orphaned model references)
- PostGIS SRID mismatches
5. **Returns binary result:**
- `PASS` - No blocking violations found
- `FAIL` - One or more blocking violations
## Output
### On PASS
```
DATA GATE: PASS
No blocking data integrity violations found.
```
### On FAIL
```
DATA GATE: FAIL
Blocking Issues (2):
1. dbt/models/staging/stg_census.sql - Compilation error: column 'census_yr' not found
Fix: Column was renamed to 'census_year' in source table. Update model.
2. portfolio_app/toronto/loaders/census.py:67 - References table 'census_raw' which does not exist
Fix: Table was renamed to 'census_demographics' in migration 003.
Run /data-review for full audit report.
```
## Integration with projman
This command is automatically invoked by the projman orchestrator when:
1. An issue has the `Domain/Data` label
2. The orchestrator is about to mark the issue as complete
3. The orchestrator passes the path of changed files
**Gate behavior:**
- PASS: Issue can be marked complete
- FAIL: Issue stays open, blocker comment added with failure details
## Differences from /data-review
| Aspect | /data-gate | /data-review |
|--------|------------|--------------|
| Output | Binary PASS/FAIL | Detailed report with all severities |
| Severity | FAIL only | FAIL + WARN + INFO |
| Purpose | Automation gate | Human review |
| Verbosity | Minimal | Comprehensive |
| Speed | Skips INFO checks | Full scan |
## When to Use
- **Sprint execution**: Automatic quality gates via projman
- **CI/CD pipelines**: Automated data integrity checks
- **Quick validation**: Fast pass/fail without full report
- **Pre-merge checks**: Verify data changes before integration
For detailed findings including warnings and suggestions, use `/data-review` instead.
## Requirements
- data-platform MCP server must be running
- For dbt checks: dbt project must be configured (auto-detected via `dbt_project.yml`)
- For PostgreSQL checks: connection configured in `~/.config/claude/postgres.env`
- If database or dbt unavailable: applicable checks skipped with warning (non-blocking degradation)

View File

@@ -0,0 +1,149 @@
---
description: Audit data integrity, schema validity, and dbt compliance
arguments:
- name: path
description: File, directory, or dbt project to audit
required: true
---
# /data-review
Comprehensive data integrity audit producing a detailed report with findings at all severity levels. For human review and standalone codebase auditing.
## Usage
```
/data-review <path>
```
**Examples:**
```
/data-review ./dbt/
/data-review ./portfolio_app/toronto/
/data-review ./dbt/models/marts/
```
## What It Does
1. **Activates** the `data-advisor` agent in review mode
2. **Scans target path** to determine scope:
- Identifies dbt project files (.sql models, schema.yml, sources.yml)
- Identifies Python files with database operations
- Identifies migration files
- Identifies PostGIS usage
3. **Runs all check categories:**
- Schema validity (PostgreSQL tables, columns, types)
- dbt project health (parse, compile, test, lineage)
- PostGIS compliance (SRID, geometry types, extent)
- Data type consistency
- Code patterns (unsafe SQL, hardcoded queries)
4. **Produces detailed report** with all severity levels (FAIL, WARN, INFO)
5. **Provides actionable recommendations** for each finding
## Output Format
```
+----------------------------------------------------------------------+
| DATA-PLATFORM - Data Integrity Audit |
| /path/to/project |
+----------------------------------------------------------------------+
Target: /path/to/project
Scope: N files scanned, N models checked, N tables verified
FINDINGS
FAIL (N)
1. [location] violation description
Fix: actionable fix
WARN (N)
1. [location] warning description
Suggestion: improvement suggestion
INFO (N)
1. [location] info description
Note: context
SUMMARY
Schema: Valid | N issues
Lineage: Intact | N orphaned
dbt: Passes | N failures
PostGIS: Valid | N issues | Not applicable
VERDICT: PASS | FAIL (N blocking issues)
```
## When to Use
### Before Sprint Planning
Audit data layer health to identify tech debt and inform sprint scope.
```
/data-review ./dbt/
```
### During Code Review
Get detailed data integrity findings alongside code review comments.
```
/data-review ./dbt/models/staging/stg_new_source.sql
```
### After Migrations
Verify schema changes didn't break anything downstream.
```
/data-review ./migrations/
```
### Periodic Health Checks
Regular data infrastructure audits for proactive maintenance.
```
/data-review ./data_pipeline/
```
### New Project Onboarding
Understand the current state of data architecture.
```
/data-review .
```
## Severity Levels
| Level | Meaning | Gate Impact |
|-------|---------|-------------|
| **FAIL** | Blocking issues that will cause runtime errors | Would block `/data-gate` |
| **WARN** | Quality issues that should be addressed | Does not block gate |
| **INFO** | Suggestions for improvement | Does not block gate |
## Differences from /data-gate
`/data-review` gives you the full picture. `/data-gate` gives the orchestrator a yes/no.
| Aspect | /data-gate | /data-review |
|--------|------------|--------------|
| Output | Binary PASS/FAIL | Detailed report |
| Severity | FAIL only | FAIL + WARN + INFO |
| Purpose | Automation | Human review |
| Verbosity | Minimal | Comprehensive |
| Speed | Fast (skips INFO) | Thorough |
Use `/data-review` when you want to understand.
Use `/data-gate` when you want to automate.
## Requirements
- data-platform MCP server must be running
- For dbt checks: dbt project must be configured (auto-detected via `dbt_project.yml`)
- For PostgreSQL checks: connection configured in `~/.config/claude/postgres.env`
**Graceful degradation:** If database or dbt unavailable, applicable checks are skipped with a note in the report rather than failing entirely.
## Skills Used
- `skills/data-integrity-audit.md` - Audit rules and patterns
- `skills/mcp-tools-reference.md` - MCP tool reference
## Related Commands
- `/data-gate` - Binary pass/fail for automation
- `/lineage` - Visualize dbt model dependencies
- `/schema` - Explore database schema

View File

@@ -2,8 +2,13 @@
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
}
]
}
],
"PostToolUse": [

View File

@@ -0,0 +1,307 @@
---
name: data-integrity-audit
description: Rules and patterns for auditing data integrity, schema validity, and dbt compliance
---
# Data Integrity Audit
## Purpose
Defines what "data valid" means for the data-platform domain. This skill is loaded by the `data-advisor` agent for both review and gate modes during sprint execution and standalone audits.
---
## What to Check
| Check Category | What It Validates | MCP Tools Used |
|----------------|-------------------|----------------|
| **Schema Validity** | Tables exist, columns have correct types, constraints present, no orphaned columns | `pg_tables`, `pg_columns`, `pg_schemas` |
| **dbt Project Health** | Project parses without errors, models compile, tests defined for critical models | `dbt_parse`, `dbt_compile`, `dbt_test`, `dbt_ls` |
| **Lineage Integrity** | No orphaned models (referenced but missing), no circular dependencies, upstream sources exist | `dbt_lineage`, `dbt_ls` |
| **Data Type Consistency** | DataFrame dtypes match expected schema, no silent type coercion, date formats consistent | `describe`, `head`, `pg_columns` |
| **PostGIS Compliance** | Spatial tables have correct SRID, geometry types match expectations, extent is reasonable | `st_tables`, `st_geometry_type`, `st_srid`, `st_extent` |
| **Query Safety** | SELECT queries used for reads (not raw SQL for mutations), parameterized patterns | Code review - manual pattern check |
---
## Common Violations
### FAIL-Level Violations (Block Gate)
| Violation | Detection Method | Example |
|-----------|-----------------|---------|
| dbt parse failure | `dbt_parse` returns error | Project YAML invalid, missing ref targets |
| dbt compilation error | `dbt_compile` fails | SQL syntax error, undefined column reference |
| Missing table/column | `pg_tables`, `pg_columns` lookup | Code references `census_raw` but table doesn't exist |
| Type mismatch | Compare `pg_columns` vs dbt schema | Column is `varchar` in DB but model expects `integer` |
| Broken lineage | `dbt_lineage` shows orphaned refs | Model references `stg_old_format` which doesn't exist |
| PostGIS SRID mismatch | `st_srid` returns unexpected value | Geometry column has SRID 0 instead of 4326 |
| Unreasonable spatial extent | `st_extent` returns global bbox | Toronto data shows coordinates in China |
### WARN-Level Violations (Report, Don't Block)
| Violation | Detection Method | Example |
|-----------|-----------------|---------|
| Missing dbt tests | `dbt_ls` shows model without test | `dim_customers` has no `unique` test on `customer_id` |
| Undocumented columns | dbt schema.yml missing descriptions | Model columns have no documentation |
| Schema drift | `pg_columns` vs dbt schema.yml | Column exists in DB but not in dbt YAML |
| Hardcoded SQL | Scan Python for string concatenation | `f"SELECT * FROM {table}"` without parameterization |
| Orphaned model | `dbt_lineage` shows no downstream | `stg_legacy` has no consumers and no exposure |
### INFO-Level Violations (Suggestions Only)
| Violation | Detection Method | Example |
|-----------|-----------------|---------|
| Missing indexes | Query pattern suggests need | Frequent filter on non-indexed column |
| Documentation gaps | dbt docs incomplete | Missing model description |
| Unused models | `dbt_ls` vs actual queries | Model exists but never selected |
| Optimization opportunity | `describe` shows data patterns | Column has low cardinality, could be enum |
---
## Severity Classification
| Severity | When to Apply | Gate Behavior |
|----------|--------------|---------------|
| **FAIL** | Broken lineage, models that won't compile, missing tables/columns, data type mismatches that cause runtime errors, invalid SRID | Blocks issue completion |
| **WARN** | Missing dbt tests, undocumented columns, schema drift, hardcoded SQL, orphaned models | Does NOT block gate, included in review report |
| **INFO** | Optimization opportunities, documentation gaps, unused models | Review report only |
### Severity Decision Tree
```
Is the dbt project broken (parse/compile fails)?
YES -> FAIL
NO -> Does code reference non-existent tables/columns?
YES -> FAIL
NO -> Would this cause a runtime error?
YES -> FAIL
NO -> Does it violate data quality standards?
YES -> WARN
NO -> Is it an optimization/documentation suggestion?
YES -> INFO
NO -> Not a violation
```
---
## Scanning Strategy
### For dbt Projects
1. **Parse validation** (ALWAYS FIRST)
```
dbt_parse → if fails, immediate FAIL (project is broken)
```
2. **Catalog resources**
```
dbt_ls → list all models, tests, sources, exposures
```
3. **Lineage check**
```
dbt_lineage on changed models → check upstream/downstream integrity
```
4. **Compilation check**
```
dbt_compile on changed models → verify SQL renders correctly
```
5. **Test execution**
```
dbt_test --select <changed_models> → verify tests pass
```
6. **Test coverage audit**
```
Cross-reference dbt_ls tests against model list → flag models without tests (WARN)
```
### For PostgreSQL Schema Changes
1. **Table verification**
```
pg_tables → verify expected tables exist
```
2. **Column validation**
```
pg_columns on affected tables → verify types match expectations
```
3. **Schema comparison**
```
Compare pg_columns output against dbt schema.yml → flag drift
```
### For PostGIS/Spatial Data
1. **Spatial table scan**
```
st_tables → list tables with geometry columns
```
2. **SRID validation**
```
st_srid → verify SRID is correct for expected region
Expected: 4326 (WGS84) for GPS data, local projections for regional data
```
3. **Geometry type check**
```
st_geometry_type → verify expected types (Point, Polygon, etc.)
```
4. **Extent sanity check**
```
st_extent → verify bounding box is reasonable for expected region
Toronto data should be ~(-79.6 to -79.1, 43.6 to 43.9)
```
### For DataFrame/pandas Operations
1. **Data quality check**
```
describe → check for unexpected nulls, type issues, outliers
```
2. **Structure verification**
```
head → verify data structure matches expectations
```
3. **Memory management**
```
list_data → verify no stale DataFrames from previous failed runs
```
### For Python Code (Manual Scan)
1. **SQL injection patterns**
- Scan for f-strings with table/column names
- Check for string concatenation in queries
- Look for `.format()` calls with SQL
2. **Mutation safety**
- `pg_execute` usage should be intentional, not accidental
- Verify DELETE/UPDATE have WHERE clauses
3. **Credential exposure**
- No hardcoded connection strings
- No credentials in code (check for `.env` usage)
---
## Report Templates
### Gate Mode (Compact)
```
DATA GATE: PASS
No blocking data integrity violations found.
```
or
```
DATA GATE: FAIL
Blocking Issues (N):
1. <location> - <violation description>
Fix: <actionable fix>
2. <location> - <violation description>
Fix: <actionable fix>
Run /data-review for full audit report.
```
### Review Mode (Detailed)
```
+----------------------------------------------------------------------+
| DATA-PLATFORM - Data Integrity Audit |
| [Target Path] |
+----------------------------------------------------------------------+
Target: <scanned path or project>
Scope: N files scanned, N models checked, N tables verified
FINDINGS
FAIL (N)
1. [location] violation description
Fix: actionable fix
2. [location] violation description
Fix: actionable fix
WARN (N)
1. [location] warning description
Suggestion: improvement suggestion
2. [location] warning description
Suggestion: improvement suggestion
INFO (N)
1. [location] info description
Note: context
SUMMARY
Schema: Valid | N issues
Lineage: Intact | N orphaned
dbt: Passes | N failures
PostGIS: Valid | N issues | Not applicable
VERDICT: PASS | FAIL (N blocking issues)
```
---
## Skip Patterns
Do not flag violations in:
- `**/tests/**` - Test files may have intentional violations
- `**/__pycache__/**` - Compiled files
- `**/fixtures/**` - Test fixtures
- `**/.scratch/**` - Temporary working files
- Files with `# noqa: data-audit` comment
- Migration files marked as historical
---
## Error Handling
| Scenario | Behavior |
|----------|----------|
| Database not reachable (`pg_connect` fails) | WARN, skip PostgreSQL checks, continue with file-based |
| dbt not configured (no `dbt_project.yml`) | Skip dbt checks entirely, not an error |
| No PostGIS tables found | Skip PostGIS checks, not an error |
| MCP tool call fails | Report as WARN with tool name, continue with remaining checks |
| No data files in scanned path | Report "No data artifacts found" - PASS (nothing to fail) |
| Empty directory | Report "No files found in path" - PASS |
---
## Integration Notes
### projman Orchestrator
When called as a domain gate:
1. Orchestrator detects `Domain/Data` label on issue
2. Orchestrator identifies changed files
3. Orchestrator invokes `/data-gate <path>`
4. Agent runs gate mode scan
5. Returns PASS/FAIL to orchestrator
6. Orchestrator decides whether to complete issue
### Standalone Usage
For manual audits:
1. User runs `/data-review <path>`
2. Agent runs full review mode scan
3. Returns detailed report with all severity levels
4. User decides on actions

View File

@@ -1,16 +1,19 @@
{
"hooks": [
{
"event": "PreToolUse",
"matcher": "Bash",
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/branch-check.sh"
},
{
"event": "PreToolUse",
"matcher": "Bash",
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/commit-msg-check.sh"
}
]
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/branch-check.sh"
},
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/commit-msg-check.sh"
}
]
}
]
}
}

View File

@@ -2,8 +2,13 @@
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
}
]
}
]
}

View File

@@ -0,0 +1,5 @@
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

View File

@@ -11,6 +11,8 @@ You are the **Code Reviewer Agent** - a thorough, practical reviewer who ensures
- skills/review-checklist.md
- skills/test-standards.md
- skills/sprint-lifecycle.md
- skills/visual-output.md
## Your Personality
@@ -28,14 +30,10 @@ You are the **Code Reviewer Agent** - a thorough, practical reviewer who ensures
## Visual Output
Display header at start of every response:
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ 🏁 CLOSING ║
║ Code Review ║
╚══════════════════════════════════════════════════════════════════╝
```
See `skills/visual-output.md` for header templates. Use the **Code Reviewer** row from the Phase Registry:
- Phase Emoji: Magnifier
- Phase Name: REVIEW
- Context: Sprint Name
## Your Responsibilities

View File

@@ -15,6 +15,7 @@ You are the **Executor Agent** - an implementation-focused specialist who writes
- skills/progress-tracking.md
- skills/runaway-detection.md
- skills/lessons-learned.md
- skills/visual-output.md
## Your Personality
@@ -32,14 +33,10 @@ You are the **Executor Agent** - an implementation-focused specialist who writes
## Visual Output
Display header at start of every response:
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ ⚡ EXECUTION ║
║ [Issue Title] ║
╚══════════════════════════════════════════════════════════════════╝
```
See `skills/visual-output.md` for header templates. Use the **Executor** row from the Phase Registry:
- Phase Emoji: Wrench
- Phase Name: IMPLEMENTING
- Context: Issue Title
## Your Responsibilities

View File

@@ -18,6 +18,9 @@ You are the **Orchestrator Agent** - a concise, action-oriented coordinator who
- skills/progress-tracking.md
- skills/runaway-detection.md
- skills/wiki-conventions.md
- skills/domain-consultation.md
- skills/sprint-lifecycle.md
- skills/visual-output.md
## Your Personality
@@ -35,28 +38,17 @@ You are the **Orchestrator Agent** - a concise, action-oriented coordinator who
## Visual Output
Display header at start of every response:
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ ⚡ EXECUTION ║
║ [Sprint Name] ║
╚══════════════════════════════════════════════════════════════════╝
```
See `skills/visual-output.md` for header templates. Use the **Orchestrator** row from the Phase Registry:
- Phase Emoji: Lightning
- Phase Name: EXECUTION
- Context: Sprint Name
Progress block format:
```
┌─ Sprint Progress ────────────────────────────────────────────────┐
│ [Sprint Name] │
│ ████████████░░░░░░░░░░░░░░░░░░ 40% complete │
│ ✅ Done: 4 ⏳ Active: 2 ⬚ Pending: 4 │
└──────────────────────────────────────────────────────────────────┘
```
Also use the Progress Block format from `skills/visual-output.md` during sprint execution.
## Your Responsibilities
### 1. Verify Approval (Sprint Start)
Execute `skills/sprint-approval.md` - Check milestone for approval record.
Execute `skills/sprint-approval.md` - Check milestone for approval record. **STOP execution if approval is missing** unless user provided `--force` flag.
### 2. Detect Checkpoints (Sprint Start)
Check for resume points from interrupted sessions.
@@ -73,6 +65,25 @@ Execute `skills/dependency-management.md` - Check for file conflicts before para
### 6. Track Progress
Execute `skills/progress-tracking.md` - Manage status labels, parse progress comments.
### 6.5. Domain Gate Checks
Execute `skills/domain-consultation.md` (Execution Gate Protocol section):
1. **Before marking any issue as complete**, check for `Domain/*` labels
2. **If `Domain/Viz` label present:**
- Identify files changed by this issue
- Invoke `/design-gate <path-to-changed-files>`
- Gate PASS → proceed to mark issue complete
- Gate FAIL → add comment to issue with failure details, keep issue open
3. **If `Domain/Data` label present:**
- Identify files changed by this issue
- Invoke `/data-gate <path-to-changed-files>`
- Gate PASS → proceed to mark issue complete
- Gate FAIL → add comment to issue with failure details, keep issue open
4. **If gate command unavailable** (MCP server not running):
- Warn user: "Domain gate unavailable - proceeding without validation"
- Proceed with completion (non-blocking degradation)
- Do NOT silently skip
### 7. Monitor for Runaway Agents
Execute `skills/runaway-detection.md` - Intervene when agents are stuck.
@@ -85,6 +96,13 @@ Execute `skills/wiki-conventions.md` - Update implementation status.
### 10. Git Operations (Sprint Close)
Execute `skills/git-workflow.md` - Merge, tag, clean up branches.
### 11. Maintain Dispatch Log
Execute `skills/progress-tracking.md` (Sprint Dispatch Log section):
- Create dispatch log header at sprint start
- Append row on every task dispatch, completion, failure, and domain gate check
- On sprint resume: add "Resumed" row with checkpoint context
- Log is posted as comments, one `add_comment` per event
## Critical Reminders
1. **NEVER use CLI tools** - Use MCP tools exclusively (see `skills/mcp-tools-reference.md`)
@@ -93,6 +111,7 @@ Execute `skills/git-workflow.md` - Merge, tag, clean up branches.
4. **ALWAYS monitor dispatched agents** - Intervene if stuck
5. **ALWAYS capture lessons** - Don't skip the interview at sprint close
6. **ALWAYS update milestone** - Close milestone when sprint complete
7. **ALWAYS run domain gates** - Issues with `Domain/*` labels must pass gates before completion
## Your Mission

View File

@@ -20,6 +20,9 @@ You are the **Planner Agent** - a methodical architect who thoroughly analyzes r
- skills/sprint-approval.md
- skills/planning-workflow.md
- skills/label-taxonomy/labels-reference.md
- skills/domain-consultation.md
- skills/sprint-lifecycle.md
- skills/visual-output.md
## Your Personality
@@ -37,14 +40,10 @@ You are the **Planner Agent** - a methodical architect who thoroughly analyzes r
## Visual Output
Display header at start of every response:
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ 🎯 PLANNING ║
║ [Sprint Name or Goal] ║
╚══════════════════════════════════════════════════════════════════╝
```
See `skills/visual-output.md` for header templates. Use the **Planner** row from the Phase Registry:
- Phase Emoji: Target
- Phase Name: PLANNING
- Context: Sprint Name or Goal
## Your Responsibilities
@@ -66,10 +65,25 @@ Execute `skills/wiki-conventions.md` - Create proposal and implementation pages.
### 6. Task Sizing
Execute `skills/task-sizing.md` - **REFUSE to create L/XL tasks without breakdown.**
### 7. Issue Creation
### 7. Domain Consultation
Execute `skills/domain-consultation.md` (Planning Protocol section):
1. **After drafting issues but BEFORE creating them in Gitea**
2. **Analyze each issue for domain signals:**
- Check planned labels for `Component/Frontend`, `Component/UI` -> Domain/Viz
- Check planned labels for `Component/Database`, `Component/Data` -> Domain/Data
- Scan issue description for domain keywords (see skill for full list)
3. **For detected domains, append acceptance criteria:**
- Domain/Viz: Design System Compliance checklist
- Domain/Data: Data Integrity checklist
4. **Add corresponding `Domain/*` label** to the issue's label set
5. **Document in planning summary** which issues have domain gates active
### 8. Issue Creation
Execute `skills/issue-conventions.md` - Use proper format with wiki references.
### 8. Request Approval
### 9. Request Approval
Execute `skills/sprint-approval.md` - Planning DOES NOT equal execution permission.
## Critical Reminders
@@ -81,6 +95,7 @@ Execute `skills/sprint-approval.md` - Planning DOES NOT equal execution permissi
5. **ALWAYS search lessons** - Past experience informs better planning
6. **ALWAYS include wiki reference** - Every issue links to implementation wiki page
7. **ALWAYS use proper title format** - `[Sprint XX] <type>: <description>`
8. **ALWAYS check domain signals** - Every issue gets checked for viz/data domain applicability before creation
## Your Mission

View File

@@ -12,6 +12,11 @@ This project uses the **projman** plugin for sprint planning and project managem
| `/sprint-close` | Complete sprint and capture lessons learned to Gitea Wiki |
| `/labels-sync` | Synchronize label taxonomy from Gitea |
| `/initial-setup` | Run initial setup for projman plugin |
| `/rfc create` | Create new RFC from conversation or clarified spec |
| `/rfc list` | List all RFCs grouped by status |
| `/rfc review` | Submit Draft RFC for review |
| `/rfc approve` | Approve RFC for sprint planning |
| `/rfc reject` | Reject RFC with documented reason |
### MCP Tools Available
@@ -40,12 +45,14 @@ The following Gitea MCP tools are available for issue and project management:
- `create_issue_dependency` - Create dependency between issues
- `get_execution_order` - Get parallel execution batches
**Wiki (Lessons Learned):**
**Wiki (Lessons Learned & RFCs):**
- `list_wiki_pages` - List wiki pages
- `get_wiki_page` - Fetch specific page content
- `create_wiki_page` - Create new wiki page
- `update_wiki_page` - Update existing wiki page
- `create_lesson` - Create lessons learned document
- `search_lessons` - Search past lessons by tags
- `allocate_rfc_number` - Get next available RFC number
### Usage Guidelines

View File

@@ -1,34 +0,0 @@
---
description: Clear plugin cache to force fresh configuration reload after marketplace updates
---
# Clear Cache
## Purpose
Clear plugin cache to force fresh configuration reload after marketplace updates.
## When to Use
- After updating the marketplace (`git pull` or reinstall)
- When MCP servers show stale configuration
- When plugin changes don't take effect
## Workflow
Execute cache clear:
```bash
rm -rf ~/.claude/plugins/cache/leo-claude-mktplace/
```
Then inform user: "Cache cleared. Restart Claude Code for changes to take effect."
## Visual Output
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ Clear Cache ║
╚══════════════════════════════════════════════════════════════════╝
```

View File

@@ -8,6 +8,7 @@ agent: code-reviewer
## Skills Required
- skills/review-checklist.md
- skills/sprint-lifecycle.md
## Purpose
@@ -19,6 +20,7 @@ Run `/review` before `/sprint-close` to catch issues.
## Workflow
0. **Check Lifecycle State** - Execute `skills/sprint-lifecycle.md` check protocol. Expect `Sprint/Executing`. Set `Sprint/Reviewing` after review begins. Warn if in wrong state (allow with `--force`).
1. **Determine Scope** - Sprint files or recent commits (`git diff --name-only HEAD~5`)
2. **Read Files** - Use Read tool for each file in scope
3. **Scan for Patterns** - Check each category from review checklist

View File

@@ -0,0 +1,144 @@
---
description: RFC lifecycle management - create, list, review, approve, reject
agent: planner
---
# RFC Management
## Skills Required
- skills/mcp-tools-reference.md
- skills/rfc-workflow.md
- skills/rfc-templates.md
## Purpose
Manage the full RFC lifecycle through sub-commands. RFCs provide a structured way to document, discuss, and approve changes before implementation.
## Invocation
```
/rfc <sub-command> [arguments]
```
### Sub-Commands
| Sub-Command | Usage | Description |
|-------------|-------|-------------|
| `create` | `/rfc create` | Create new RFC from conversation or clarified spec |
| `list` | `/rfc list [filter]` | List all RFCs grouped by status |
| `review` | `/rfc review <number>` | Submit Draft RFC for review |
| `approve` | `/rfc approve <number>` | Approve RFC in Review status |
| `reject` | `/rfc reject <number>` | Reject RFC with documented reason |
---
## Sub-Command: create
Create a new RFC wiki page to track a feature idea through the review lifecycle.
**Workflow:**
1. Check if conversation has clarified specification (from `/clarify`)
2. If no context: prompt for Summary, Motivation, and initial Design
3. Call `allocate_rfc_number` MCP tool for next sequential number
4. Create RFC page using template from `skills/rfc-templates.md`
5. Update RFC-Index wiki page (create if doesn't exist)
6. Display RFC number, wiki link, and next steps
**Input Mapping (from /clarify):**
| Clarify Section | RFC Section |
|-----------------|-------------|
| Problem/Context | Motivation > Problem Statement |
| Goals/Outcomes | Motivation > Goals |
| Scope/Requirements | Detailed Design > Overview |
| Constraints | Non-Goals or Detailed Design |
| Success Criteria | Testing Strategy |
**Edge cases:**
- No RFC-Index exists: Create it with empty sections
- User provides minimal input: Create minimal RFC template, note sections to fill
- Duplicate title: Proceed (RFC numbers are unique, titles don't need to be)
---
## Sub-Command: list
Display all RFCs grouped by lifecycle status.
**Filters:** `/rfc list approved`, `/rfc list draft`, `/rfc list review`
**Workflow:**
1. Fetch RFC-Index wiki page via `get_wiki_page`
2. Parse tables from each status section
3. Display grouped by status, highlight Approved section
4. Show counts per status
**Edge cases:**
- No RFC-Index: "No RFCs yet. Create one with `/rfc create`"
- Empty sections: Show "(none)"
---
## Sub-Command: review
Submit a Draft RFC for review, transitioning status to Review.
**Usage:** `/rfc review <number>` (leading zeros optional)
**Workflow:**
1. Validate RFC number, fetch page
2. Check status is Draft - STOP if not
3. Validate minimum content (Summary, Motivation, Detailed Design > Overview required)
4. Optionally assign champion
5. Update RFC page: status Draft -> Review, update date
6. Update RFC-Index: move from Draft to In Review section
---
## Sub-Command: approve
Approve an RFC in Review status for sprint planning.
**Usage:** `/rfc approve <number>` (leading zeros optional)
**Workflow:**
1. Validate RFC number, fetch page
2. Check status is Review - STOP if not
3. Gather approval rationale (required)
4. Update RFC page: status Review -> Approved, add Decision section
5. Update RFC-Index: move from In Review to Approved section
---
## Sub-Command: reject
Reject an RFC with documented reason.
**Usage:** `/rfc reject <number>` (leading zeros optional)
**Workflow:**
1. Validate RFC number, fetch page
2. Check status is Draft or Review - STOP if not
3. Require rejection reason (mandatory)
4. Update RFC page: status -> Rejected, add Decision section
5. Update RFC-Index: move to Rejected section
---
## Visual Output
```
+----------------------------------------------------------------------+
| PROJMAN - RFC [Sub-Command] |
+----------------------------------------------------------------------+
```
---
## Validation Errors (All Sub-Commands)
- **RFC not found**: "RFC-NNNN not found. Check the number with `/rfc list`"
- **Wrong status**: "RFC-NNNN is in [status] status. [Specific allowed statuses for this action]."
- **Missing required input**: Specific message per sub-command
- **No sub-command provided**: Display sub-command reference table

View File

@@ -26,6 +26,7 @@ Unified setup command for all configuration needs.
/setup --full # Full wizard (MCP + system + project)
/setup --quick # Project-only setup
/setup --sync # Update after repo move
/setup --clear-cache # Clear plugin cache (between sessions only)
```
## Mode Detection
@@ -79,6 +80,21 @@ Steps:
6. Update `.env`
7. Confirm
## Mode: Clear Cache (--clear-cache)
Clear plugin cache to force fresh configuration reload.
**WARNING:** Only run between sessions, never mid-session. Clearing cache mid-session destroys MCP tool venv paths and breaks all MCP operations.
Steps:
1. Execute: `rm -rf ~/.claude/plugins/cache/leo-claude-mktplace/`
2. Inform user: "Cache cleared. Restart Claude Code for changes to take effect."
When to use:
- After updating the marketplace (`git pull` or reinstall)
- When MCP servers show stale configuration
- When plugin changes don't take effect
## Visual Output
```

View File

@@ -10,8 +10,10 @@ agent: orchestrator
- skills/mcp-tools-reference.md
- skills/lessons-learned.md
- skills/wiki-conventions.md
- skills/rfc-workflow.md
- skills/progress-tracking.md
- skills/git-workflow.md
- skills/sprint-lifecycle.md
## Purpose
@@ -25,17 +27,49 @@ Run `/sprint-close` when sprint work is complete.
Execute the sprint close workflow:
0. **Check Lifecycle State** - Execute `skills/sprint-lifecycle.md` check protocol. Expect `Sprint/Reviewing`. Clear all Sprint/* labels (return to idle) at the END of close workflow, after all other steps. Warn if in wrong state (allow with `--force`).
1. **Review Sprint Completion** - Verify issues closed or moved to backlog
2. **Capture Lessons Learned** - Interview user about challenges and insights
3. **Tag for Discoverability** - Apply technology, component, and pattern tags
4. **Save to Gitea Wiki** - Use `create_lesson` with metadata and implementation link
5. **Update Wiki Implementation Page** - Change status to Implemented/Partial/Failed
6. **Update Wiki Proposal Page** - Update overall status if all implementations complete
7. **New Command Verification** - Remind user new commands require session restart
8. **Update CHANGELOG** (MANDATORY) - Add changes to `[Unreleased]` section
9. **Version Check** - Run `/suggest-version` to recommend version bump
10. **Git Operations** - Commit, merge, tag, clean up branches
11. **Close Milestone** - Update milestone state to closed
7. **Update RFC Status (if applicable)** - See RFC Update section below
8. **New Command Verification** - Remind user new commands require session restart
9. **Update CHANGELOG** (MANDATORY) - Add changes to `[Unreleased]` section
10. **Version Check** - Run `/suggest-version` to recommend version bump
11. **Git Operations** - Commit, merge, tag, clean up branches
12. **Close Milestone** - Update milestone state to closed
## RFC Status Update (Step 7)
If the sprint was linked to an RFC:
1. **Check Sprint Completion Status:**
- All issues completed → RFC status = Implemented
- Partial completion → RFC status stays Implementing (note progress)
- Blocked/Failed → RFC status reverts to Draft (with notes)
2. **Update RFC Page (if Implemented):**
- Change status: Implementing → Implemented
- Add Completion section with date and release version
- Link to lessons learned page
```python
update_wiki_page(
page_name="RFC-NNNN:-Title",
content="[content with Implemented status and completion details]",
repo="org/repo"
)
```
3. **Update RFC-Index:**
- Remove from "## Implementing" section
- Add to "## Implemented" section with completion date and release
4. **Handle Partial Completion:**
- Keep RFC in Implementing status
- Add progress notes to Implementation section
- Next sprint can continue the work
**Don't skip lessons learned!** Future sprints will benefit from captured insights.

View File

@@ -18,6 +18,7 @@ agent: planner
- skills/sprint-approval.md
- skills/planning-workflow.md
- skills/label-taxonomy/labels-reference.md
- skills/sprint-lifecycle.md
## Purpose
@@ -35,6 +36,7 @@ Provide sprint goals as natural language input, or prepare input via:
Execute the planning workflow as defined in `skills/planning-workflow.md`.
**Key steps:**
0. **Check Lifecycle State** - Execute `skills/sprint-lifecycle.md` check protocol. Expect idle state. Set `Sprint/Planning` after planning completes. Warn and stop if sprint is in another active state (unless `--force`).
1. Run pre-planning validations (branch, repo org, labels)
2. Detect input source (file, wiki, or conversation)
3. Search relevant lessons learned

View File

@@ -15,6 +15,7 @@ agent: orchestrator
- skills/git-workflow.md
- skills/progress-tracking.md
- skills/runaway-detection.md
- skills/sprint-lifecycle.md
## Purpose
@@ -24,11 +25,14 @@ Initiate sprint execution. The orchestrator agent verifies approval, analyzes de
Run `/sprint-start` when ready to begin executing a planned sprint.
**Flags:**
- `--force` — Bypass approval gate (emergency only, logged to milestone)
## Workflow
Execute the sprint start workflow:
1. **Verify Sprint Approval** (recommended) - Check milestone for approval record
1. **Verify Sprint Approval & Lifecycle State** (required) - Check milestone for approval record. STOP if missing unless `--force` flag provided. Also verify lifecycle state is `Sprint/Planning` per `skills/sprint-lifecycle.md`. Set `Sprint/Executing` after verification passes.
2. **Detect Checkpoints** - Check for resume points from interrupted sessions
3. **Fetch Sprint Issues** - Get open issues from milestone
4. **Analyze Dependencies** - Use `get_execution_order` for parallel batches

View File

@@ -9,6 +9,7 @@ description: Check current sprint progress, identify blockers, optionally genera
- skills/mcp-tools-reference.md
- skills/progress-tracking.md
- skills/dependency-management.md
- skills/sprint-lifecycle.md
## Purpose
@@ -23,6 +24,7 @@ Check current sprint progress, identify blockers, and show execution status. Opt
## Workflow
0. **Display Lifecycle State** - Read current Sprint/* state from milestone description per `skills/sprint-lifecycle.md` and display in output header.
1. **Fetch Sprint Issues** - Get all issues for current milestone
2. **Calculate Progress** - Count completed vs total issues
3. **Identify Active Tasks** - Find issues with `Status/In-Progress`

View File

@@ -93,6 +93,78 @@ Generate comprehensive tests for specified code.
See `skills/test-standards.md` for test patterns and structure.
### DO NOT (Generate Mode)
- Install dependencies without asking first
- Generate tests that import private/internal functions not meant for testing
- Overwrite existing test files without confirmation
- Generate tests with hardcoded values that should be environment-based
---
## Sprint Integration
The `/test` command plays a critical role in the sprint close workflow:
1. After `/review` identifies code quality issues
2. Before `/sprint-close` finalizes the sprint
3. The code reviewer and orchestrator reference test results when deciding if a sprint is ready to close
### Pre-Close Verification
When running `/test run` before sprint close:
1. **Identify sprint files** - Files changed in the current sprint (via git diff against development)
2. **Check test coverage** - Report which sprint files have tests and which don't
3. **Flag untested code** - Warn if new code has no corresponding tests
4. **Recommend action** - "READY FOR CLOSE" or "TESTS NEEDED: [list of untested files]"
---
## Examples
### Run all tests
```
/test run
```
Detects framework, runs full test suite, reports results.
### Run with coverage
```
/test run --coverage
```
Same as above plus coverage percentage per file.
### Generate tests for a specific file
```
/test gen src/auth/jwt_service.py
```
Analyzes the file, generates a test file at `tests/test_jwt_service.py`.
### Generate specific test type
```
/test gen src/api/routes/auth.py --type=integration
```
Generates integration tests (request/response patterns) instead of unit tests.
### Generate with specific framework
```
/test gen src/components/Card.jsx --framework=vitest
```
Uses Vitest instead of auto-detected framework.
---
## Edge Cases
| Scenario | Behavior |
|----------|----------|
| No test framework detected | List what was checked, ask user to specify test command |
| Tests fail | Report failures clearly, recommend "TESTS MUST PASS before sprint close" |
| No tests exist for sprint files | Warn with file list, offer to generate with `/test gen` |
| External services required | Ask for confirmation before running tests that need database/API |
| Mixed framework project | Detect all frameworks, ask which to run or run all |
---
## Visual Output

View File

@@ -2,8 +2,13 @@
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
}
]
}
]
}

View File

@@ -0,0 +1,165 @@
---
name: domain-consultation
description: Cross-plugin domain consultation for specialized planning and validation
---
# Domain Consultation
## Purpose
Enables projman agents to detect domain-specific work and consult specialized plugins for expert validation during planning and execution phases. This skill is the backbone of the Domain Advisory Pattern.
---
## When to Use
| Agent | Phase | Action |
|-------|-------|--------|
| Planner | After task sizing, before issue creation | Detect domains, add acceptance criteria |
| Orchestrator | Before marking issue complete | Run domain gates, block if violations |
| Code Reviewer | During review | Include domain compliance in findings |
---
## Domain Detection Rules
| Signal Type | Detection Pattern | Domain Plugin | Action |
|-------------|-------------------|---------------|--------|
| Label-based | `Component/Frontend`, `Component/UI` | viz-platform | Add design system criteria, apply `Domain/Viz` |
| Content-based | Keywords: DMC, Dash, layout, theme, component, dashboard, chart, responsive, color, UI, frontend, Plotly | viz-platform | Same as above |
| Label-based | `Component/Database`, `Component/Data` | data-platform | Add data validation criteria, apply `Domain/Data` |
| Content-based | Keywords: schema, migration, pipeline, dbt, table, column, query, PostgreSQL, lineage, data model | data-platform | Same as above |
| Both signals | Frontend + Data signals present | Both plugins | Apply both sets of criteria |
---
## Planning Protocol
When creating issues, the planner MUST:
1. **Analyze each issue** for domain signals (check labels AND scan description for keywords)
2. **For Domain/Viz issues**, append this acceptance criteria block:
```markdown
## Design System Compliance
- [ ] All DMC components validated against registry
- [ ] Theme tokens used (no hardcoded colors/sizes)
- [ ] Accessibility check passed (WCAG contrast)
- [ ] Responsive breakpoints verified
```
3. **For Domain/Data issues**, append this acceptance criteria block:
```markdown
## Data Integrity
- [ ] Schema changes validated
- [ ] dbt tests pass
- [ ] Lineage intact (no orphaned models)
- [ ] Data types verified
```
4. **Apply the corresponding `Domain/*` label** to route the issue through gates
5. **Document in planning summary** which issues have domain gates active
---
## Execution Gate Protocol
Before marking any issue as complete, the orchestrator MUST:
1. **Check issue labels** for `Domain/*` labels
2. **If `Domain/Viz` label present:**
- Identify files changed by this issue
- Invoke `/design-gate <path-to-changed-files>`
- Gate PASS → proceed to mark issue complete
- Gate FAIL → add comment to issue with failure details, keep issue open
3. **If `Domain/Data` label present:**
- Identify files changed by this issue
- Invoke `/data-gate <path-to-changed-files>`
- Gate PASS → proceed to mark issue complete
- Gate FAIL → add comment to issue with failure details, keep issue open
4. **If gate command unavailable** (MCP server not running):
- Warn user: "Domain gate unavailable - proceeding without validation"
- Proceed with completion (non-blocking degradation)
- Do NOT silently skip - always inform user
---
## Review Protocol
During code review, the code reviewer SHOULD:
1. After completing standard code quality and security checks, check for `Domain/*` labels
2. **If Domain/Viz:** Include "Design System Compliance" section in review report
- Reference `/design-review` findings if available
- Check for hardcoded colors, invalid props, accessibility issues
3. **If Domain/Data:** Include "Data Integrity" section in review report
- Reference `/data-gate` findings if available
- Check for schema validity, lineage integrity
---
## Extensibility
To add a new domain (e.g., `Domain/Infra` for cmdb-assistant):
1. **In domain plugin:** Create advisory agent + gate command
- Agent: `agents/infra-advisor.md`
- Gate command: `commands/infra-gate.md`
- Audit skill: `skills/infra-audit.md`
2. **In this skill:** Add detection rules to the Detection Rules table above
- Define label-based signals (e.g., `Component/Infrastructure`)
- Define content-based keywords (e.g., "server", "network", "NetBox")
3. **In label taxonomy:** Add `Domain/Infra` label with appropriate color
- Update `plugins/projman/skills/label-taxonomy/labels-reference.md`
4. **No changes needed** to planner.md or orchestrator.md agent files
- They read this skill dynamically
- Detection rules table is the single source of truth
This pattern ensures domain expertise stays in domain plugins while projman orchestrates when to ask.
---
## Domain Acceptance Criteria Templates
### Design System Compliance (Domain/Viz)
```markdown
## Design System Compliance
- [ ] All DMC components validated against registry
- [ ] Theme tokens used (no hardcoded colors/sizes)
- [ ] Accessibility check passed (WCAG contrast)
- [ ] Responsive breakpoints verified
```
### Data Integrity (Domain/Data)
```markdown
## Data Integrity
- [ ] Schema changes validated
- [ ] dbt tests pass
- [ ] Lineage intact (no orphaned models)
- [ ] Data types verified
```
---
## Gate Command Reference
| Domain | Gate Command | Contract | Review Command | Advisory Agent |
|--------|--------------|----------|----------------|----------------|
| Viz | `/design-gate <path>` | v1 | `/design-review <path>` | `design-reviewer` |
| Data | `/data-gate <path>` | v1 | `/data-review <path>` | `data-advisor` |
Gate commands return binary PASS/FAIL for automation.
Review commands return detailed reports for human review.
**Contract Version:** Gate commands declare `gate_contract: vN` in their frontmatter. The version in this table is what projman expects. If a gate command bumps its contract version, this table must be updated to match. The `contract-validator` plugin checks this automatically via `validate_workflow_integration`.

View File

@@ -1,6 +1,6 @@
---
name: input-detection
description: Detect planning input source (file, wiki, or conversation)
description: Detect planning input source (RFC, file, wiki, or conversation)
---
# Input Source Detection
@@ -20,12 +20,56 @@ Defines how to detect where planning input is coming from and how to handle each
| Priority | Source | Detection | Action |
|----------|--------|-----------|--------|
| 0 | Approved RFC | RFC-Index has entries in "Approved" section | Offer RFC selection or new work |
| 1 | Local file | `docs/changes/*.md` exists | Parse frontmatter, migrate to wiki, delete local |
| 2 | Existing wiki | `Change VXX.X.X: Proposal` exists | Use as-is, create implementation page |
| 3 | Conversation | Neither exists | Create wiki from discussion context |
---
## RFC Detection (Priority 0)
Before checking for local files or wiki proposals, check for approved RFCs.
### Detection Steps
1. **Fetch RFC-Index:**
```python
get_wiki_page(page_name="RFC-Index", repo="org/repo")
```
2. **Parse Approved Section:**
- Find "## Approved" section
- Extract RFC entries from table
3. **If Approved RFCs Exist:**
```
Approved RFCs available for implementation:
| RFC | Title | Champion |
|-----|-------|----------|
| RFC-0003 | Feature X | @user |
| RFC-0007 | Enhancement Y | @user |
Options:
[1] Implement RFC-0003: Feature X
[2] Implement RFC-0007: Enhancement Y
[3] Describe new work (skip RFCs)
Select an option:
```
4. **If RFC Selected:**
- Use RFC content as planning input
- Status will transition to Implementing after planning approval
- Skip local file and wiki proposal detection
5. **If "New Work" Selected:**
- Continue with normal Priority 1-3 detection
- Optionally offer: "Would you like to create an RFC first? (y/n)"
---
## Local File Format
```yaml

View File

@@ -13,7 +13,7 @@ description: Dynamic reference for Gitea label taxonomy (organization + reposito
This skill provides the current label taxonomy used for issue classification in Gitea. Labels are **fetched dynamically** from Gitea and should never be hardcoded.
**Current Taxonomy:** 47 labels (31 organization + 16 repository)
**Current Taxonomy:** 49 labels (31 organization + 18 repository)
## Organization Labels (31)
@@ -66,7 +66,7 @@ Organization-level labels are shared across all repositories in your configured
- `Status/Failed` (#de350b) - Implementation attempted but failed, needs investigation
- `Status/Deferred` (#6554c0) - Moved to a future sprint or backlog
## Repository Labels (16)
## Repository Labels (18)
Repository-level labels are specific to each project.
@@ -90,6 +90,39 @@ Repository-level labels are specific to each project.
- `Tech/Vue` (#42b883) - Vue.js frontend framework
- `Tech/FastAPI` (#009688) - FastAPI backend framework
### Sprint Lifecycle (Milestone Metadata)
These are tracked as milestone description metadata, not as Gitea issue labels. They are documented here for completeness.
| Label | Description |
|-------|-------------|
| `Sprint/Planning` | Sprint planning in progress |
| `Sprint/Executing` | Sprint execution in progress |
| `Sprint/Reviewing` | Code review in progress |
**Note:** Lifecycle state is stored in milestone description as `**Sprint State:** Sprint/Executing`. See `skills/sprint-lifecycle.md` for state machine rules.
### Domain (2 labels)
Cross-plugin integration labels for domain-specific validation gates.
| Label | Color | Description |
|-------|-------|-------------|
| `Domain/Viz` | `#7c4dff` | Issue involves visualization/frontend — triggers viz-platform design gates |
| `Domain/Data` | `#00bfa5` | Issue involves data engineering — triggers data-platform data gates |
**Detection Rules:**
**Domain/Viz:**
- Keywords: "dashboard", "chart", "theme", "DMC", "component", "layout", "responsive", "color", "UI", "frontend", "Dash", "Plotly"
- Also applied when: `Component/Frontend` or `Component/UI` label is present
- Example: "Create new neighbourhood comparison dashboard tab"
**Domain/Data:**
- Keywords: "schema", "migration", "pipeline", "dbt", "table", "column", "query", "PostgreSQL", "lineage", "data model"
- Also applied when: `Component/Database` or `Component/Data` label is present
- Example: "Add census demographic data pipeline"
## Label Suggestion Logic
When suggesting labels for issues, consider the following patterns:

View File

@@ -40,10 +40,18 @@ Execute in order:
### 3. Detect Input Source
Follow `skills/input-detection.md`:
1. Check for `docs/changes/*.md` files
2. Check for existing wiki proposal
3. If neither: use conversation context
4. If ambiguous: ask user
1. **Check for approved RFCs** (Priority 0)
2. Check for `docs/changes/*.md` files
3. Check for existing wiki proposal
4. If neither: use conversation context
5. If ambiguous: ask user
### 3a. RFC Status Update (if RFC selected)
If input source is an RFC:
1. **Note the RFC number** for later status update
2. RFC status update happens AFTER sprint approval (Step 11)
3. The RFC provides the planning context - use its Summary, Motivation, and Design sections
### 4. Search Relevant Lessons Learned
@@ -110,6 +118,31 @@ Follow `skills/sprint-approval.md`:
- Wait for explicit user approval
- Record approval in milestone description
### 12. Update RFC Status (if applicable)
If planning input was an RFC:
1. **Fetch RFC page:**
```python
get_wiki_page(page_name="RFC-NNNN:-Title", repo="org/repo")
```
2. **Update RFC page:**
- Change status: Approved → Implementing
- Add Sprint reference to frontmatter
- Add Implementation section with sprint details and issue links
```python
update_wiki_page(
page_name="RFC-NNNN:-Title",
content="[updated content with Implementing status]",
repo="org/repo"
)
```
3. **Update RFC-Index:**
- Remove from "## Approved" section
- Add to "## Implementing" section with sprint reference
---
## Cleanup After Planning

View File

@@ -138,6 +138,49 @@ For resume support, save checkpoints after major steps:
---
## Sprint Dispatch Log
A single structured comment on the sprint milestone that records all task dispatches and completions. This is the first place to look when resuming an interrupted sprint.
### Format
Post as a comment on the milestone (via `add_comment` on a pinned tracking issue, or as milestone description appendix):
```markdown
## Sprint Dispatch Log
| Time | Issue | Action | Agent | Branch | Notes |
|------|-------|--------|-------|--------|-------|
| 14:30 | #45 | Dispatched | Executor | feat/45-jwt | Parallel batch 1 |
| 14:30 | #46 | Dispatched | Executor | feat/46-login | Parallel batch 1 |
| 14:45 | #45 | Complete | Executor | feat/45-jwt | 47 tool calls, merged |
| 14:52 | #46 | Failed | Executor | feat/46-login | Auth test failure |
| 14:53 | #46 | Re-dispatched | Executor | feat/46-login | After fix |
| 15:10 | #46 | Complete | Executor | feat/46-login | 62 tool calls, merged |
| 15:10 | #47 | Dispatched | Executor | feat/47-tests | Batch 2 (depended on #45, #46) |
```
### When to Log
| Event | Action Column | Required Fields |
|-------|---------------|-----------------|
| Task dispatched to executor | `Dispatched` | Time, Issue, Branch, Batch info |
| Task completed | `Complete` | Time, Issue, Tool call count |
| Task failed | `Failed` | Time, Issue, Error summary |
| Task re-dispatched | `Re-dispatched` | Time, Issue, Reason |
| Domain gate checked | `Gate: PASS` or `Gate: FAIL` | Time, Issue, Domain |
| Sprint resumed | `Resumed` | Time, Notes (from checkpoint) |
### Implementation
The orchestrator appends rows to this log via `add_comment` on the first issue in the milestone (or a dedicated tracking issue). Each append is a single `add_comment` call updating the table.
**On sprint start:** Create the dispatch log header.
**On each event:** Append a row.
**On sprint resume:** Add a "Resumed" row with checkpoint context.
---
## Sprint Progress Display
```

View File

@@ -0,0 +1,380 @@
---
name: rfc-templates
description: RFC page templates and frontmatter format specifications
---
# RFC Templates
## Purpose
Provides templates for RFC wiki pages and defines the required/optional sections for complete RFC documentation.
## When to Use
- **Commands**: `/rfc create` when generating new RFC pages
- **Integration**: Referenced by `rfc-workflow.md` for page structure
---
## RFC Page Frontmatter
Every RFC page starts with a metadata block using blockquote format:
```markdown
> **RFC:** 0001
> **Title:** Short Descriptive Title
> **Status:** Draft
> **Author:** @username
> **Created:** 2026-01-25
> **Updated:** 2026-01-25
> **Champion:** (unassigned)
> **Sprint:** (none)
> **Superseded-By:** (none)
```
### Frontmatter Fields
| Field | Required | Description |
|-------|----------|-------------|
| `RFC` | Yes | 4-digit RFC number (e.g., 0001) |
| `Title` | Yes | Short descriptive title |
| `Status` | Yes | Current lifecycle status |
| `Author` | Yes | Original RFC author |
| `Created` | Yes | Creation date (YYYY-MM-DD) |
| `Updated` | Yes | Last update date (YYYY-MM-DD) |
| `Champion` | No | Assigned reviewer/sponsor |
| `Sprint` | No | Sprint reference when implementing |
| `Superseded-By` | No | RFC number if superseded |
---
## Full RFC Page Template
```markdown
> **RFC:** NNNN
> **Title:** [Short Title]
> **Status:** Draft
> **Author:** @[username]
> **Created:** YYYY-MM-DD
> **Updated:** YYYY-MM-DD
> **Champion:** (unassigned)
> **Sprint:** (none)
> **Superseded-By:** (none)
# RFC-NNNN: [Full Title]
## Summary
A brief (2-3 paragraph) explanation of the proposed change. This should be understandable by someone unfamiliar with the codebase.
**What:** What is being proposed?
**Why:** Why is this change needed?
**Impact:** What will be different after this is implemented?
## Motivation
### Problem Statement
Describe the problem this RFC addresses. Include:
- Current pain points or limitations
- User stories or use cases
- Why existing solutions are insufficient
### Goals
- [ ] Goal 1: Specific, measurable outcome
- [ ] Goal 2: Another specific outcome
- [ ] Goal 3: Third outcome
### Non-Goals
What is explicitly out of scope for this RFC:
- Non-goal 1
- Non-goal 2
## Detailed Design
### Overview
High-level description of the solution approach.
### Architecture
Describe the technical architecture:
- Components involved
- Data flow
- Integration points
### Implementation Details
#### Component 1
Detailed implementation for component 1.
#### Component 2
Detailed implementation for component 2.
### API/Interface Changes
If applicable, describe any API or interface changes:
```python
# Example new API
def new_function(param1: str, param2: int) -> dict:
"""Description of new function."""
pass
```
### Database/Storage Changes
If applicable, describe any data model changes.
### Configuration Changes
If applicable, describe any new configuration options.
## Alternatives Considered
### Alternative 1: [Name]
**Description:** Brief description of this alternative.
**Pros:**
- Pro 1
- Pro 2
**Cons:**
- Con 1
- Con 2
**Why not chosen:** Explanation.
### Alternative 2: [Name]
**Description:** Brief description of this alternative.
**Pros:**
- Pro 1
**Cons:**
- Con 1
**Why not chosen:** Explanation.
## Unresolved Questions
Questions that need to be answered before or during implementation:
1. **Question 1:** Description of open question
- Possible answer A
- Possible answer B
2. **Question 2:** Description of another open question
## Dependencies
- Dependency 1: Description and status
- Dependency 2: Description and status
## Security Considerations
Describe any security implications:
- Authentication/authorization impacts
- Data privacy considerations
- Potential attack vectors and mitigations
## Testing Strategy
How will this be tested:
- Unit tests
- Integration tests
- Manual testing checklist
## Rollout Plan
How will this be deployed:
- Feature flags
- Phased rollout
- Rollback strategy
---
## Review Notes
*(Added during Review phase)*
### Review Discussion
Summary of review feedback and discussions.
### Changes Made
List of changes made in response to review feedback.
---
## Decision
*(Added when Approved or Rejected)*
**Decision:** [Approved/Rejected]
**Date:** YYYY-MM-DD
**Decided By:** @[username]
**Rationale:**
Explanation of the decision.
---
## Implementation
*(Added during Implementing phase)*
**Sprint:** [Sprint reference]
**Started:** YYYY-MM-DD
**Issues:**
- #123: Issue title
- #124: Another issue
### Progress Notes
Updates during implementation.
---
## Completion
*(Added when Implemented)*
**Completed:** YYYY-MM-DD
**Release:** vX.Y.Z
**Lessons Learned:** [Link to lessons wiki page]
### Final Notes
Summary of what was implemented and any deviations from the original design.
```
---
## Section Requirements by Status
### Draft (Minimum)
- Summary (complete)
- Motivation (at least Problem Statement)
- Detailed Design (at least Overview)
### Review (Required)
All Draft sections plus:
- Alternatives Considered (at least 1)
- Unresolved Questions (can be empty if none)
### Approved (Required)
All Review sections plus:
- Decision section with approval
### Implementing (Required)
All Approved sections plus:
- Implementation section with Sprint and Issues
### Implemented (Required)
All Implementing sections plus:
- Completion section
---
## RFC-Index Entry Format
### Draft Section Entry
```markdown
| [RFC-0005](RFC-0005:-Idea-Z) | Idea Z | @user | 2026-01-25 |
```
### Review Section Entry
```markdown
| [RFC-0004](RFC-0004:-Feature-Y) | Feature Y | @user | 2026-01-20 |
```
### Approved Section Entry
```markdown
| [RFC-0003](RFC-0003:-Feature-X) | Feature X | @champion | 2026-01-15 |
```
### Implementing Section Entry
```markdown
| [RFC-0002](RFC-0002:-Feature-W) | Feature W | Sprint 18 | 2026-01-22 |
```
### Implemented Section Entry
```markdown
| [RFC-0001](RFC-0001:-Initial-Feature) | Initial Feature | 2026-01-10 | v5.0.0 |
```
### Rejected Section Entry
```markdown
| [RFC-0006](RFC-0006:-Rejected-Idea) | Rejected Idea | Out of scope | 2026-01-18 |
```
---
## Minimal RFC Template (Quick Start)
For rapid RFC creation from conversation:
```markdown
> **RFC:** NNNN
> **Title:** [Title]
> **Status:** Draft
> **Author:** @[username]
> **Created:** YYYY-MM-DD
> **Updated:** YYYY-MM-DD
> **Champion:** (unassigned)
> **Sprint:** (none)
> **Superseded-By:** (none)
# RFC-NNNN: [Title]
## Summary
[Brief description of the proposal]
## Motivation
### Problem Statement
[What problem does this solve?]
### Goals
- [ ] [Primary goal]
## Detailed Design
### Overview
[High-level approach]
## Alternatives Considered
*(To be added during review)*
## Unresolved Questions
- [Any open questions?]
```
---
## Creating RFC from Clarified Spec
When `/clarify` provides a clarified specification, map sections:
| Clarify Output | RFC Section |
|----------------|-------------|
| Problem/Context | Motivation > Problem Statement |
| Goals/Outcomes | Motivation > Goals |
| Scope/Requirements | Detailed Design > Overview |
| Constraints | Detailed Design or Non-Goals |
| Success Criteria | Testing Strategy |

View File

@@ -0,0 +1,308 @@
---
name: rfc-workflow
description: RFC lifecycle management, state transitions, and wiki page conventions
---
# RFC Workflow
## Purpose
Defines the Request for Comments (RFC) system for capturing, reviewing, and tracking feature ideas through their lifecycle from initial proposal to implementation.
## When to Use
- **Planner agent**: When detecting approved RFCs for sprint planning
- **Commands**: `/rfc create`, `/rfc list`, `/rfc review`, `/rfc approve`, `/rfc reject`
- **Integration**: With `/sprint-plan` to select approved RFCs for implementation
---
## RFC Lifecycle States
```
┌──────────────────────────────────────────────┐
│ │
▼ │
┌─────────┐ ┌─────────┐ ┌──────────┐ ┌──────────────┐ │
│ Draft │───▶│ Review │───▶│ Approved │───▶│ Implementing │────┤
└─────────┘ └─────────┘ └──────────┘ └──────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌─────────────┐ │
│ │ │ Implemented │ │
│ │ └─────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────┐ ┌────────────┐ │
│ │ Rejected │ │ Superseded │ │
│ └──────────┘ └────────────┘ │
│ │
▼ │
┌─────────┐ │
│ Stale │────────────────────────────────────────────────────────┘
└─────────┘ (revived → Draft)
```
---
## State Definitions
| Status | Meaning | Valid Transitions |
|--------|---------|-------------------|
| `Draft` | Idea captured, needs refinement | → Review, → Stale |
| `Review` | Being evaluated by maintainers | → Approved, → Rejected, → Draft |
| `Approved` | Ready for sprint planning | → Implementing |
| `Rejected` | Declined with documented reason | (terminal) |
| `Implementing` | Active sprint work in progress | → Implemented, → Draft (if blocked) |
| `Implemented` | Completed, links to release | → Superseded |
| `Stale` | Draft with no activity >90 days | → Draft (if revived) |
| `Superseded` | Replaced by newer RFC | (terminal) |
---
## State Transition Rules
### Draft → Review
- **Who can transition**: RFC author or any maintainer
- **Requirements**: RFC has complete Summary, Motivation, and Detailed Design sections
- **Action**: Update status, optionally assign champion
### Review → Approved
- **Who can transition**: Maintainer or designated reviewer
- **Requirements**: Review discussion complete, no blocking concerns
- **Action**: Update status, add Decision section with approval reason
### Review → Rejected
- **Who can transition**: Maintainer or designated reviewer
- **Requirements**: Reason must be documented
- **Action**: Update status, add Decision section with rejection reason
### Approved → Implementing
- **Who can transition**: Planner agent via `/sprint-plan`
- **Requirements**: RFC selected for sprint
- **Action**: Update status, add Sprint reference, update RFC-Index
### Implementing → Implemented
- **Who can transition**: Orchestrator agent via `/sprint-close`
- **Requirements**: Sprint completed successfully
- **Action**: Update status, add completion date, link to lessons learned
### Implementing → Draft
- **Who can transition**: Any maintainer
- **Requirements**: Implementation blocked, needs rework
- **Action**: Update status, add Implementation Notes explaining why
### Draft → Stale
- **Automatic**: No activity for 90 days
- **Action**: Update status in RFC-Index
### Stale → Draft
- **Who can transition**: Anyone
- **Requirements**: Renewed interest, updated content
- **Action**: Update status, add Revival Notes
### Implemented → Superseded
- **Who can transition**: Any maintainer
- **Requirements**: New RFC replaces functionality
- **Action**: Update status, add Superseded-By reference
---
## Wiki Page Naming
| Page Type | Naming Convention | Example |
|-----------|-------------------|---------|
| RFC Page | `RFC-NNNN: Short Title` | `RFC-0001: RFC System Implementation` |
| Index Page | `RFC-Index` | `RFC-Index` |
**Number Format:**
- 4-digit zero-padded (0001, 0002, 0003, ...)
- Sequential, never reused
- Allocated via `allocate_rfc_number` MCP tool
---
## Number Allocation Logic
```python
# Pseudocode for allocate_rfc_number
async def allocate_rfc_number(repo):
pages = await list_wiki_pages(repo)
rfc_pages = [p for p in pages if p['title'].startswith('RFC-')]
if not rfc_pages:
return {'next_number': 1, 'formatted': 'RFC-0001'}
numbers = []
for page in rfc_pages:
# Extract number from "RFC-NNNN: Title"
match = re.match(r'RFC-(\d{4})', page['title'])
if match:
numbers.append(int(match.group(1)))
next_num = max(numbers) + 1 if numbers else 1
return {
'next_number': next_num,
'formatted': f'RFC-{next_num:04d}'
}
```
---
## RFC-Index Page Format
The RFC-Index page organizes RFCs by status:
```markdown
# RFC Index
## Approved
RFCs ready for implementation in upcoming sprints.
| RFC | Title | Champion | Created |
|-----|-------|----------|---------|
| [RFC-0003](RFC-0003:-Feature-X) | Feature X | @user | 2026-01-15 |
## In Review
RFCs currently being evaluated.
| RFC | Title | Author | Created |
|-----|-------|--------|---------|
| [RFC-0004](RFC-0004:-Feature-Y) | Feature Y | @user | 2026-01-20 |
## Draft
RFCs in early development.
| RFC | Title | Author | Created |
|-----|-------|--------|---------|
| [RFC-0005](RFC-0005:-Idea-Z) | Idea Z | @user | 2026-01-25 |
## Implementing
RFCs currently being implemented.
| RFC | Title | Sprint | Started |
|-----|-------|--------|---------|
| [RFC-0002](RFC-0002:-Feature-W) | Feature W | Sprint 18 | 2026-01-22 |
## Implemented
Completed RFCs.
| RFC | Title | Completed | Release |
|-----|-------|-----------|---------|
| [RFC-0001](RFC-0001:-Initial-Feature) | Initial Feature | 2026-01-10 | v5.0.0 |
## Rejected
RFCs that were declined.
| RFC | Title | Reason | Date |
|-----|-------|--------|------|
| [RFC-0006](RFC-0006:-Rejected-Idea) | Rejected Idea | Out of scope | 2026-01-18 |
## Stale
Inactive RFCs (no updates >90 days).
| RFC | Title | Last Updated |
|-----|-------|--------------|
```
---
## Creating RFC-Index
If RFC-Index doesn't exist when creating first RFC:
```python
create_wiki_page(
repo="org/repo",
title="RFC-Index",
content="""# RFC Index
## Approved
RFCs ready for implementation in upcoming sprints.
| RFC | Title | Champion | Created |
|-----|-------|----------|---------|
## In Review
RFCs currently being evaluated.
| RFC | Title | Author | Created |
|-----|-------|--------|---------|
## Draft
RFCs in early development.
| RFC | Title | Author | Created |
|-----|-------|--------|---------|
## Implementing
RFCs currently being implemented.
| RFC | Title | Sprint | Started |
|-----|-------|--------|---------|
## Implemented
Completed RFCs.
| RFC | Title | Completed | Release |
|-----|-------|-----------|---------|
## Rejected
RFCs that were declined.
| RFC | Title | Reason | Date |
|-----|-------|--------|------|
## Stale
Inactive RFCs (no updates >90 days).
| RFC | Title | Last Updated |
|-----|-------|--------------|
"""
)
```
---
## Updating RFC-Index
When RFC status changes:
1. Fetch current RFC-Index content
2. Parse sections by status header
3. Remove RFC entry from old section (if present)
4. Add RFC entry to new section
5. Update wiki page
**Example status change (Draft → Review):**
1. Remove from "## Draft" section
2. Add to "## In Review" section
---
## Integration Points
| Component | How It Uses RFC System |
|-----------|------------------------|
| `/rfc create` | Creates RFC page + updates RFC-Index |
| `/rfc list` | Reads and displays RFC-Index |
| `/rfc review` | Transitions Draft -> Review |
| `/rfc approve` | Transitions Review -> Approved |
| `/rfc reject` | Transitions Review/Draft -> Rejected |
| `/sprint-plan` | Detects Approved RFCs, transitions to Implementing |
| `/sprint-close` | Transitions Implementing -> Implemented |
| `clarity-assist` | Suggests `/rfc create` for feature ideas |

View File

@@ -84,15 +84,17 @@ get_milestone(repo="org/repo", milestone_id=17)
### If Approval Missing
```
⚠️ SPRINT APPROVAL NOT FOUND (Warning)
🔴 SPRINT APPROVAL NOT FOUND — BLOCKED
Sprint 17 milestone does not contain an approval record.
Execution cannot proceed without approval.
Recommended: Run /sprint-plan first to:
Required: Run /sprint-plan first to:
1. Review the sprint scope
2. Document the approved execution plan
2. Get explicit approval for execution
Proceeding anyway - consider adding approval for audit trail.
To override (emergency only): /sprint-start --force
This bypasses the approval gate and logs a warning to the milestone.
```
### If Approval Found
@@ -134,3 +136,16 @@ Request re-approval when:
- Scope expansion needed (new files, new branches)
- Dependencies change significantly
- Timeline changes require scope adjustment
---
## Force Override
The `--force` flag bypasses the approval gate for emergency situations.
When `--force` is used:
1. Log a warning comment on the milestone: "⚠️ Sprint started without approval via --force on [date]"
2. Proceed with execution
3. The sprint close will flag this as an audit concern
**Do NOT use --force** as standard practice. If you find yourself using it regularly, the planning workflow needs adjustment.

View File

@@ -0,0 +1,104 @@
---
name: sprint-lifecycle
description: Sprint lifecycle state machine using milestone labels
---
# Sprint Lifecycle
## Purpose
Defines the valid sprint lifecycle states and transitions, enforced via labels on the sprint milestone. Each projman command checks the current state before executing and updates it on completion.
## When to Use
- **All sprint commands**: Check state on entry, update on exit
- **Sprint status**: Display current lifecycle state
---
## State Machine
```
idle -> Sprint/Planning -> Sprint/Executing -> Sprint/Reviewing -> idle
(sprint-plan) (sprint-start) (review) (sprint-close)
```
## State Labels
| Label | Set By | Meaning |
|-------|--------|---------|
| *(no Sprint/* label)* | `/sprint-close` or initial state | Idle - no active sprint phase |
| `Sprint/Planning` | `/sprint-plan` | Planning in progress |
| `Sprint/Executing` | `/sprint-start` | Execution in progress |
| `Sprint/Reviewing` | `/review` | Code review in progress |
**Rule:** Only ONE `Sprint/*` label may exist on a milestone at a time. Setting a new one removes the previous one.
---
## State Transition Rules
| Command | Expected State | Sets State | On Wrong State |
|---------|---------------|------------|----------------|
| `/sprint-plan` | idle (no Sprint/* label) | `Sprint/Planning` | Warn: "Sprint is in [state]. Run `/sprint-close` first or use `--force` to re-plan." Allow with `--force`. |
| `/sprint-start` | `Sprint/Planning` | `Sprint/Executing` | Warn: "Expected Sprint/Planning state but found [state]. Run `/sprint-plan` first or use `--force`." Allow with `--force`. |
| `/review` | `Sprint/Executing` | `Sprint/Reviewing` | Warn: "Expected Sprint/Executing state but found [state]." Allow with `--force`. |
| `/sprint-close` | `Sprint/Reviewing` | Remove all Sprint/* labels (idle) | Warn: "Expected Sprint/Reviewing state but found [state]. Run `/review` first or use `--force`." Allow with `--force`. |
| `/sprint-status` | Any | No change (read-only) | Display current state in output. |
---
## Checking State (Protocol)
At command entry, before any other work:
1. Fetch the active milestone using `get_milestone`
2. Check milestone description for `**Sprint State:**` line
3. Compare against expected state for this command
4. If mismatch: display warning with guidance, STOP unless `--force` provided
5. If match: proceed and update state after command completes its primary work
**Implementation:** Use milestone description metadata. Add/update a line:
```
**Sprint State:** Sprint/Executing
```
This avoids needing actual Gitea labels on milestones (which may not be supported). Parse this line to check state, update it to set state.
---
## Setting State
After command completes successfully:
1. Fetch current milestone description
2. If `**Sprint State:**` line exists, replace it
3. If not, append it to the end of the description
4. Update milestone via `update_milestone`
**Format:** `**Sprint State:** <state>` where state is one of:
- `Sprint/Planning`
- `Sprint/Executing`
- `Sprint/Reviewing`
- (empty/removed for idle)
---
## Displaying State
In `/sprint-status` output, include:
```
Sprint Phase: Executing (since 2026-02-01)
```
Parse the milestone description for the `**Sprint State:**` line and display it prominently.
---
## Edge Cases
- **No active milestone**: State is implicitly `idle`
- **Multiple milestones**: Use the open/active milestone. If multiple open, use the most recent.
- **Milestone has no state line**: Treat as `idle`
- **`--force` used**: Log to milestone: "Warning: Lifecycle state override: [command] forced from [actual] state on [date]"

View File

@@ -0,0 +1,101 @@
---
name: visual-output
description: Standard visual formatting for projman commands and agents
---
# Visual Output Standards
## Purpose
Single source of truth for all projman visual headers, progress blocks, and verdict formats. All agents and commands reference this skill instead of defining their own templates.
---
## Plugin Header (Double-Line)
Projman uses the double-line box drawing header style with emoji phase indicators.
### Agent Headers
```
+----------------------------------------------------------------------+
| PROJMAN |
| [Phase Emoji] [PHASE NAME] |
| [Context Line] |
+----------------------------------------------------------------------+
```
### Phase Registry
| Agent | Phase Emoji | Phase Name | Context |
|-------|-------------|------------|---------|
| Planner | Target | PLANNING | Sprint Name or Goal |
| Orchestrator | Lightning | EXECUTION | Sprint Name |
| Executor | Wrench | IMPLEMENTING | Issue Title |
| Code Reviewer | Magnifier | REVIEW | Sprint Name |
### Command Headers (Non-Agent)
For commands that don't invoke a specific agent phase:
| Command | Phase Emoji | Phase Name |
|---------|-------------|------------|
| `/sprint-status` | Chart | STATUS |
| `/setup` | Gear | SETUP |
| `/debug` | Bug | DEBUG |
| `/labels-sync` | Label | LABELS |
| `/suggest-version` | Package | VERSION |
| `/proposal-status` | Clipboard | PROPOSALS |
| `/test` | Flask | TEST |
| `/rfc` | Document | RFC [Sub-Command] |
---
## Progress Block
Used by orchestrator during sprint execution:
```
+-- Sprint Progress -------------------------------------------------------+
| [Sprint Name] |
| [Progress bar] XX% complete |
| Done: X Active: X Pending: X |
+--------------------------------------------------------------------------+
```
---
## Sprint Close Summary
```
+----------------------------------------------------------------------+
| PROJMAN |
| Finish Flag CLOSING |
| [Sprint Name] |
+----------------------------------------------------------------------+
```
---
## Gate Verdict Format
For domain gate results displayed by orchestrator:
```
+-- Domain Gate: [Viz/Data] -----------------------------------------------+
| Status: PASS / FAIL |
| [Details if FAIL] |
+--------------------------------------------------------------------------+
```
---
## Status Indicators
| Indicator | Meaning |
|-----------|---------|
| Check | Complete / Pass |
| X | Failed / Blocked |
| Hourglass | In progress |
| Empty box | Pending / Not started |
| Warning | Warning |

View File

@@ -0,0 +1,288 @@
---
agent: design-reviewer
description: Reviews code for design system compliance using viz-platform MCP tools
triggers:
- /design-review command
- /design-gate command
- projman orchestrator domain gate
---
# Design Reviewer Agent
You are a strict design system compliance auditor. Your role is to review code for proper use of Dash Mantine Components, theme tokens, and accessibility standards.
## Visual Output Requirements
**MANDATORY: Display header at start of every response.**
```
+----------------------------------------------------------------------+
| VIZ-PLATFORM - Design Reviewer |
| [Target Path] |
+----------------------------------------------------------------------+
```
## Trigger Conditions
Activate this agent when:
- User runs `/design-review <path>`
- User runs `/design-gate <path>`
- Projman orchestrator requests design domain gate check
- Code review includes DMC/Dash components
## Skills to Load
- skills/design-system-audit.md
## Available MCP Tools
| Tool | Purpose |
|------|---------|
| `validate_component` | Check DMC component configurations for invalid props |
| `get_component_props` | Retrieve expected props for a component |
| `list_components` | Cross-reference components against DMC registry |
| `theme_validate` | Validate theme configuration |
| `accessibility_validate_colors` | Verify color contrast meets WCAG standards |
| `accessibility_validate_theme` | Full theme accessibility audit |
## Operating Modes
### Review Mode (default)
Triggered by `/design-review <path>`
**Characteristics:**
- Produces detailed report with all findings
- Groups findings by severity (FAIL/WARN/INFO)
- Includes actionable recommendations with code fixes
- Does NOT block - informational only
- Shows theme compliance percentage
### Gate Mode
Triggered by `/design-gate <path>` or projman orchestrator domain gate
**Characteristics:**
- Binary PASS/FAIL output
- Only reports FAIL-level issues
- Returns exit status for automation integration
- Blocks completion on FAIL
- Compact output for CI/CD pipelines
## Audit Workflow
### 1. Receive Target Path
Accept file or directory path from command invocation.
### 2. Scan for DMC Usage
Find relevant files:
```python
# Look for files with DMC imports
import dash_mantine_components as dmc
# Look for component instantiations
dmc.Button(...)
dmc.Card(...)
```
### 3. Component Validation
For each DMC component found:
1. Extract component name and props from code
2. Call `list_components` to verify component exists in registry
3. Call `get_component_props` to get valid prop schema
4. Compare used props against schema
5. **FAIL**: Invalid props, unknown components
6. **WARN**: Deprecated patterns, React-style props
### 4. Theme Compliance Check
Detect hardcoded values that should use theme tokens:
| Pattern | Issue | Recommendation |
|---------|-------|----------------|
| `color="#228be6"` | Hardcoded color | Use `color="blue"` or theme token |
| `color="rgb(34, 139, 230)"` | Hardcoded RGB | Use theme color reference |
| `style={"padding": "16px"}` | Hardcoded size | Use `p="md"` prop |
| `style={"fontSize": "14px"}` | Hardcoded font | Use `size="sm"` prop |
### 5. Accessibility Validation
Check accessibility compliance:
1. Call `accessibility_validate_colors` on detected color pairs
2. Check color contrast ratios (min 4.5:1 for AA)
3. Verify interactive components have accessible labels
4. Flag missing aria-labels on buttons/links
### 6. Generate Report
Output format depends on operating mode.
## Report Formats
### Gate Mode Output
**PASS:**
```
DESIGN GATE: PASS
No blocking design system violations found.
```
**FAIL:**
```
DESIGN GATE: FAIL
Blocking Issues (2):
1. app/pages/home.py:45 - Invalid prop 'onclick' on dmc.Button
Fix: Use 'n_clicks' for click handling
2. app/components/nav.py:12 - Component 'dmc.Navbar' not found
Fix: Use 'dmc.AppShell.Navbar' (DMC v0.14+)
Run /design-review for full audit report.
```
### Review Mode Output
```
+----------------------------------------------------------------------+
| VIZ-PLATFORM - Design Review Report |
| /path/to/project |
+----------------------------------------------------------------------+
Files Scanned: 8
Components Analyzed: 34
Theme Compliance: 78%
## FAIL - Must Fix (2)
### app/pages/home.py:45
**Invalid prop on dmc.Button**
- Found: `onclick=handle_click`
- Valid props: n_clicks, disabled, loading, ...
- Fix: `n_clicks` triggers callback, not `onclick`
### app/components/nav.py:12
**Component not in registry**
- Found: `dmc.Navbar`
- Status: Removed in DMC v0.14
- Fix: Use `dmc.AppShell.Navbar` instead
## WARN - Should Fix (3)
### app/pages/home.py:23
**Hardcoded color**
- Found: `color="#228be6"`
- Recommendation: Use `theme.colors.blue[6]` or `color="blue"`
### app/components/card.py:56
**Hardcoded spacing**
- Found: `style={"padding": "16px"}`
- Recommendation: Use `p="md"` prop instead
### app/layouts/header.py:18
**Low color contrast**
- Foreground: #888888, Background: #ffffff
- Contrast ratio: 3.5:1 (below AA standard of 4.5:1)
- Recommendation: Darken text to #757575 for 4.6:1 ratio
## INFO - Suggestions (2)
### app/components/card.py:8
**Consider more specific component**
- Found: `dmc.Box` used as card container
- Suggestion: `dmc.Paper` provides card semantics and shadow
### app/pages/dashboard.py:92
**Missing aria-label**
- Found: `dmc.ActionIcon` without accessible label
- Suggestion: Add `aria-label="Close"` for screen readers
## Summary
| Severity | Count | Action |
|----------|-------|--------|
| FAIL | 2 | Must fix before merge |
| WARN | 3 | Address in this PR or follow-up |
| INFO | 2 | Optional improvements |
Gate Status: FAIL (2 blocking issues)
```
## Severity Definitions
| Level | Criteria | Action Required |
|-------|----------|-----------------|
| **FAIL** | Invalid props, unknown components, breaking changes | Must fix before merge |
| **WARN** | Hardcoded values, deprecated patterns, contrast issues | Should fix |
| **INFO** | Suboptimal patterns, missing optional attributes | Consider for improvement |
## Common Violations
### FAIL-Level Issues
| Issue | Pattern | Fix |
|-------|---------|-----|
| Invalid prop | `onclick=handler` | Use `n_clicks` + callback |
| Unknown component | `dmc.Navbar` | Use `dmc.AppShell.Navbar` |
| Wrong prop type | `size=12` (int) | Use `size="lg"` (string) |
| Invalid enum value | `variant="primary"` | Use `variant="filled"` |
### WARN-Level Issues
| Issue | Pattern | Fix |
|-------|---------|-----|
| Hardcoded color | `color="#hex"` | Use theme color name |
| Hardcoded size | `padding="16px"` | Use spacing prop |
| Low contrast | ratio < 4.5:1 | Adjust colors |
| React prop pattern | `className` | Use Dash equivalents |
### INFO-Level Issues
| Issue | Pattern | Suggestion |
|-------|---------|------------|
| Generic container | `dmc.Box` for cards | Use `dmc.Paper` |
| Missing aria-label | Interactive without label | Add accessible name |
| Inline styles | `style={}` overuse | Use component props |
## Error Handling
| Error | Response |
|-------|----------|
| MCP server unavailable | Report error, suggest checking viz-platform MCP setup |
| No DMC files found | "No Dash Mantine Components detected in target path" |
| Invalid path | "Path not found: {path}" |
| Empty directory | "No Python files found in {path}" |
## Integration with Projman
When called as a domain gate by projman orchestrator:
1. Receive path from orchestrator
2. Run audit in gate mode
3. Return structured result:
```json
{
"gate": "design",
"status": "PASS|FAIL",
"blocking_count": 0,
"summary": "No violations found"
}
```
4. Orchestrator decides whether to proceed based on gate status
## Example Interactions
**User**: `/design-review src/pages/`
**Agent**:
1. Scans all .py files in src/pages/
2. Identifies DMC component usage
3. Validates each component with MCP tools
4. Checks theme token usage
5. Runs accessibility validation
6. Returns full review report
**User**: `/design-gate src/`
**Agent**:
1. Scans all .py files
2. Identifies FAIL-level issues only
3. Returns PASS if clean, FAIL with blocking issues if not
4. Compact output for pipeline integration

View File

@@ -0,0 +1,94 @@
---
description: Design system compliance gate (pass/fail) for sprint execution
gate_contract: v1
arguments:
- name: path
description: File or directory to validate
required: true
---
# /design-gate
Binary pass/fail validation for design system compliance. Used by projman orchestrator during sprint execution to gate issue completion.
## Usage
```
/design-gate <path>
```
**Examples:**
```
/design-gate ./app/pages/dashboard.py
/design-gate ./app/components/
```
## What It Does
1. **Activates** the `design-reviewer` agent in gate mode
2. **Loads** the `skills/design-system-audit.md` skill
3. **Scans** target path for DMC usage
4. **Checks only for FAIL-level violations:**
- Invalid component props
- Non-existent components
- Missing required props
- Deprecated components
5. **Returns binary result:**
- `PASS` - No blocking violations found
- `FAIL` - One or more blocking violations
## Output
### On PASS
```
DESIGN GATE: PASS
No blocking design system violations found.
```
### On FAIL
```
DESIGN GATE: FAIL
Blocking Issues (2):
1. app/pages/home.py:45 - Invalid prop 'onclick' on dmc.Button
Fix: Use 'n_clicks' for click handling
2. app/components/nav.py:12 - Component 'dmc.Navbar' not found
Fix: Use 'dmc.AppShell.Navbar' (DMC v0.14+)
Run /design-review for full audit report.
```
## Integration with projman
This command is automatically invoked by the projman orchestrator when:
1. An issue has the `Domain/Viz` label
2. The orchestrator is about to mark the issue as complete
3. The orchestrator passes the path of changed files
**Gate behavior:**
- PASS → Issue can be marked complete
- FAIL → Issue stays open, blocker comment added
## Differences from /design-review
| Aspect | /design-gate | /design-review |
|--------|--------------|----------------|
| Output | Binary PASS/FAIL | Detailed report |
| Severity | FAIL only | FAIL + WARN + INFO |
| Purpose | Automation gate | Human review |
| Verbosity | Minimal | Comprehensive |
## When to Use
- **Automated pipelines**: CI/CD design system checks
- **Sprint execution**: Automatic quality gates
- **Quick validation**: Fast pass/fail without full report
For detailed findings, use `/design-review` instead.
## Requirements
- viz-platform MCP server must be running
- Target path must exist

View File

@@ -0,0 +1,70 @@
---
description: Audit codebase for design system compliance
arguments:
- name: path
description: File or directory to audit
required: true
---
# /design-review
Scans target path for Dash Mantine Components usage and validates against design system standards.
## Usage
```
/design-review <path>
```
**Examples:**
```
/design-review ./app/pages/
/design-review ./app/components/dashboard.py
/design-review .
```
## What It Does
1. **Activates** the `design-reviewer` agent in review mode
2. **Loads** the `skills/design-system-audit.md` skill
3. **Scans** target path for:
- Python files with DMC imports
- Component instantiations and their props
- Style dictionaries and color values
- Accessibility attributes
4. **Validates** against:
- DMC component registry (valid components and props)
- Theme token usage (no hardcoded colors/sizes)
- Accessibility standards (contrast, ARIA labels)
5. **Produces** detailed report grouped by severity
## Output
Generates a comprehensive audit report with:
- **FAIL**: Invalid props, deprecated components, missing required props
- **WARN**: Hardcoded colors/sizes, missing accessibility attributes
- **INFO**: Optimization suggestions, consistency recommendations
Each finding includes:
- File path and line number
- Description of the issue
- Recommended fix
## When to Use
- **Before PR review**: Catch design system violations early
- **On existing codebases**: Audit for compliance gaps
- **During refactoring**: Ensure changes maintain compliance
- **Learning**: Understand design system best practices
## Related Commands
- `/design-gate` - Binary pass/fail for sprint execution (no detailed report)
- `/component` - Inspect individual DMC component props
- `/theme` - Check active theme configuration
## Requirements
- viz-platform MCP server must be running
- Target path must contain Python files with DMC usage

View File

@@ -1,3 +1,3 @@
{
"hooks": []
"hooks": {}
}

View File

@@ -0,0 +1,280 @@
---
name: design-system-audit
description: Design system compliance rules and violation patterns for viz-platform audits
---
# Design System Audit
## Purpose
Defines what to check, how to classify violations, and common patterns for design system compliance auditing of Dash Mantine Components (DMC) code.
---
## What to Check
### 1. Component Prop Validity
| Check | Tool | Severity |
|-------|------|----------|
| Invalid prop names (typos) | `validate_component` | FAIL |
| Invalid prop values | `validate_component` | FAIL |
| Missing required props | `validate_component` | FAIL |
| Deprecated props | `get_component_props` | WARN |
| Unknown props | `validate_component` | WARN |
### 2. Theme Token Usage
| Check | Detection | Severity |
|-------|-----------|----------|
| Hardcoded hex colors | Regex `#[0-9a-fA-F]{3,6}` | WARN |
| Hardcoded RGB/RGBA | Regex `rgb\(` | WARN |
| Hardcoded font sizes | Regex `fontSize=\d+` | WARN |
| Hardcoded spacing | Regex `margin=\d+|padding=\d+` | INFO |
| Missing theme provider | AST analysis | FAIL |
**Allowed exceptions:**
- Colors in theme definition files
- Test/fixture files
- Comments and documentation
### 3. Accessibility Compliance
| Check | Tool | Severity |
|-------|------|----------|
| Color contrast ratio < 4.5:1 (AA) | `accessibility_validate_colors` | WARN |
| Color contrast ratio < 3:1 (large text) | `accessibility_validate_colors` | WARN |
| Missing aria-label on interactive | Manual scan | WARN |
| Color-only information | `accessibility_validate_theme` | WARN |
| Focus indicator missing | Manual scan | INFO |
### 4. Responsive Design
| Check | Detection | Severity |
|-------|-----------|----------|
| Fixed pixel widths > 600px | Regex `width=\d{3,}` | INFO |
| Missing breakpoint handling | No `visibleFrom`/`hiddenFrom` | INFO |
| Non-responsive layout | Fixed Grid columns | INFO |
---
## Common Violations
### FAIL-Level Violations
```python
# Invalid prop name (typo)
dmc.Button(colour="blue") # Should be 'color'
# Invalid enum value
dmc.Button(size="large") # Should be 'lg'
# Missing required prop
dmc.Select(data=[...]) # Missing 'id' for callbacks
# Invalid component name
dmc.Buttons(...) # Should be 'Button'
# Wrong case
dmc.Button(fullwidth=True) # Should be 'fullWidth'
# React patterns in Dash
dmc.Button(onClick=fn) # Should use 'id' + callback
```
### WARN-Level Violations
```python
# Hardcoded colors
dmc.Text(color="#ff0000") # Use theme token
dmc.Button(style={"color": "red"}) # Use theme token
# Hardcoded font size
dmc.Text(style={"fontSize": "14px"}) # Use 'size' prop
# Poor contrast
dmc.Text(color="gray") # Check contrast ratio
# Inline styles for colors
dmc.Container(style={"backgroundColor": "#f0f0f0"})
# Deprecated patterns
dmc.Button(variant="subtle") # Check if still supported
```
### INFO-Level Violations
```python
# Fixed widths
dmc.Container(w=800) # Consider responsive
# Missing responsive handling
dmc.Grid.Col(span=6) # Consider span={{ base: 12, md: 6 }}
# Optimization opportunity
dmc.Stack([dmc.Text(...) for _ in range(100)]) # Consider virtualization
```
---
## Severity Classification
| Level | Icon | Meaning | Action |
|-------|------|---------|--------|
| **FAIL** | Red circle | Blocking issue, will cause runtime error | Must fix before completion |
| **WARN** | Orange circle | Quality issue, violates best practices | Should fix, may be waived |
| **INFO** | Yellow circle | Suggestion for improvement | Consider for future |
### Severity Decision Tree
```
Is it invalid syntax/props?
YES -> FAIL
NO -> Does it violate accessibility standards?
YES -> WARN
NO -> Does it use hardcoded styles?
YES -> WARN
NO -> Is it a best practice suggestion?
YES -> INFO
NO -> Not a violation
```
---
## Scanning Strategy
### File Types to Scan
| Extension | Priority | Check For |
|-----------|----------|-----------|
| `*.py` | High | DMC component usage |
| `*.dash.py` | High | Layout definitions |
| `theme*.py` | High | Theme configuration |
| `layout*.py` | High | Layout structure |
| `components/*.py` | High | Custom components |
| `callbacks/*.py` | Medium | Component references |
### Scan Process
1. **Find relevant files**
```
glob: **/*.py
filter: Contains 'dmc.' or 'dash_mantine_components'
```
2. **Extract component usages**
- Parse Python AST
- Find all `dmc.*` calls
- Extract component name and kwargs
3. **Validate each component**
- Call `validate_component(name, props)`
- Record violations with file:line reference
4. **Scan for patterns**
- Hardcoded colors (regex)
- Inline styles (AST)
- Fixed dimensions (regex)
5. **Run accessibility checks**
- Extract color combinations
- Call `accessibility_validate_colors`
---
## Report Template
```
Design System Audit Report
==========================
Path: <scanned-path>
Files Scanned: N
Timestamp: YYYY-MM-DD HH:MM:SS
Summary
-------
FAIL: N blocking violations
WARN: N quality warnings
INFO: N suggestions
Findings
--------
FAIL Violations (must fix)
--------------------------
[file.py:42] Invalid prop 'colour' on Button
Found: colour="blue"
Expected: color="blue"
Docs: https://mantine.dev/core/button
[file.py:58] Invalid size value on Text
Found: size="huge"
Expected: One of ['xs', 'sm', 'md', 'lg', 'xl']
WARN Violations (should fix)
----------------------------
[theme.py:15] Hardcoded color detected
Found: color="#ff0000"
Suggestion: Use theme color token (e.g., color="red")
[layout.py:23] Low contrast ratio (3.2:1)
Found: Text on background
Required: 4.5:1 for WCAG AA
Suggestion: Darken text or lighten background
INFO Suggestions
----------------
[dashboard.py:100] Consider responsive breakpoints
Found: span=6 (fixed)
Suggestion: span={{ base: 12, md: 6 }}
Files Scanned
-------------
- src/components/button.py (3 components)
- src/layouts/main.py (8 components)
- src/theme.py (1 theme config)
Gate Result: PASS | FAIL
```
---
## Integration with MCP Tools
### Required Tools
| Tool | Purpose | When Used |
|------|---------|-----------|
| `validate_component` | Check component props | Every component found |
| `get_component_props` | Get expected props | When suggesting fixes |
| `list_components` | Verify component exists | Unknown component names |
| `theme_validate` | Validate theme config | Theme files |
| `accessibility_validate_colors` | Check contrast | Color combinations |
| `accessibility_validate_theme` | Full a11y audit | Theme files |
### Tool Call Pattern
```
For each Python file:
For each dmc.Component(...) found:
result = validate_component(
component_name="Component",
props={extracted_props}
)
if result.errors:
record FAIL violation
if result.warnings:
record WARN violation
```
---
## Skip Patterns
Do not flag violations in:
- `**/tests/**` - Test files may have intentional violations
- `**/__pycache__/**` - Compiled files
- `**/fixtures/**` - Test fixtures
- Files with `# noqa: design-audit` comment
- Theme definition files (colors are expected there)

View File

@@ -278,7 +278,7 @@ print_report() {
# --- Main ---
main() {
echo "=============================================="
echo " Leo Claude Marketplace Setup (v5.1.0)"
echo " Leo Claude Marketplace Setup (v5.7.1)"
echo "=============================================="
echo ""