> Reusable workflow extracted from davide-project-manager expertise.
Executes comprehensive project planning and delivery using proven methodologies (Agile, Waterfall, Hybrid). Use this when initiating new projects, planning sprints, managing risks, tracking budgets, or reporting status to stakeholders.
/plugin marketplace add Roberdan/MyConvergio/plugin install roberdan-myconvergio@Roberdan/MyConvergioThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Reusable workflow extracted from davide-project-manager expertise.
Execute comprehensive project planning, tracking, and delivery using proven methodologies (Agile, Waterfall, Hybrid) to ensure on-time, on-budget delivery while maintaining quality and stakeholder satisfaction.
Project Initiation
Work Breakdown Structure (WBS)
Schedule Development
Resource Planning
Risk Management
Budget Management
Execution & Monitoring
Stakeholder Communication
Quality Management
Project Closure
# Sprint {N} Planning - {Date Range}
## Sprint Goal
[One-sentence goal for this sprint]
## Capacity
- Team size: {count} developers
- Sprint duration: {weeks} weeks
- Available capacity: {hours} hours
- Planned capacity: {hours} hours (80% of available)
## Stories Selected
| Story ID | Title | Story Points | Assignee | Dependencies |
|----------|-------|--------------|----------|--------------|
| US-123 | ... | 5 | Alice | None |
| US-124 | ... | 3 | Bob | US-123 |
## Definition of Done
- [ ] Code complete and reviewed
- [ ] Unit tests written and passing (>80% coverage)
- [ ] Integration tests passing
- [ ] Documentation updated
- [ ] Deployed to staging
- [ ] Product owner acceptance
## Risks
- **Risk**: API dependency not ready
- Mitigation: Mock API for development, parallel track with API team
## Sprint Ceremonies
- Daily Standup: 9:00 AM daily
- Sprint Review: {date} at {time}
- Sprint Retrospective: {date} at {time}
Risk Score = Likelihood (1-5) Ć Impact (1-5)
| Likelihood | Score | Definition |
|---|---|---|
| Very Unlikely | 1 | <10% chance |
| Unlikely | 2 | 10-30% chance |
| Possible | 3 | 30-50% chance |
| Likely | 4 | 50-70% chance |
| Very Likely | 5 | >70% chance |
| Impact | Score | Definition |
|---|---|---|
| Negligible | 1 | <1 day delay, <$1K cost |
| Minor | 2 | 1-3 days delay, <$5K cost |
| Moderate | 3 | 1 week delay, <$20K cost |
| Major | 4 | 2-4 weeks delay, <$50K cost |
| Severe | 5 | >1 month delay, >$50K cost |
# Project Status Report - {Date}
## Executive Summary
**Status**: š¢ On Track / š” At Risk / š“ Critical
**Key Highlights**:
- {Major accomplishment this period}
- {Important milestone reached}
## Progress This Period
- Completed: {count} tasks ({X}% of sprint)
- In Progress: {count} tasks
- Blocked: {count} tasks
## Milestones
| Milestone | Planned Date | Forecast Date | Status |
|-----------|--------------|---------------|--------|
| Alpha | 2025-02-01 | 2025-02-01 | ā
Complete |
| Beta | 2025-03-15 | 2025-03-20 | š” 5-day slip |
| GA | 2025-04-30 | 2025-04-30 | š¢ On track |
## Budget Status
- Budget: ${total}K
- Spent: ${spent}K ({percent}%)
- Forecast: ${forecast}K
- Status: š¢ Within budget / š” Trending over
## Top Risks & Issues
1. **š“ Critical API dependency delayed**
- Impact: 2-week slip to Beta
- Mitigation: Working with API team, created mock for parallel development
2. **š” Key developer on leave next sprint**
- Impact: Reduced capacity
- Mitigation: Cross-training backup developer this sprint
## Key Decisions Needed
1. {Decision required with deadline}
2. {Approval needed for budget increase}
## Next Period Focus
- {Key objective 1}
- {Key objective 2}
| Factor | Agile | Waterfall |
|---|---|---|
| Requirements stability | ā Changing frequently | ā Well-defined, stable |
| Project size | ā Small to medium | ā Large, complex |
| Team experience | ā Experienced, self-organizing | ā Structured, junior-friendly |
| Customer availability | ā High involvement | ā Limited involvement |
| Risk tolerance | ā Iterative, adaptive | ā Need predictability |
| Regulatory | ā ļø Needs documentation | ā Heavy documentation |
Input: Plan new e-commerce feature launch - payment integration
Workflow Execution:
1. Initiation:
- Goal: Integrate Stripe payment in checkout flow
- Stakeholders: Product, Engineering, Finance, Legal
- Success: Process payments with <1% failure rate
- Timeline: 8 weeks
- Budget: $80K
2. WBS:
- Phase 1: Design (1 week)
- Payment flow UX design
- Security architecture review
- Phase 2: Development (4 weeks)
- Backend API integration
- Frontend checkout UI
- Payment validation
- Phase 3: Testing (2 weeks)
- Unit and integration tests
- PCI-DSS compliance validation
- Phase 4: Deployment (1 week)
- Staged rollout to 10%/50%/100%
3. Schedule:
- Critical path: Backend API ā Frontend ā Testing
- Milestones: Design review (week 1), Dev complete (week 5)
- Sprint cadence: 2-week sprints
4. Resources:
- 2 backend devs, 1 frontend dev, 1 QA
- Security consultant (week 2-3)
- 80% capacity = 128 hours/sprint
5. Risks:
- š“ HIGH (Score: 16): Stripe API changes during integration
- Mitigation: Use stable API version, monitor changelog
- š” MEDIUM (Score: 9): PCI compliance gaps found
- Mitigation: Early security review, buffer time
6. Budget:
- Labor: $60K (4 devs Ć 8 weeks)
- Tools: $5K (Stripe fees, testing)
- Security audit: $10K
- Contingency: $5K (6%)
7. Execution:
- Daily standups at 9 AM
- Weekly stakeholder demo on Fridays
- Bi-weekly sprint planning
8. Communication:
- Weekly status email to stakeholders
- Slack channel for real-time updates
- Monthly steering committee presentation
9. Quality:
- Code review required for all PRs
- >80% test coverage required
- Security scan before each deployment
10. Closure:
- All deliverables met, launched to 100% users
- Retrospective: Payment failures 0.3% (beat 1% target)
- Lesson: Early security review prevented late delays
Output:
ā
Project delivered ON TIME, ON BUDGET
Timeline: 8 weeks (as planned)
Budget: $78K spent ($80K budget, 2.5% under)
Quality: 0.3% payment failure rate (target: <1%)
Stakeholder satisfaction: 4.8/5.0
# Change Request: {ID}
## Requested By
{Name}, {Date}
## Description
{What is the requested change?}
## Justification
{Why is this change needed?}
## Impact Analysis
- **Scope**: {How does this affect deliverables?}
- **Schedule**: {Delay in days/weeks}
- **Budget**: {Additional cost}
- **Resources**: {Additional people/skills needed}
- **Quality**: {Impact on quality/testing}
- **Risk**: {New risks introduced}
## Decision
ā Approved - {Reason}
ā Rejected - {Reason}
ā Deferred - {To when and why}
## Approval
- Project Sponsor: {Name}, {Date}
- Product Owner: {Name}, {Date}
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.