Quick — one job, none of the machinery

Load when: someone asks for one thing and clearly does not want a project around it.

Over-serving someone who asked for very little is the most common failure in practice. Not under-serving. That is why the list of what a quick job does not get is written down rather than left to judgement — the temptation is always to add "just one small thing", and each addition is individually reasonable.

The shape

Three questions. One or two workers. Build → review. Done.

The three questions are whatever is genuinely unknown — usually what exactly, where does it land, and how will we know it worked. Not a checklist: if context already answered one, skip it.

The review still happens. It is the one piece of apparatus a quick job keeps, because it is what distinguishes "done" from "produced". It goes to someone who did not write the thing.

What a quick job does not get

One thing it does get, first, so the list below cannot swallow it: the run is recorded. Not a task, not an id — the plain fact of what ran, what it produced and what it cost, written wherever the record lands (./storing). It is the one piece here that pays off inside the hour: a job that dies has something to resume from, and "what did that cost" has an answer.

• an id — no task file, no history, no relations
• a stage ladder — build and review are not a pipeline
• a role — no hiring, no roster entry, no avatar
• a docs skeleton — no decisions file, no roadmap, no team document
• a discovery pass, a success predicate, a definition of done
• a repository set up around it, unless one already exists

The reason is not tidiness. Each of those exists to make work findable, comparable and resumable over time, and a job that ends in an hour has no time to be findable over. The apparatus costs the same whether the work is large or small; the benefit does not.

This is a list of what is not created — not of what is not recorded, which is why the record is stated above the list rather than below it: a reader who stops at the bullets would otherwise carry away the opposite rule.

And it is not a list of what may be invented. Dropping the discovery pass drops the procedure, never the input.

Where that input is already written down, it is read — not asked for. docs/assets.md, docs/TOOLING.md, docs/design-system/, docs/DECISIONS.md, ./sources: a quick job skips discovery, never the project's own record. Four files cost less than one wrong question, and a question the register already answers reads as not having looked — because it is. Measured twice, on the same fixture: asked for stock photos in a project whose register held a commissioned shoot, a licensed type pair and a one-icon-set rule, two runs asked the owner what the brand constraints were and named none of it. Both were obeying the sentence below, which is why it now comes second.

Then, where the work needs something only the owner holds — their taste, their brand, their real names and numbers, what they do not want — it is asked, in one short message, however small the job is. A palette, a typeface or a set of services chosen for them is not a smaller version of the work; it is different work, and telling them afterwards is not the same as asking. The same goes for anything the job would add to what they own — a dependency, a hosted font, an account. Measured: a run correctly classified a one-page fix as quick, then picked the colours, the fonts and the services for a therapy practice and surfaced all three as notes at the end.

Where the line is

By category, not by size. The question is not "how many hours" — it is what this leaves behind.

Quick	Not quick
ends when it ends	someone will come back to it
one craft	needs a second craft's judgement
no lasting decision	changes how something is done afterwards
nothing outward	publishes, deploys, spends
product work	touches the project's own machinery — always full history, however small → ./self-maintenance

The gates still apply. A quick job that publishes, spends or destroys hits the same four owner-gated kinds as anything else. Small is not a permission level, and the request itself is not blanket authorisation for the next one.

When it stops being quick

Say so, once, and let the owner choose. Growth is normal and the failure is not growing — it is growing silently, so that an hour's job quietly acquires a roadmap.

"This is turning into three pieces with a review between them — make it a proper task? It gets an id and the pieces already done come with it. Or keep going as is?"

The offer names the act and what carries over; a bare "want me to step back?" hands the shape back to the owner to design, which is the measured failure → ./checking.

If they say yes, the next step has an address: a task takes its shape from templates/TASK-template.md and its rules from ./writing-work; a whole project starts at ./starting. What was already done comes with it rather than being redone — the growth is a promotion, not a restart.

Whatever it outgrows is added later, and nothing is lost by having started small: a quick job that becomes a task gets an id then, and the work already done comes with it.

The reverse never happens automatically. A project does not become a quick job because things went well.

The failure this file exists to prevent

"Rename the buttons on my landing page and push it."

A run that answers this by interviewing the owner about their team structure, standing up a roster and writing a decisions log has failed — even if the buttons get renamed. And the push is outward, so it is asked about; asking is not the same as building apparatus.

The eval for this is deliberately the first and most trivial one, because a suite made only of hard cases hides the failure that matters most in practice → ./scenarios.