/complete

Complete current task properly with full verification. Session ends after completion.

Agent Complete - Finish Task Properly

**Usage:**

• `/jat:complete` - Complete current task and show completion block for review
• `/jat:complete --kill` (or `-k`) - Complete task and auto-kill session (no review)

**What this command does:** a thin wrapper around `tools/core/jat-complete-exec` (`specs/prd-cli-completion.md`) — one deterministic pipeline driven by the brief you composed on the `review` signal: build gate → `jat-runtime-verify` → commit → land (worktree spawn) or push (direct) → memory entry → reporter reply (if applicable) → release file lease → `jt close` (always LAST). **The brief field guide** (`commitMessage`, `stagePaths`, `memoryEntry`, `devResponse`, `teardown`, `docsTouched`, `briefRev`, `doNow`/`doLater`/`suggestedTasks`) lives in `/jat:start` → "When You Finish Working" — not repeated here.

**When to use:** after displaying "🔍 READY FOR REVIEW" and the user approves. **When NOT to use:** to pivot quickly mid-task → `/jat:pause` instead.

**PREREQUISITE:** a `review` signal with a `brief` (composed per `/jat:start`'s field guide) must already be live — `jat-complete-exec` can reconstruct a minimal one from the review signal + git diff, but that's a safety net, not a substitute for composing the real thing.

---

CRITICAL: "Ready for Review" vs "Complete" — never confuse them

| State | Display | Task Status | |-------|---------|--------------| | **Ready for Review** — awaiting user decision | "🔍 READY FOR REVIEW" | `in_progress` | | **Complete** — closed, reservations released | "✅ TASK COMPLETE" | `closed` |

Never say "Task Complete" until `jt close` has actually run — other agents check the queue and will see the task as still in-progress if you announce completion early.

---

Implementation Steps

STEP 0: Detect `--kill`

If `--kill` or `-k` is in the command args, set `is_kill=true` and output:

💥 SELF-DESTRUCT MODE: Session will self-destruct after completion.

STEP 1: Identify Session, Agent, Task

get-current-session-id                                  # session_id
# Read .claude/agent-{session_id}.txt                    # agent_name
TMUX_SESSION=$(tmux display-message -p '#S' 2>/dev/null)
cat "/tmp/jat-signal-tmux-${TMUX_SESSION}.json" 2>/dev/null | jq -r '.task_id // .data.taskId // empty'
jt show "$task_id" --json                                # confirm it exists

If no task is found (empty signal file, no `in_progress`/non-closed task assigned to you in `jt list --json`), treat this as **spontaneous work**: infer a title/type/description from the conversation + `git status --porcelain`/`git diff --stat`, propose a backfilled task (`jt create ... --status in_progress`), continue to STEP 2 only if the user confirms — else stop and point the user at `/jat:start`.

STEP 2: Pre-Flight Authoring (feeds the brief you compose in STEP 3)

• **Docs:** most tasks skip this — only new tools/endpoints/breaking changes/config get a 1-3

line addition to an existing section, never a new one.

• **Changelog:** only user-visible changes, only if `CHANGELOG.md` exists — one line under

`## [Unreleased]`.

• **Teardown:** dev servers/watchers/background jobs THIS session started (not a shared service

you merely connected to) as shell commands in `brief.teardown` — `--kill` only kills the tmux session, not child processes.

• **Browser evidence:** if `filesModified` touches routes/components, capture a

`.jat/runs/<taskId>/` bundle via `jat-run-workspace.js` (recipe: `jat-browser flows run-workspace-verify --json`) and attach it to the `review` signal's `evidence` field (`runDir`, `screenshots`, `harEntries`, `harFailures`, `consoleErrors` — from `summary.json`, never estimated).

• **Fleet-skill nomination:** nominate **0–2** lessons from this session that would help an

agent doing a *different* task in the same class. Zero is the common and correct answer — see the bar below.

  jat-lesson nominate \
    --title "Short imperative lesson" \
    --trigger "when does this apply — situation + keywords a future task would match on" \
    --recipe "Self-contained steps. No task IDs, no 'as described above', no this-session context." \
    --task "$task_id" --confidence 0.9

Lands as `candidate`; a human or overseer runs `jat-lesson promote <id>` to embed it and make it retrievable. Nominating does not publish — that gate is the point.

**The bar (a nomination is a claim on every future agent's attention):**

| Nominate | Do NOT nominate | |---|---| | A hazard that silently produces a wrong result | What the code already says | | A tool/flag whose absence costs an hour of rediscovery | Anything in `AGENTS.md` or a CLAUDE.md | | A failure whose symptom points at the wrong cause | This task's status, or what you built | | A lesson that generalizes past this file/feature | A lesson only true for this one task |

The memory entry in `brief.memoryEntry` is still the full record and is written regardless — nomination is the narrow, curated subset that earns fleet-wide injection at `/jat:start`.

STEP 3: Ensure the Brief Is Ready, Detect Mode, Run the Pipeline

Everything from here runs inside one deterministic CLI, `jat-complete-exec` — compose the brief and mode, then react to the exit code.

**3A — brief check:**

jt show "$task_id" --json | jq -r '.[0].metadata.waypoint // empty'

Non-empty with `commitMessage`+`stagePaths` or `memoryEntry` → proceed to 3B. Otherwise compose one now (per `/jat:start`'s field guide) and re-emit `jat-signal review` with `brief` included.

⚠️ If you stage that payload in a file, put it in your **per-session** scratchpad named for the task, and assert `jq -r .taskId` matches before emitting — a bare `review.json` at the shared `/tmp/claude-1000/` root is how one agent published a review over another agent's waypoint, leaving a `stagePaths` entry