kwwork

<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:** | 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 | ### 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:** | 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. ### 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