The order you build in

First: how the skill actually grows

Work with AI for a while and it tends to go the same way. You start out fussing over how to phrase a single request, get tired of repeating the same background, start saving it into files, and eventually end up building tools.

The nine steps below are those three laid out as an actual working order. Steps 1–2 are prompting, step 3 is context, step 8 is tools.

This page is about order and principles, not tool names. Specific services and frameworks appear only as examples; the order survives them changing. The other half, getting people to find it, is in Marketing: the order you tell people.

The most common failure is asking for something that only exists in your head. Ask for something you haven't decided on yet and you get back exactly that much.

Before you ask the AI, ask yourself. Writing it down is what shows you which parts you haven't settled.

Six lines is enough. It takes under ten minutes, and skipping it costs days.

• Actually wrote the six lines down (not just thought them)
• Reduced "What" to one core function
• "How" includes how the money works

Grow the six lines into one spec document. Everything after this measures itself against it.

The spec is the reference. When the code and the spec disagree, fix the spec first, then the code.

Do it the other way round and the document goes stale fast, and once it's stale nobody opens it. Then you're back to explaining everything from scratch every time.

You don't have to write the spec yourself. Hand over the raw material and specify the format and the AI writes it.

Write a spec from the following.

## Project
- Name / one-line definition / where it runs

## 5W1H
- Why / Who / What / When / Where / How
  (the six lines from before, as written)

## Screens
- [list the screens needed]

## Nature of this document
This document is the reference. Every later piece of work
consults it first. Give it numbered sections and anchors so a
specific part can be cited on its own.

## Do not include
Design direction (colour, type, spacing) does not belong here.
Design is managed in a separate document.

## Output
1. Overview · 2. Who it's for · 3. Core features · 4. Screen structure
· 5. Success measures (with numbers)

Save it as a file, then stop without making any other changes.

The last line matters. Drop "stop without making any other changes" and the AI will happily start writing code. It isn't time for that yet.

• The spec exists as a file
• Adopted the rule: code disagrees → fix the document first
• Design talk is absent from the spec

An AI remembers nothing from the last conversation. So you end up saying the same things over and over: the colour, the tone, the things it must never do.

Write them once into a file and the AI reads them automatically at the start of every session.

Split the documents by what they hold. Mixed together, neither works.

The most valuable entry in the rules file is "never do this". Every time the AI repeats a mistake, add a line. The longer that list gets, the less it wanders.

Design lives apart because swapping one file changes the whole feel at once, which is far faster than editing screen by screen.

Rules can live in two places. Rules for this project go with the project; rules you want on every job go global. We keep "deployment requires a passed review" in the global file so every project inherits it.

• Rules and design are separate documents
• "Never do this" has at least three lines in it
• Global rules and project rules are kept apart

Start with functionality and you can't see what you're building. With screens up, a wrong direction shows itself within a day.

Put up the skeleton first: every screen present, nothing working yet.

You don't have to write each screen's instructions yourself. Ask first for "instructions for building each screen, one set per screen" and the AI lays them all out. Then run them one at a time.

Using the spec, build [screen name]. (Screen only for now —
wiring it up comes later.)

What goes on it, top to bottom:
  1. [area] — [what it shows]
  2. [area] — [what it shows]
  3. ...

Decide what it shows when there's nothing to show.
Tone, spacing and colour follow the rules and design documents.

First, plan this screen in detail. (before building it)

"Plan it first" is the important part. Let it build straight away and you get something finished that isn't what you meant. Fixing it at the planning stage is far cheaper.

• Settled the list of screens first
• Had the AI write per-screen instructions before building
• Reviewed the plan before it was built
• Decided the empty and error states too

Having a spec doesn't mean saying "now build all of it". Even if something comes out, you can't follow how any of it was made.

One piece at a time — ask → generate → check → correct. Repeat those four beats.

And don't accept the first result. It takes a round or two of feedback before it's yours. Feedback doesn't need to be long: "drop the testimonials, use a comparison table instead" is enough.

Narrowing the working area raises accuracy. Point at one file when it's one file, one folder when it's a folder. The bigger the project, the more this matters.

