/define

name: define
description: 'Manifest builder. Turns shared understanding into a verifiable Manifest with Deliverables, Acceptance Criteria, Global Invariants, and an Initial Approach. Use when planning features, scoping refactors, debugging complex issues, or when the user asks to define, scope, plan, spec out, make a manifest, or break down a task.'
argument-hint: '[task] [<manifest-path> to amend] [--babysit <pr-url>] [--autonomous]'
user-invocable: true

Read `../ticket-up/references/AUTHORITY.md` before acting. Keep this assignment, its applicable authority and retained decisions in every skill handoff; an isolated caller must receive them explicitly, with the useful intent and evidence.

Encode the conversation's shared understanding as a Manifest at `~/.manifest-dev/manifests/manifest-<ts>.md` (create the dir; fall back to a writable temp path only if home is not writable); how you interview is yours. No shared understanding in the transcript → invoke `figure-out` first, propagating `--autonomous` when the caller is unattended. A manifest path in the arguments means amend: read `references/AMENDMENT.md` before changing that Manifest.

Project surfaces — setup and its update, the verification harness and its recipes, decision records, the glossary, the North Star — belong to a project: a repository or working folder holding, or about to hold, work later sessions will change — a new one the user is starting counts — which this work concerns. A chat with no workspace, a home or scratch folder, a folder holding one finished artifact, or a question that does not concern the folder the session runs in is none. There, offer, build, read for, gate on or record none of them, and write the Manifest as usual, its own gates checking the work directly. One-off work inside a project is still project work: it keeps the gate of every recipe whose paths it touches.

Before encoding a new Manifest for work in a project, read what earlier work left on it — logs and Manifests for this repository, open Tickets on the work's paths, and pull requests' "Debt left" sections — following `../figure-out/references/RECALL.md`. For a project, note in the digest when its surfaces version, read from the context file on disk, is missing or older than setup-project's newest, without stopping to update, and record it as an `ASM-*` entry. Record each offer flagged upstream as its own `ASM-*` entry, so the completion report names it.

figure-out reaches understanding of the problem; this skill makes the agreement executable. Keep the intended result and hard requirements distinct from the agent's revisable operational choices. Resolve a missing user decision only where it changes that agreement; choose the representation and methods yourself, recording material assumptions in `ASM-*`.

Where the host offers a question-selection capability — a way to put a question to the user as options to pick from, with room to answer in their own words — ask through it by default, with your recommended answer as each ask's first option. Key calls are mostly independent of each other, so batch them there into as few turns as they allow; a call whose answer would change another's goes first, and the other waits for it. Without that capability, or once the user has asked you to ask in prose, write the ask in plain text, one ask per turn. An unattended caller is asked nothing: decide each call within its delegation and record each material one as an `(auto)` item whose `ASM-*` names the rationale and impact if wrong.

**The user's call.** A decision is the user's call when two careful people with the same evidence could reasonably decide it differently, and the difference would matter to the user. Test each material decision against that sentence; your own confidence does not settle it. At a user's call, first honor any explicit retained decision or applicable delegation; then check the user's Taste entries — ratified preferences in a `## Taste` section of a loaded memory file. Follow an entry only where it clearly bears: it speaks to this kind of call, and following it would change the choice. A general lean that would tilt almost any call, such as less effort or lower cost, does not bear on its own. Otherwise decide on the evidence. Wherever decisions are reported, list first each decision record the run reopened, with the reason set aside and what reversing would cost, then the user's calls, each with the alternative not taken and what decided it — the entry followed, or that no entry applied.

**Taste on reversal.** When the user, present in the session, reverses a call an earlier run made and states why, and the reason is a preference another user could want the opposite of — not a behavior every session owes — offer a Taste entry before the handoff: read `references/TASTE_ON_REVERSAL.md` then, and make the offer as it says. An unattended session makes no offer. A reaction to a disposable draft — a throwaway rendering made only to get that reaction — is about that draft's direction, not such a reversal, unless the user states it as reaching beyond that artifact.

Carry the prior Read's useful rationale, intended progress, circumstances, trade-offs and uncertainties into Intent, Approach and Assumptions, as reasoning that holds now rather than the Read's provenance notes and dates; encode retained decisions and other binding authority limits in gates. The Manifest is finite work, not the project's permanent direction record.

The Manifest is the acceptance contract — what the user accepts as "I'd ship the outcome of executing this" — and `/do` executes it later with none of this conversation's context. Its Outcome states the result owed; its gates state the current acceptance claims, each with its source authority and a separate evidence method. That gives a floor that isn't ceremony:

• Follow the schema in `references/SCHEMA.md` exactly — it is what the executor

parses, and it carries the ceiling invariant every manifest