27 checks · the guide's definition of done, in public
The quality bar
What “done” means for anything you publish. Each check says why it matters, how to check it and what to ask your agent.
Pre-publish review: copy for your agent
Before we merge, check the project against the Agentic Makers quality bar: Works · Safe · Handles errors · Fast · Accessible and responsive · Private · Findable. Report pass or fail for each item in plain words, with how you checked it, and propose a fix for anything that fails. Don't merge until I say so.
01 Works
Tried locally and on the Preview
Why: If you haven't clicked through it, nobody has.
How to check: Open the Preview link on a computer and a phone and do what a real person would do.
Give me a checklist of what I should try on the Preview before we publish.Lint, type check and tests pass
Why: Automatic checks catch mistakes before your visitors do.
How to check: Your agent runs them before every push; the pull request shows them green.
Run lint, type check and tests and tell me the result in one line each.Matches SPEC.md
Why: The spec is the promise; the app should keep it.
How to check: Compare each must-have in the spec with the app.
Compare the app with SPEC.md and list anything missing or extra.SPEC.md and tasks/todo.md match what was built
Why: Your next session starts by reading these two files.
How to check: Completed tasks are ticked and any change of mind is reflected in SPEC.md.
Update SPEC.md and tasks/todo.md so they match what we built today.Small commits on a branch, merged through a pull request
Why: main stays live and working at all times.
How to check: Changes live on a feature branch with a pull request and a working Preview.
Confirm we are on a feature branch with everything committed and pushed.02 Safe
No secrets in code, commits, logs or the chat
Why: A leaked key lets anyone spend your money or read your data.
How to check: Secrets live only in Vercel and .env.local; .env* is in .gitignore; nothing secret starts with NEXT_PUBLIC_.
Scan the code and history for anything that looks like a secret and confirm .env files are ignored. Don't print values.Every endpoint checks who's asking and validates input
Why: Every Server Action and Route Handler is a public door.
How to check: Each one checks the session and permissions, validates input with a schema, then touches the database.
List every endpoint and confirm each checks the session and validates its input.Rate limits on logins and AI calls
Why: Without limits, a script can guess passwords or burn your AI credit.
How to check: Sign-in and model-calling endpoints have limits stored in the database.
Check that sign-in and AI endpoints are rate-limited and tell me the limits.Parameterized database queries and a separate dev database branch
Why: Prevents SQL injection and keeps local tests away from real users' data.
How to check: Queries use parameters, never string concatenation, and .env.local points to a Neon dev branch.
Check all database queries are parameterized and confirm local dev does not use the production database.Security headers (CSP) and tight CORS
Why: Protects visitors' browsers against injected scripts and clickjacking.
How to check: Next.js config sends Content-Security-Policy, X-Content-Type-Options and frame-ancestors 'none'.
Check our security headers and confirm CSP and frame protection are active.Model output and error text treated as untrusted
Why: AI answers and logs can contain unexpected or injected content.
How to check: Model output is validated and escaped before showing or running it; AI calls run on the server only.
Confirm all AI calls happen on the server with max_completion_tokens and validated output.03 Handles errors
Friendly messages, never stack traces
Why: People should know what happened and what to do, without technical noise.
How to check: Expected errors are shown as plain messages; forms keep what was typed.
Trigger each expected error (bad input, missing item) and show me what people would see.Error boundaries with “Try again” and a reference id
Why: Unexpected errors happen; the page shouldn't go blank.
How to check: error.tsx per main section and global-error.tsx exist; users see a short reference id.
Check every main section has an error boundary with Try again and a reference id.Helpful 404 page (not-found.tsx) for missing links
Why: A broken link should guide people back, not strand them.
How to check: not-found.tsx exists and links back to the main sections.
Open a non-existent URL on the Preview and show me the 404 page.Structured logs without personal data
Why: Logs explain what broke; they must never leak secrets or personal data.
How to check: One JSON line per event with level, message and request id; no secrets, emails, prompts or outputs.
Review our logging: one JSON line per event, and no secrets or personal data anywhere.Error alerts before real users arrive
Why: You should hear about a problem before your users tell you.
How to check: Error tracking (for example Sentry's free plan) sends you an alert.
Set up error tracking with alerts, following the observability skill.AI fallback tested
Why: If the main AI provider refuses, your feature should still answer.
How to check: Point the Tokentide client at a dead address in a Preview: the Gateway must answer.
Test our AI fallback in a Preview and tell me whether every request got an answer.04 Fast
Good Core Web Vitals
Why: Slow pages lose people and rank lower in search.
How to check: Run a Lighthouse check on the Preview, on mobile.
Run Lighthouse on the Preview for mobile and explain the three biggest improvements.Images sized and compressed
Why: Huge images are the most common cause of slow pages.
How to check: Images have dimensions and modern formats, so nothing jumps while loading.
Check every image has explicit dimensions and a modern format.Parallel data fetching and small client components
Why: Pages load faster when the server fetches data in parallel and sends less JavaScript.
How to check: Independent queries run in parallel and only interactive pieces use use client.
Check that our pages fetch data in parallel and keep business logic out of small UI components.05 Accessible and responsive
Works from a small phone to a big screen
Why: Most people will open your link on a phone.
How to check: No sideways scrolling at 320 px wide; touch targets at least 44 px.
Check the app at 320 px, 768 px and 1440 px wide and fix anything that breaks.Usable with a keyboard and a screen reader
Why: Accessibility is for everyone, and often the law.
How to check: Tab through every control; text contrast at least 4.5:1; images have alt text.
Run an accessibility check (axe) and fix every serious issue.Respects reduced motion and light/dark themes
Why: Animations and low-contrast dark modes can make an app unusable for some visitors.
How to check: Animations check prefers-reduced-motion and both colour themes keep 4.5:1 contrast.
Check that reduced motion is respected and contrast passes in both light and dark mode.06 Private
Collects only what it needs
Why: Data you don't collect can't leak.
How to check: List each piece of personal data, why it's needed and how long it's kept.
List every piece of personal data the app stores, why, and for how long.No personal data in AI prompts unless needed
Why: What goes into a prompt leaves your app.
How to check: Prompts are reviewed and personal data is redacted.
Check our prompts for personal data and redact what isn't needed.07 Findable
Title, description and a clear heading on every page
Why: Search engines and AI assistants need to know what each page is about.
How to check: Each page has a unique title, a description and one H1.
Check every page has a unique title, a meta description and one H1.Sitemap, robots.txt and Preview noindex configured
Why: Only your live Production site should appear in search engines, never test Previews.
How to check: Production serves sitemap.xml and robots.txt; Preview deployments send X-Robots-Tag: noindex.
Confirm our sitemap and robots.txt work and Preview deployments are marked noindex.