• Asking for one thing at a time
• Gave feedback instead of accepting the first result
• Specifying which files or folders to work in

Something that only runs on your machine may as well not exist yet. Close the laptop and it's gone, and you can't show anyone.

Don't deploy after the features are done. Get deployment working the moment the skeleton stands.

Deployment is hard once and close to automatic thereafter. Postpone that hard once until the project is complicated and finding the cause costs twice as much. Do it while it's just a skeleton and from then on saving updates the live site by itself.

• Deployed successfully once while it was still a skeleton
• Confirmed updates now go out automatically
• Opened the live address on another device

Sign-in, storage, payments: you don't build these. You borrow the counter of a company that does only that.

Attaching an outside service follows the same three steps whatever it is: ① sign up and get a key ② put the key somewhere safe ③ connect it and confirm it actually works.

The third one always gets skipped. "Connected" and "working" are different. Use it once for real before moving on.

Keys don't go in the code. Keep them in a separate file and make sure that file can never reach a public repository. This one is worth checking yourself rather than delegating. A leaked key can't be un-leaked.

This is also where things that cost money per use get attached. The moment you connect a metered service, that's a running cost. What to charge for it is step 6 of the marketing page.

• Attached services one at a time, confirming each for real
• Personally verified no keys reach the public repository
• Have a list of everything that charges by usage

This is the third stage. Collapsing the instructions you keep retyping into a single line.

Anything done twice becomes a tool. From the third time on, the time comes back.

Nothing grand required. Ours are things like: scan the code and bring the rules file up to date, run the pre-deployment review, sharpen a plan by asking questions.

A newly made tool isn't picked up until you restart the AI. "I made it but it isn't in the list" is nearly always this.

• Listed the work I've now repeated twice or more
• Turned one of them into a tool
• Always-needed tools go global; project-only ones stay local

AI-written code fails plausibly. Human code tends to fail clumsily; AI code fails wearing a finished face. Reading it isn't enough to catch that.

One part working and the whole path a person actually walks working are different things. What you check before shipping is the second.

Walk the route from arriving to finishing, once, end to end. The question isn't whether each screen loads. It's whether it breaks between them. That's where the bugs live.

We made this a procedure rather than a habit. The deployment command itself is blocked, and only opens when there's a record of a passed review. Change one line after the review and that record is void, so it's blocked again. Better than relying on willpower.

• Walked the whole path once, end to end
• Paid particular attention to the joins between screens
• Made verification a procedure, not a habit

Outside the sequence, all the time

Three conditions for a good instruction

When the output disappoints, the instruction is usually where the problem is. You need all three.

Context is the one most often left out. Say why it's needed and the tone and judgement come out right too.

Pushing a goal all the way

For a large job you have to give both of these. Give one and you get its weakness undiluted.

Goal: [what gets completed]

Done when all of these are true:
  - [a checkable condition]
  - [a checkable condition]

How to proceed:
  - Break the goal into a checklist and work through it one by one
  - On an error, find the cause, fix it, and try again
  - Keep going until every done-condition is met
  - Summarise what was done at the end

Write done-criteria as things you can check. "It works well" isn't checkable. "Opening this address shows the list" is.

When there's an error

Red text usually gets fixed by the AI itself. The question is when to wait and when to step in.

And after the same error three times, change the approach. A fourth identical request is wasted time. Narrow the scope, add context, or break it smaller.

What not to do

• Don't ask for what's only in your head. Write it down first
• Don't build without a spec
• Don't ask for everything at once
• Don't accept the first result as-is
• Don't put keys in the code
• Don't leave verification to willpower. Make it a procedure

The whole thing, in one line

Write it → spec → rules → screens → build in pieces → deploy → back end → tools → verify. The first three involve no code at all. Skimp there and it all comes back at you later.

The AI writes the code. What's left for the human is deciding what to build, setting the rules, and checking the result. The rest can be asked for.

After this order comes the order you tell people. We're still walking that road ourselves, and we'll revise this page as we learn. If something here is wrong, tell us.