# Transforming Your First Repo Prompt with AI Config Kits > Source: > Published: 2026-07-18 14:05:48+00:00 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. 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: `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.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. 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]] A kit ships three things that change the math on that first prompt: `CLAUDE.md` at the repo root.`.cursorrules` / `AGENTS.md` .`ai/prompts/` .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. 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)//page.tsx` , server actions in `app/(dashboard)//actions.ts` , form schema in `lib/schemas/.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
, , 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. 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. 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]] 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.