feat(marketplace): hook migration, projman commands, optimizations [BREAKING]
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:
34
plugins/projman/commands/adr-create.md
Normal file
34
plugins/projman/commands/adr-create.md
Normal 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
23
plugins/projman/commands/adr-list.md
Normal 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
25
plugins/projman/commands/adr-supersede.md
Normal 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
25
plugins/projman/commands/adr-update.md
Normal 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
23
plugins/projman/commands/adr.md
Normal 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>
|
||||
```
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
41
plugins/projman/commands/project-close.md
Normal 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
52
plugins/projman/commands/project-initiation.md
Normal 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
52
plugins/projman/commands/project-plan.md
Normal 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
47
plugins/projman/commands/project-status.md
Normal 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
23
plugins/projman/commands/project.md
Normal 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>
|
||||
```
|
||||
@@ -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 ║
|
||||
╚══════════════════════════════════════════════════════════════════╝
|
||||
```
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 ║
|
||||
╚══════════════════════════════════════════════════════════════════╝
|
||||
```
|
||||
Reference in New Issue
Block a user