Skip to content
Roy Yang
Blog

The prompt of autonomous coding that I deduced from Claude for using Claude Code work on its own

8 min read

An autonomous coding run lives or dies on what you write down before it starts. Here's the prompt I use to make the agent build its own guardrails first.

After many failed projects, bugs fixing and restart of the project, I learnt that setting up a great foundation is much more important than keep revising and bugs fixing.

So I stopped kicking these off with "build X." Now I make the agent interview me and write its own instructions before it touches real code. Sometimes I'd use free tools like gemini for the brainstorming, list out all the ways that could do it with Pros and Cons. Asked for recommendation from AI, but do the judgement and critical thinking and make the final decision by myself. Once
narrow down to the best candidate. It produces at least four files: a description of the architecture, a plan broken into tasks I can check off, a rules file it reloads every session, and the kickoff prompt itself. Sometimes I asked for more, like create all the necessary files.

It's like our project workflow. list the requirements, find and discuss about the solution, review the funcation spec, confirm before starting the development. list out the user acceptance requirements for the testing, let it run until all the requirements are fulfilled before it is allowed to deploy.

the issue is memory

An autonomous agent has no memory of the conversation you had last week, and no instinct for what you'd quietly consider out of scope. Left to guess, it guesses wildly. When it is a guessing, you are taking the chance that the guess is not what you want in your brain. The contract files are how you give it both: a memory it can re-read, and a fence it won't climb.

How the prompt it deduce and how it works

Nothing better than deduce the workflow from the AI (claude) itself. After rounds and rounds of discussion, here we came up with the workflow and the prompt.

It runs in seven phases, and it won't move to the next one until I approve the current one. That gate matters more than it sounds. It forces me to read what the agent is about to commit to instead of rubber-stamping a wall of text.

Phase one is discovery. It asks me, in small batches rather than dumping twenty questions at once, what I'm building, my stack preferences, what's explicitly in and out of scope, any constraints, and my definition of "the whole thing is done." If I'm vague, it pushes back and asks for specifics. That sounds minor. It's the whole game. Most bad runs trace back to a fuzzy answer here that nobody challenged.

Phase two drafts ARCHITECTURE.md: the modules and what each is responsible for, how data flows, the key schemas, the external dependencies and why they're there, and the decisions we've locked in so they don't get relitigated at 2am by a machine.

Phase three drafts PLAN.md. The work gets broken into phases — foundation, then core, then polish — and under each one sits a list of small checkbox tasks. Every task carries two lines: an acceptance line (what "done" looks like) and a verify line (the exact command that proves it). The rule I care about most is that each task has to be independently verifiable. If a checkbox can't be proven by a command or a concrete check, it isn't a task yet, it's a wish.

Phase four drafts CLAUDE.md — the file the agent loads at the start of every session, so it stays tight. The part that earns its place is a Definition of Done that applies to every single task: tests pass with nothing skipped, lint clean, types clean, the PLAN.md box checked, and the change committed with a message that names the task.

Phase five hands me the exact shell commands to scaffold all of it: initialize the repo, wire up named scripts for test, lint, typecheck, and build, install the test runner with one passing skeleton test, create the folder structure, and drop in empty DECISIONS.md and BLOCKERS.md. Those last two are where the agent logs its assumptions and parks anything that needs me, instead of stopping cold.

Phase six is a sanity check, and one item on it does the heavy lifting: a single command that objectively says whether the run succeeded. If you can't name that command, you're not ready to walk away.

Phase seven writes the kickoff prompt — the thing I actually paste to start the run. It names which files to read first, the work loop (implement, verify, commit, check the box), and the stop conditions: everything checked and the full verification suite green, or the same task failed three times, or it hit a question only I can answer, or it reached a safety cap I set. Plus the anti-drift rules: don't stop just because something's hard, don't add scope, log assumptions and keep going.

TLDR: the final prompt

Here's the full prompt. Paste it into Claude Code and answer its questions honestly.

You are helping me set up a project for an autonomous Claude Code session.
Your job is to walk me through setup step by step, ask the right questions,
and produce all the scaffolding files I need before I launch the autonomous run.
Follow this process exactly:

