execute

Overview of execute skill

What execute does

execute is a C-level advisor skill that turns an approved decision into a 90-day operating plan. Instead of leaving a strategic call as a static note, the execute skill produces weekly milestones, workstreams, named DRIs, success metrics, definitions of done, and a check-in cadence. Its core job is to bridge the gap between “we decided” and “what happens next Monday?”

Best fit for Project Management and leadership teams

The strongest fit for execute for Project Management is after a founder, executive team, product lead, or operating team has already made a clear decision and needs an accountable rollout plan. Typical uses include market entry, pricing changes, hiring plans, product launches, sales process changes, or internal operating model shifts. It is especially useful when the decision has cross-functional workstreams and failure would come from vague ownership, not lack of ideas.

What makes the execute skill different

Unlike a generic “make me a project plan” prompt, execute expects a decision record as its input and preserves the binding outcome from that decision. The skill’s output format is opinionated: 90-day horizon, weekly milestones, DRI ownership, success and kill criteria, workstreams, and check-ins. That structure makes it better for execution discipline than for brainstorming or early strategic exploration.

Important adoption notes

The repository path is c-level-advisor/c-level-agents/skills/execute, and the main file is SKILL.md. There are no extra scripts, rules, resources, or README files in this skill directory, so the value is concentrated in the prompt structure itself. Install execute if you want a lightweight execution-planning command inside a Claude skills workflow; do not expect a full project management integration or automated task sync.

How to Use execute skill

execute install context

Install the skill from the repository with:

npx skills add alirezarezvani/claude-skills --skill execute

After install, inspect SKILL.md first because it contains the command, expected input, pipeline position, and output format. The upstream skill is designed around the command:

/cs:execute <decision-path>

The <decision-path> should point to an approved decision record, ideally one produced by /cs:decide in the same C-level advisor workflow.

Inputs the execute skill needs

For best execute usage, provide more than a title. The skill needs enough decision context to create accountable milestones:

• the approved decision and rationale
• the binding outcome, success criteria, and kill criteria
• sponsor or executive owner
• relevant teams and likely DRIs
• deadline, launch window, or 90-day checkpoint
• known constraints such as budget, hiring, engineering capacity, compliance, or dependencies
• existing tools or operating cadence, such as weekly exec review or sprint planning

Weak input: “Create an execution plan for entering Germany.”

Stronger input: “Use /cs:execute decisions/2026-02-03-germany-entry.md. Preserve the approved success criteria: €250k qualified pipeline by day 90 and kill criteria: CAC payback above 18 months after pilot. Assume Sales, Marketing, Legal, and Product workstreams. Weekly exec check-in is Mondays. Name placeholder DRIs where people are not assigned.”

Suggested workflow

Use execute after the decision is approved, not while the team is still debating options. A practical workflow is:

1. Run or gather the decision record.
2. Confirm the outcome and kill criteria are explicit.
3. Call /cs:execute <decision-path>.
4. Review the generated workstreams and weekly milestones.
5. Replace placeholder DRIs with real names.
6. Move milestones into your project system if needed.
7. Use the check-in cadence to track risks and missed definitions of done.

The skill’s default output is saved as a markdown execution plan, commonly under a path like ~/.claude/execution/YYYY-MM-DD-<slug>.md, depending on your local Claude skill setup.

Prompting tips that improve output quality

Be specific about the operating environment. If you already know the team’s cadence, capacity, or dependencies, include them. If a milestone must be observable, say so. If leadership cares about a particular metric, ask the skill to make that metric visible in each related workstream.

A useful prompt pattern is:

/cs:execute <decision-path>. Build a 90-day plan with weekly milestones, named DRIs where known, placeholder DRIs where unknown, definitions of done, dependency risks, and a Monday check-in cadence. Keep the binding outcome and kill criteria unchanged from the decision record.

This prevents the plan from drifting away from the original decision.

execute skill FAQ

Is execute only for executives?

No. The language and pipeline are executive-oriented, but the execute skill is useful for product managers, operators, founders, chiefs of staff, and project leads who need to convert an approved decision into an accountable plan. The main requirement is that the decision is already made.

When should I not use execute?

Do not use execute for open-ended ideation, option comparison, market research, or deciding between competing strategies. It is also a poor fit when there is no clear owner, no success metric, or no willingness to assign DRIs. In those cases, use a briefing, decision, or planning process first.

How is execute different from a normal prompt?

A normal prompt may produce a plausible task list. Execute enforces a decision-to-plan shape: 90 days, workstreams, DRIs, weekly milestones, definitions of done, and check-in rhythm. That constraint is the point. It reduces ambiguity and makes the result easier to review with a leadership team.

Does execute integrate with Jira, Asana, or Linear?

The repository evidence for execute shows only SKILL.md and no helper scripts or tool integrations. Treat the output as a structured markdown plan that can be copied into Jira, Asana, Linear, Notion, or a spreadsheet. If tool sync matters, plan on adding that workflow yourself.

How to Improve execute skill

Improve execute inputs before running it

The fastest way to improve execute results is to strengthen the decision record. Make sure it includes the actual decision, why it was chosen, what success looks like, what would cause reversal, and who sponsors the work. A vague decision creates a vague execution plan; a measurable decision creates useful weekly milestones.

Check for common failure modes

After the first output, look for these issues:

• milestones that are activities rather than outcomes
• DRIs assigned to teams instead of people
• missing dependency owners
• success metrics that do not match the original decision
• week-one work that is too large or unclear
• no explicit review cadence or escalation path

Ask execute to revise only the weak parts instead of regenerating everything.

Iterate toward operating reality

A good second prompt is practical, not decorative:

“Revise the plan so each weekly milestone has an observable definition of done, no DRI is a department, Legal dependencies are visible by week, and the week 4 checkpoint can determine whether we continue, adjust, or stop.”

This kind of iteration improves management usefulness more than asking for a longer plan.

Adapt execute to your organization

If you use execute often, standardize the fields your team cares about: budget owner, risk level, customer impact, reporting forum, launch checklist, or escalation trigger. Keep the 90-day structure, but tune the workstreams and check-in cadence to your operating model. That makes execute more repeatable without turning it into a generic project template.