Kirti Kumar Sahu · September 2, 2026 · 11:00 · 6 min read
|
For years, starting a new project meant the same five minutes: create-next-app, lay out the folders the way you always do, drop in an ESLint config, maybe a Prettier config next to it, and start writing code. That checklist isn't wrong, it's just incomplete now. It covers the human half of the setup and skips the half that's actually doing a lot of the coding with you.
Here's what I'd add, in the order I'd actually do it.
A linter tells a human "don't do this." It doesn't tell an AI agent how your project builds, what your test command actually is, or which files are off-limits. That's a separate file now, and there's finally something close to a standard for it: AGENTS.md, a plain markdown file at the repo root that over 30 tools read — Codex, Copilot, Cursor, Windsurf, and more. It's stewarded by the Agentic AI Foundation under the Linux Foundation now, which is as close to "this isn't going away" as this space gets.
Claude Code doesn't read AGENTS.md natively yet, so the workaround is a one-line CLAUDE.md that just imports it: @AGENTS.md as the first line. One file, every agent.
What actually goes in it: project overview and framework versions, exact build and test commands (uv run pytest tests/unit/ -v, not "run the tests"), code style rules that differ from the language defaults, how secrets are handled, and PR/commit conventions. Keep it short — a couple hundred lines, not a wiki.
For anything more specific than general instructions — "how we do database migrations in this repo," "how we structure a new API route" — that's a SKILL.md, not a rules file. It's gated by a description field that decides when the agent bothers reading the rest of it, so it only loads when relevant instead of bloating every single prompt.
Left alone, AI-generated UI converges on the same look — centered card, purple gradient, a shadow that's slightly too soft, Inter everywhere. That's not a model problem, it's a missing-input problem: nobody told it what "good" looks like for this project.
Two ways to actually fix that instead of re-explaining your aesthetic in every prompt:
npx skills add Leonxlnx/taste-skill) — before generating anything, the agent identifies industry, audience, mood, and layout family, then runs a checklist before calling the work done: dark mode parity, no leftover placeholder content, no generic AI visual tropes.Pair either with shadcn/ui as the actual component layer — don't let the agent invent components from scratch, feed it shadcn context and let it compose from primitives, then customize through Tailwind rather than fighting the component contract. AI generates static layouts fine; motion and interaction need to be asked for explicitly, so budget a pass for that separately. A theme generator like tweakcn sets the palette once instead of re-describing it every session.
An agent that has to guess your database schema or your deployment state from memory will guess wrong eventually. MCP servers fix that by giving it real, live access instead:
Scope permissions tight. Read-only where you can get it. The point is giving it eyes on the real system, not giving it the keys.
ESLint plus Prettier isn't wrong, it's just two configs and two passes where one would do now. For a fresh project in 2026, Biome is the sane default — linting, formatting, and import sorting in a single tool and a single config. Keep ESLint around only for the plugin-dependent rules Biome doesn't cover yet (React Hooks rules, Next.js-specific rules), not as the whole setup. Oxlint is worth adding only if lint speed is a real, measured bottleneck in CI on a large monorepo — don't reach for it by default on a fresh project.
Add an AI reviewer to the PR before it needs a human, not instead of one. Pick based on what you actually want caught:
Any one of these as a required GitHub check turns "did I miss something obvious" into a five-minute wait instead of a code review comment three days later.
This one's conditional: if the project's own product is doing something with an LLM — not just being built by one — regular error tracking doesn't cover it. A bad response isn't a stack trace, it's a wrong answer that returned a 200. That needs its own eval and observability layer, separate from the rest of this list. Worth its own post rather than a bullet point here.
Half of what's in this post will look outdated in six months, the same way "just run create-next-app" quietly stopped being the whole answer without anyone announcing it. That's not a reason to skip setting this up now, it's just why the specific tool names matter less than the shape: give the agent rules, give it taste, give it real access, and put something automated between its output and your merge button. The tools will keep changing. That checklist won't, for a while.