Complete Seed — Evidence Collection Before Completion

What This Does

You invoke this when you believe your work is done on a "seed" — an approved task description created by /dispatch-seed, /seed, or /align (whichever of those you have). It walks you through collecting EVIDENCE that your work actually did what the seed says it should do. You cannot mark the task complete until you've done this.

This is not a punishment. This is how you prove to yourself, and to the person you're building for, that the work is real. An agent that collects evidence is an agent that can be trusted with bigger tasks next time.

This is the seed-scoped, artifact-producing version of "don't claim done without proof." If your harness install has the always-on evidence gate (the Stop hook that checks any completion claim for real command output), that one still applies to every turn regardless of whether a seed is involved — this skill is the deeper version for seed-tracked work specifically, not a replacement for it.

When to Invoke

When you think you're done with a seed task. Before your final message. Before marking any task complete.

Step 1: Re-read the Seed

Read the seed file you were given. Find the "What success looks like" section. Each bullet point is a success criterion you need to verify.

List them out:

Success criteria from seed:
1. {criterion 1}
2. {criterion 2}
3. {criterion 3}

If you were asked to run this skill but have no seed in hand — or the seed has no "What success looks like" section — say so plainly and point back to whichever skill was supposed to create it (/dispatch-seed, /seed, or /align). Don't invent success criteria on the spot.

Step 2: Verify Each Criterion

For each criterion, run a concrete verification:

• If it's about a page loading or looking right: use whatever visual-verification tool this project has set up (a browser MCP, Playwright, or similar) to load the page and capture a screenshot. Save it under this project's seeds folder — usually docs/intent/seeds/evidence/{seed-name}/ — with a descriptive filename. If no such tool is configured, say so and describe in words exactly what you observed (what you ran, what appeared) instead of substituting a screenshot you don't have.

• If it's about an API returning something: run a curl command and paste the actual output.

• If it's about code existing or not existing: run a grep and paste the result.

• If it's about a test passing: run the test and paste the output.

• If you CANNOT verify something: say so explicitly. "I cannot verify criterion 3 because the staging server is not running." Do NOT substitute your opinion for evidence.

Step 3: Build the Evidence Report

For each criterion, tag it:

## Evidence Report

### Criterion 1: {description}
**Status:** VERIFIED
**Evidence:** {actual command output or screenshot path}

### Criterion 2: {description}
**Status:** UNVERIFIED — {reason you couldn't verify}

### Criterion 3: {description}
**Status:** BLOCKED — {what's preventing this}

Step 4: Attach Evidence to the Seed

If you have screenshots, save them under this project's seeds-evidence folder and add links to the seed file:

## Evidence (collected {date})

![{description}](evidence/{seed-name}/{filename}.png)

{evidence report from Step 3}

Step 5: Update Seed Status

Update the seed's frontmatter status field:

• If ALL criteria are VERIFIED → status: evidence-collected
• If SOME are verified, some unverified → status: partial-evidence
• If ANY are BLOCKED → status: blocked

Then say so plainly, in the moment, rather than ending silently: name the seed file's path and its new status, so the hand-off actually lands instead of being implied.

Step 6: State What Changed, In Plain Terms

Write one sentence per change in the format: "When {a person does X}, they now see {Y} because {Z}"

This is what a non-technical reviewer reads. Not what files you edited. What changed in the experience of the product.

What This Skill Does NOT Do

• It does not merge code
• It does not modify hooks or settings.json
• It does not self-assess quality ("I think the code is good") — it collects EVIDENCE
• It does not mark the task as approved — only the person you're building for does that

After This Skill Completes

The seed file now has evidence attached, at a path you've just named. The person can open it — in Obsidian if they use it, or in any plain-text/markdown viewer otherwise — see the evidence, and decide: approve (merge the work) or reject (delete the worktree). They don't have to dig through transcripts or ask what happened — the seed tells the whole story.