doodledood/manifest-dev/define

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, as Amendment below describes.

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. Show it verbatim in three parts: the preference, stated as a principle that carries to calls never discussed and naming the kind of call it covers; the rationale, built on the reason the user stated, never one you inferred; and when it should yield. Name the memory file it would go in, and ask whether it is standing or for this case only; "this case only" is a no. Only the user's explicit yes to that text writes it, inside that file's ## Taste section, changing nothing else. When an existing entry decided the reversed call, raise the clash instead — has the entry's default moved, or is this an exception? Show any revision or removal verbatim, and apply it only on the user's explicit yes to that text. 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 ships verbatim.

• Write the current state. A reader who was not in the session reads the Manifest top to

bottom and has the current task, with nothing to piece together — after every amendment as on the first draft. Gates, Intent, Initial Approach and Process Guidance state only what holds now: no date that records when something was decided or changed, nothing about what an item used to say. A gate's Authority names the actual source and obligation. Known Assumptions records unresolved assumptions and material choices without duplicating that authority; an (auto) mark points to a choice made without asking. What changed, when and why belongs in the figure-out log and /do's Execution Log, never in the Manifest.

• Open Intent with the Outcome: the requested result, for whom and in what circumstances.

Keep operational interpretations in working gates, so an invented detail cannot become hard merely by being placed here. State how the whole result will be assessed, using the person's observable use or chosen references and any retained acceptance. An agent-selected assessment method remains revisable; do not add routine owner sign-off when the source did not retain it. Then name the Problem: one specific story of what breaks or grates today, the baseline everything else is pitched against. A session that cannot name a pain has found a stop signal, not an empty field — return to figure-out, or conclude there is nothing worth building. Appetite follows: the size of change the problem is worth, bounding complexity and surface rather than time. Appetite never counts effort an agent controls, such as building and testing, so it never cuts the right solution for that effort alone.

• Cut each Deliverable as a slice that can be finished on its own and

exercised end-to-end — put in front of its real use, not merely inspected as present — which is what lets its criteria judge whether it works rather than whether it exists. A slice cut along a layer ("the data model", "the sources") can only be gated on existence, and it compiles or the file exists are inspections rather than uses. Re-cut incidental implementation layers while keeping their scope, recording the re-cut as an (auto) choice. A deliberately required delivery boundary keeps its source authority: make the work exercisable within it, and surface a genuine conflict rather than silently changing that boundary. A numbered list alone does not establish such a requirement. Order least-proven first within real dependencies, so an unworkable direction surfaces while there is room to turn.

• Make the change easy first. When the shape of a change that crosses a function

boundary — figure-out's sketch, or one drawn here for a direct request — shows that the area it touches resists it (a value threaded through layers, state with more than one writer, a missing seam, a workaround the change would extend), cut a behavior-preserving preparatory Deliverable before the change itself: scoped to what this change needs, pinned by existing or characterization tests, and able to land as its own pull request. Recorded debt on the work's path that still stands, checked against the current code, joins it — offered to an attended user, decided within the caller's delegation when unattended. Debt off the path stays where it is.

• Verification comes before the work it checks. In a project, the verification bullet of the

context file's project-surfaces section records how the project checks that its work still does its job: its verification harness — one command with a recipe per thing it checks, as ../setup-project/references/VERIFICATION_HARNESS.md describes — or its own way, named there; a harness already on disk with no bullet counts as chosen, and an ASM-* suggests recording its bullet. The harness is the project's choice, never the run's. Building is the choice's; keeping sound is every run's: in any form, a check the work meets that is broken, drifting or not fit to trust (../setup-project/references/VERIFICATION_HARNESS.md → Fit to trust) is repaired in its own form, ahead of the work that relies on it.

• Harness: where it lacks what the work needs, or a recipe the work touches is drifting or not

fit to trust, cut building or repairing it, scoped to what the change touches, as the first Deliverable, ahead of any preparatory slice; unattended runs build it too. A Manifest that touches anything a recipe covers, or a path one should cover but does not, carries a gate that each touched recipe is added or updated and run, and what it found reported. A recipe marked ask-first is run only where the project's setting or the user allows — a user who approves a Manifest whose gate runs it has agreed; otherwise its gate holds that the recipe is updated and that the run it still owes is named in the report.

• Its own way, or no bullet yet: gates verify through the means the bullet names, or with no

bullet through the verification assets the project keeps — its tests, scripts and checklists — and no gate or Deliverable builds a harness the project did not choose. A touched check of theirs that fails Fit to trust is repaired in its own form, cut as the first Deliverable like a harness repair. Where none of them can check what the work touches, the first Deliverable adds that check in the project's own form. With no bullet and no harness on disk, record the harness as a recommendation the report carries, as an ASM-*, never as work.

• A recorded check still to be built is built. Search the project's decision records for

Enforced by lines reading not yet. When the work implements or touches such a decision, a gate holds that the named che