Tier 1 of 4

Prototypes & landing pages

A light setup for work that may be thrown away. You get one file of project rules, a few basic checks, and a place to note decisions.

1 personWeeksSomeone will ask: Nothing+ Access: People sign in, and what they see depends on who they are
Give this to your agent
Set this repo up to ntent tier 1.

Fetch https://ntent.app/r/tier/1.json?with=signin and follow the plan in it exactly. Write every file verbatim, and check each file's sha256 against its step before you write it. It also carries steps that follow from what the product is: people sign in, and what they see depends on who they are. Those are as required as the tier's own.

Skip any step whose "needs" this repo does not satisfy, and do not install a framework just to satisfy one. Run each step's verify line before you call it done, write the manifest the plan describes, then tell me what you installed and what you skipped.

Reads https://ntent.app/r/tier/1.json?with=signin

Install plan8 steps

Follow the steps in order. Then 2 more that follow from what you said the product is. Each step ends with a quick check the agent must run before it says the step worked. At the end, it writes a short record of what it added, which version it came from, and what it skipped.

Tier 1

Prototypes & landing pages

6 steps · 01–06
  1. 01
    Shared project instructionsA person checks this

    Everyone inventing their own conventions, and every assistant inventing a different set again.

    writes AGENTS.md · point CLAUDE.md at it with a one-line @AGENTS.md import

    Then edit It is a template. Replace every <angle bracket>, delete the sections marked for tiers above yours, and cut any row of the enforcement table whose command this repo does not have.

    Verify Ask an assistant "what are the rules in this repo" and it answers from the file.

  2. 02

    2 rule files that disagree, because one tool reads CLAUDE.md and another reads AGENTS.md.

    Skipped unless the repo has AGENTS.md.

    Verify Run it twice: the second run says there is nothing to do. Then start a session and ask the assistant to name a rule that only exists in AGENTS.md. In Claude Code, /context lists CLAUDE.md under Memory files. Copy a line of AGENTS.md into CLAUDE.md and run it again: it names that line and leaves it where it is.

  3. 03
    Pre-commit checksBlocks the commit

    A mistake caught an hour later on the build server, after someone has already spent time reviewing it. This catches it on your machine, before the commit.

    writes scripts/git-hooks/pre-commit · make it executable

    Verify Stage a file that fails a check this tier installs and the commit is refused, naming the check and the fix. At tier 1 that is check-env: add a variable to the env schema and not to .env.example. The hardcoded-colour case needs the tier 2 lint rules.

  4. 04

    Store hook setup in git so every contributor and coding agent runs the same checks.

    merges into package.json · inside the "scripts" block

    Verify Run pnpm install, then `git config core.hooksPath` prints scripts/git-hooks. A fresh clone gets the same answer with no manual step. Leave .git/hooks alone: it may hold hooks somebody else installed.

  5. 05

    A setting the app needs that is missing from .env.example, so someone who downloads the repo cannot start it and has no idea why. Also the reverse, and code that reads process.env directly instead of through the schema.

    writes scripts/check-env.mjs

    Then edit Point CONFIG.schemaFile at this repo’s env schema, CONFIG.exampleFile at its example file, and CONFIG.sourceDirs at the directories it keeps source in, if they are not src/env.ts, .env.example and src. The pre-commit hook reads those three back out of the file, so moving them keeps the gate wired.

    Verify Add a variable to the schema, do not add it to .env.example, and the check names it.

  6. 06
    Decision logA person checks this

    The same decision being re-made in month 6 because nobody remembers the reason for the first one.

    writes DECISIONS.md

    Then edit The first entry is an example from a billing app: delete it. Then write the decisions this project has actually made, one entry each, and label any whose source is memory rather than a thread or a call as "(from memory)". A fresh project may have none yet, and a file with only the template entry in it is correct.

    Verify Every entry names a real decision, who agreed it and when. Nothing in the file is invented, and an entry reconstructed from memory says so.

Because

People sign in, and what they see depends on who they are

2 steps · 07–08
  1. 07

    "Mostly done" as an answer. With this you can say the screens lift 80% of the model, here are the 3 named gaps, and one journey has no UI at all.

    writes contract.json

    Then edit It is an example billing product. Keep the shape and replace the actors, entities, journeys, rules, constraints and open questions with this product’s own. Delete the example acceptance records: they describe journeys you have not built.

    Verify The coverage check runs and prints a number, and `--refs` says the references resolve. Start with entities and journeys; add a pillar when you can name the screen it changes. Mark a journey built only with its acceptance record beside it.

  2. 08
    Access rulesA person checks this

    Define permissions and row access in one place. Use them to design gated navigation, empty lists, and disabled actions.

    merges into contract.json · at the top level, after actors

    Verify Point at a new route and ask which matrix row permits it. If the answer needs a conversation, the row is missing.