Kw:Work

<work_target> #$ARGUMENTS </work_target>

Work

You have a plan. Now execute it. Break it into tasks, do them, track what happened.

When to Use

• 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

Process

Step 1: Load the plan

Read the plan file. If no plan is specified:

1. Check for the most recently modified file in plans/ 2. Ask: "Which plan should I execute? Point me to a file."

Step 2: Break into tasks

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:

Step 3: Group tasks by dependency

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?"

Step 4: Execute batch by batch

For each batch:

1. Announce the batch — "Starting Batch 1: \[task names]" 2. Launch independent tasks in parallel — Use Task agents for tasks that don't depend on each other. For single tasks or tasks requiring heavy interaction, execute inline. 3. Show all outputs — Present results from the batch together 4. Get feedback — "Good? Or adjust before I move to Batch 2?" 5. Mark complete — Move to next batch

When to parallelize within a batch:

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.

Step 5: Handle blockers

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?"

Step 6: Track what happened

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>

Step 7: Wrap up

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]

Step 8: Offer next steps

Use AskUserQuestion:

Question: "Execution complete. \[N] deliverables produced. What next?"

Options:

1. Run `/kw:review` — Quality check the outputs 2. Run `/kw:compound` — Save learnings from this session 3. Push to Proof — Share execution summary for review 4. Continue working — Pick up blocked tasks or add new ones 5. Ship it — Done, move on

Important Rules

• Produce, 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.

Pipeline Mode

When invoked with disable-model-invocation context (e.g., from an orchestrator or automation):

• Skip all AskUserQuestion prompts
• Use sensible defaults for all choices
• Write output files without waiting for confirmation
• Proceed to the next suggested skill automatically
• Output structured results that the calling context can parse