## Phase 1 — Discovery (ask me questions)
Ask me, one batch at a time, about:
1. What I'm building (one-paragraph description)
2. Tech stack preferences (language, framework, database, test runner) —
   suggest defaults if I'm unsure
3. Scope boundaries — what's IN and what's explicitly OUT
4. Any constraints (deployment target, performance, existing code to integrate with)
5. My definition of "the whole project is done"
Do not move on until you have clear answers. If I'm vague, push back and ask
for specifics.

## Phase 2 — Draft ARCHITECTURE.md
Based on my answers, draft an ARCHITECTURE.md containing:
- Module list and responsibilities
- Data flow
- Key data models / schemas
- External dependencies and purpose
- Locked-in decisions (so they don't get relitigated)
Show it to me. Ask if I want changes. Iterate until I approve.

## Phase 3 — Draft PLAN.md
Break the work into phases (Foundation → Core → Polish). Under each phase,
list small checkbox tasks in this format:
- [ ] Task name
  - Acceptance: <what "done" looks like for this task>
  - Verify: <exact command or check that proves it>
Rules for tasks:
- Each task must be independently verifiable
- Each task should be small enough to finish in one iteration
- Order so each task builds on completed ones
- For UI/content tasks where tests can't fully verify, add explicit acceptance criteria
Show it to me. Ask if I want changes. Iterate until I approve.

## Phase 4 — Draft CLAUDE.md
Draft a concise CLAUDE.md containing:
- One-paragraph project description
- Tech stack and conventions
- Commands the agent will run (build, test, lint, typecheck, dev)
- Architectural rules to respect
- Pointers to PLAN.md, ARCHITECTURE.md, DECISIONS.md, BLOCKERS.md
- A Definition of Done checklist that applies to EVERY task:
  * Tests pass with no skipped tests
  * Lint passes
  * Typecheck passes
  * PLAN.md checkbox is checked
  * Changes committed with descriptive message referencing the task
Keep it tight — this file is loaded every session. No filler.
Show it to me. Iterate until I approve.

## Phase 5 — Scaffolding instructions
Give me the exact commands to run to:
- Initialize the repo and .gitignore
- Set up package.json (or equivalent) with named scripts: test, lint,
  typecheck, build
- Install the test framework and create one passing skeleton test
- Create the folder structure from ARCHITECTURE.md
- Create empty DECISIONS.md and BLOCKERS.md placeholders
- Verify test/lint/typecheck commands all work
- Make the initial commit

## Phase 6 — Sanity check
Walk me through this checklist and confirm each item:
- [ ] CLAUDE.md exists with Definition of Done
- [ ] PLAN.md has ordered checkbox tasks with acceptance criteria
- [ ] ARCHITECTURE.md drafted
- [ ] DECISIONS.md and BLOCKERS.md exist
- [ ] Test, lint, typecheck commands all work on the skeleton
- [ ] Repo committed and clean
- [ ] One command exists that objectively verifies whether the autonomous
      run succeeded (name it explicitly)

## Phase 7 — Produce the kickoff prompt
Generate the exact kickoff prompt I will paste into Claude Code, including:
- Which files to read first
- The work loop (implement → verify → commit → check box)
- Explicit stop conditions:
  1. All PLAN.md checkboxes checked AND full verification suite passes
  2. Same task failed 3 times → log to BLOCKERS.md and stop
  3. Question requires my input → log to BLOCKERS.md and stop
  4. A safety cap (ask me what cap to use — task count, time, or cost)
- Anti-drift rules: don't stop for difficulty, don't add scope, log
  assumptions to DECISIONS.md and keep going
- Final verification pass before declaring complete

## Rules for you throughout
- Ask one batch of questions at a time, don't dump 20 questions on me
- When drafting files, show them in full so I can copy-paste
- Push back if my answers are vague — better to clarify now than debug later
- Don't proceed to the next phase until I've approved the current one
- At the end, the deliverable is: four files I can save, scaffolding commands
  I can run, and a kickoff prompt I can paste

Start with Phase 1 now.

How to use it

  • Best in regular Claude (claude.ai or desktop) for Phases 1–4, where you're iterating on docs conversationally
  • Switch to Claude Code for Phase 5 onward so it can actually create the files and run the setup commands
  • Or use Claude Code's plan mode (--permission-mode plan) start-to-finish — it'll discuss without making changes until you approve