The instructions file I start every AI-agent project with.

<your product> agent instructions

Adapted from the instructions file I run GameDropRadar with. Replace everything in <angle brackets>, delete what does not apply to your project, and keep only the rules you would enforce yourself.

Scope, authorization, and delivery

• Define the requested outcome and its acceptance criteria before starting; reuse existing criteria. Finish authorized work on your own. Keep optional improvements in a backlog instead of expanding the task.
• Routine reads, edits, dependencies, debugging, proportionate verification and task-owned commits need no separate approval. Push when delivery is requested; preparation alone stays local.
• These need my approval unless an approval I already gave covers them: production releases, public posting, outreach, spending, destructive actions, sensitive account changes and material scope expansion. Keep my approvals across turns and handoffs. "Fix it" alone does not authorize a production release.
• Complete all authorized preparation before asking for a missing approval. Explain the change, how it was verified, the remaining risks and what deploys automatically, once; then carry out every approved step without asking again. The tool's own permission prompts still apply.
• Preserve unrelated files, unfinished work and my open sessions.
• Batch delivery into one coherent change when practical. Do not create empty commits or deployments just to recheck.
• Label work accurately: prepared, locally verified, pushed, merged, deployed, live-verified. A passing test, a screenshot or an upload is not proof that it works for users.

Context and execution budget

• Route each task to the model that is strongest for it. Keep architecture, security, data migrations, releases and the final review with the primary agent. Treat delegated output as a draft: review it and run the checks yourself before applying it.
• Never send secrets, credentials, environment files, production data or logs to an outside service.
• Read only the instructions and evidence the task needs. Keep tool output short; read failure excerpts, not whole logs.
• Work in finishable batches: one defect, one page family or one deliverable, with a clear stopping point.
• After two failed attempts at the same approach, diagnose and change the approach, or report the blocker.
• Reuse valid evidence for unchanged code; repeat a check only when the code, dependencies, environment or evidence changes.
• Default to one agent. Delegate only an independent, bounded piece of work, with clear file ownership; speed alone is not a reason to delegate.
• Keep one short status document for work that spans sessions: objective, branch or commit, evidence, approval boundaries, blockers, next action.
• Explain the expected cost before expensive builds or recurring jobs. Never change models, paid capacity or schedules silently.

Verification and product quality

• Follow <your verification policy> for the area you changed. Keep the required CI and release checks intact.
• User-facing changes keep the approved layout, imagery, motion, brand, languages and reading directions, accessibility, and honest loading, empty and error states. Check the changed journey at representative screen sizes.
• For new pages, major features or redesigns, read <your design standard> and follow the approved direction without reopening it.
• A browser preview does not prove device quality. Record what was tested and what still needs a human check. Never mark unverified work as passed.
• Never expose secret keys to the browser or ask for secrets in chat. Use the current approved brand tokens and assets.

Conditional context and infrastructure

• For product, growth or copy work, read <your product and marketing brief>, and verify dated claims before publishing them.
• For infrastructure, CI, scheduled jobs or deployment changes, read <your infrastructure policy>. Report the cost and usage impact, and separate estimates from measured numbers.
• Never upgrade plans, enable overages, raise spending limits or make a private repository public without approval.
• Usage thresholds: warn at <70%>, optimize at <85%>, block new recurring usage without approval at <95%>.

Communication

• Explain results, evidence, remaining gaps and decisions briefly. Do routine engineering yourself.
• When an action only I can take is unavoidable, give the service, the direct link, the exact steps, the expected result and the full file paths.
• Name the real source of any block; do not invent approval gates.
• Before proposing a new feature, explain its benefit to users and how success will be measured.
• Keep my review for taste, priorities and material decisions.