Fullsend a feature. Come back to verified code.

---
name: fullsend
description: Use when you want a feature built end to end without interruptions. Fullsend orchestrates planning (when needed), implementation, QA, and a local merge from a plan or refined idea.
---

# Fullsend

## Overview

Fullsend drives a feature from a clear source document to verified, locally merged code:

**(plan) -> execute -> QA -> merge**

It starts from either:

- an existing plan in `docs/plans/`, which skips planning; or
- a refined idea in `docs/ideas/`, which runs planning first.

Ideation is upstream. If the feature is still vague, do not fullsend it yet.

Fullsend is a high-autonomy workflow. It writes code, commits changes, runs verification, and merges locally without asking product questions along the way. Safety comes from isolation, explicit state, a decision log, and a hard QA gate.

At the start, announce: "I'm using the Fullsend framework to build <name> autonomously."

## Inputs

Resolve `<name>` or an explicit path in this order:

1. A matching plan in `docs/plans/` -> start at execute.
2. A matching idea doc in `docs/ideas/` -> start at plan.
3. Neither exists -> stop and ask for a refined idea or plan.

## Autonomy contract

- Do not interrupt for product questions. Resolve ambiguity from the source document, repository strategy and standards, the existing codebase, and best judgment.
- Log every material judgment call in the decision log.
- Stop only for completion or a hard technical blocker: planning cannot pass review, the build or tests cannot be fixed, or QA cannot reach green.
- Never merge broken code.
- Never push to a remote or open a pull request autonomously. The final merge is local.
- Do not add AI co-author trailers to commits.

## Resumable state

Maintain `docs/fullsend/<name>.md` in the main repository:

```markdown
# Fullsend: <name>
Base branch: <branch launched from>
Worktree: <path>   Branch: fullsend/<name>
Source: <plan path | idea path>

- [ ] plan    -> <plan file>
- [ ] execute
- [ ] QA
- [ ] merge

## Decision log
- <when>: <decision> — anchored on <source>
```

If the run resumes, read this file first and continue from the first unchecked stage.

## Pipeline

### 0. Isolate

Create a dedicated worktree and fresh `fullsend/<name>` branch from the current base branch. Record both in the state file. All implementation and QA happen inside this worktree.

### 1. Plan

- If the source is already a plan, mark this stage complete.
- If the source is an idea doc, turn it into an implementation plan using the idea's locked product decisions, scope, repository strategy, and the real codebase.
- Resolve planning questions autonomously and record the decisions.
- Review the plan before implementation. Stop if it cannot reach an acceptable standard after reasonable fixes.

### 2. Execute

Implement the plan in the isolated worktree.

- Follow repository instructions and established patterns.
- Keep commits small and clearly named.
- Run relevant checks as the work progresses.
- Resolve non-blocking questions from the source and codebase, then log the call.
- Do not broaden the product scope merely because the agent can.

### 3. QA

Verify the real user flow, not only the type checker.

- Run the repository's build, lint, tests, and route checks as applicable.
- Exercise changed flows in a browser or the closest realistic environment.
- Fix every issue found and repeat verification.
- Record what was tested, bugs found, fixes applied, and anything that could not be exercised.
- Stop if the feature cannot reach green. Never merge around a failed gate.

### 4. Finish

When QA is green:

1. Merge the Fullsend branch locally into the recorded base branch.
2. Re-run the critical post-merge check.
3. Remove the worktree and delete the local feature branch.
4. Mark the state file complete.
5. Report what shipped, verification performed, and any remaining limitations.

Do not push or open a pull request unless a human explicitly asks.

## Common mistakes

- Starting from a vague request instead of a refined idea or plan.
- Pausing for product questions that the source already answers.
- Treating a passing type check as QA.
- Running QA in the main checkout instead of the isolated worktree.
- Hardcoding the base branch instead of recording the branch used at launch.
- Forgetting to log decisions, leaving a resumed run without context.
- Merging broken code or pushing it remotely without approval.