Instructions

Instructions are how you build, written down once and followed every time.

They cover the same ground as your policies, how this organization does things, in a different form: freeform where policies are formal, written at the organization, a team or a project where policies are set once for everyone, and empty until you have something to add where policies arrive generated. Both apply to everything beneath the level they are written at.

Many organizations run on their policies alone at first, and nothing is wrong with that. Instructions are what you reach for after correcting the same thing twice. Correcting an output fixes that output. Writing the rule fixes every run after it, including the ones nobody is watching.

Three levels

Instructions exist at the organization, the team and the project.

• Organization. House style everything inherits.
• Team. That team’s domain, stack and conventions.
• Project. The specifics of this codebase.

Write a rule as high as it is true and no higher. Too high and it constrains projects it was never meant for. Too low and it is a rule you have to remember to repeat.

Where you edit one level, the levels above it are shown read-only, so you can see what you are adding to before you add to it.

Nothing overrides anything

This is the part worth understanding properly.

All three levels are supplied to an agent together, as three separate sets of rules. The project’s instructions do not replace the organization’s, and no level wins over another. There is no precedence to appeal to, because there is no merge step.

So a project instruction that contradicts an organization instruction does not correct it. It just puts both in front of the agent, which then has to pick, and the results stop being predictable.

Each level should narrow what the level above says, not argue with it. If a project genuinely needs to break an organization rule, the rule is wrong at the organization level and belongs fixed there.

Empty until you write them

Instructions are empty at every level when you start. There is a template you can start from, but you have to ask for it. Nothing is filled in behind you.

That is deliberate. Standing rules that nobody chose are the worst kind: they shape everything and no one remembers agreeing to them.

A draft changes nothing

Instructions have a draft state, and agents read the published version.

Editing without publishing is therefore free, and worth using: a rule that is half-written is a rule that will be misread.

Once published, the next run picks it up and every run after that. Nobody has to remember to apply it, which is the leverage, and also why a careless line at the organization level is expensive.

Who can write them

Not the same answer at each level.

Level	Who can write
Organization	Owners and admins.
Team	Members, alongside owners and admins.
Project	Members, alongside owners and admins.

Everyone who can see a scope can read its instructions.

The line is drawn at the organization. An organization instruction sets a standard for everyone, so it sits with the other organization-level governance. Below that, the people doing the work write the instructions for it: whoever notices a missing convention can write it down, in the team or the project where it applies.

Writing a team’s instructions is not the same as administering the team. Creating teams, changing who is on them and connecting their repositories remain owner and admin work.

Check what the policies already say

Before writing an instruction, it is worth knowing how much your generated policies already cover, because it is more than most people expect. Reviewed, tested and scanned before merge; versioned APIs with machine-readable contracts; backward-compatible migrations; rollback procedures; observability designed in; tenant isolation tested; decisions recorded. All of that is already policy, with control IDs, before you write a word. And the approved technology table, generated from your stack and cloud answers, already names tools down to the linter and formatter.

So an instruction that restates a policy is noise. The good instructions add what the policy set does not already carry:

• Fill in an open parameter. The policies name the obligation and leave the value to you: what coverage threshold, which error format, how APIs are versioned, which pagination pattern.
• Say who you build for and what to optimize. No policy knows your users.
• Give the domain its vocabulary and invariants. “Money is always integer minor units” exists in no governance template.
• Draw the scope lines. The module nobody touches, the concern this product excludes.
• Write down the gotcha. The constraint that is invisible in the code and obvious to the team, which is exactly why nobody writes it down and exactly why an agent trips on it.

Writing ones that work

The failure mode is not a wrong rule. It is a rule too vague to act on.

Write intake agents can act on covers that in full. The short version: state the rule and what it excludes, not the sentiment.

For which kind of standing context a given thing belongs in, see Policies, Instructions and Knowledge. If the question is whether it belongs in standing context at all rather than in the work itself, write intake agents can act on puts the specification beside the three.