feat: complete Phase 2 & 3 - projman plugin with commands and agents
Implemented complete projman plugin foundation for sprint planning and
project management with Gitea and Wiki.js integration.
Phase 2: Commands (5 total)
- /sprint-plan: AI-guided planning with planner agent
- /sprint-start: Sprint execution with orchestrator agent
- /sprint-status: Quick progress check
- /sprint-close: Lessons learned capture
- /labels-sync: Label taxonomy synchronization
Phase 3: Agents (3 total)
- Planner: Thoughtful sprint planning, asks questions, searches lessons
- Orchestrator: Concise coordination, lean prompts, tracks progress
- Executor: Precise implementation, follows specs, applies lessons
Components:
- plugin.json: Valid manifest with 5 commands, 3 agents, 1 skill
- .mcp.json: MCP configuration for Gitea + Wiki.js servers
- Label taxonomy skill with dynamic 44-label system
- README.md: Complete usage guide (409 lines)
- CONFIGURATION.md: Step-by-step setup instructions
- Local test marketplace for validation
Features:
- Branch-aware security (development/staging/production)
- Dynamic label taxonomy (fetched from Gitea, never hardcoded)
- Lessons learned integration (search at start, capture at close)
- Hybrid configuration (system + project level)
- Security best practices (${CLAUDE_PLUGIN_ROOT}, path safety)
Total: 13 plugin files, ~3,719 lines of documentation
Testing: docs/TEST_01_PROJMAN.md provides comprehensive testing plan
Ready for Phase 5: Testing & Validation
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
129
projman/commands/sprint-plan.md
Normal file
129
projman/commands/sprint-plan.md
Normal file
@@ -0,0 +1,129 @@
|
||||
---
|
||||
name: sprint-plan
|
||||
description: Start sprint planning with AI-guided architecture analysis and issue creation
|
||||
agent: planner
|
||||
---
|
||||
|
||||
# Sprint Planning
|
||||
|
||||
You are initiating sprint planning. The planner agent will guide you through architecture analysis, ask clarifying questions, and help create well-structured Gitea issues with appropriate labels.
|
||||
|
||||
## Branch Detection
|
||||
|
||||
**CRITICAL:** Before proceeding, check the current git branch:
|
||||
|
||||
```bash
|
||||
git branch --show-current
|
||||
```
|
||||
|
||||
**Branch Requirements:**
|
||||
- ✅ **Development branches** (`development`, `develop`, `feat/*`, `dev/*`): Full planning capabilities
|
||||
- ⚠️ **Staging branches** (`staging`, `stage/*`): Can create issues to document needed changes, but cannot modify code
|
||||
- ❌ **Production branches** (`main`, `master`, `prod/*`): READ-ONLY - no planning allowed
|
||||
|
||||
If you are on a production or staging branch, you MUST stop and ask the user to switch to a development branch.
|
||||
|
||||
## Planning Workflow
|
||||
|
||||
The planner agent will:
|
||||
|
||||
1. **Understand Sprint Goals**
|
||||
- Ask clarifying questions about the sprint objectives
|
||||
- Understand scope, priorities, and constraints
|
||||
- Never rush - take time to understand requirements fully
|
||||
|
||||
2. **Search Relevant Lessons Learned**
|
||||
- Use the `search_lessons` MCP tool to find past experiences
|
||||
- Search by keywords and tags relevant to the sprint work
|
||||
- Review patterns and preventable mistakes from previous sprints
|
||||
|
||||
3. **Architecture Analysis**
|
||||
- Think through technical approach and edge cases
|
||||
- Identify architectural decisions needed
|
||||
- Consider dependencies and integration points
|
||||
- Review existing codebase architecture
|
||||
|
||||
4. **Create Gitea Issues**
|
||||
- Use the `create_issue` MCP tool for each planned task
|
||||
- Apply appropriate labels using `suggest_labels` tool
|
||||
- Structure issues with clear titles and descriptions
|
||||
- Include acceptance criteria and technical notes
|
||||
|
||||
5. **Generate Planning Document**
|
||||
- Summarize architectural decisions
|
||||
- List created issues with labels
|
||||
- Document assumptions and open questions
|
||||
- Provide sprint overview
|
||||
|
||||
## MCP Tools Available
|
||||
|
||||
**Gitea Tools:**
|
||||
- `list_issues` - Review existing issues
|
||||
- `get_labels` - Fetch current label taxonomy
|
||||
- `suggest_labels` - Get intelligent label suggestions based on context
|
||||
- `create_issue` - Create new issue with labels
|
||||
|
||||
**Wiki.js Tools:**
|
||||
- `search_lessons` - Search lessons learned from previous sprints
|
||||
- `search_pages` - Search project documentation
|
||||
- `get_page` - Fetch specific documentation page
|
||||
|
||||
## Label Taxonomy
|
||||
|
||||
The system uses a dynamic 44-label taxonomy (28 org + 16 repo). Always use the `suggest_labels` tool to get appropriate labels based on the issue context.
|
||||
|
||||
**Key Label Categories:**
|
||||
- **Type/***: Bug, Feature, Refactor, Documentation, Test, Chore
|
||||
- **Priority/***: Low, Medium, High, Critical
|
||||
- **Complexity/***: Simple, Medium, Complex
|
||||
- **Efforts/***: XS, S, M, L, XL
|
||||
- **Component/***: Backend, Frontend, API, Database, Auth, Deploy, Testing, Docs, Infra
|
||||
- **Tech/***: Python, JavaScript, Docker, PostgreSQL, Redis, Vue, FastAPI
|
||||
|
||||
## Planner Personality
|
||||
|
||||
The planner agent is thoughtful and methodical:
|
||||
- Asks clarifying questions before making assumptions
|
||||
- Thinks through edge cases and architectural implications
|
||||
- Never rushes planning - quality over speed
|
||||
- References lessons learned proactively
|
||||
- Suggests appropriate labels based on context
|
||||
- Creates well-structured, detailed issues
|
||||
|
||||
## Example Planning Session
|
||||
|
||||
```
|
||||
User: I want to plan a sprint for user authentication
|
||||
Planner: Great! Let me ask a few questions to understand the scope:
|
||||
|
||||
1. What authentication method are you planning? (JWT, OAuth, session-based?)
|
||||
2. Are there any specific security requirements or compliance needs?
|
||||
3. Should this integrate with existing user management?
|
||||
4. What's the priority level for this sprint?
|
||||
|
||||
Let me also search for relevant lessons learned about authentication...
|
||||
|
||||
[Uses search_lessons to find past authentication work]
|
||||
|
||||
Based on previous experience, I found these relevant lessons:
|
||||
- Sprint 12: JWT token expiration handling edge cases
|
||||
- Sprint 8: OAuth integration pitfalls with third-party providers
|
||||
|
||||
Now, let me analyze the architecture...
|
||||
|
||||
[Creates issues with appropriate labels]
|
||||
|
||||
Created 5 issues for the authentication sprint:
|
||||
- Issue #45: Implement JWT token generation [Type/Feature, Priority/High, Component/Auth, Tech/Python]
|
||||
- Issue #46: Build user login endpoint [Type/Feature, Priority/High, Component/API, Tech/FastAPI]
|
||||
...
|
||||
```
|
||||
|
||||
## Getting Started
|
||||
|
||||
Invoke the planner agent by providing your sprint goals. The agent will guide you through the planning process.
|
||||
|
||||
**Example:**
|
||||
> "I want to plan a sprint for extracting the Intuit Engine service from the monolith"
|
||||
|
||||
The planner will then ask clarifying questions and guide you through the complete planning workflow.
|
||||
Reference in New Issue
Block a user