# `` agent instructions Adapted from the instructions file I run GameDropRadar with. Replace everything in ``, 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 `` 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 `` 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 ``, and verify dated claims before publishing them. - For infrastructure, CI, scheduled jobs or deployment changes, read ``. 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.