When this skill is activated, always start your first response with the 🧢 emoji.

Project Execution

Project execution is the discipline of turning a plan into delivered outcomes while navigating uncertainty, managing cross-team dependencies, and keeping stakeholders aligned. Most projects fail not from bad ideas but from poor execution - untracked risks that materialize, dependencies that slip silently, and stakeholders who learn about problems too late to help. This skill equips an agent to build risk registers, map dependency chains, write crisp status updates, and make sound escalation decisions throughout a project's lifecycle.

When to use this skill

Trigger this skill when the user:

• Needs to create a project plan, timeline, or milestone breakdown
• Wants to identify, assess, or mitigate project risks
• Asks to map dependencies between teams, services, or deliverables
• Needs to write a status update, executive summary, or steering committee report
• Wants to build or maintain a RAID log (Risks, Assumptions, Issues, Dependencies)
• Asks about critical path analysis or schedule compression
• Needs to escalate a blocked or at-risk project
• Wants to estimate timelines or evaluate schedule feasibility

Do NOT trigger this skill for:

• Pure technical architecture decisions (use system-design or clean-architecture instead)
• Agile ceremony design or Scrum process questions (this skill is methodology-agnostic)

Key principles

1. Risks are first-class artifacts - Every project maintains a living risk register. A risk without an owner, a likelihood rating, and a mitigation plan is just a worry. Quantify risks on a 3x3 matrix (likelihood x impact) and review them weekly, not just at kickoff.

2. Dependencies are contracts, not hopes - When your timeline depends on another team's deliverable, treat it as a contract. Document the what, the when, the who, and the fallback if it slips. Check dependency health weekly - do not wait for the deadline to discover a slip.

3. Communicate before they ask - Stakeholders should never learn about problems from a status meeting. Bad news travels up immediately. Status updates are predictable, structured, and honest. Use red/amber/green (RAG) status consistently and never inflate green to avoid a conversation.

4. Plan for recovery, not perfection - Every plan will deviate. The mark of good execution is how fast you detect deviation and course-correct. Build explicit decision points (go/no-go gates) into the plan, not just milestones.

5. Scope is the primary lever - When timeline, resources, and quality are constrained, scope is the variable you negotiate. Never silently reduce quality to hit a date. Make trade-offs explicit and get stakeholder sign-off.

Core concepts

RAID Log - The central tracking artifact for any project. Risks are things that might happen. Assumptions are things you believe to be true but have not verified. Issues are risks that have materialized - they are active problems. Dependencies are external deliverables your project requires.

Critical Path - The longest sequence of dependent tasks that determines the minimum project duration. Any delay on the critical path delays the entire project. Non-critical tasks have float (slack time). Focus risk mitigation and dependency tracking efforts on critical-path items first.

RAG Status - Red/Amber/Green health indicator used in status reporting. Green means on track with no significant risks. Amber means at risk - there are issues that could cause a miss without intervention. Red means off track - the current plan will not meet its commitments without a scope, timeline, or resource change. Define these thresholds explicitly at project start.

Stakeholder Map - A matrix classifying stakeholders by influence and interest. High-influence/high-interest stakeholders get direct, frequent updates. Low-influence/low-interest stakeholders get broadcast updates. Misclassifying a stakeholder's quadrant is a common source of project friction.

Common tasks

Build a risk register

Create a structured table with these columns: Risk ID, Description, Likelihood (Low/Medium/High), Impact (Low/Medium/High), Risk Score (L x I), Owner, Mitigation Plan, Status (Open/Mitigated/Occurred), Last Reviewed. Seed the register during planning by running a pre-mortem exercise - ask "It is 3 months from now and this project has failed. What went wrong?" Categorize risks into Technical, Resource, Dependency, Scope, and External buckets.

Map project dependencies

Create a dependency graph with four attributes per dependency: Source (who needs it), Target (who provides it), Deliverable (what exactly), Due Date, and Fallback Plan. Visualize as a table or directed list. Flag any dependency where the target team has not acknowledged the commitment - these are "unconfirmed dependencies" and carry the highest risk.

Dependency Chain:
  [Design Team] --wireframes (Mar 20)--> [Frontend Team] --UI components (Apr 5)--> [QA Team]
  [Auth Team] --OAuth SDK v3 (Mar 25)--> [Backend Team] --API endpoints (Apr 10)--> [QA Team]
  [Data Team] --schema migration (Mar 15)--> [Backend Team]

Unconfirmed: Auth Team has not acknowledged Mar 25 date - ESCALATE

Write a weekly status update

Follow this template for consistent, scannable status updates:

## Project: [Name] - Week of [Date]
**Overall Status: [GREEN/AMBER/RED]**

### Progress this week
- [Completed item 1]
- [Completed item 2]

### Planned next week
- [Planned item 1]
- [Planned item 2]

### Risks & blockers
- [AMBER] [Risk description] - Mitigation: [action] - Owner: [name]
- [RED] [Blocker description] - Need: [what you need] - From: [who]

### Key decisions needed
- [Decision 1] - Deadline: [date] - Decision maker: [name]

### Metrics
- Milestone progress: [X/Y] complete
- Days to next milestone: [N]
- Open risks: [N] (H:[n] M:[n] L:[n])

Conduct a pre-mortem

Before execution begins, run a structured pre-mortem session. Prompt the team (or simulate as an agent) with: "Assume this project has failed spectacularly. List every reason why." Group responses into categories (Technical, People, Process, External). Convert the top findings into risk register entries with owners and mitigations. A pre-mortem surfaces risks that optimism bias hides during normal planning.

Create a stakeholder communication plan

Map each stakeholder to a communication cadence:

Perform critical path analysis

List all tasks with their durations and dependencies. Identify the longest path through the dependency graph - this is your critical path and minimum project duration. Calculate float for non-critical tasks. When the critical path is too long, apply schedule compression: fast-tracking (parallelizing sequential tasks that can overlap) or crashing (adding resources to critic