Skills for coding
with an agent

Makes the agent state what it is assuming — and verify it — before it writes a line.

• The agent lists what it believes about your codebase before editing, so a wrong belief surfaces as a sentence instead of as a broken build.
• Each belief is checked against the repository — a file read, a grep, a test run — rather than asserted.

Decides in one sentence what this session is for, and writes down what it will not touch.

• The session opens with a single outcome sentence and a written not-list of 3–5 adjacent things, both agreed before any edit.
• Out-of-scope discoveries land in a parked list with file paths and one-line descriptions, instead of quietly entering the diff.

Gets the real limits — deadline, platform, budget, who inherits it — out of you before anything is designed around a guess.

• The agent asks a short, specific batch of questions before proposing a design, instead of designing first and hearing about the deadline later.
• Limits you never thought to mention — the phone it must run on, the person who inherits it, the service you are not allowed to call — get written down as facts.

Decides whether a library earns its place, or whether twenty lines of your own would do.

• Before installing, the agent states the one thing the package is needed for, which is usually a fraction of what it ships.
• You see the real cost: how much it pulls in, how big it is, when it last shipped, and how many of your files would import it.

Turns "make it feel premium" into properties with numbers you can check when it comes back.

• Each feel word becomes 3–5 named properties with values — type scale, spacing step, animation duration, border treatment — instead of staying a mood.
• You get an explicit list of what the feel rules out, so the agent knows which obvious moves are wrong before it makes them.

Points at how another product behaves precisely enough to build from, without asking for a clone.

• The reference gets restated as trigger, response, timing, and failure behavior, so you can see whether the right thing was understood before any code exists.
• You get a take list and a leave list, separating the mechanic from the other product's brand, copy, icons, and visual identity.

Forces an honest answer to 'fix it or start over', costed in evidence rather than taste.

• The agent states what the existing code already gets right, including behavior nobody documented, before proposing to throw it away.
• Both options are costed in the same units — files touched, tests to redo, behavior at risk — so they can actually be compared.

Turns a sprawling request into the smallest version that would actually prove the idea.

• The agent restates your request as a numbered list of separable pieces, so you can see how many things you actually asked for.
• One piece is named as the core — the part that, if it worked, would tell you the idea is worth continuing.

Buys certainty about an unknown approach with a throwaway experiment on a fixed budget.

• The agent names the single question the experiment must answer, so you can tell when it is finished.
• A budget is stated before the work starts, and the agent stops at it instead of sliding into building the real thing.

Decides the shape of the screen before any colour is picked, because being recognisable on sight is the failure — not any one ingredient.

• The default arrangement gets named out loud before it is inherited, so choosing it again becomes a decision rather than a drift.
• One structural fact about the brief is written down first, and the layout is derived from that fact rather than from a template.

Starts new code from the closest existing file in your repo instead of from a blank page.

• The summary names the exact file used as the template, so you can diff the new one against it directly.
• Every deviation from that template is listed with a stated reason, and unreasoned deviations get reverted.

Makes new code look like the code already around it, instead of like whatever the agent prefers.

• Before editing, the agent reads two or three nearby files and states the conventions it found — imports, exports, error handling, file layout, test style.
• New code follows the local pattern even where the agent would have written it differently on its own.

Writes what happens when it fails before writing what happens when it works.

• The agent lists the ways the operation can fail before implementing it, including timeouts, partial success and a response that parses to nonsense.
• Each failure gets a decided behavior — retry, fall back, surface, refuse — chosen and written down before the happy path exists.

Bounds a change to what you can actually read before approving it.

• The change opens with a stated budget — files touched, lines added, new files allowed or not — that the final diff is checked against.
• Every touched file gets a one-line reason; files without one are reverted rather than explained.

Fixes how many things may move on a screen before any of them are built, because quantity of motion gives away machine-made work faster than any single effect.

• Everything that would animate is listed and counted first, which is usually the first time the total has been seen.
• Each candidate is ranked by what its motion tells the user, so decoration competes with feedback instead of being added alongside it.

Settles what everything is called before the code is written, so one idea does not arrive under four names.

• The agent lists the nouns and verbs of the feature and picks one name for each, before a file is created.
• Names already used in the codebase win over new inventions, so the feature reads like it belongs there.

Stops the agent coining terms that compete with the words your codebase already uses.

• You get a list of the specific words the agent invented and what your codebase already calls each one.
• A term list maps concept to existing word to defining file, so a reviewer can check the mapping rather than trust it.

Gets the thing running in a single file before anyone decides where its pieces should live.

• The first diff is one file plus zero new directories, with a stated command or URL for actually seeing it run.
• Types, constants, sample data, helpers, and styles stay inline until the behavior is agreed, so early changes touch one place.

