personal-projects/leo-claude-mktplace
Template
0
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(marketplace): hook migration, projman commands, optimizations [BREAKING]

Browse Source 
Remove all SessionStart and PostToolUse hooks across the marketplace,
retaining only PreToolUse safety hooks and UserPromptSubmit quality hooks.
Add /project and /adr command families, /hygiene check, /cv status.
Create 7 new projman skills for project lifecycle management.
Remove /pm-debug, /suggest-version, /proposal-status commands.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Leo Miranda
2026-02-06 12:28:06 -05:00
parent 442ed63b4c
commit 9ba2e660d3
60 changed files with 1061 additions and 1828 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
plugins/projman/agents/orchestrator.md
View File

@@ -28,8 +28,6 @@ You are the **Orchestrator Agent** - a concise, action-oriented coordinator who
- skills/lessons-learned.md
- skills/git-workflow.md
- skills/progress-tracking.md
- skills/wiki-conventions.md
- skills/domain-consultation.md
**CRITICAL: Read each skill file exactly ONCE. Do NOT re-read skill files between MCP API calls. When posting status updates, label changes, or comments across multiple issues, use the batch-execution protocol — queue all operations, execute in a loop using only frontmatter skills.**
@@ -76,25 +74,6 @@ 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.
@@ -110,7 +89,7 @@ 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
- Append row on every task dispatch, completion, and failure
- On sprint resume: add "Resumed" row with checkpoint context
- Log is posted as comments, one `add_comment` per event
@@ -122,7 +101,7 @@ Execute `skills/progress-tracking.md` (Sprint Dispatch Log section):
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
7. **ALWAYS use wiki-conventions** - Load `skills/wiki-conventions.md` when updating wiki pages at sprint close
## Your Mission

22
plugins/projman/agents/planner.md
View File

@@ -30,7 +30,6 @@ You are the **Planner Agent** - a methodical architect who thoroughly analyzes r
- skills/issue-conventions.md
- skills/planning-workflow.md
- skills/label-taxonomy/labels-reference.md
- skills/domain-consultation.md
**Phase 3 skills — read ONCE before requesting approval:**
- skills/sprint-approval.md
@@ -78,25 +77,10 @@ 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. 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
### 7. Issue Creation
Execute `skills/issue-conventions.md` - Use proper format with wiki references.
### 9. Request Approval
### 8. Request Approval
Execute `skills/sprint-approval.md` - Planning DOES NOT equal execution permission.
## Critical Reminders
@@ -108,7 +92,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
8. **ALWAYS use proper labels** - Apply relevant labels from the label taxonomy
## Your Mission

34
plugins/projman/commands/adr-create.md Normal file
View File

@@ -0,0 +1,34 @@
---
description: Create a new Architecture Decision Record wiki page
agent: planner
---
# /adr create
## Skills Required
- skills/adr-conventions.md — ADR template and naming
- skills/wiki-conventions.md — page naming and dependency headers
- skills/visual-output.md — output formatting
## Workflow
### Step 1: Allocate ADR Number
Search existing wiki pages for `ADR-NNNN` pattern. Allocate next sequential number.
### Step 2: Gather Context
Ask user for:
- Title (short, decision-focused)
- Context (what prompted this decision)
- Options considered (at least 2)
- Recommended option
### Step 3: Create Wiki Page
Create `ADR-NNNN: {Title}` per `skills/adr-conventions.md` template.
Set status to `Proposed`.
### Step 4: Update ADR Index
Update or create `ADR-Index` wiki page, adding the new ADR under "Proposed".
### Step 5: Confirm
Display the created ADR and its URL.

23
plugins/projman/commands/adr-list.md Normal file
View File

@@ -0,0 +1,23 @@
---
description: List all ADRs grouped by status
agent: planner
---
# /adr list
## Skills Required
- skills/adr-conventions.md — ADR lifecycle states
- skills/visual-output.md — output formatting
## Workflow
### Step 1: Read ADR Index
Load `ADR-Index` wiki page.
### Step 2: Display
Group ADRs by status (Accepted, Proposed, Superseded, Deprecated).
Show table with ID, Title, Date, Status.
### Optional Filter
`/adr list --status proposed` — show only proposed ADRs.

25
plugins/projman/commands/adr-supersede.md Normal file
View File

@@ -0,0 +1,25 @@
---
description: Mark an ADR as superseded by a newer ADR
agent: planner
---
# /adr supersede
## Skills Required
- skills/adr-conventions.md — ADR lifecycle
- skills/wiki-conventions.md — page naming
## Workflow
### Step 1: Validate
Verify both ADRs exist. The superseding ADR should be in `Accepted` or `Proposed` state.
### Step 2: Update Old ADR
Set status to `Superseded`. Add note: "Superseded by ADR-MMMM: {Title}".
### Step 3: Update New ADR
Add note: "Supersedes ADR-NNNN: {Title}".
### Step 4: Update ADR Index
Move old ADR to "Superseded" section.

25
plugins/projman/commands/adr-update.md Normal file
View File

@@ -0,0 +1,25 @@
---
description: Update an existing ADR's content or status
agent: planner
---
# /adr update
## Skills Required
- skills/adr-conventions.md — ADR template
- skills/wiki-conventions.md — page naming
## Workflow
### Step 1: Load ADR
Read `ADR-NNNN: {Title}` wiki page.
### Step 2: Apply Updates
Update content or status as specified. Valid status transitions:
- Proposed → Accepted
- Proposed → Deprecated
- Accepted → Deprecated
### Step 3: Update ADR Index
Move ADR to correct status section in `ADR-Index`.

23
plugins/projman/commands/adr.md Normal file
View File

