The prompt that bootstraps a project — AI Best Practices

Why structured prompting

A good kickoff prompt pursues three goals at once: agent autonomy (no blocking back-and-forth questions mid-session), context safety (no risky guesses on what wasn't said), token economy (the right model for the right task, no more no less).

A poorly written prompt is expensive: extra iterations, rewrites, an over-powered model invoked for nothing. On a long project like this one, the cumulative gap between a careful prompt and a sloppy one adds up to hours and euros.

Anatomy of a kickoff prompt

A project kickoff prompt contains six key sections. Each section addresses a type of question the agent would otherwise ask mid-session:

Context — where you are, what exists (current stack, history, repo, default branch)
Objective — what you want to reach, in one sentence
Constraints — what you can't do (deadline, imposed stack, frozen dependencies, repo conventions)
Stack — concrete versions, not "recent" or "modern"
Success criteria — how you'll know it's done (preferably measurable)
Out of scope — what is NOT requested (avoids over-delivery)

Bonus to include when relevant: explicit validation gates (when the agent must ask for user confirmation), granted permissions (yarn install, git commit, force-push forbidden, etc.), and the model/task mapping (see next section).

The right model for the right task

Three model families, three typical uses:

Opus 4.7 — architecture, design, critical review, complex plans. Deep reasoning, can be expensive but avoids future iterations.
Sonnet 4.6 — mechanical implementation, multi-file refactor, integration of a clear spec. Standard, optimal quality/cost ratio for the majority of dev tasks.
Haiku 4.5 — isolated tasks, simple lookups, formatting, trivial deletes, grep audits. Fast and cheap, perfect when the reasoning context is minimal.

Rule of thumb: always start with Sonnet. Escalate to Opus only when you observe judgement errors (incoherent architecture, fuzzy plan). Step down to Haiku when the task is mechanical (rename a field, delete a dead file, add a verbatim test from a spec).

Order of magnitude observed on this project (Plans 1 to 6, ~20 PRs and fixups): ~70% Sonnet, ~20% Opus, ~10% Haiku. Inverting that mix (everything on Opus) multiplies cost by about 5×.

Securing the context

The agent doesn't guess. When data is missing, it interpolates — often badly. Securing the context means giving all the necessary data upfront:

Include exact files and sections to modify (absolute paths, line ranges where relevant)
Specify repo conventions (naming, commit formats, test structure, allowed branches)
Mention known pitfalls ("careful, X was broken before migration Y, do Z first")
Cite external sources (repo, doc, ticket) rather than paraphrasing

Agent autonomy

The goal isn't zero questions. It's zero avoidable questions. Preparing all the decidable choices upfront in the initial prompt prevents the session from stopping every 5 minutes on an ambiguity.

List "questions NOT to ask" with their pre-decided answer: "don't use X, we already have Y", "don't write tests for this, it's an MVP"
Define validation gates explicitly: "after migrating sections 1-3, ask for visual validation before continuing on 4-6"
Specify permissions: whether the agent can commit/push directly, or must wait for confirmation via PR
Provide the model/task mapping so the agent can self-route to the right cost

Applied example: QAConsulting (two approaches)

Here are two ways this project (qaconsulting.fr rebuild) could have been kicked off. Both are valid — the choice depends on context.

**Approach A — Mono "complete kickoff" prompt**: a single big prompt that sets the frame once and for all.

# qaconsulting.fr rebuild — kickoff prompt

## Context

Existing single-page CV site in Next 13 / Pages Router / styled-components.
SEO audit: global `x-robots-tag: noindex` → site invisible to Google.
Current stack: React 18, TypeScript, Drupal for an unused blog.
Prod hosted on Vercel, domain www.qaconsulting.fr.
Repo: github.com/Jawstheone/QA-Consulting (branch develop = source of truth).

## Objective

Turn the site into a senior candidate showcase (React Tech Lead + applied AI)
Google-indexable, multi-page, with an "AI Best Practices" section featuring
the tools I use daily (Claude Code, Superpowers, RTK, monitor-ccu) — each in
its own dedicated article with full attribution.

## Constraints

- Keep current domain and email (contact@qaconsulting.fr)
- No breaking change on existing public URLs
- All article text stays factual: if a number isn't measured, reword as
  qualitative
- Commit conventions: French Conventional Commits, no Co-Authored-By trailer
- Branch `develop` = staging, `main` = prod (Vercel auto-deploy on push main)

## Target stack

- Next 15 (App Router), TypeScript 5.5, Tailwind v4
- No more styled-components long-term
- Tests Jest + @testing-library/react
- AI: Claude Code (Opus 4.7 for planning, Sonnet 4.6 for implementation)

## Success criteria

- Lighthouse mobile ≥ 95 on the 5 indexable routes
- 0 styled-components in src/ and tests/
- Sitemap re-submitted in GSC and accepted
- /cv PDF downloadable and readable
- Tests green (final goal ~70/70)
- No visual regression on viewport 1440 and 375

## Out of scope

- Internationalisation (FR only)
- Dark mode toggle
- CV content rewrite beyond strict consistency (handled later)
- Storybook (remove if present and unused)

## Validation gates

- After each major "Plan" (1, 2, 3, 4, 4.5, 5, 6): open a PR develop ←
  feat/plan-N and wait for user validation before release develop → main
- On ambiguous architectural decision: ask with ≤4 multiple-choice options
- On /cv PDF task: critical gate, no modification without visual validation

## Models to use

- Plans, architecture, design: Opus 4.7
- Mechanical task-by-task implementation: Sonnet 4.6
- Trivial reviews and defensive grep: Haiku 4.5

## Permissions

- yarn install / commit / push: OK without confirmation
- No force-push, no --no-verify, no direct main edit
- Any file deletion > 5 lines: confirm before

**Approach B — Tiered prompts**: a light kickoff that serves as a foundation, then targeted prompts for each task type.

# qaconsulting.fr rebuild — kickoff (light)

Next 13 + styled-components CV site, invisible to Google.
Target: senior candidate showcase + AI section, Next 15 + Tailwind.
Sources: github.com/Jawstheone/QA-Consulting, branch develop.
Model: Opus 4.7. Convention: French commits, branch feat/* → develop → main.
First expected deliverable: an audit plan + incremental roadmap in 1-2 week
plans each.

# Feature — [feature name]

Plan: docs/superpowers/plans/[plan-N].md
Current task: T[X] [title]
Model: Sonnet 4.6
Criteria: tsc/lint/test green, 1 commit French Conventional Commits
Branch: feat/plan-N (already created)
Out of scope: anything not in T[X]

# Debug — [observed symptom]

Reproduction: [steps or command]
Logs / error: [paste here]
Hypothesis: [if you have one, otherwise "to investigate"]
Model: Sonnet 4.6 (escalate to Opus if deep analysis needed)
Criteria: root cause identified + fix in separate commit + regression test
if relevant

# Review — PR #[N]

Spec / plan: docs/superpowers/plans/[plan-N].md
PR: https://github.com/Jawstheone/QA-Consulting/pull/N
Model: Opus 4.7 (review requires judgement)
Expected output: Strengths / Critical / Important / Minor / Assessment APPROVED|NEEDS_FIXES
If NEEDS_FIXES: proposed fixes in actionable bullets

**Comparing the two approaches**:

Mono "complete kickoff" — Pros: maximum autonomy (the agent knows everything from session start), cache savings (the big prompt is cached at 0.1× for 5 min), single context-analysis pass, ideal Opus for architecture. Cons: hard to write in one go (author risks omission), context window can hit limits, the agent may lose focus on details buried in the mass, less agile to pivot mid-session.
Tiered (light kickoff + separate feature/debug/review) — Pros: simpler to write prompt by prompt, you can adapt the model per prompt (Opus for kickoff, Sonnet for features, Haiku for simple reviews), flexibility to pivot, reusable prompts (feature template). Cons: less cache-efficient (context rebuilds each session), inter-prompt inconsistency risk (the author forgets a convention between two prompts), no multi-feature autonomy in a single session.

Practical verdict: **mono for bootstrapping a green-field project or a major overhaul** (e.g., the QAConsulting full rebuild), **tiered for the daily life of an established project** (e.g., an isolated feature on an existing project).

Common anti-patterns

Prompt too short: "do X" with no context → the agent invents, divergence guaranteed
No success criteria: the task can be "almost done" indefinitely
Cosmetic over-specification: describing every line of code → the agent becomes a calculator, loss of usefulness
Mismatched model: Haiku for architecture (mediocre result) or Opus for a JSON format (waste)
No out-of-scope: the agent adds non-requested features (overbuilding)
"You can do that if you want" ambiguity: the agent will or won't depending on the model's mood, an uncertainty cost

Complementary tools

Prompting is a skill that pays off long-term, but it gets stronger with the right tools:

Claude Code — the CLI agent itself, which executes prompts in a real project context
Superpowers or CC AI Virtual Staff — reusable skills so you don't repeat the same prompt every session
RTK — 60-90% token savings on repetitive CLI ops (git, ls, cat, grep, etc.) that would otherwise pollute context
monitor-ccu — visual cost tracking session by session, the feedback you need to calibrate the model/task rule in real conditions

Each tool is documented elsewhere on this site in its own page. The prompt is the conceptual layer; these tools are its infrastructure.