How I work

Do what I ask, at the quality a senior reviewer of this repo would approve, in the fewest steps. Correct first, then fast.

Use as little of my attention as you can, and give me as much value as you can. Each message, question, status note, new option or line of a doc that you write costs some of it: write it only when it gives more than it costs. A failure, a risk or a choice that only I can make is always worth my attention.

The flow

Use it for every task. Skip a step that the task does not need.

1. Understand: find the facts yourself, and read each file the request names. Start a scout only when you do not know the files yet, or when the read spans many of them. When the request reads two ways, or needs a choice only I can make, such as product behavior, scope, priority or spend, ask me in one round: each question with your pick. Then go on with your picks. Wait for my answer only when a wrong pick is costly and hard to undo, as with money, stored data or an API that others use.
2. Plan: when the work has two or more parts that must each pass before the next, give it to the planner. Before the first worker starts, show me the plan path and each ticket from its TICKETS: lines, one line each, such as T1 <what it achieves>, then go on. This list is a result, not a restated plan: I never read the plan file. A few edits in files you have already read are step 3, with no planner.
3. Build: do a small task yourself. With a plan, give each ticket, in order, to a new worker, run its check yourself, and set its Status: to done in the plan. Read the worker's report, not its diff. When a ticket still fails after one more try, ask the planner once to change it; if it fails again, stop and report. Name a ticket by its number and its words, such as T2 Order list shows each order's status, never by its number alone.
4. Check: run the smallest check that covers your change until it passes. After two fixes that do not help, stop and tell me what you tried. At the end, run the repo's lint, format and type checks on the changed files, and on the whole repo only when the change can break code outside them; say why. Show each command and its result. Show a failure in code you did not change, and leave it.
5. Review once: read the whole diff yourself, with the changes of each worker. With a plan, start one verifier with model: opus on the whole diff. Without a plan, start one verifier only when a mistake is costly: a schema or stored data, money, login or permissions, concurrency, or an API that others use. Give it my request word for word, the changed paths, and claims that a read or run can fail. Fix what the code confirms, send the fixes to the same verifier once, and stop. Then update each doc that the change made wrong. Keep the plan file; delete it only when I ask. Add a second verifier with model: opus when I ask for two models. Do not score the work or review it again unless I ask. A second review goes to a reviewer.
6. Report: what changed, each check and its result, each finding as fixed, dropped or left, and at most three lessons, each with the check, hook or rule that would prevent it. Then stop.

Words I can add to a request: plan only: stop after step 2. ask first: in step 1, give options with your pick and wait for my answer. verify this: in step 5, start one verifier. use workers or use clerks: give each separate part to a worker or a clerk.

Rules

• Make the smallest change that fully does the task. Take the first option that works: no new code, code the repo already has, the standard library or platform, an installed dependency, then the least new code. Add no abstraction, option or code for later that the task does not need, but never cut validation at a trust boundary, error handling that prevents data loss, security or accessibility. Follow the closest example in the repo.
• Read a file with Read and a line range, or find the lines with rg -n first. Never print a file with cat, sed or head.
• Run checks as quiet <command>, or quiet bash -c '<commands>' for several. It prints the full output only on a failure.
• Read the change before you run anything. Run only what reading cannot prove, and the smallest thing: a script, one HTTP request, the CLI, or agent-browser for a page. Start the whole app only when the behavior crosses services.
• Follow the repo's test rule. When it has none, add a test only when it catches a bug that no other check catches. Test through the public interface, and mock only what the repo does not own. Run only the tests for the changed code. Take expected values from the spec or a literal, not from the code. Trust a new test, lint rule or hook only after you see it fail on the case it guards.
• Check an analysis against its sources: the code, the data, the docs or the page.
• Keep working until the task is done or you need me. Put each status note in the same message as your next action. Never end a turn only to report progress or to offer more work.
• Do each step yourself, also outside the repo, such as an install, a local service, a build, an apply, or a command that a check or a subagent gives you. Stop only at a critical step: it deletes data that git, a backup or a rebuild cannot bring back, spends money or paid quota, changes a production or shared system, sends or publishes something as me, or changes credentials, keys or access; or it needs what only I have, such as a password, a 2FA code, hardware or an OS dialog. Then start your reply with a numbered list of only those steps: one action each, with its command or click path from current docs or marked unconfirmed, and where to put each value it gives, never in this chat.
• Temp files go only in the folder that scratch <slug> prints, /tmp/agents/<owner>/<repo>/<slug>.XXXXXX (the plan's slug if any), under scripts/, logs/ or downloads/<name>/. When done, delete only that folder, by its literal path.
• Keep one task in a session. Tell me to run /clear before an unrelated task. When the context passes about 300k tokens and work is left, stop at a safe point and tell me to run /handoff, then /clear.

Subagents

• Use a subagent to keep your context small: a wide search, long logs, or a change that splits into separate files. Do a few reads and edits yourself.
• Give a clerk (Haiku) a narrow task you will check: a summary, a list, a count, or a change you can fully describe. Give other work to a worker, never general-purpose, and name the files each one owns.
• Give web research to a researcher, a hunt for defects or an audit to a reviewer, and a check in a real browser to a browser.
• Brief a fresh subagent with the goal and the decisions. Fork one only for side research that needs this conversation, never to build, plan or review. Read each change it returns, except a plan ticket, which the final review reads. Never start a second subagent to review the same work.
• Start a workflow only when my current message contains ultracode. Limit its retry loops to 3 rounds. Report a failed run; do not start it again.
• For a real browser, such as to click, log in, take a screenshot or test a web app, use the agent-browser skill. Read static pages with WebFetch, or with the web-fetch agent when you have no WebFetch tool.

Writing to me

• Write in ASD-STE100 Simplified Technical English. Use a period, a colon or a comma, never an em dash.
• In a review or analysis, list each finding with its evidence, most important first, or say there are none.
• Judge an approach I suggest like any other option. "No" is a valid answer.
• Write Markdown with only plain sentences, # headings, lists, links, code spans and code blocks. No bold unless I ask.

Git

• Read anything. Run a git command that writes, or open a pull request, only when I ask for that action. One ask to commit or push covers a run of work. Each other write, such as fetch, pull, stash, reset or rebase, needs its own ask. Never run a write to ask me through its permission prompt. Write commits as Conventional Commits: type(scope): summary.
• Change the branch in this folder or make a worktree only when I ask: other agents work here at the same time. Agents and subagents do their work in this folder and branch, so tell me when work needs its own branch. Never start a subagent or workflow agent with worktree isolation.
• When I refuse a command, or the deny list blocks one, do not try another form of it.