Leaves one deliberate place to extend, instead of making everything configurable just in case.

• The agent names the single most likely change and puts one extension point exactly there, rather than adding options across the whole feature.
• The rest of the code stays concrete: no configuration flags, no strategy objects, no plugin registry for something with one implementation.

Lists every state a feature can be in before any of them get coded, so the ugly ones are not discovered in production.

• The agent enumerates the states as a plain list — including loading, empty, partial, stale and error — before writing the component.
• Combinations that cannot happen are made impossible to represent, instead of being policed by a pile of booleans.

Gets one complete path working end to end — real click to real result — before anything gets widened.

• The agent picks one concrete case — one input, one screen, one result — and writes it down before any code exists.
• You get something runnable early: a path you can click through yourself, even while every other case is missing.

Catches the accessibility failures generated interfaces produce almost every time.

• A tab-order walk listing every interactive element, whether its focus state is visible, and whether the order matches the visual layout.
• Every icon-only control and every input is listed with its accessible name, or flagged as having none.

Strips the comments that repeat the code and keeps the ones carrying facts the code cannot state.

• Comments that restate the line below them get deleted, so what remains is worth stopping to read.
• Comments recording a reason, a limit, or a bug someone already hit are kept, and sharpened where they are vague.

Looks for what can come out before anything new goes in.

• The agent hunts for removable code first — unused exports, unreachable branches, superseded helpers, config nobody reads — and reports each one.
• Every candidate comes with the search that proves it has no callers, so deleting is a fact rather than a hunch.

Catches the fix that is not one: trading the machine's favourite look for a tastefuller look you now apply to everything.

• The last three things you shipped get laid side by side, which is the only view in which a personal default is visible at all.
• Each recurring choice is sorted into one of two piles — a house decision with a reason, or a habit with none.

Makes the agent review the change as a stranger would, before it tells you the work is done.

• The agent reads the complete diff line by line and reports what it found, rather than declaring success from memory of what it intended.
• Debug leftovers, commented-out code, stray print statements and unrelated formatting get removed before they reach you.

Names the specific tells of generic machine-made code and design, so you can delete them.

• You get a located list — file and line — of each tell, rather than a general sense that something is off.
• Every abstraction with exactly one caller is named, then inlined or justified in a single clause.

Reviews generated interface against design criteria you can count, instead of "looks fine".

• You get a defect list with file and line locations rather than an overall verdict.
• Countable findings: how many distinct spacing values, type sizes, and colours are in play, and which interaction states are missing entirely.

Checks what the agent said it did against what the diff actually does.

• Each sentence of the summary becomes a numbered claim marked verified, false, or unverifiable, with the evidence named.
• Files changed but not mentioned in the summary are listed explicitly — that is where the surprises live.

Finds what broke it by halving the search space instead of touring the suspects.

• The agent establishes a known-good point and a known-bad point first, so the search is bounded instead of open-ended.
• One repeatable check decides good or bad at every step, applied identically each time.

Finds what changed when, as far as you know, nothing changed.

• The symptom is pinned as an exact command and exact output, reproduced at least twice, before anything is touched.
• "It worked yesterday" gets checked against a specific commit and environment instead of being taken as given.

Reads what the error really says — the file, the values, the chain — before matching it to a bug you have seen before.

• The agent quotes the error text and the relevant stack frames instead of paraphrasing them, so you can check the reading yourself.
• The first frame belonging to your own code gets identified, so the fix does not land on a line inside a dependency.

Requires a failing case you can run on demand before a single line gets changed.

• The agent produces a command or a sequence of steps that fails reliably, and shows you the failure, before proposing any fix.
• 'It happens sometimes' gets turned into the exact conditions that make it happen, or reported as not yet reproducible — never guessed at.

Turns "this should be faster now" into a before number, an after number, and a delta.

• The claim becomes a named metric with a unit and a threshold, both fixed before the measurement is taken.
• You get a before number, an after number, the delta, and the number of runs with their spread.

Settles contradictory answers with an experiment instead of a third opinion.

• The disagreement is reduced to a single proposition that one command can settle.
• Each side's evidence is labeled read-from-the-repo, ran-it, or from-memory — and from-memory loses by default.

Turns “add some tests” into tests that state what the code promises, instead of tests that exist to move a percentage.

• Every test is named as a sentence about behaviour, so a red run tells you what broke before you open the file.
• Assertions land on what a caller can observe — a return value, a written row, an emitted event, rendered text — not on which private helper ran.

Makes the agent prove the bug exists — with a test that fails for the right reason — before it is allowed to fix anything.

