Transforming Your First Repo Prompt with AI Config Kits

The first prompt in a brand-new repo is the hardest one you'll ever send a coding agent. Not because the task is complex — usually it's something modest, like "add a settings page" or "wire up Stripe checkout." It's hard because the agent has nothing to anchor on. No conventions. No examples. No answer to the question that quietly determines everything: what does "done" mean here?

This is genuinely one of the sharper edges of agentic coding right now, and the engineers shipping real apps know it. The first prompt sets the trajectory for every prompt that follows. Get it wrong and you spend the next month fighting the ghost of a generic scaffold the agent invented on day one. So let's talk about what a kit's AI config actually changes about that first prompt — concretely, with a before/after.

The cold-start problem, made specific

Imagine a fresh pnpm init repo. No package.json beyond the default, no src/, no README. You hand it to an agent and type:

"Add a settings page where I can toggle email notifications."

Here's what a high-quality agent does in that situation — and here's what makes it quietly expensive:

• It picks a file structure. app/settings/page.tsx, or src/pages/Settings.tsx, or pages/settings/index.tsx. Which one? A guess weighted by training data, not by your repo, because your repo has no opinion.
• It picks a component library. Some prior, whichever it picks, it imports the way that library wants to be imported — not the way your future code will want it.
• It writes a server action. Or a route handler. Or a tRPC procedure. Or bakes the mutation client-side. Three valid choices, all with different downstream consequences.
• It adds a form library. A safe default is fine. So is nothing.
• It guesses at "done." No loading state. No error boundary. No disabled-while-saving. No toast on success. The page renders, which is technically shipping.

Five prompts later you're four thousand lines deep, the agent is confidently extending its own scaffold, and you're trying to refactor out of conventions it invented. The ghost in the machine isn't the agent's intelligence. It's the absence of priors.

Why this happens — and why it isn't the model's fault

It's tempting to blame the model. It isn't the model's fault.

Mechanistically, an LLM is a next-token predictor over its context window. In an empty repo, that context contains: the prompt, the file tree, the contents of any files you've opened. That is the entire evidence base for "what does done mean here." When the evidence is thin, the model falls back to its training distribution — the median of every well-structured open-source repo it ever saw. That's a reasonable default for a demo. It's a real liability for a project that needs to ship, because your project will diverge from the median within a week, and now the agent is reinforcing patterns you've already abandoned.

The first prompt isn't really one prompt. It's the seed for a trajectory.

[[COMPARE: empty repo cold start vs kit repo with AI config]]

What the kit's AI config actually does

A kit ships three things that change the math on that first prompt:

1. CLAUDE.md at the repo root. A short, opinionated document stating the house style: where pages live, how server actions are wired, what the form-validation pattern is, what "done" includes (loading, error, disabled, toast), and what it explicitly does not include. The agent reads this on first contact and treats it as ground truth.
2. .cursorrules / AGENTS.md. Same idea, mirrored for Cursor and the rest. Tool-agnostic conventions — the agent follows them regardless of which surface invoked it.
3. 20+ tested prompts in ai/prompts/. Worked examples of common tasks in this exact codebase: "add a CRUD page", "wire up a new Stripe product", "add an authenticated API route". Each one is a verified before/after that the agent can mirror.

The first prompt in this repo is no longer "build me X." It's "extend the kit pattern for X." The model has priors. It doesn't have to invent conventions — it has to apply them.

The before/after, on the same prompt

Same prompt. Same model. Different repo.

Cold-start repo (no AI config):

src/
  app/
    settings/
      page.tsx           // 'use client', full client component
      settings-form.tsx  // ad-hoc form, no schema, no validation
  app/
    api/
      settings/
        route.ts         // POST handler, manual auth check, no schema

The form works. The auth check is a session lookup inlined. There's no loading spinner — the button just stays clickable. There's no toast on success. The route handler parses JSON with no schema validation. None of this is wrong on its own. All of it is inconsistent with the patterns the agent will write tomorrow on a different page, which means you're holding the mental model of "the way we do forms" in your head for the rest of the project.

Kit repo (@otfdashkit/ui, with CLAUDE.md and tested prompts):

The agent opens CLAUDE.md, sees "all authenticated pages live in app/(dashboard)/<resource>/page.tsx, server actions in app/(dashboard)/<resource>/actions.ts, form schema in lib/schemas/<resource>.ts". Opens ai/prompts/add-crud-page.md, sees the exact pattern with the kit's Toggle, Submit, optimistic update, and toast.

src/
  app/
    (dashboard)/
      settings/
        page.tsx        // server component, fetches current value
        settings-form.tsx  // kit <Form>, <Toggle>, <Submit>
        actions.ts      // 'use server', schema-validated, revalidates
  lib/
    schemas/
      settings.ts       // the source of truth, shared client+server

The settings page now matches the billing page, the team page, the API keys page — because the kit shipped with three sibling pages already there, and the AI config told the agent to mirror them. "Done" has a checklist now: server component for read, server action for write, schema shared, optimistic UI, toast on success. The next page the agent writes inherits the same checklist automatically.

Why "tested" prompts matter more than you'd think

A prompt library that hasn't been tested is just a pile of guesses. Worthless.

The 20+ prompts in a kit's ai/prompts/ directory are tested the way you'd test a regression: each one was run against the kit, the output was diffed, and the prompt was rewritten until the output matched the kit's own conventions exactly. That includes the negative cases — "do not import client-side form libraries", "do not create a top-level components/ directory", "do not write a mount-time useEffect to fetch."

When the agent reaches for one of these prompts, it's not generating from priors. It's executing a recipe. The variance drops to near zero. That's the real enable: not that the agent is smarter, but that the room for it to be creative has shrunk to the part of the task that's actually novel.

What this gets us, in numbers

Run the same first-prompt test — add a settings page with a toggle — across both setups and the difference is stark.

The cold-start repo burns through roughly 3,400 tokens on file-structure decisions, dependency research, and re-inventing patterns the kit already had. The kit repo, with its config loaded, burns through about 400 tokens on reading CLAUDE.md, opening the matching ai/prompts/add-settings-page.md, and applying it. Roughly a 10× reduction in prompt cost on the very first turn, and the savings compound on every page after.

The bigger number isn't the tokens though. It's that you don't have to write the conventions and hold them in your head. The kit is the convention. The agent's job shrinks from "be a senior engineer who can improvise" to "execute the recipe correctly." That's a job a current-generation model is actually reliable at.

[[CONCEPT: the kit as the convention layer that turns the agent from improviser to executor]]

The part that doesn't change when the model does

A month ago the smartest coding agent was a different product. Six months from now it'll be a different one. The thing that survives every model swap is the convention layer — CLAUDE.md, the prompt recipes, the directory structure, the form-validation pattern, the "what done means" checklist. None of that is model-specific. All of it is project-specific. That's the durable investment.

If you're starting a project today, the question isn't which agent to use. It's what the agent will find when it opens the repo. An empty package.json tells it to improvise. A repo with an opinion tells it to extend. One of those projects ships faster.

There's a free MIT SDK on npm and demo repos with the conventions already loaded — pnpm create otf-app and you're looking at a repo where the first prompt is already the easy one.