// Execute a knowledge work plan. Break it into tasks, do the work, and track what happened. Use after planning to actually produce the deliverables.
Brain dump and compile knowledge before structuring a plan. Use when starting any non-trivial knowledge work — after a meeting, when tackling a new problem, or when you need to pull together what you know before planning.
Extract and save learnings from a completed knowledge work session. Saves to docs/knowledge/ so future plans automatically find them.
Gut-check what you know and don't know before proceeding. Use at any point to assess confidence, surface gaps, and decide whether to proceed or dig deeper.
Research past work and structure a knowledge work plan. Use when starting strategy docs, campaign plans, content briefs, research synthesis, or operational playbooks.
Multi-reviewer quality check for knowledge work. Runs strategic alignment and data accuracy reviewers on plans, briefs, and strategy docs.
| name | kw:work |
| description | Execute a knowledge work plan. Break it into tasks, do the work, and track what happened. Use after planning to actually produce the deliverables. |
| argument-hint | [plan file to execute] |
<work_target> #$ARGUMENTS </work_target>
You have a plan. Now execute it. Break it into tasks, do them, track what happened.
After /kw:plan or /kw:review — the plan is ready, time to execute
"Start working on this", "Execute the plan", "Let's do this"
When you have a clear plan and need to produce deliverables
Read the plan file. If no plan is specified:
plans/Extract concrete deliverables from the plan. For each deliverable, create a task:
## Tasks
- [ ] [Task 1] — [what needs to be produced]
- [ ] [Task 2] — [what needs to be produced]
- [ ] [Task 3] — [what needs to be produced]
Present the task list to the user:
"I see [N] deliverables in this plan. Here's how I'd break them down. Want to adjust before I start?"
Task types in knowledge work:
| Deliverable | How to execute |
|---|---|
| Strategy doc / brief | Write it using the plan as structure |
| Email draft | Write it, check tone, present for review |
| Social copy | Write variations, check against style guides |
| Data analysis | Pull data, analyze, summarize findings |
| Presentation | Structure slides, write content |
| Research synthesis | Gather sources, extract insights, summarize |
| Meeting agenda | Structure topics, time-box, add context |
| Notion page / doc | Create and populate |
| Campaign assets | Create copy, briefs, timelines |
Before executing, sort tasks into batches:
## Execution Plan
### Batch 1 (parallel) — no dependencies
- [ ] [Task A] — independent
- [ ] [Task B] — independent
### Batch 2 (parallel) — depends on Batch 1
- [ ] [Task C] — needs output from Task A
- [ ] [Task D] — independent of C, but needs Batch 1 context
### Batch 3 (sequential) — needs user direction
- [ ] [Task E] — depends on user feedback from earlier batches
Grouping rules:
Tasks with no dependencies on each other go in the same batch
Tasks that need another task's output go in a later batch
Tasks that need user feedback before starting go in their own batch
Present the execution plan to the user:
"I've grouped these into [N] batches. Batch 1 has [N] independent tasks I can run in parallel. Want to adjust before I start?"
For each batch:
When to parallelize within a batch:
| Situation | Approach |
|---|---|
| 2+ independent deliverables (e.g., 3 social posts, a brief + a data pull) | Launch as parallel Task agents |
| Single deliverable | Execute inline |
| Deliverable needs back-and-forth (e.g., iterating on tone) | Execute inline, don't delegate |
Execution principles:
Use what's available. If there are MCP tools, APIs, or skills that can help, use them. Don't recreate what exists.
Follow project conventions. Check CLAUDE.md for style guides, data sources, tool preferences.
Show, don't describe. Produce the actual deliverable, not a description of what it would look like.
Approve between batches, not between every task. Independent tasks don't need individual sign-off. Check in after each batch completes.
Fall back to sequential if unsure. When in doubt about whether tasks are independent, run them one at a time. Wrong parallelism is worse than no parallelism.
If you can't complete a task:
Missing information — Ask the user. Be specific about what you need.
Missing access — Note it and move to the next task. Come back when unblocked.
Scope creep — If a task is bigger than expected, flag it: "This is turning into its own project. Should I keep going or add it as a separate plan?"
Quality concern — If the output doesn't feel right, say so. "I produced this but I'm not confident about [X]. Want to review before I continue?"
As you work, maintain a running log. After each batch completes, append the log to the plan file under a ## Execution Log section:
## Execution Log
### [timestamp] Batch 1: [batch name]
- [Task 1] ✅ — Produced: [what], Location: [path]
- [Task 2] ✅ — Produced: [what], Location: [path]
- Notes: [anything notable]
### [timestamp] Batch 2: [batch name]
- [Task 3] ✅ — Produced: [what], Location: [path]
- [Task 4] ⏳ Blocked — [blocker], Next step: [what needs to happen]
<critical_requirement> Write the execution log to the plan file after each batch. Do not keep it only in conversation. This log feeds /kw:compound with concrete material to extract learnings from. </critical_requirement>
When all tasks are complete (or blocked), summarize:
## Execution Summary
**Plan:** [plan name]
**Tasks completed:** [N] of [total]
**Deliverables produced:**
- [deliverable 1] — [location]
- [deliverable 2] — [location]
**Still open:**
- [blocked task] — [blocker]
**Discoveries:**
- [anything learned during execution worth noting]
Use AskUserQuestion:
Question: "Execution complete. [N] deliverables produced. What next?"
Options:
/kw:review — Quality check the outputs/kw:compound — Save learnings from this sessionProduce, don't plan. This is execution mode. If you find yourself writing another plan, you're in the wrong workflow. Use /kw:plan for that.
Show your work. After each task, show the actual output. Don't say "I would create a doc that..." — create the doc.
Respect scope. The plan defines what to do. If something isn't in the plan, ask before adding it. Scope creep is the enemy of finishing.
Track everything. The work log is how you know what happened. It also feeds /kw:compound with concrete results to learn from.
Ask for feedback between batches. Knowledge work is subjective. Check in after each batch rather than producing everything and hoping it's right. Independent tasks within a batch don't need individual sign-off.
When invoked with disable-model-invocation context (e.g., from an orchestrator or automation):