@@ -0,0 +1,23 @@
---
description: Architecture Decision Records management
---
# /adr
## Sub-commands
| Sub-command | Description |
|-------------|-------------|
| `/adr create` | Create a new ADR wiki page |
| `/adr list` | List all ADRs by status |
| `/adr update` | Update an existing ADR |
| `/adr supersede` | Mark an ADR as superseded by a new one |
## Usage
```
/adr create "<title>"
/adr list [--status proposed|accepted|superseded|deprecated]
/adr update <ADR-NNNN> [--status accepted|deprecated]
/adr supersede <ADR-NNNN> --by <ADR-MMMM>
```

2
plugins/projman/commands/labels-sync.md
View File

@@ -36,6 +36,8 @@ Run `/labels-sync` when setting up the plugin or after taxonomy updates.
| Priority/* | Low, Medium, High, Critical |
| Complexity/* | Simple, Medium, Complex |
| Efforts/* | XS, S, M, L, XL |
| Epic/* | Database, API, Frontend, Auth, Infrastructure |
| RnD/* | Friction, Gap, Pattern, Automation |
## DO NOT

162
plugins/projman/commands/pm-debug.md
View File

@@ -1,162 +0,0 @@
---
description: Diagnose issues and create reports, or investigate existing diagnostic issues
---
# PM Debug
## Skills Required
- skills/mcp-tools-reference.md
- skills/lessons-learned.md
- skills/git-workflow.md
## Purpose
Unified debugging command for diagnostics and issue investigation.
## Invocation
```
/pm-debug # Ask which mode
/pm-debug report # Run diagnostics, create issue
/pm-debug review # Investigate existing issues
```
## Mode Selection
If no subcommand provided, ask user:
1. **Report** - Run MCP tool diagnostics and create issue in marketplace
2. **Review** - Investigate existing diagnostic issues and propose fixes
---
## Mode: Report
Create structured issues in the marketplace repository.
### Prerequisites
Project `.env` must have:
```env
PROJMAN_MARKETPLACE_REPO=personal-projects/leo-claude-mktplace
```
### Workflow
#### Step 0: Select Report Type
- **Automated** - Run MCP tool diagnostics and report failures
- **User-Reported** - Gather structured feedback about a problem
#### For User-Reported (Step 0.1)
Gather via AskUserQuestion:
1. Which plugin/command was affected
2. What was the goal
3. What type of problem (error, missing feature, unexpected behavior, docs)
4. Problem description
5. Expected behavior
6. Workaround (optional)
#### Steps 1-2: Context Gathering
1. Gather project context (git remote, branch, pwd)
2. Detect sprint context (active milestone)
3. Read marketplace config
#### Steps 3-4: Diagnostic Suite (Automated Only)
Run MCP tools with explicit `repo` parameter:
- `validate_repo_org`
- `get_labels`
- `list_issues`
- `list_milestones`
- `suggest_labels`
Categorize: Parameter Format, Authentication, Not Found, Network, Logic
#### Steps 5-6: Generate Labels and Issue
**Automated:** `Type/Bug`, `Source/Diagnostic`, `Agent/Claude` + suggested
**User-Reported:** Map problem type to labels
#### Step 7: Create Issue
**Use curl (not MCP)** - avoids branch protection issues
#### Step 8: Report to User
Show summary and link to created issue
### DO NOT (Report Mode)
- Attempt to fix anything - only report
- Create issues if all automated tests pass (unless user-reported)
- Use MCP tools to create issues in marketplace - always use curl
---
## Mode: Review
Investigate diagnostic issues and propose fixes with human approval.
### Workflow with Approval Gates
#### Steps 1-8: Investigation
1. Detect repository (git remote)
2. Fetch diagnostic issues: `list_issues(labels=["Source: Diagnostic"])`
3. Display issue list
4. User selects issue (AskUserQuestion)
5. Fetch full details: `get_issue(issue_number=...)`
6. Parse diagnostic report (failed tools, errors, hypothesis)
7. Map errors to files
8. Read relevant files - **MANDATORY before proposing fix**
#### Step 9: Investigation Summary
Present analysis to user.
**APPROVAL GATE 1:** "Does this analysis match your understanding?"
- STOP and wait for user response
#### Step 9.5: Search Lessons Learned
Search for related past fixes using `search_lessons`.
#### Step 10: Propose Fix
Present specific fix approach with changes and rationale.
**APPROVAL GATE 2:** "Proceed with this fix?"
- STOP and wait for user response
#### Steps 11-12: Implement
1. Create feature branch (`fix/issue-N-description`)
2. Make code changes
3. Run tests
4. Show diff to user
**APPROVAL GATE 3:** "Create PR with these changes?"
- STOP and wait for user response
#### Steps 13-15: Finalize
13. Commit and push
14. Create PR
15. After user verifies fix: Close issue (REQUIRED) and capture lesson
### Error-to-File Quick Reference
| Error Pattern | Check Files |
|---------------|-------------|
| "owner/repo format" | config.py, gitea_client.py |
| "404" + "orgs" | gitea_client.py |
| "401", "403" | config.py (token) |
| "No repository" | Command .md file |
### DO NOT (Review Mode)
- Skip reading relevant files
- Proceed past approval gates without confirmation
- Close issues until user confirms fix works
- Commit directly to development/main
---
## Visual Output
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ 🔧 DEBUG ║
║ [Mode: Report | Review] ║
╚══════════════════════════════════════════════════════════════════╝
```

41
plugins/projman/commands/project-close.md Normal file
View File

@@ -0,0 +1,41 @@
---
description: Close a completed project — retrospective, archive, lessons learned
agent: orchestrator
---
# /project close
## Purpose
Run project-level retrospective, capture lessons learned, and archive project artifacts.
## Prerequisites
- All sprints in roadmap are closed
- Project status is `Executing`
## Skills Required
- skills/project-charter.md — to update status
- skills/wiki-conventions.md — page naming
- skills/visual-output.md — output formatting
## Workflow
### Step 1: Verify Completion
Check that all sprints in `Roadmap: {Name}` are marked complete.
Check that all epic-labeled issues are closed.
### Step 2: Project Retrospective
Create a retrospective section in the project charter:
- What went well
- What didn't go well
- Key learnings
- Metrics: total sprints, total issues, duration
### Step 3: Archive
Update `Project: {Name}` status → `Closed`
Update `Risk-Register: {Name}` status → `Archived`
### Step 4: Final Report
Display project summary with key metrics.

52
plugins/projman/commands/project-initiation.md Normal file
View File

@@ -0,0 +1,52 @@
---
description: Discover, analyze, and charter a new project
agent: planner
---
# /project initiation
## Purpose
Analyze an existing codebase or system description, create a project charter, and decompose into epics.
## Skills Required
- skills/source-analysis.md — analysis framework
- skills/project-charter.md — charter template and naming
- skills/epic-conventions.md — epic decomposition rules
- skills/wiki-conventions.md — page naming and dependency headers
- skills/visual-output.md — output formatting
## Workflow
### Step 1: Source Analysis
If a source codebase path is provided, analyze it using `skills/source-analysis.md`:
- Identify tech stack, architecture, features, data model, quality state
- If no source provided (greenfield), skip to Step 2
### Step 2: Project Charter
Create wiki page `Project: {Name}` following `skills/project-charter.md`:
- Set status to `Initiating`
- Fill Vision, Scope (In/Out), Source Analysis Summary (if applicable)
- Leave Architecture Decisions, Epic Decomposition, Roadmap as placeholders
### Step 3: Epic Decomposition
Using analysis results, decompose project into epics per `skills/epic-conventions.md`:
- Create `Epic/*` labels if they don't exist (check with `list_labels`)
- Fill the Epic Decomposition table in the charter
### Step 4: Present and Confirm
Show the charter to the user. Wait for approval before proceeding to `/project plan`.
## Output
- Wiki page: `Project: {Name}`
- Labels: `Epic/*` labels created in Gitea
- State: `Initiating` — awaiting `/project plan`
## DO NOT
- Create sprint issues — that's `/sprint-plan`
- Create WBS or roadmap — that's `/project plan`
- Make architecture decisions — suggest ADRs via `/adr create`
- Skip user approval of the charter

52
plugins/projman/commands/project-plan.md Normal file
View File

@@ -0,0 +1,52 @@
---
description: Create WBS, risk register, and sprint roadmap for an initiated project
agent: planner
---
# /project plan
## Purpose
Take an approved project charter and create the planning artifacts: WBS, risk register, and sprint roadmap.
## Prerequisites
- Project charter exists (`Project: {Name}` wiki page with status `Initiating` or `Planning`)
- Epic decomposition complete in charter
## Skills Required
- skills/wbs.md — work breakdown structure
- skills/risk-register.md — risk identification and scoring
- skills/sprint-roadmap.md — sprint sequencing
- skills/project-charter.md — to update charter status
- skills/wiki-conventions.md — page naming and dependency headers
- skills/visual-output.md — output formatting
## Workflow
### Step 1: Load Charter
Read `Project: {Name}` wiki page. Verify epic decomposition is present.
### Step 2: Create WBS
Create wiki page `WBS: {Name}` per `skills/wbs.md`.
### Step 3: Create Risk Register
Create wiki page `Risk-Register: {Name}` per `skills/risk-register.md`.
### Step 4: Create Sprint Roadmap
Create wiki page `Roadmap: {Name}` per `skills/sprint-roadmap.md`.
### Step 5: Update Charter
Update `Project: {Name}` wiki page:
- Fill Architecture Decisions links (ADRs created so far)
- Link to WBS, Risk Register, Roadmap
- Change status: `Initiating` → `Planning`
### Step 6: Present and Confirm
Show all artifacts to user. Approval transitions to `Executing` (ready for first `/sprint-plan`).
## Output
- Wiki pages: `WBS: {Name}`, `Risk-Register: {Name}`, `Roadmap: {Name}`
- Updated: `Project: {Name}` status → Planning

47
plugins/projman/commands/project-status.md Normal file
View File

@@ -0,0 +1,47 @@
---
description: Full project hierarchy status view (absorbs /proposal-status)
agent: planner
---
# /project status
## Purpose
Display comprehensive project status including charter state, epic progress, risk summary, and sprint roadmap status. Absorbs the former `/proposal-status` functionality.
## Skills Required
- skills/project-charter.md — charter structure
- skills/visual-output.md — output formatting
## Workflow
### Step 1: Load Project Artifacts
Read wiki pages:
- `Project: {Name}` — charter and status
- `Roadmap: {Name}` — sprint sequence and completion
- `Risk-Register: {Name}` — open risks
- `WBS: {Name}` — work package completion
### Step 2: Aggregate Sprint Progress
For each sprint in the roadmap:
- Check milestone status (open/closed)
- Count issues by state (open/closed)
- Calculate completion percentage
### Step 3: Display Status
```
Project: {Name}
Status: Executing
Epics: 3/6 complete
Sprints: 4/8 closed
Open Risks: 2 (highest: R1 score 6)
Next Sprint: Sprint 5
```
### Step 4: Detail Sections
- Epic progress bars
- Top risks by score
- Upcoming sprint scope from roadmap
- ADR summary (accepted/proposed counts)

23
plugins/projman/commands/project.md Normal file
View File

@@ -0,0 +1,23 @@
---
description: Project lifecycle management — concept to MVP
---
# /project
## Sub-commands
| Sub-command | Description |
|-------------|-------------|
| `/project initiation` | Analyze source, create charter, decompose into epics |
| `/project plan` | Create WBS, risk register, sprint roadmap |
| `/project status` | Full project hierarchy view |
| `/project close` | Retrospective, lessons learned, archive |
## Usage
```
/project initiation <source-path-or-description>
/project plan <project-name>
/project status <project-name>
/project close <project-name>
```

49
plugins/projman/commands/proposal-status.md
View File

@@ -1,49 +0,0 @@
---
description: View proposal and implementation hierarchy with status tracking
---
# Proposal Status
## Skills Required
- skills/mcp-tools-reference.md
- skills/wiki-conventions.md
## Purpose
View status of all change proposals and their implementations in Gitea Wiki.
## Invocation
```
/proposal-status
/proposal-status --version V04.1.0
/proposal-status --status "In Progress"
```
## Workflow
1. **Fetch Wiki Pages** - Use `list_wiki_pages()` to get all pages
2. **Filter Proposals** - Match `Change V*: Proposal*` pattern
3. **Parse Structure** - Group implementations under parent proposals
4. **Extract Status** - Read page metadata (In Progress, Implemented, Abandoned)
5. **Fetch Linked Artifacts** - Find issues and lessons referencing each implementation
6. **Display Tree View** - Show hierarchy with status and links
## Status Definitions
| Status | Meaning |
|--------|---------|
| Pending | Proposal created, no implementation started |
| In Progress | At least one implementation is active |
| Implemented | All planned implementations complete |
| Abandoned | Proposal cancelled or superseded |
## Visual Output
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ Proposal Status ║
╚══════════════════════════════════════════════════════════════════╝
```

16
plugins/projman/commands/sprint-close.md
View File

@@ -10,11 +10,10 @@ agent: orchestrator
- skills/mcp-tools-reference.md
- skills/lessons-learned.md
- skills/wiki-conventions.md
- skills/rfc-workflow.md
- skills/rfc-workflow.md *(conditional — load only when sprint milestone metadata contains `**RFC:**` reference)*
- skills/progress-tracking.md
- skills/git-workflow.md
- skills/sprint-lifecycle.md
- skills/token-budget-report.md
## Purpose
@@ -35,10 +34,10 @@ Execute the sprint close workflow:
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. **Update RFC Status (if applicable)** - See RFC Update section below
7. **Update RFC Status (if applicable)** - Skip if sprint is not RFC-linked. Only load `rfc-workflow.md` and execute this step if the milestone description contains `**RFC:**`.
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
10. **Version Review** - Review CHANGELOG.md for version bump recommendation (manual)
11. **Git Operations** - Commit, merge, tag, clean up branches
12. **Close Milestone** - Update milestone state to closed
@@ -84,11 +83,6 @@ If the sprint was linked to an RFC:
╚══════════════════════════════════════════════════════════════════╝
```
## Final Step: Token Budget Report
## Token Usage Note
After displaying the closing summary and completing all workflow steps, generate a Token Budget Report per `skills/token-budget-report.md`.
- Phase: CLOSING
- List all skills that were loaded during this closing session
- Use the orchestrator agent's model (sonnet) for agent overhead
- Display the formatted report
Token usage is captured as a `## Token Usage` section in the lessons learned wiki page — no standalone report.

9
plugins/projman/commands/sprint-plan.md
View File

@@ -20,7 +20,6 @@ agent: planner
- skills/planning-workflow.md
- skills/label-taxonomy/labels-reference.md
- skills/sprint-lifecycle.md
- skills/token-budget-report.md
## Purpose
@@ -59,11 +58,3 @@ Execute the planning workflow as defined in `skills/planning-workflow.md`.
╚══════════════════════════════════════════════════════════════════╝
```
## Final Step: Token Budget Report
After displaying the planning summary and gaining sprint approval, generate a Token Budget Report per `skills/token-budget-report.md`.
- Phase: PLANNING
- List all skills that were loaded during this planning session
- Use the planner agent's model (sonnet) for agent overhead
- Display the formatted report

47
plugins/projman/commands/suggest-version.md
View File

@@ -1,47 +0,0 @@
---
description: Analyze CHANGELOG.md and suggest appropriate semantic version bump
---
# Suggest Version
## Purpose
Analyze CHANGELOG.md and suggest appropriate semantic version bump.
## Invocation
Run `/suggest-version` after updating CHANGELOG or before release.
## Workflow
1. **Read Current State**
- CHANGELOG.md for current version and [Unreleased] content
- marketplace.json for marketplace version
- Individual plugin versions
2. **Analyze [Unreleased] Section**
- Extract entries under Added, Changed, Fixed, Removed, Deprecated
- Categorize changes by impact
3. **Apply SemVer Rules**
| Change Type | Bump | Indicators |
|-------------|------|------------|
| MAJOR (X.0.0) | Breaking changes | Removed, "BREAKING:" in Changed |
| MINOR (x.Y.0) | New features | Added with new commands/plugins |
| PATCH (x.y.Z) | Bug fixes only | Fixed only |
4. **Output Recommendation**
- Current version
- Summary of changes
- Recommended bump with reason
- Release command
## Visual Output
```
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ Version Analysis ║
╚══════════════════════════════════════════════════════════════════╝
```

15
plugins/projman/hooks/hooks.json
View File

@@ -1,15 +0,0 @@
{
"hooks": {
"SessionStart": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/startup-check.sh"
}
]
}
]
}
}

85
plugins/projman/hooks/startup-check.sh
View File

@@ -1,85 +0,0 @@
#!/bin/bash
# projman startup check hook
# Checks for common issues AND suggests sprint planning proactively
# All output MUST have [projman] prefix
PREFIX="[projman]"
# Calculate paths
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(dirname "$(dirname "$(realpath "$0")")")}"
# Check git remote vs .env config (only if .env exists)
if [[ -f ".env" ]]; then
CONFIGURED_REPO=$(grep -E "^GITEA_REPO=" .env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
if [[ -n "$CONFIGURED_REPO" ]]; then
CURRENT_REMOTE=$(git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\/[^.]*\).*/\1/' || true)
if [[ -n "$CURRENT_REMOTE" && "$CONFIGURED_REPO" != "$CURRENT_REMOTE" ]]; then
echo "$PREFIX Git remote mismatch - run /project-sync"
exit 0
fi
fi
fi
# Check for open issues (suggests sprint planning)
# Only if .env exists with valid GITEA config
if [[ -f ".env" ]]; then
GITEA_API_URL=$(grep -E "^GITEA_API_URL=" ~/.config/claude/gitea.env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
GITEA_API_TOKEN=$(grep -E "^GITEA_API_TOKEN=" ~/.config/claude/gitea.env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
GITEA_REPO=$(grep -E "^GITEA_REPO=" .env 2>/dev/null | cut -d'=' -f2 | tr -d '"' || true)
if [[ -n "$GITEA_API_URL" && -n "$GITEA_API_TOKEN" && -n "$GITEA_REPO" ]]; then
# Quick check for open issues without milestone (unplanned work)
# Note: grep -c returns 0 on no match but exits non-zero, causing || to also fire
# Use subshell to ensure single value
OPEN_ISSUES=$(curl -s -m 5 \
-H "Authorization: token $GITEA_API_TOKEN" \
"${GITEA_API_URL}/repos/${GITEA_REPO}/issues?state=open&milestone=none&limit=1" 2>/dev/null | \
grep -c '"number"' 2>/dev/null) || OPEN_ISSUES=0
if [[ "$OPEN_ISSUES" -gt 0 ]]; then
# Count total unplanned issues
TOTAL_UNPLANNED=$(curl -s -m 5 \
-H "Authorization: token $GITEA_API_TOKEN" \
"${GITEA_API_URL}/repos/${GITEA_REPO}/issues?state=open&milestone=none" 2>/dev/null | \
grep -c '"number"' 2>/dev/null) || TOTAL_UNPLANNED="?"
echo "$PREFIX ${TOTAL_UNPLANNED} open issues without milestone - consider /sprint-plan"
fi
fi
fi
# ============================================================================
# Check version consistency across files (early drift detection)
# ============================================================================
# Versions must stay in sync across: README.md, marketplace.json, CHANGELOG.md
# Drift here causes confusion and release issues
if [[ -f "README.md" && -f ".claude-plugin/marketplace.json" && -f "CHANGELOG.md" ]]; then
VERSION_README=$(grep -oE "^# .* - v[0-9]+\.[0-9]+\.[0-9]+" README.md 2>/dev/null | grep -oE "[0-9]+\.[0-9]+\.[0-9]+" || echo "")
# Extract metadata.version specifically (appears after "metadata" in marketplace.json)
VERSION_MARKETPLACE=$(sed -n '/"metadata"/,/}/p' .claude-plugin/marketplace.json 2>/dev/null | grep -oE '"version"[[:space:]]*:[[:space:]]*"[0-9]+\.[0-9]+\.[0-9]+"' | head -1 | grep -oE "[0-9]+\.[0-9]+\.[0-9]+" || echo "")
VERSION_CHANGELOG=$(grep -oE "^## \[[0-9]+\.[0-9]+\.[0-9]+\]" CHANGELOG.md 2>/dev/null | head -1 | grep -oE "[0-9]+\.[0-9]+\.[0-9]+" || echo "")
if [[ -n "$VERSION_README" && -n "$VERSION_MARKETPLACE" && -n "$VERSION_CHANGELOG" ]]; then
if [[ "$VERSION_README" != "$VERSION_MARKETPLACE" ]] || [[ "$VERSION_README" != "$VERSION_CHANGELOG" ]]; then
echo "$PREFIX Version mismatch detected:"
echo "$PREFIX README.md: v$VERSION_README"
echo "$PREFIX marketplace.json: v$VERSION_MARKETPLACE"
echo "$PREFIX CHANGELOG.md: v$VERSION_CHANGELOG"
echo "$PREFIX Run /suggest-version to analyze and fix"
fi
fi
fi
# Check for CHANGELOG.md [Unreleased] content (version management)
if [[ -f "CHANGELOG.md" ]]; then
# Check if there's content under [Unreleased] that hasn't been released
UNRELEASED_CONTENT=$(sed -n '/## \[Unreleased\]/,/## \[/p' CHANGELOG.md 2>/dev/null | grep -E '^### (Added|Changed|Fixed|Removed|Deprecated)' | head -1 || true)
if [[ -n "$UNRELEASED_CONTENT" ]]; then
UNRELEASED_LINES=$(sed -n '/## \[Unreleased\]/,/## \[/p' CHANGELOG.md 2>/dev/null | grep -E '^- ' | wc -l | tr -d ' ')
if [[ "$UNRELEASED_LINES" -gt 0 ]]; then
echo "$PREFIX ${UNRELEASED_LINES} unreleased changes in CHANGELOG - consider version bump"
fi
fi
fi
exit 0

49
plugins/projman/skills/adr-conventions.md Normal file
View File

@@ -0,0 +1,49 @@
---
description: Architecture Decision Record conventions and wiki page template
---
# ADR Conventions
## Wiki Page Naming
Page name: `ADR-NNNN: {Title}` (e.g., `ADR-0001: Use PostgreSQL with Alembic`)
Sequential numbering. Allocate next available number.
## Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A or sprint where ADR was created
> **Issues:** Related issue numbers or N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Proposed | Accepted | Superseded | Deprecated
```
## ADR Template
1. **Context** — What is the issue motivating this decision?
2. **Decision** — What is the change being proposed/made?
3. **Consequences** — Positive, Negative, Neutral outcomes
4. **Alternatives Considered** — Table of options with pros, cons, verdict
5. **References** — Related ADRs, RFCs, external links
## Lifecycle
| State | Meaning |
|-------|---------|
| Proposed | Under discussion, not yet approved |
| Accepted | Approved and in effect |
| Superseded | Replaced by a newer ADR (link to replacement) |
| Deprecated | No longer relevant |
## ADR Index Page
Maintain an `ADR-Index` wiki page listing all ADRs grouped by status.
## Integration with Sprint Workflow
- ADRs created via `/adr create` during project initiation or planning
- ADR status checked during `/project status`
- Sprint planning can reference ADRs in issue descriptions

165
plugins/projman/skills/domain-consultation.md
View File

@@ -1,165 +0,0 @@
---
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`.

49
plugins/projman/skills/epic-conventions.md Normal file
View File

@@ -0,0 +1,49 @@
---
description: Epic decomposition and management conventions using Gitea labels and projects
---
# Epic Conventions
## What Is an Epic
An epic is a large body of work that spans multiple sprints. Epics are tracked as Gitea labels (`Epic/*`) and optionally as Gitea Project boards.
## Label Convention
Labels follow the pattern `Epic/{Name}`:
- `Epic/Database` — Schema design, migrations, seed data
- `Epic/API` — Backend endpoints, middleware, auth
- `Epic/Frontend` — UI components, routing, state management
- `Epic/Auth` — Authentication and authorization
- `Epic/Infrastructure` — CI/CD, deployment, monitoring
Epics are defined during `/project initiation` as part of the charter's Epic Decomposition table.
## Epic-to-Sprint Mapping
Each sprint focuses on one or more epics. The sprint milestone description references the active epics:
```
**Epics:** Epic/Database, Epic/API
**Project:** Driving School SaaS
```
## Wiki Cross-References
- Project Charter (`Project: {Name}`) contains the Epic Decomposition table
- Sprint Roadmap (`Roadmap: {Name}`) maps epics to sprint sequence
- WBS (`WBS: {Name}`) breaks epics into work packages
- Sprint Lessons (`Sprint-Lessons: Sprint-X`) reference which epics were active
## Issue-Epic Relationship
Every issue in an epic-aligned sprint gets the `Epic/*` label. This enables:
- Filtering all issues by epic across sprints
- Tracking epic completion percentage
- Epic velocity analysis in lessons learned
## DO NOT
- Create epics for single-sprint work — use regular labels
- Mix unrelated work under one epic label
- Skip epic labels during sprint planning — they're the traceability link

25
plugins/projman/skills/label-taxonomy/labels-reference.md
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:** 49 labels (31 organization + 18 repository)
**Current Taxonomy:** 58 labels (31 organization + 27 repository)
## Organization Labels (31)
@@ -123,6 +123,29 @@ Cross-plugin integration labels for domain-specific validation gates.
- Also applied when: `Component/Database` or `Component/Data` label is present
- Example: "Add census demographic data pipeline"
### Epic (5 labels)
Project-level epic labels for multi-sprint work tracking.
| Label | Color | Description |
|-------|-------|-------------|
| `Epic/Database` | `#0E8A16` | Database schema, migrations, seed data |
| `Epic/API` | `#1D76DB` | Backend endpoints, middleware, auth |
| `Epic/Frontend` | `#E99695` | UI components, routing, state management |
| `Epic/Auth` | `#D93F0B` | Authentication and authorization |
| `Epic/Infrastructure` | `#BFD4F2` | CI/CD, deployment, monitoring |
### R&D (4 labels)
Research and development tracking labels for lessons learned.
| Label | Color | Description |
|-------|-------|-------------|
| `RnD/Friction` | `#FBCA04` | Workflow friction points |
| `RnD/Gap` | `#B60205` | Capability gaps discovered |
| `RnD/Pattern` | `#0075CA` | Reusable patterns identified |
| `RnD/Automation` | `#5319E7` | Automation opportunities |
## Label Suggestion Logic
When suggesting labels for issues, consider the following patterns:

46
plugins/projman/skills/project-charter.md Normal file
View File

@@ -0,0 +1,46 @@
---
description: Template and conventions for project charter wiki pages
---
# Project Charter Conventions
## Wiki Page Naming
Page name: `Project: {Name}` (e.g., `Project: Driving School SaaS`)
## Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level)
> **Issues:** N/A (created during planning)
> **Parent:** N/A (top-level artifact)
> **Created:** YYYY-MM-DD
> **Status:** Initiating | Planning | Executing | Closing | Closed
```
## Charter Structure
The wiki page follows this structure:
1. **Vision** — One paragraph describing what this project achieves and why
2. **Scope** — In Scope (explicit list) and Out of Scope (prevents scope creep)
3. **Source Analysis Summary** — Key findings from `/project initiation` (if applicable)
4. **Architecture Decisions** — Links to ADR wiki pages
5. **Epic Decomposition** — Table of epics with description, priority, estimated sprints
6. **Sprint Roadmap** — Link to `Roadmap: {Name}` wiki page
7. **Risk Register** — Link to `Risk-Register: {Name}` wiki page
8. **Stakeholders** — Table of roles, persons, responsibilities
9. **Success Criteria** — Measurable outcomes that define "done"
## Lifecycle States
| State | Meaning | Transition |
|-------|---------|------------|
| Initiating | Discovery and chartering in progress | Planning (charter approved) |
| Planning | WBS, risk, roadmap being created | Executing (first sprint starts) |
| Executing | Sprints are running | Closing (all epics complete) |
| Closing | Retrospective and archival | Closed |
| Closed | Archived | Terminal |
State is tracked in the charter's `Status` field.

58
plugins/projman/skills/risk-register.md Normal file
View File

@@ -0,0 +1,58 @@
---
description: Risk register template and management conventions for project planning
---
# Risk Register
## Wiki Page
Page name: `Risk-Register: {Name}` (e.g., `Risk-Register: Driving School SaaS`)
### Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level, reviewed per sprint)
> **Issues:** N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Active | Archived
```
## Risk Register Template
| ID | Risk | Probability | Impact | Score | Mitigation | Owner | Status |
|----|------|------------|--------|-------|------------|-------|--------|
| R1 | Example risk description | Medium | High | 6 | Mitigation strategy | Dev | Open |
## Scoring
| Probability | Value |
|-------------|-------|
| Low | 1 |
| Medium | 2 |
| High | 3 |
| Impact | Value |
|--------|-------|
| Low | 1 |
| Medium | 2 |
| High | 3 |
**Score** = Probability x Impact (1-9 range)
## Risk Lifecycle
| Status | Meaning |
|--------|---------|
| Open | Active risk, mitigation planned |
| Monitoring | Risk identified but not yet actionable |
| Mitigated | Mitigation applied, risk reduced |
| Occurred | Risk materialized — track resolution |
| Closed | No longer relevant |
## Integration
- `/project plan` creates initial risk register
- `/project status` summarizes open risk count and top-3 by score
- `/sprint-close` updates risk statuses in lessons learned

51
plugins/projman/skills/source-analysis.md Normal file
View File

@@ -0,0 +1,51 @@
---
description: Framework for analyzing existing codebases and systems as input to project initiation
---
# Source Analysis
## Purpose
Structured approach to analyzing an existing codebase or system before project planning. Used by `/project initiation` to understand what exists before defining what to build.
## Analysis Framework
### 1. Codebase Discovery
- Technology stack identification (languages, frameworks, databases, ORMs)
- Architecture pattern recognition (monolith, microservices, modular monolith)
- Dependency inventory (package managers, versions, lock files)
- Environment configuration (env files, config patterns, secrets management)
### 2. Feature Inventory
- User-facing features (pages, flows, API endpoints)
- Admin/internal features (dashboards, tools, scripts)
- Integration points (third-party APIs, external services)
- Background processes (cron jobs, workers, queues)
### 3. Data Model Analysis
- Database schemas and relationships
- Data migration history
- Seed data patterns
- Data validation rules
### 4. Quality Assessment
- Test coverage (types, frameworks, CI integration)
- Documentation state (README, inline, API docs)
- Code quality indicators (linting, formatting, type safety)
- Known technical debt (TODO/FIXME/HACK comments)
### 5. Deployment Assessment
- Current hosting/infrastructure
- CI/CD pipeline state
- Environment parity (dev/staging/prod)
- Monitoring and logging
## Output Format
The analysis produces a structured report stored as a wiki page (`Project: {Name}`) that feeds into the project charter and epic decomposition.
## DO NOT
- Make assumptions about missing components — document gaps explicitly
- Evaluate "good vs bad" — document facts for decision-making
- Propose solutions during analysis — that's the planning phase

41
plugins/projman/skills/sprint-roadmap.md Normal file
View File

@@ -0,0 +1,41 @@
---
description: Sprint roadmap template for sequencing epics across multiple sprints
---
# Sprint Roadmap
## Wiki Page
Page name: `Roadmap: {Name}` (e.g., `Roadmap: Driving School SaaS`)
### Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level)
> **Issues:** N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Draft | Active | Complete
```
## Roadmap Template
| Sprint | Epics | Focus | Dependencies | Status |
|--------|-------|-------|-------------|--------|
| Sprint 1 | Epic/Database | Schema design, initial migrations | None | Planned |
| Sprint 2 | Epic/Database, Epic/API | Seed data, API scaffolding | Sprint 1 | Planned |
## Milestones
| Milestone | Target Sprint | Criteria |
|-----------|--------------|----------|
| Backend MVP | Sprint 3 | All core API endpoints passing tests |
| Integration Complete | Sprint 6 | End-to-end flows working |
## Integration
- `/project plan` creates the initial roadmap from epic decomposition + dependency analysis
- `/sprint-plan` references the roadmap to determine sprint scope
- `/sprint-close` updates sprint status in roadmap
- `/project status` shows roadmap progress

7
plugins/projman/skills/visual-output.md
View File

@@ -42,12 +42,13 @@ For commands that don't invoke a specific agent phase:
|---------|-------------|------------|
| `/sprint-status` | 📊 Chart | STATUS |
| `/pm-setup` | ⚙️ Gear | SETUP |
| `/pm-debug` | 🐛 Bug | DEBUG |
| `/labels-sync` | 🏷️ Label | LABELS |
| `/suggest-version` | 📦 Package | VERSION |
| `/proposal-status` | 📋 Clipboard | PROPOSALS |
| `/pm-test` | 🧪 Flask | TEST |
| `/rfc` | 📄 Document | RFC [Sub-Command] |
| `/project` | 📋 Clipboard | PROJECT [Sub-Command] |
| `/adr` | 📐 Ruler | ADR [Sub-Command] |
| `/hygiene check` | 🧹 Broom | HYGIENE |
| `/cv status` | ✅ Check | CV STATUS |
---

45
plugins/projman/skills/wbs.md Normal file
View File

@@ -0,0 +1,45 @@
---
description: Work Breakdown Structure skill for decomposing projects and sprints into implementable work packages
---
# Work Breakdown Structure (WBS)
## Purpose
Bridges project-level epics and sprint-level issues. Used by `/project plan` to create the initial decomposition and by `/sprint-plan` to refine sprint scope.
## Wiki Page
Page name: `WBS: {Name}` (e.g., `WBS: Driving School SaaS`)
### Dependency Header
```
> **Project:** {Name}
> **Sprint:** N/A (project-level, refined per sprint)
> **Issues:** N/A
> **Parent:** Project: {Name}
> **Created:** YYYY-MM-DD
> **Status:** Draft | Active | Complete
```
## Decomposition Rules
1. **Level 1:** Epics (from project charter)
2. **Level 2:** Work packages (groupings within an epic — typically 1 sprint each)
3. **Level 3:** Tasks (become Gitea issues — must be S or M size per task-sizing.md)
## Sprint Refinement
During `/sprint-plan`, the planner:
1. Loads the WBS
2. Identifies the next unstarted work packages
3. Creates issues from Level 3 tasks
4. Marks consumed work packages as "Sprint-X" in the WBS
## Integration
- `/project plan` creates the initial WBS from epic decomposition
- `/sprint-plan` consumes WBS work packages to create sprint issues
- `/sprint-close` updates WBS with completion status
- `/project status` aggregates WBS progress for project-level view

148
plugins/projman/skills/wiki-conventions.md
View File

@@ -1,73 +1,98 @@
---
name: wiki-conventions
description: Proposal and implementation page format and naming conventions
description: Wiki page naming conventions and dependency headers (Decision #30)
---
# Wiki Conventions
## Purpose
Defines the naming and structure for wiki proposal and implementation pages.
Defines naming conventions, dependency headers, and structure for all wiki pages in the project management workflow.
## When to Use
- **Planner agent**: When creating wiki pages during planning
- **Orchestrator agent**: When updating status at sprint close
- **Commands**: `/sprint-plan`, `/sprint-close`, `/proposal-status`
- **Commands**: `/sprint-plan`, `/sprint-close`, `/project initiation`, `/project plan`, `/project status`, `/project close`, `/adr create`
---
## Page Naming
## Page Naming Pattern
| Page Type | Naming Convention |
|-----------|-------------------|
| Proposal | `Change VXX.X.X: Proposal` |
| Implementation | `Change VXX.X.X: Proposal (Implementation N)` |
All wiki pages follow: `{Type}-{ID}: {Title}` or `{Type}: {Title}`
**Examples:**
- `Change V4.1.0: Proposal`
- `Change V4.1.0: Proposal (Implementation 1)`
- `Change V4.1.0: Proposal (Implementation 2)`
| Type | ID Format | Example |
|------|-----------|---------|
| RFC | NNNN (sequential) | `RFC-0001: OAuth2 Provider Support` |
| ADR | NNNN (sequential) | `ADR-0001: Use PostgreSQL with Alembic` |
| Project | Name | `Project: Driving School SaaS` |
| WBS | Name | `WBS: Driving School SaaS` |
| Risk-Register | Name | `Risk-Register: Driving School SaaS` |
| Roadmap | Name | `Roadmap: Driving School SaaS` |
| Sprint-Lessons | Sprint ID | `Sprint-Lessons: Sprint-3` |
| ADR-Index | — | `ADR-Index` |
| Change Proposal | Version | `Change VXX.X.X: Proposal` |
| Implementation | Version + N | `Change VXX.X.X: Proposal (Implementation N)` |
## Dependency Header
Every wiki page MUST include this header block:
```markdown
> **Project:** [project name or N/A]
> **Sprint:** [sprint milestone or N/A]
> **Issues:** #12, #15, #18 [or N/A]
> **Parent:** [parent wiki page or N/A]
> **Created:** YYYY-MM-DD
> **Status:** [lifecycle state]
```
## Hierarchy
- `Project: {Name}` is the root
- `WBS: {Name}` (parent: Project)
- `Risk-Register: {Name}` (parent: Project)
- `Roadmap: {Name}` (parent: Project)
- `ADR-NNNN: {Title}` (parent: Project)
- `Sprint-Lessons: Sprint-X` (parent: Project)
---
## Proposal Page Template
## Change Proposal Pages (Legacy Format)
### Proposal Page Template
```markdown
> **Type:** Change Proposal
> **Version:** V04.1.0
> **Version:** VXX.X.X
> **Plugin:** projman
> **Status:** In Progress
> **Date:** 2026-01-26
> **Date:** YYYY-MM-DD
# Feature Title
[Content migrated from input source or created from discussion]
## Implementations
- [Implementation 1](link) - Sprint 17 - In Progress
- [Implementation 1](link) - Sprint N - In Progress
```
---
## Implementation Page Template
### Implementation Page Template
```markdown
> **Type:** Change Proposal Implementation
> **Version:** V04.1.0
> **Version:** VXX.X.X
> **Status:** In Progress
> **Date:** 2026-01-26
> **Date:** YYYY-MM-DD
> **Origin:** [Proposal](wiki-link)
> **Sprint:** Sprint 17
> **Sprint:** Sprint N
# Implementation Details
[Technical details, scope, approach]
## Issues
- #45: JWT token generation
- #46: Login endpoint
- #47: Auth tests
- #45: Issue description
- #46: Issue description
```
---
@@ -85,71 +110,26 @@ Defines the naming and structure for wiki proposal and implementation pages.
## Completion Update (Sprint Close)
On sprint close, update implementation page:
On sprint close, update implementation page status to `Implemented` and add a `## Completion Summary` section with lessons learned link.
```markdown
> **Type:** Change Proposal Implementation
> **Version:** V04.1.0
> **Status:** Implemented ✅
> **Date:** 2026-01-26
> **Completed:** 2026-01-28
> **Origin:** [Proposal](wiki-link)
> **Sprint:** Sprint 17
# Implementation Details
[Original content...]
## Completion Summary
- All planned issues completed
- Lessons learned: [Link to lesson]
```
On proposal page, update implementation entries with completion status.
---
## Proposal Status Update
## R&D Notes Section
When all implementations complete, update proposal:
Lessons learned pages include a `## R&D Notes` section at the bottom for capturing:
```markdown
> **Type:** Change Proposal
> **Version:** V04.1.0
> **Status:** Implemented ✅
> **Date:** 2026-01-26
# Feature Title
[Original content...]
## Implementations
- [Implementation 1](link) - Sprint 17 - ✅ Completed
```
| Label | Description | Action |
|-------|-------------|--------|
| `RnD/Friction` | Workflow friction points | Consider improvements |
| `RnD/Gap` | Capability gaps discovered | Prioritize new tools |
| `RnD/Pattern` | Reusable patterns identified | Document for reuse |
| `RnD/Automation` | Automation opportunities | Add to backlog |
---
## Creating Pages
## Enforcement
**Create proposal:**
```python
create_wiki_page(
repo="org/repo",
title="Change V4.1.0: Proposal",
content="[proposal template content]"
)
```
**Create implementation:**
```python
create_wiki_page(
repo="org/repo",
title="Change V4.1.0: Proposal (Implementation 1)",
content="[implementation template content]"
)
```
**Update implementation on close:**
```python
update_wiki_page(
repo="org/repo",
page_name="Change-V4.1.0:-Proposal-(Implementation-1)",
content="[updated content with completion status]"
)
```
- Commands creating wiki pages use these templates from their respective skills
- Malformed pages are flagged, not auto-corrected