define

Read 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 (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 first, propagating when the caller is unattended. A manifest path in the arguments means amend: read 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 . 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 entry. Record each offer flagged upstream as its own 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 .

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 item whose 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 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 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 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:

Before writing gate bodies, invoke the prompt-engineering skill for its calibration if it is available; a body is a prompt the moment an evaluator follows it, and readable-but-vague prose states an aspiration where a check belongs. Come back here — this skill owns the interview.

Identify the task type and load the matching file(s) from . Their Quality Gates supply the qualities to encode as / and their Defaults as before the interview, so the dialogue carries the encoding forward; a Default whose violation would be unsafe or irreversible routes to a Global Invariant instead. A rule the user has stated — in the session or in a context file — or a convention the project states or documents overrides a conflicting Default: omit or adjust the Default. Every Default of a loaded file ends up carried, adjusted or omitted — carrying one changed in a is adjusting it — and each adjusted or omitted one is named in an with why: the rule that overrides it, or what makes it clearly inapplicable. A reader can then tell a Default set aside on purpose from one lost. The context file's outcome rules — naming, structure, architecture — also constrain the shape the Manifest specifies, not only which Defaults it drops. Where the project context file points to a principles skill for an area the work touches — a project skill holding how the project's people want that area's work done — load it: its principles constrain that shape too and outrank a conflicting Default, and a principle the result must not depart from becomes a gate citing the skill as its source. Where what was asked conflicts with a principle and that line's own yield does not cover the case, the principle holds unless the user chose the departure: they named the principle or said to set it aside, or a decision record or a delegation that names the departure covers it. With the user present, ask whether the principle has moved or this is an exception. For an unattended caller, encode the principle's side, record what was asked in an , and open the digest with the conflict: what was asked, the principle, what the Manifest specifies instead, and the one change that restores what was asked. A departure the user chose is encoded as asked, and its names the principle and why ( → Using one). Taste entries stay weighed per call, as above. Per-repo for multi-repo manifests. State what must be true for the artifact's actual users, operators, readers and maintainers over its useful life. Keep the task files' applicable review coverage; several concerns may share a claim and its Evidence when they judge the same result. A review dimension is not a reason for a separate gate. These carry encoder data only — figure-out's own probe files are a separate set this skill never reads, and any is gate-evaluation lookup data, not loaded here. A disposable draft made only to get a person's reaction loads no task file — no Quality Gate and no Default — because that reaction is its check. Its Deliverable owes only that the draft, kept outside the project's files, reaches that person with the question it poses; nothing reviews, tests or checks the draft's quality. Where the Manifest also holds work beyond the draft, load task files for that work as usual and keep the draft's Deliverable outside their gates.

CODING.md

FEATURE.md

BUG.md

REFACTOR.md

UI.md

PR_LIFECYCLE.md

PROMPTING.md

PROSE_FLOOR.md

WRITING.md

DOCUMENT.md

TECH_DESIGN.md

MEASURE.md

PERF.md

HILLCLIMB.md

research/RESEARCH.md

BLOG.md

MARKETING.md

FEATURE/BUG/REFACTOR/PERF compose onto when code changes, adding where the change touches something seen; stands alone for a non-code visual artifact. PERF and HILLCLIMB compose onto ; HILLCLIMB also composes onto the artifact's own file, whose gates become floors every kept version holds. Text-authoring composes with exactly one register — (BLOG, MARKETING compose onto it) or (TECH_DESIGN composes onto it). The two registers never compose together: their rules contradict each other by design, so a deliverable takes the register of its dominant body and the other's gates do not apply. Research composes with its sources. composes where the output ships through a GitHub pull request. does not compose with unless executable code also changes.

The omission valve. A task-file quality concern is omitted only with stated reasoning, on one of two grounds: it is clearly inapplicable, or — advisory-tier concerns only — it fails the bearer test. Each advisory dimension protects some future activity (modification, regression-catching, reading, operating, the next contributor); omit its assessment only where that activity will not occur on this manifest's surface within the artifact's life, and record the omission as an whose assumption is the missing bearer, stated as a fact — "no future reader exists", never "unlikely to find much" — and whose impact if wrong names what goes unreviewed. Weigh surface and stakes together, never size alone: a one-line change on a payment path keeps the full sweep. The full set is the default and doubt includes. Never eligible: defect-finding dimensions, deterministic project gates, safety-critical Global Invariants, and the ceiling. Where a task file splits its Quality Gates into Baselines and Selectable Gates, encode both; the labels say only how far this valve reaches. A baseline holds for every task of that type and is omitted only where the thing it judges is absent from this work. A selectable gate is a degree of rigor some tasks of that type do not call for, so it may also be omitted, with that reasoning stated, where this task's question and stakes clearly do not call for it.

Specialized gates activate a skill. Put the substantive quality claim in the body and the assessment in Evidence: activate the named skill with the claim, relevant source obligations and its dimension or register, never prescribe a further context. The skill owns classification; the Manifest owns what fails. Reviewer grades and recommendations are evidence about the claim, not independent acceptance conditions. A finding must show a concrete failure or material cost in the artifact's supported use or maintenance; a preferred shape alone does not establish one. Keep a deliberately required severity policy, assessment or approval in the claim with its source authority. An agent-selected reviewer or threshold does not become hard by insertion.

Every new Manifest and every amendment gets one review in a fresh context before the digest, attended or unattended. The context that wrote the gates reads them as it meant them, which is how an invented number, a dropped point, two gates that cannot both hold, or a note an amendment left behind survive the reread above. Hand a fresh context the paths of — its brief — this file, , the task files this session loaded, the project context file, any principles skills this session loaded, and any loaded memory file holding Taste entries, and the Manifest; the session record — the path of the figure-out log when one exists, and of the transcript where the host keeps one the fresh context can read, else the conversation itself, passed verbatim; and any model of the design built earlier in the session or recorded in a figure-out log the recall above found, so the review can extend it. For an amendment, also hand it , the Manifest as it stood before, or a diff of the file — never a description of the change — and the steering or decision the amendment encodes. Where no isolated context is available, review against that brief yourself and say in the digest that the review was self-graded. Settle every finding in one pass: fix it, or reject it and name it with the reason in the digest. A fix that changes the Outcome or a hard requirement needs its source's authorization: asked when attended; unattended, return the evidenced boundary without applying it. A working-claim repair within the assignment lands with its basis and refreshed evidence. Any other fix lands wherever its fault sits: in a touched gate, in non-binding text, or — where it changes no requirement, such as removing a note — in an untouched gate. Unattended, a new Manifest also records each rejected or unapplied finding in an . An amendment adds no Known Assumption that only records how a review finding was handled, so such entries do not pile up with each amendment; its digest lists each rejected or unapplied finding as an open item, for the caller to name in its own report. A hole is a result the stated Intent already rejects, so close each one whose gate or design decision serves that Intent, attended or unattended; only a fix that would change the Intent or the scope is the user's call, and unattended one names the hole as still open, replaced rather than repeated by a later amendment. An entry that merely accepts a hole the Intent rejects does not settle it. Settle each ambiguity by writing one reading into the gate. No second review follows.

Give a plain-language digest. Open it with what needs the person, set apart from the rest: a conflict with a principle, as Task files above says; then the user's calls, as The user's call above says; then what is theirs to confirm or veto: the pain, which matters most, being the one thing only the user can confirm and the surface where an invented Problem gets caught, and every number a gate holds the work to (each threshold, bound, count or target, in plain words) so the user can veto one before execution. Then the rest: the intended result, what must stay fixed, what the agent may revise, the plan, how it is verified, and the holes the review found and how each was settled (a search that found none is never offered as proof the Manifest is sound). No codes, no schema vocabulary; it reads like talking to a colleague. Wait for a yes unless the caller is unattended or this is an amendment. Then emit the handoff ( is the absolute path you wrote):

Manifest complete: <manifest-path>

To execute: /do <manifest-path>
For unattended execution, invoke /do <manifest-path> as the execution entrypoint. /do reads the manifest and owns the manifest-completion contract: it sets that completion contract when the active harness exposes a goal-setting or continuation capability, or prints the manual copy-paste contract when not. /define does not set a separate /do goal.

Then stop. A yes to the plan approves the Manifest, not its execution: /do runs only when the user or a calling workflow invokes it, so the lines above are for them, never an instruction to you.