Execution Operating System

Execution Operating System

Use $ARGUMENTS as initial context.

When to use this skill

• A strategy or decision must become coordinated execution over multiple weeks.
• Several workstreams, dependencies, owners, or operating metrics must stay aligned.
• Leaders need a review cadence, definitions of done, and escalation rules.

When not to use this skill

• Do not use it for a one-off task that needs no coordination or review cadence.
• Do not use it to conceal an unresolved decision or to create activity without an outcome.
• Use high-agency first when an urgent 24–72 hour blocker is the primary problem.

Required inputs

• Approved outcome, definition of done, planning horizon, and decision owner.
• Workstreams, current status, dependencies, capacity, and known constraints.
• Leading and lagging metrics, review cadence, and escalation authority.
• Existing commitments that may create overload or sequencing conflicts.

Workflow

1. Convert the objective into a measurable outcome and definition of done.
2. Decompose work into bounded workstreams with one accountable owner each.
3. Map dependencies, critical path, capacity, and the smallest viable sequence.
4. Define milestones, leading indicators, lagging outcomes, and decision gates.
5. Establish operating cadence, status format, escalation path, and meeting rules.
6. Create the first cycle plan with owners, due dates, success signals, and WIP limits.
7. Set review triggers, re-planning rules, and a closeout or handoff condition.

Ask-first questions

Ask up to 3 questions before building the operating system:

1. What measurable outcome must be true by the end of the planning horizon?
2. Which owner, dependency, or capacity constraint is most likely to break the plan?
3. What review cadence and escalation authority already exist?

Assumption policy

• Separate approved decisions from assumptions still needing validation.
• Do not promise capacity that has not been confirmed by accountable owners.
• Make dependencies explicit and assign a fallback when a critical path can fail.
• Use confidence and validation dates for uncertain milestones or metrics.

Output contract

Always produce these sections in order:

1. Outcome and definition of done
2. Workstreams and critical path
3. Ownership and operating cadence
4. Metrics and review gates
5. Risks, blockers, and escalation
6. First cycle plan
7. Assumptions

• Every action includes an owner, due date, and success signal.
• Every critical dependency has an owner, deadline, and fallback.
• State the condition that triggers re-planning or escalation.

Guardrails

• Do not create a plan without a measurable outcome and definition of done.
• Do not assign work without confirming ownership, capacity, and due date.
• Limit work in progress and surface blocked work instead of hiding it in status language.
• Protect quality, safety, and sustainable workload; urgency does not erase constraints.
• Escalate unresolved dependencies to the correct decision owner with a concrete ask.

Handoffs

• Use decision-analysis-under-uncertainty when the execution path is not yet chosen.
• Use high-agency for a specific blocker requiring a 24–72 hour unblock plan.
• Use consulting-portfolio-growth-strategy when execution follows a multi-unit resource allocation.
• Use pyramid-principle-structured-communication for executive progress reporting.

Resources

• references/operating-cadence.md - Cadence, metrics, milestone, and review design.
• references/dependency-and-capacity.md - Critical path, capacity, WIP, and escalation controls.
• templates/execution-operating-system.md - Multi-week execution template.
• examples/execution-operating-system-example.md - Golden example with owners and review gates.

Keywords

execution plan, operating cadence, milestones, dependencies, critical path, ownership, capacity, delivery, accountability