Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
.claude/skills/aiskillstore-coordinating-projects/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-07 | ✗→✓ | ▲ Improved | 205% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 217% | 0% |
| case-15 | ✗→✓ | ▲ Improved | 425% | 0% |
| case-16 | ✗→✓ | ▲ Improved | 241% | 0% |
| case-18 | ✗→✓ | ▲ Improved | 223% | 0% |
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:
bash# 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:
bash# 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/:
bash# Create dependency map cp {baseDir}/templates/dependency-map-template.md .claude-project/dependency-map.md
Use roadmap templates:
bash# 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:
markdownObjective: 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:
markdownProjects 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:
markdownQ2 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:
markdownInitiative: 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:
markdown- 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:
markdown- Blocking: Project B cannot start until Project A completes - Enabling: Project A unlocks Project B's value - Coordinated: Projects must release simultaneously
Resource Dependencies:
markdown- 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:
markdownProject 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:
markdownCritical 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:
markdownTeam 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
markdownShared 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
markdownEngineer 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
markdownTotal 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:
markdown1. **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:
markdownScenario: 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:
markdownDecision: 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:
markdownFor 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:
markdown- 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:
markdown# 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:
bashcp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2.md
Located in {baseDir}/scripts/:
Usage:
bash# 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:
markdownI'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:
markdownI'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:
markdownI'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.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 44,161 | 43,061 | -2% | 1 | 1 | 0% | 6,557 | 11,438 | +74% | 0 | 0 | — |
case-02 | fail→fail | 41,317 | 49,253 | +19% | 1 | 1 | 0% | 5,910 | 10,401 | +76% | 0 | 0 | — |
case-03 | fail→fail | 41,209 | 11,541 | -72% | 1 | 1 | 0% | 3,890 | 6,436 | +65% | 0 | 0 | — |
case-04 | pass→pass | 19,047 | 18,424 | -3% | 1 | 1 | 0% | 2,334 | 8,247 | +253% | 0 | 0 | — |
case-05 | pass→pass | 18,740 | 11,962 | -36% | 1 | 1 | 0% | 3,926 | 8,323 | +112% | 0 | 0 | — |
case-06 | pass→pass | 18,257 | 9,212 | -50% | 1 | 1 | 0% | 2,420 | 7,731 | +219% | 0 | 0 | — |
case-07 | fail→pass | 22,233 | 20,982 | -6% | 1 | 1 | 0% | 2,899 | 8,836 | +205% | 0 | 0 | — |
case-08 | fail→fail | 18,643 | 15,541 | -17% | 1 | 1 | 0% | 2,186 | 7,837 | +259% | 0 | 0 | — |
case-09 | pass→pass | 20,391 | 13,700 | -33% | 1 | 1 | 0% | 2,314 | 7,638 | +230% | 0 | 0 | — |
case-10 | pass→pass | 7,879 | 11,676 | +48% | 1 | 1 | 0% | 1,292 | 7,215 | +458% | 0 | 0 | — |
case-11 | pass→pass | 11,120 | 12,787 | +15% | 1 | 1 | 0% | 1,183 | 7,450 | +530% | 0 | 0 | — |
case-12 | pass→pass | 17,356 | 20,587 | +19% | 1 | 1 | 0% | 2,614 | 8,402 | +221% | 0 | 0 | — |
case-13 | fail→pass | 21,955 | 20,963 | -5% | 1 | 1 | 0% | 2,761 | 8,747 | +217% | 0 | 0 | — |
case-14 | pass→pass | 16,608 | 24,963 | +50% | 1 | 1 | 0% | 2,637 | 9,213 | +249% | 0 | 0 | — |
case-15 | fail→pass | 7,814 | 8,336 | +7% | 1 | 1 | 0% | 1,264 | 6,633 | +425% | 0 | 0 | — |
case-16 | fail→pass | 22,132 | 20,605 | -7% | 1 | 1 | 0% | 2,436 | 8,299 | +241% | 0 | 0 | — |
case-17 | pass→pass | 19,057 | 10,111 | -47% | 1 | 1 | 0% | 2,568 | 7,140 | +178% | 0 | 0 | — |
case-18 | fail→pass | 22,519 | 18,263 | -19% | 1 | 1 | 0% | 2,793 | 9,011 | +223% | 0 | 0 | — |
case-19 | pass→pass | 25,711 | 22,113 | -14% | 1 | 1 | 0% | 2,963 | 8,655 | +192% | 0 | 0 | — |
case-20 | fail→fail | 23,939 | 27,213 | +14% | 1 | 1 | 0% | 3,275 | 9,729 | +197% | 0 | 0 | — |
case-21 | pass→pass | 20,772 | 12,013 | -42% | 1 | 1 | 0% | 2,410 | 7,281 | +202% | 0 | 0 | — |
case-22 | fail→pass | 17,446 | 12,705 | -27% | 1 | 1 | 0% | 2,120 | 7,370 | +248% | 0 | 0 | — |
case-23 | fail→pass | 21,575 | 6,720 | -69% | 1 | 1 | 0% | 2,591 | 7,167 | +177% | 0 | 0 | — |
case-24 | fail→fail | 14,567 | 8,775 | -40% | 1 | 1 | 0% | 1,452 | 6,731 | +364% | 0 | 0 | — |
case-25 | fail→fail | 18,057 | 7,588 | -58% | 1 | 1 | 0% | 2,342 | 6,487 | +177% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 25 cases were attempted, and 24 counted toward the lift figure. The other 1 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +28 percentage points is the difference between those two pass rates over the 24 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.