• You watch the test fail before any fix exists, so “it is fixed” can never quietly mean “the test never ran the broken path”.
• The failure message is matched against the reported symptom; a test that fails for a different reason is rewritten rather than counted.

Cuts test setup down to the few facts the test actually depends on, so the test says what it means.

• Each test shows the values its assertion depends on, in the test body, named for the role they play — everything else moves behind a builder with defaults.
• You can read a test top to bottom and point at the input that causes the outcome without opening a shared fixture file.

Finds out why a test is intermittent, instead of retrying it until the pipeline turns green.

• You finish with a named cause — shared state, a real clock, an unordered collection, an unawaited promise, a port collision — rather than a retry count.
• The flake is made reproducible on demand through repetition, seeding, forced ordering or constrained parallelism, so “fixed” becomes something you can test.

Points the tests at the boundaries where things actually break, instead of one test per function you happened to write.

• You get a written list of the boundaries this change crosses — network, database, queue, clock, file system, config — and a test aimed at each, instead of a test aimed at each function.
• Boundary tests assert the thing that crosses: the exact request body, the exact stored row, the exact published message, so a silently renamed field turns the suite red.

Proves the feature works in the actual running app, not only in the tests written for it.

• You get a numbered click-by-click script, starting from a cold start, run against the build that actually ships.
• Each step is reported as observed output with evidence attached — screenshot, status code, log line — instead of expected behavior.

Ship behind a flag with the removal already written down, so the flag does not quietly become a permanent fork in the code.

• Every new flag arrives with an owner, a review date and the written condition that ends it, so removal is scheduled rather than hoped for.
• Both paths are run before the flag ships, so the off path — which is your rollback — is not discovered broken during an incident.

Change a schema or move data without ever creating a minute where the running code and the database disagree.

• The change is split into deploys that are each safe on their own — add, write both, backfill, switch reads, stop writing, drop — so none of them needs a maintenance window.
• For every step you can state what the previously deployed version does when it meets the new schema, which is what makes a mid-rollout rollback survivable.

Takes responsibility for code you did not type, before other things start depending on it.

• Every file in the change gets a one-line answer for what it does, why it exists, and what happens when it fails.
• Lines nobody can explain are listed, then explained, replaced, or deleted before merge — none of the three is skipping.

Turns what actually changed into something a user can read — grounded in the commits, not in what you meant to build.

• Every line traces back to a change in the range, so nothing gets announced that did not actually ship.
• Entries are written as what the reader can now do or no longer suffers, rather than as the name of the module you touched.

Work out how you would undo the change before you make it — and find out early when the honest answer is that you cannot.

• You end with an undo written as commands and steps, in order, that someone who did not write the change could run at three in the morning without asking you.
• One-way steps are named up front — dropped columns, deleted rows, sent email, external side effects — and either made reversible or accepted on purpose.

The last pass before a change goes out — what to verify, in the order that catches the most for the least time.

• You read your own diff end to end before anyone else does, which is where debug output, a hardcoded local URL, a stray key and a half-finished rename get caught.
• The change is exercised through the door a user comes in by — the button, the endpoint, the command — not only through the test written for it.

When you are blocked, work out the single question that unblocks the most — and ask that one, well.

• One question goes out, phrased so it can be answered in a word, with your recommended default attached.
• Everything you could have settled yourself is settled first, so the question that reaches a person is one that genuinely needed one.

Push back on a requirement that will not survive contact with reality — with a specific failure case and a way forward.

• The objection is stated as a specific failure — the case, the user, the number, the device where it falls apart — rather than as a feeling about quality.
• The goal gets separated from the requested solution and confirmed out loud, which resolves a surprising share of disagreements before they start.

Give a range, name the assumptions holding it up, and say what it would take to make it narrower.

• You answer with two ends you would each defend, rather than a single number that is really a hope with a deadline attached.
• The assumptions are listed with their consequences, so “this doubles if the endpoint is public” is visible before it happens rather than after.

Records the reasoning a diff cannot show — what you rejected, and what would make this the wrong choice later.

• Each non-obvious decision gets one written reason where the code lives, answering why rather than restating what.
• The alternatives you rejected are named, so the next person does not clean the code back to the thing that already failed.

Compresses a long session into the few things the next person — or the next agent — needs in order to keep going.

• The note opens with the state in three lines — what works, what is broken right now, what has not been started — instead of a story about your afternoon.
• Every half-done thing is named with its path or branch, so nothing important lives only in your head or in terminal scrollback.

Review a change you did not write without quietly rewriting it in your own style.

• Comments are labelled blocking, worth considering, or preference, and only the first kind holds up the merge.
• Style opinions are either dropped or turned into a lint rule, instead of being relitigated on every change.