Set Up the Loop With One Prompt

This is the setup companion to The Loop Outlives the Model. That note is why the loop matters. This one is how to put it on your device.

You can set up the loop in one session, starting with a prompt. I call the whole thing the loop contract: the standards you write are the rules, the repo's instruction file is the front door, the plan is the work, the checklist is the proof that the loop loaded, the report is the evidence, and the human gate is the stop. The harness is the program that runs the session; the model is the rented part. The model is not in the contract. That is the point.

This is my setup, not a requirement. Take what fits and improve the rest. The loop is model-agnostic: I use Claude, Codex and DeepSeek, and the same shape would take Gemini, a local model, or whatever comes next.

Start with the prompt

The prompt is short. It points at this page, and the page carries the detail. Paste this into a fresh session at the repo root.

Set up the loop in this repo. Read the setup guide:
https://portfolio.tjakoen.com/notes/loop-setup
Start with the smallest first step. Do not edit anything
until you have told me what you found and what you would
do first.

The right answer is small. It should name the instruction file, the plan, the one check, the first task, and the public rule you would rewrite for this repo. If it comes back with a platform, a hook for every event and a migration plan, stop. That is the loop as a settings project, not the loop as a practice.

You are setting up my AI loop on this repo. Read these public
standards as a reference, not a rulebook:
- https://portfolio.tjakoen.com/standards/loop
- https://portfolio.tjakoen.com/standards/session-loop
- https://portfolio.tjakoen.com/standards/hooks
- https://portfolio.tjakoen.com/standards/ai-repo-standard
- https://portfolio.tjakoen.com/standards/voice

Then inspect this repository and tell me, before you write
anything:
1. What already exists: the instruction file, the plan, the
   tests, the CI, the git state, and the board.
2. What is missing for a session to start with a check,
   work from a plan, leave a report, and stop at a human gate.
3. Where these public standards do not fit this repo, and what
   we should write in our own front door instead.
4. The smallest first step, with the exact files and commands.

If this repository has a pantry.config.json, use PANTRY:
orient first, then next, claim the plan, heartbeat while
you work, and release it when done. PANTRY is optional;
it is just the board I use. If it does not, the plans
folder is enough.

Do not edit or install anything yet. Ask me before the first
write. Keep the loop thin: one instruction file, one plan, one
report, one check. Do not copy the standards into the repo;
link them.

If the answer is longer than a screen, ask for the first step only. The rest can wait.

What the loop is

The loop is five pieces. The harness is the program that runs them. The model is not one of them.

The loop: a plan, a session with the checklist first, a report, a second reader, and the human who lands it. The front door is the rules around all of it. Then the next plan.

The standards are the rules you write. The public set is my example. The repo's instruction file is the front door. The plan is the work. The checklist is the proof that the loop loaded. The report is the evidence. The human gate is the stop. The harness is the program that calls those pieces; the adapter step is the only part that changes per harness. The model is the rented part.

A contract is something both sides can check. The model can change; the contract stays. Addy Osmani calls the gap between the code you can generate and the code you can understand comprehension debt. The loop is how I keep that debt visible.

The five pieces are the thin loop. The guards and the adapters are add-ons. You do not need them on the first day.

Your standards are the contract you write

The public standards are my example, not a rulebook you adopt. Read them, steal the shape, and write the version that fits your work. The front door is where your standards live. If a public rule does not fit, write the version that does, and say why. A standard you did not write is a rule you cannot defend.

The prompt asks the AI to tell you where the public standards do not fit. That is the point. The loop is yours; the standards are the part you keep.

Step one: the front door

One instruction file, linked to the standards, not a copy of them.

The front door is the AGENTS.md file, with CLAUDE.md as a symlink to it. It is the first file a session reads. It should answer four questions in plain language: what this repo is, how to run the checks, where the plan lives, and what a session may not touch.

What to put in it:

• The repo, the stack, the commands.
• The standards links you actually use: mine, or yours. The public set is a reference.
• The rules you wrote, where they differ from the public set.
• The loop: where the plan lives, how to run the checklist, where the report goes, what the human gate is.
• The board, if you have one: PANTRY or a plans folder.
• The one-file rule: AGENTS.md is the file; CLAUDE.md is the symlink; no second copy.

What not to do: paste the standards into the file. A copy is a future argument about which one is right. Link them, and let the standards carry the detail. Do not adopt a public rule you have not read; a rule you cannot defend is not yours.

The prompt should propose this file first. If it proposes a hook or a platform before the front door, ask it to start again.

Step two: the plan and the report

The plan is a markdown file. The board is a window. The report is the receipt.

A plan in the repo is enough. Put it in a plans folder, give it a scope, a finish, and a status. The board is a view of those files. Mine is PANTRY, the orchestrator I built: it reads the plans folder, shows what is ready, and lets a session claim a plan, heartbeat while it works, and release it when it is done. It writes nothing back; the markdown is the truth.

PANTRY is live, and it is not required for this setup. It is just what I use. If your repo has a pantry.config.json, use the PANTRY flow: orient first, take the next plan, claim it, heartbeat while you work, and release it when done. If it does not, a plans folder is the same shape. The plan file is the truth; the board is the window. The plan is not a project management tool. It is the sentence the session can finish.

The report goes in an artifacts folder, dated and named. It carries the checks that actually ran, the output, the diff, and the open questions. It is not a diary. It is the evidence the next person needs.

What to check:

• The plan has a finish.
• The report names the checks, not just the result.
• The report is short enough for a second person to read.

Step three: the checklist

