refactor(projman): extract skills and consolidate commands
Major refactoring of projman plugin architecture: Skills Extraction (17 new files): - Extracted reusable knowledge from commands and agents into skills/ - branch-security, dependency-management, git-workflow, input-detection - issue-conventions, lessons-learned, mcp-tools-reference, planning-workflow - progress-tracking, repo-validation, review-checklist, runaway-detection - setup-workflows, sprint-approval, task-sizing, test-standards, wiki-conventions Command Consolidation (17 → 12 commands): - /setup: consolidates initial-setup, project-init, project-sync (--full/--quick/--sync) - /debug: consolidates debug-report, debug-review (report/review modes) - /test: consolidates test-check, test-gen (run/gen modes) - /sprint-status: absorbs sprint-diagram via --diagram flag Architecture Cleanup: - Remove plugin-level mcp-servers/ symlinks (6 plugins) - Remove plugin README.md files (12 files, ~2000 lines) - Update all documentation to reflect new command structure - Fix documentation drift in CONFIGURATION.md, COMMANDS-CHEATSHEET.md Commands are now thin dispatchers (~20-50 lines) that reference skills. Agents reference skills for domain knowledge instead of inline content. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
136
plugins/projman/skills/sprint-approval.md
Normal file
136
plugins/projman/skills/sprint-approval.md
Normal file
@@ -0,0 +1,136 @@
|
||||
---
|
||||
name: sprint-approval
|
||||
description: Approval gate logic for sprint execution
|
||||
---
|
||||
|
||||
# Sprint Approval
|
||||
|
||||
## Purpose
|
||||
|
||||
Defines the approval workflow that gates sprint execution.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Planner agent**: After creating issues, request approval
|
||||
- **Orchestrator agent**: Before execution, verify approval exists
|
||||
- **Commands**: `/sprint-plan`, `/sprint-start`
|
||||
|
||||
---
|
||||
|
||||
## Core Principle
|
||||
|
||||
**Planning DOES NOT equal execution permission.**
|
||||
|
||||
Sprint approval is a mandatory checkpoint between planning and execution.
|
||||
|
||||
---
|
||||
|
||||
## Requesting Approval (Planner)
|
||||
|
||||
After creating issues, present approval request:
|
||||
|
||||
```
|
||||
Sprint 17 Planning Complete
|
||||
===========================
|
||||
|
||||
Created Issues:
|
||||
- #45: [Sprint 17] feat: JWT token generation
|
||||
- #46: [Sprint 17] feat: Login endpoint
|
||||
- #47: [Sprint 17] test: Auth tests
|
||||
|
||||
Execution Scope:
|
||||
- Branches: feat/45-*, feat/46-*, feat/47-*
|
||||
- Files: auth/*, api/routes/auth.py, tests/test_auth*
|
||||
- Dependencies: PyJWT, python-jose
|
||||
|
||||
⚠️ APPROVAL REQUIRED
|
||||
|
||||
Do you approve this sprint for execution?
|
||||
This grants permission for agents to:
|
||||
- Create and modify files in the listed scope
|
||||
- Create branches with the listed prefixes
|
||||
- Install listed dependencies
|
||||
|
||||
Type "approve sprint 17" to authorize execution.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recording Approval
|
||||
|
||||
On user approval, update milestone description:
|
||||
|
||||
```markdown
|
||||
## Sprint Approval
|
||||
**Approved:** 2026-01-28 14:30
|
||||
**Approver:** User
|
||||
**Scope:**
|
||||
- Branches: feat/45-*, feat/46-*, feat/47-*
|
||||
- Files: auth/*, api/routes/auth.py, tests/test_auth*
|
||||
- Dependencies: PyJWT, python-jose
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verifying Approval (Orchestrator)
|
||||
|
||||
Before execution, check milestone for approval:
|
||||
|
||||
```python
|
||||
get_milestone(repo="org/repo", milestone_id=17)
|
||||
# Check description for "## Sprint Approval" section
|
||||
```
|
||||
|
||||
### If Approval Missing
|
||||
|
||||
```
|
||||
⚠️ SPRINT APPROVAL NOT FOUND (Warning)
|
||||
|
||||
Sprint 17 milestone does not contain an approval record.
|
||||
|
||||
Recommended: Run /sprint-plan first to:
|
||||
1. Review the sprint scope
|
||||
2. Document the approved execution plan
|
||||
|
||||
Proceeding anyway - consider adding approval for audit trail.
|
||||
```
|
||||
|
||||
### If Approval Found
|
||||
|
||||
```
|
||||
✓ Sprint Approval Verified
|
||||
Approved: 2026-01-28 14:30
|
||||
Scope:
|
||||
Branches: feat/45-*, feat/46-*, feat/47-*
|
||||
Files: auth/*, api/routes/auth.py, tests/test_auth*
|
||||
|
||||
Proceeding with execution within approved scope...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Scope Enforcement
|
||||
|
||||
When approval exists, agents SHOULD operate within approved scope:
|
||||
|
||||
```
|
||||
Approved scope:
|
||||
Branches: feat/45-*, feat/46-*
|
||||
Files: auth/*, tests/test_auth*
|
||||
|
||||
Task #48 wants to create: feat/48-api-docs
|
||||
→ NOT in approved scope!
|
||||
→ STOP and ask user to approve expanded scope
|
||||
```
|
||||
|
||||
**Operations outside scope should trigger re-approval via `/sprint-plan`.**
|
||||
|
||||
---
|
||||
|
||||
## Re-Approval Scenarios
|
||||
|
||||
Request re-approval when:
|
||||
- New tasks discovered during execution
|
||||
- Scope expansion needed (new files, new branches)
|
||||
- Dependencies change significantly
|
||||
- Timeline changes require scope adjustment
|
||||
Reference in New Issue
Block a user