Dispatch Seed — From Intent to Running Agent

What This Skill Does

Takes a task the person wants done and walks through the full pipeline:

1. Align — clarify what the person actually wants (using /align)
2. Seed — create an observable seed file the person can review
3. Plan — write documentation for what the finished product looks like BEFORE building
4. Dispatch — hand the seed to an agent in an isolated worktree

This exists for the moment the person stops watching — they've described a task and want an agent to go do it alone. Every other check in this harness assumes someone is still reading each turn; this is what runs before that assumption stops holding. It forces the agent to get intent confirmed in writing, write it down as a file the person can read and edit, write the user-facing docs for the finished thing before any code exists, then send the work into an isolated git worktree (a separate checkout on its own branch) so nothing it does touches the main codebase until a human says so.

The person stays in control at every step. Nothing moves without confirmation.

When to Use This

• The person describes a task they want an agent to handle autonomously
• You have an approved proposal from wherever this project tracks those
• A gap-finding pass surfaced an intent gap worth addressing

When NOT to Use This

• Simple tasks you can do directly (typo fix, one-line change)
• Tasks that require the person's active involvement throughout
• Tasks that modify the hook system, CLAUDE.md, or anything this project's own risk list marks as too sensitive for unsupervised dispatch (payments and auth are common defaults — add your own)

---

Step 1: Align

Run /align on the task. This is a conversation, not a command.

Your goal: arrive at 2-3 specific UX intent statements the person confirms. Each one should be testable — "when X, the user sees Y."

To predict the wider intent instead of asking from nothing, you can read the person's own past messages and corrections in ~/.claude/projects/*/*.jsonl if that history exists — say so, and say plainly if nothing turned up.

Don't move past this step until:

• The person has confirmed the intent
• You can state in one sentence what the agent will do
• You know what "done" looks like in terms a non-coder can verify

Output of this step: confirmed intent statements with certainty ≥ 90%.

If there's no confirmed intent yet, don't dispatch anything — say plainly that hand-off to an unwatched agent is waiting on that confirmation, and that you can still help directly in the conversation meanwhile.

---

Step 2: Create the Seed

Generate a seed file in this project's own seeds folder (commonly docs/intent/seeds/ at the repo root — use whatever convention this project's /seed or /align skill already established; create the folder if this is the first seed) using this template:

---
name: {short-name}
parent_seed: {this project's own top-level intent document, if it has one}
type: agent-seed
status: proposed
certainty: {from step 1}%
worktree: {short-name}
---

# Seed: {What the agent will do — plain language}

## What this makes possible

{One paragraph. What becomes true when this is done that isn't true now.
Use the person's confirmed words from Step 1.}

## The specific gap this closes

{One paragraph. What's wrong or missing right now.}

## What success looks like

{Bullet points. Concrete things you can check to verify it worked.
Each one should be verifiable by running a command, looking at the app,
or checking a file — not by reading the agent's self-assessment.}

## Scope boundaries

- IN SCOPE: {what the agent should work on}
- OUT OF SCOPE: {what the agent must NOT touch}
- CRITICAL CONSTRAINTS: {anything that could break if done wrong}

## Agent execution instructions

1. Read this seed — it is your contract
2. Commit your work referencing: Implements-Seed: {filename without .md}
3. Before marking done, run your verification items and show actual output
4. Use /complete-seed (and /agent-outcome-summary if you have it) to produce your completion report

Tell the person: "I've created a seed file at docs/intent/seeds/{name}.md. Review it — if anything is wrong, edit it directly or tell me what to change. When it looks right, say 'approved' and I'll dispatch the agent." (If they use Obsidian or another vault viewer over this folder, mention they can review it there — it's optional, not required.)

Don't move past this step until the person approves the seed.

---

Step 3: Write Docs-First Plan

Before dispatching, write documentation for the finished product AS IF it's already built. Add it to the seed file as a "## How this gets used" section.

This documentation should answer:

• What command do you run (if any)?
• What do you see when it's working?
• What do you see when it's broken?
• How do you undo it if it went wrong?

Why docs-first: if you can't write clear docs for what the finished product does, the agent can't build it clearly either. The docs ARE the spec. The agent will read these docs and implement to match.

---

Step 4: Dispatch

If this project has a dispatch script set up (for example, one built during /alignment-harness:harness-setup, commonly scripts/dispatch-agent.sh), run it against the seed file:

scripts/dispatch-agent.sh docs/intent/seeds/{name}.md

That script typically: creates an isolated git worktree for the agent, and prints the dispatch command to paste into a new Claude Code session. Some setups also register the seed for periodic intent reminders during the run (re-surfacing the seed's intent every N tool calls) — treat that as a bonus if your setup has it wired up, not something to assume works; confirm it's actually firing before relying on it (check whatever log location your setup uses).

If there's no such script, do the equivalent by hand:

git worktree add ../{repo-name}-seed-{name} -b seed/{name}

Then open that worktree in a new Claude Code session and paste the seed file's path as the first message, telling the agent to read it as its contract.

Tell the person: "Agent dispatched in worktree seed-{name}. It's working in isolation — nothing can affect your main codebase. I'll tell you when it's done."

---

Step 5: Review (after agent completes)

If this project has a review script (for example scripts/review-dispatch.sh), run it against the worktree name. It typically shows: what the agent was supposed to do (from the seed), what it actually did (the diff), and a review checklist.

Otherwise, do it by hand: git diff <base-branch>...seed/{name} for the code, and re-read the seed's evidence section (from /complete-seed) for the proof.

Tell the person: "The agent is done. Here's what it did: {one-sentence UX summary}. The diff is {N} files, {M} lines. Want me to show you the review, or do you want to merge/delete directly?"

---

Step 6: Decide

The person says merge or delete. Execute whichever they choose.

Merge: cd <repo root> && git merge seed/{name} --no-ff Delete: git worktree remove ../{repo-name}-seed-{name} (or your project's own delete-worktree script, if it has one)

---

What This Skill Does NOT Do

• Modify settings.json or the hook system
• Dispatch agents on tasks that touch payments, auth, or anything else this project's own risk list marks as too sensitive
• Skip the alignment step (Step 1 is not optional)
• Proceed without the person's confirmation at Steps 1, 2, and 6