Blog / / 4 min read
Boring prompts are the goal
If your prompts to coding agents keep getting longer, you're compensating for context the project should already carry. Why one-line prompts are a sign the setup is right, and how to move the missing information out of your prompts and into the repo.
There’s a genre of advice that treats prompting as a craft to master: templates, incantations, thousand-word “mega-prompts” that specify everything from the tone of the comments to the testing strategy.
I think the mega-prompt is a smell. If you have to say all of that every time, the project isn’t carrying its own context, and you’ve become the courier.
The prompts I actually use
On a well-set-up codebase, my prompts to Cursor look like this:
- “Add a new blog post about X.”
- “Create a careers page that matches the rest of the site.”
- “Change the brand color.”
No file paths, no conventions, no reminders about which components to use. One line each, and the results land on-pattern. Not because the model is psychic, but because the repository answers the questions the prompt doesn’t: AGENTS.md says which collection blog posts live in and what frontmatter they need. The design skill says which Text variants and spacing rhythm pages use. A scoped rule says the import alias is @/ and that nobody asked for a refactor.
“Change the brand color” is my favorite test. With context files in place, the agent finds the token file and changes the color across the whole scale in one edit, because the skill told it where color decisions live. Without them, the same prompt produces a grep-and-replace across components that misses half the cases. Same model, same prompt, different repository.
Every long prompt is a filing error
Here’s the reframe that changed how I work: whenever a prompt gets long, the extra words are almost always project knowledge, not task description.
“Add a careers page — use the Wrapper component for layout, we use the @/ alias, buttons come from Button.tsx with the lg size, don’t add any new dependencies, spacing between sections is usually mt-24…” — only the first four words are the task. Everything after them is context you’ll need again next week, typed into a chat box where it dies when the session ends.
That information has a better home. The test I apply: if I’ve typed the same instruction into two different prompts, it moves into a file. Conventions go into a rule. Design decisions go into the design skill. Project structure goes into AGENTS.md. The prompt goes back to one line, and every future session inherits the knowledge instead of re-learning it from me.
The same goes for corrections. When a result comes back wrong, the tempting move is to fix it in chat: “no, we don’t use shadows here.” The durable move is to make the agent write the correction down: “we don’t use shadows here — add that to the design skill.” One is a patch on this conversation; the other is a patch on every conversation that follows.
Boring prompts are also a diagnostic
Once the context lives in the repo, prompt length becomes a signal. When a one-liner stops producing on-pattern results, something specific broke: the brief went stale after a restructure, a rule doesn’t cover a new folder, the skill never documented that component. That’s fixable, and the fix helps every future task.
If instead you’re compensating in the prompt, the feedback loop never closes. The prompts grow, the files stay stale, and the quality of your output starts depending on how much patience you had that morning.
Every Lexington theme ships with this setup out of the box: AGENTS.md, a design skill extracted from the theme’s code, and four scoped Cursor rules. But you can build it for any project in an afternoon, and the method — what to extract, in what order, with a fill-in template — is Making Your Codebase AI-Ready.
Aim for boring prompts. The interesting work is in the files.
/Michael Andreuzza