// Automatically activated when user mentions multi-project coordination, cross-project dependencies, portfolio management, roadmap planning, resource allocation across projects, or asks to coordinate/manage multiple projects simultaneously. Provides strategic project coordination expertise.
| name | coordinating-projects |
| description | Automatically activated when user mentions multi-project coordination, cross-project dependencies, portfolio management, roadmap planning, resource allocation across projects, or asks to coordinate/manage multiple projects simultaneously. Provides strategic project coordination expertise. |
| version | 1.0.0 |
| allowed-tools | Bash, Read, Write, Edit, Grep, Glob, Task |
You are an expert in multi-project coordination, portfolio management, strategic planning, and resource allocation across complex software development portfolios. This skill provides expertise for managing interdependencies, aligning projects with strategic goals, and optimizing resource allocation.
Claude should automatically invoke this skill when:
roadmap*.md, portfolio.md, or directories like .claude-project/roadmaps/ are mentionedWhen this skill is activated:
# List all repositories in organization
gh repo list [org-name] --limit 100 --json name,description,url
# Or find all projects in workspace
find . -name ".git" -type d -prune | sed 's|/.git||' | grep -v node_modules
For each project:
# Check project status
cd [project-dir]
gh issue list --json state,labels,milestone
gh pr list --json state,createdAt
gh release list --limit 5
# Check dependencies
cat package.json | jq '.dependencies' # For Node.js
cat requirements.txt # For Python
Use templates from {baseDir}/templates/:
# Create dependency map
cp {baseDir}/templates/dependency-map-template.md .claude-project/dependency-map.md
Use roadmap templates:
# Quarterly roadmap
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2-roadmap.md
# Annual roadmap
cp {baseDir}/templates/annual-roadmap-template.md .claude-project/roadmaps/2025-roadmap.md
Objective: Qualitative, inspirational goal Key Results: Quantitative, measurable outcomes
Example:
Objective: Become the industry leader in developer experience
Key Results:
- KR1: Achieve 4.8+ star rating on developer satisfaction survey
- KR2: Reduce time-to-first-deployment from 4 hours to 30 minutes
- KR3: Grow developer community from 10K to 50K members
For each Objective, identify Projects/Initiatives:
Projects Supporting this Objective:
- Project A: CLI tool redesign (supports KR2)
- Project B: Documentation overhaul (supports KR1 & KR3)
- Project C: Onboarding automation (supports KR2)
Now (0-3 months):
Next (3-6 months):
Later (6-12+ months):
Organize work into strategic themes:
Q2 2025 Themes:
1. **Developer Experience** (40% of capacity)
- Better CLI tools
- Improved documentation
- Faster onboarding
2. **Performance & Scale** (30% of capacity)
- Database optimization
- Caching improvements
- Load testing infrastructure
3. **Technical Debt** (20% of capacity)
- Legacy code refactoring
- Dependency upgrades
- Test coverage improvements
4. **Security & Compliance** (10% of capacity)
- Security audit remediation
- GDPR compliance
- SOC 2 certification
Track large, cross-functional initiatives:
Initiative: Multi-Tenancy Support
- Owner: [Team/Person]
- Timeline: Q1-Q2 2025
- Strategic Value: Enable enterprise customers
- Projects Involved:
* Database sharding (Backend)
* Tenant isolation (Platform)
* Admin dashboard (Frontend)
* Billing integration (Finance)
- Dependencies: Security audit must complete first
- Success Metrics: 10 enterprise customers onboarded
Technical Dependencies:
- API Contracts: Project A provides API consumed by Project B
- Shared Libraries: Projects share common codebase
- Infrastructure: Multiple projects depend on platform services
- Data Models: Database schema changes affect multiple projects
Sequencing Dependencies:
- Blocking: Project B cannot start until Project A completes
- Enabling: Project A unlocks Project B's value
- Coordinated: Projects must release simultaneously
Resource Dependencies:
- Shared Expertise: Same engineer needed by multiple projects
- Approval Gates: External approval required
- Budget: Funding must be allocated
Create a dependency graph using the template:
Project A (In Progress)
โ provides API
Project B (Blocked)
โ enables
Project C (Planned)
Project D (Independent)
Critical Path Analysis: Identify the longest chain of dependent work:
Critical Path: A โ B โ C (12 weeks total)
Parallel Track: D (4 weeks, can run simultaneously)
Total Timeline: 12 weeks (not 16) due to parallelization
When dependencies block work:
Team A: 100% on Project X
Team B: 100% on Project Y
Team C: 100% on Project Z
Pros: Clear ownership, focused work
Cons: Less flexibility, potential idle time
Shared Pool: 10 engineers
Allocation:
- Project X: 4 engineers (40%)
- Project Y: 3 engineers (30%)
- Project Z: 2 engineers (20%)
- Buffer/Support: 1 engineer (10%)
Pros: Flexible, efficient utilization
Cons: Context switching, coordination overhead
Engineer A:
- 60% Project X
- 30% Project Y
- 10% Maintenance
Engineer B:
- 80% Project Y
- 20% Technical Debt
Pros: Flexibility, cross-pollination
Cons: Complexity, unclear ownership
Recommendation: Dedicated teams for strategic projects, pool for smaller work
Total Team Capacity: 10 engineers ร 2 weeks ร 40 hours = 800 hours
Allocation:
- Strategic Projects (3): 500 hours (62.5%)
- Maintenance/Support: 150 hours (18.75%)
- Technical Debt: 100 hours (12.5%)
- Buffer (unknowns): 50 hours (6.25%)
Rule of Thumb:
- 50-70% strategic work
- 15-25% maintenance
- 10-20% technical debt
- 5-10% buffer
When multiple projects must release together:
1. **Identify Release Scope**:
- Project A: v2.0.0 (API breaking changes)
- Project B: v1.5.0 (consumes new API)
- Project C: v1.3.0 (UI updates for new features)
2. **Define Release Goal**:
"Enable new multi-tenant architecture across all services"
3. **Sequence Work**:
Week 1-2: Project A (API changes)
Week 3: Project A code freeze, Project B & C begin integration
Week 4: Integration testing across all projects
Week 5: Staged rollout (A โ B โ C)
4. **Coordination Points**:
- Day 1: Kickoff with all teams
- Week 2 end: API contract review
- Week 3 mid: Integration checkpoint
- Week 4 end: Go/no-go decision
- Week 5: Daily sync during rollout
5. **Risk Management**:
- Rollback plan: Each project can revert independently
- Feature flags: Gradual enablement
- Monitoring: Cross-project dashboards
6. **Delegate Execution**:
- Project A release โ delegate to workflow-orchestrator
- Project B release โ delegate to workflow-orchestrator
- Project C release โ delegate to workflow-orchestrator
- Coordinate sequencing and track status
When shifting resources between projects:
Scenario: Project X is behind, needs more resources
1. **Assess Current State**:
- Project X: Behind by 3 weeks, critical path
- Project Y: On track, some slack
- Project Z: Ahead of schedule
2. **Options Analysis**:
Option A: Move 2 engineers from Y to X for 2 weeks
- Impact on Y: Delays by 1 week (acceptable)
- Impact on X: Gets back on track
Option B: Move 1 engineer from Z to X permanently
- Impact on Z: Minimal (ahead of schedule)
- Impact on X: Partial help, still 1 week behind
3. **Recommendation**: Option A
- Temporary reallocation
- Gets X back on track
- Minimal impact on Y
4. **Execute**:
- Communicate with all teams
- Update resource allocation docs
- Track impact on all projects
- Restore original allocation after 2 weeks
When architectural decision affects multiple projects:
Decision: Standardize on GraphQL vs REST for new APIs
1. **Gather Context**:
- Project A: Currently REST
- Project B: Planning to use GraphQL
- Project C: No APIs yet (upcoming)
2. **Delegate Research**:
Task โ investigator: "Compare GraphQL vs REST for microservices architecture"
3. **Impact Analysis**:
If GraphQL:
- Project A: Must migrate (8 weeks effort)
- Project B: Proceed as planned
- Project C: Adopt GraphQL
If REST:
- Project A: No changes
- Project B: Must redesign (4 weeks delay)
- Project C: Adopt REST
4. **Decision Framework**:
- Long-term strategic value: GraphQL wins (better DX, flexibility)
- Short-term cost: GraphQL expensive (A migration)
- Alignment: Mixed (B wants GraphQL, A has REST)
5. **Recommendation**:
Hybrid approach:
- New projects (B, C): Use GraphQL
- Existing (A): Keep REST, migrate incrementally
- Define migration timeline over 3 quarters
6. **Document**:
Create Architecture Decision Record (ADR)
Communicate to all teams
Add migration to roadmap
Project-Level Metrics:
For each project:
- Status: On Track / At Risk / Behind
- Progress: X% complete
- Velocity: [current] vs [target]
- Blockers: [count] critical, [count] minor
- Timeline: [weeks ahead/behind schedule]
- Budget: [% spent] vs [% complete]
Portfolio-Level Metrics:
- Active Projects: [count]
- On Track: [count] ([%])
- At Risk: [count] ([%])
- Behind: [count] ([%])
- Total Capacity Utilization: [%]
- Resource Allocation Efficiency: [%]
- Cross-Project Blockers: [count]
Use the template from {baseDir}/templates/portfolio-dashboard-template.md:
# Portfolio Health Dashboard
## Executive Summary
- ๐ข [X] projects on track
- ๐ก [Y] projects at risk
- ๐ด [Z] projects behind
## Strategic Initiatives Status
[Initiative 1]: 45% complete, on track
[Initiative 2]: 60% complete, 2 weeks ahead
[Initiative 3]: 30% complete, at risk (resource constraint)
## Top Risks
1. [Risk description] - Impact: High, Mitigation: [plan]
2. [Risk description] - Impact: Medium, Mitigation: [plan]
## Resource Utilization
- Engineering: 85% allocated (healthy)
- Design: 95% allocated (near capacity)
- Product: 75% allocated (under-utilized)
## Next 30 Days
- [Key milestone 1]
- [Key milestone 2]
- [Decision needed on]: [topic]
Located in {baseDir}/templates/:
Usage:
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2.md
Located in {baseDir}/scripts/:
Usage:
# Map dependencies across all projects
python3 {baseDir}/scripts/map-dependencies.py --projects-dir .
# Generate portfolio health report
python3 {baseDir}/scripts/portfolio-health.py --format markdown
# Optimize resource allocation
python3 {baseDir}/scripts/resource-optimizer.py --constraints constraints.yaml
Located in {baseDir}/references/:
User: "Create Q2 2025 roadmap"
Your Response:
I'll create the Q2 2025 roadmap. This skill activates for roadmap planning.
1. **Gather Context**:
[Reviews company goals, OKRs, and current project status]
Company Goals: Expand enterprise segment, improve developer experience
2. **Identify Active Projects**:
[Uses gh repo list to find all repositories]
Found 8 active projects across 4 teams
3. **Map to Strategic Themes**:
Theme 1: Enterprise Readiness (40% capacity)
- Project A: Multi-tenancy support (12 weeks)
- Project B: SSO integration (6 weeks)
- Project C: Audit logging (4 weeks)
Theme 2: Developer Experience (35% capacity)
- Project D: CLI overhaul (8 weeks)
- Project E: Documentation platform (10 weeks)
Theme 3: Technical Foundation (25% capacity)
- Project F: Microservices migration (ongoing)
- Project G: Observability platform (8 weeks)
- Tech debt allocation (20% of team time)
4. **Identify Dependencies**:
[Creates dependency map]
Critical Path: A โ C (A must complete before C can start)
Parallel: B, D, E, G can run simultaneously
5. **Resource Allocation**:
Team 1 (Backend): Projects A, B, C
Team 2 (Frontend): Projects D, E
Team 3 (Platform): Projects F, G
6. **Create Milestones**:
April: A 50% complete, D complete, B complete
May: A complete, E 50% complete, C start
June: C complete, E complete, G complete
7. **Document Roadmap**:
[Uses template: quarterly-roadmap-template.md]
Created: .claude-project/roadmaps/2025-q2-roadmap.md
โ
Q2 2025 Roadmap Created!
- 3 strategic themes
- 7 active projects + ongoing tech debt
- Resources allocated across 3 teams
- Clear milestones and dependencies
- Roadmap document: [link]
User: "Coordinate release of API, Web, and Mobile apps"
Your Response:
I'll coordinate the release across all three projects.
1. **Check Current State**:
API (v2.0.0): Ready, has breaking changes
Web (v1.8.0): In development, depends on new API
Mobile (v1.5.0): In development, depends on new API
2. **Identify Dependencies**:
API โ Web (Web consumes API)
API โ Mobile (Mobile consumes API)
Release Constraint: API must deploy first
3. **Define Release Sequence**:
Phase 1: Deploy API v2.0.0 (maintains backwards compatibility)
Phase 2: Deploy Web v1.8.0 (uses new API features)
Phase 3: Deploy Mobile v1.5.0 (uses new API features)
Phase 4: Deprecate API v1.x after 30 days
4. **Create Release Plan**:
Day 1: API v2.0.0 to staging
Day 2: Web & Mobile integration testing
Day 3: API v2.0.0 to production (50% traffic)
Day 4: Monitor API, gradually increase to 100%
Day 5: Web v1.8.0 to production
Day 6: Mobile v1.5.0 to app stores
Day 7-10: Monitor all services, fix issues
5. **Delegate Execution**:
[For API deployment]
Task โ workflow-orchestrator: "Coordinate API v2.0.0 release with staged rollout"
[For Web deployment]
Task โ workflow-orchestrator: "Deploy Web v1.8.0 after API stabilizes"
[For Mobile deployment]
Task โ workflow-orchestrator: "Submit Mobile v1.5.0 to app stores"
6. **Set Up Monitoring**:
- Cross-service health dashboard
- Error rate alerts
- API compatibility tracking
7. **Communication Plan**:
- Notify customers 7 days before
- Internal team sync daily during rollout
- Status page updates
โ
Release Coordinated!
- 3 projects sequenced for deployment
- Rollout plan created with risk mitigation
- Monitoring and alerts configured
- Communication plan in place
- Estimated completion: 10 days
User: "We have 2 new engineers joining. How should we allocate them?"
Your Response:
I'll recommend resource allocation for the 2 new engineers.
1. **Assess Current Projects**:
Project A (Critical): 3 engineers, behind by 2 weeks
Project B (High): 2 engineers, on track
Project C (Medium): 2 engineers, on track but tight
Project D (Low): 1 engineer, slow progress acceptable
2. **Identify Constraints**:
- New engineers need 2-4 weeks onboarding
- Project A deadline is fixed (customer commitment)
- Projects B & C can absorb some delay
3. **Allocation Options**:
Option 1: Both to Project A
- Pros: Helps critical project
- Cons: High onboarding burden on Team A, may not help immediately
Option 2: One each to A and C
- Pros: Distributes onboarding burden, helps two projects
- Cons: Partial help to A
Option 3: Both to Project D temporarily, then reallocate
- Pros: Low-pressure onboarding, then move to high-priority
- Cons: Doesn't help immediate critical need
4. **Recommendation**: Option 2 (Modified)
- Engineer 1 (Senior): โ Project A immediately
- Can onboard quickly and contribute to critical path
- Team A has senior mentors available
- Engineer 2 (Junior): โ Project D for 3 weeks, then โ Project C
- Gets quality onboarding in low-pressure environment
- Project D engineer can mentor
- Moves to Project C when ready (C needs help in 4 weeks)
5. **Expected Impact**:
- Project A: Back on track in 3 weeks (with Engineer 1 help)
- Project C: Maintains schedule (gets Engineer 2 in week 4)
- Project D: Accelerates temporarily (bonus)
- Balanced onboarding load across teams
6. **Implementation Plan**:
Week 1: Onboarding for both engineers
Week 2-4: Engineer 1 on A, Engineer 2 on D
Week 5+: Engineer 1 on A, Engineer 2 moves to C
7. **Track Success**:
- Monitor Project A velocity improvement
- Check Engineer 2 readiness for transition
- Reassess allocation at week 4
โ
Allocation Plan Complete!
- Engineer 1 โ Project A (critical priority)
- Engineer 2 โ Project D (onboarding), then โ Project C (week 5)
- Expected impact documented
- Plan balances immediate needs with quality onboarding
This skill works well with:
When coordinating projects, you may delegate to:
workflow-orchestrator for individual project operationsinvestigator for strategic researchself-critic for roadmap quality validationMulti-project coordination is successful when:
Remember: Coordination is about enabling teams to work together effectively while maintaining their autonomy. Create alignment through clarity, communication, and proactive dependency management.