The checklist is the piece that tells you the loop loaded.

One script. It runs at the start of a session. It checks the things that have to be true before you trust the session: the instructions loaded, the front door is there, the plan exists, the check runs, the board and the code map are reachable, and the tree is clean. It ends with one verdict: Agentic Loop Loaded, or not loaded with the failing rows named.

This is the checklist from this repo, shortened to fit. The rows are my machine; yours will name your plan, your tests and your board.

Agentic loop check, tjakoen.github.io (PANTRY project, DSH)
 ok   DSH, deepseek-flash
 ok   Instructions: global + repo, 18k chars of the 20k budget
 ok   Memory: 83 notes, index loads whole
 ok   DSH loop: plugin linked and mounted
 ok   MCP: pantry, tokensave, headroom configured
 ok   No style override
 ok   Standards: 21 skills mounted
 ok   PANTRY: serving tjakoen.github.io, 1 ready, 0 claimed
 ok   tokensave: indexed, 0 day(s) old
 ok   graphify: graph 0 day(s) old
 ok   Git: codex/nest-terminal-controls, 0 uncommitted
Agentic Loop Loaded (DSH)

How to run it: at the start of a session, before the work. Show the block verbatim. The model does not write the verdict. If the hook printed nothing, say the checklist did not run.

The checklist is not a test suite. It proves the loop loaded. The tests and the CI prove the work. The second reader proves the judgment. Do not ask one tool to do all three.

What to do when a row fails: fix the row, not the output. Do not edit the block. The owner reads it precisely because the script produced it and the model did not.

Step four: the guards, when they earn it

Start with the guards as prose. Move them to hooks when the same mistake happens twice.

The first guard is the human lane: the short list of paths only you touch. The deploy config, the billing code, the secrets, the employer repo. Write the lane in the front door. Add a hook only when the honor system fails.

The second guard is the handoff. A subagent gets four headings:

Lane: high, gated or human, and why
Scope cap: the dirs it may touch
Hard stops: no push, no publish, no merge
Ask-triggers: what stops the run, and where the ask goes

Start with the headings as prose. Add a check when a handoff arrives without them.

The audit found one thing worth telling. A handoff I had written as a numbered list passed the old guard and failed the new one. The new guard was looking for a colon; the numbered list did not have one. A numbered list is a normal way to write a handoff, so the guard was wrong. I fixed it and added the numbered case to the test. The lesson is bigger than the bug: a rule with two implementations needs one test list, and I did not have one.

What to do about it: write one test list for the rule, not one per harness. Run the same cases against both. If the rule lives in two places, the test list is the only thing that keeps them honest.

The guards protect the five pieces. Do not add them before the pieces.

Step five: the adapter

The adapter is the only part that changes per harness.

Claude Code and Codex use hooks. DeepSeek uses a plugin, because it has no shell hook events. The checklist, the standards, the plan and the report are the same. The adapter is the small piece that calls them.

The loop is model-agnostic. I use Claude, Codex and DeepSeek; you can wire Gemini, a local model, or whatever you use. The adapter is the only part that changes.

The public standards are the contract; the private config is the wiring; the adapter is what changes. My wiring; yours can be one file.

You do not need three harnesses. Start with the one you use. The loop is one instruction file, one checklist, one plan, one report. The adapter is the only swap.

The public standards are the contract. The private config is the wiring. I keep a private config repo with the settings, the checklist, the guards, the board connection and the machine paths. You can start with one file.

What to move, what to keep. The test is whether a reader could use it without your machine. The voice rules pass. The checklist rule passes. The handoff headings pass. The machine paths, the employer rules and the secrets do not.

The private config is one point of failure: if it breaks, every machine breaks. It is not a copy per machine. link-machine.sh links each machine to the same config, and the checklist catches a machine that has slipped. Keep it small.

The first run

A fresh session, the checklist, one small task, one report, one second reader.

1. Open a fresh session at the repo root.
2. Run the checklist. Read the verdict. Fix the failing rows.
3. Pick a task small enough for one session. Write the plan. Do the work. Leave the report.
4. Give the report to a second reader. Let the human land it.

What good looks like: the checklist block is at the top, the verdict is loaded, the plan has a finish, the report names the checks, and the second reader can explain the change without you.

The next start is the backstop. If a session leaves work uncommitted, the next session's checklist sees it and asks. The close check reads the session log and scopes the dirty paths to the session. The nudge is the reminder; the close is the check; the next start is the tree check.

Two ways this goes. If you start with the prompt and the five pieces, you have a checked session by the end of the day and a loop you can improve. If you start with the platform, you have a settings project, a half-installed adapter and no work. The first is boring. The second is why most people stop.

What the loop cannot prove: the checklist proves the loop loaded, not that the work is good. The second reader is still the thing that catches the work. The private config can drift. The adapter is code, and code rots. The model will change.

What to do about it:

• Start with one repo and one harness.
• Add the second harness after the first run.
• Keep the human gate. Do not automate the commit or the publish.
• Read the standards; do not copy them.
• Keep one test list for the rules that live in two places.

The sources

The people are on the reading page, not in a footnote. The reading page has the work that shaped this: Addy Osmani on the loop and the comprehension-debt warning, Alfonso Graziano on writing down what you meant, and Cole Medin on the project as one artifact. The public standards are my own draft, not a universal; the reading page is the trail back to the people, and the standards are the shape I made from them. Write yours.

The turn

The model will change. The loop is the part you keep. Start with the prompt. The model can change after.

The judgment is human. The typing, by design, is not.