Four key rules · two AI experiences
Switch between the tabs. Each comparison comes directly from the rule map below: see how a different way of thinking changes the experience, not just the process.
🚀 Choose one next
A. Reuse the existing daily export — less change, but not live data.
B. Build a sync API — live updates, but a new integration to maintain.
💡 Recommendation: A — the partner accepts daily batches, so it meets the goal with less change.
- End-state snapshot — 🔎 Task understanding: change the upgrade flow without harming old data;
Executable. State invariants, exclusions, and known versus unverified state. - Deliverables — List affected upgrade code, data format, and documentation; do not invent an absolute path that is unknown.
- Success evidence — Old data can be read back; interruption leaves a knowable state, recovery entry, and authoritative read-back.
- Acceptance tests — Test normal upgrade plus interruption, conflict, version reversal, and a false-green case where data is still harmed.
- Goal links — Link external platform behavior to official sources and project changes to their current source of truth.
.env in the commit, then push it and create the public release..env contains a secret. It cannot appear in output, logs, or commits.
I can fix settings that are safe to modify and read them back. Pushing and creating a public release are separate external actions: I will list their target and impact, then wait for your explicit authorization.
Overview
You do not need to read every line first. Start with the four scenarios above, jump to the part that matches your work, and use the setup section when you are ready to install it.
Rule map
Precedence
When rules compete, safety, permissions, and irreversible consequences win.
Language & replies
Lead with the point. Keep simple work short. Each language version replies naturally in its own language.
Effort & stopping
Lower risk means lighter work. Stop once acceptance is sufficient; do not chase unrelated issues.
Choices & sources
Offer choices only when the user genuinely needs to choose. Do not rename existing keys, headings, or schemas.
Full-picture plan qualification
For work where a mistake would have a larger impact, see the scope, evidence, and counterexamples before deciding it can run.
Read before judging
Check changing facts, platform behavior, and target content. Say what remains unverified.
Long-lived rules
When a rule or several linked places must stay aligned, the agent first confirms the scope before proposing a change.
Checkable changes
When you need to paste a change yourself, get an anchor, before/after content, and a way to check it.
Calculations & structure
Show working only when it helps. Follow existing JSON and diagram formats.
Workspace & scope
Read related files first. Use an existing delivery location. Get separate approval for side effects.
Secrets & file safety
Do not expose secrets, bypass permissions, or solve a problem with dangerous deletion or overwrite commands.
Agent workflow
Long work can resume cleanly. Repeated failure returns to root cause. Release and spending always need separate authorization.
Problems it is built to prevent
| Common problem | What this instruction does |
|---|---|
| The agent edits before it understands the scope | Read project guidance, the target, and direct context first. Search wider only when impact is unknown. |
| A simple task gains too much ceremony and becomes slow | Match effort to consequence, uncertainty, and reversibility. Small clear work does not need a full-picture plan. |
| A polished plan has no recovery or failure model | For work where a mistake would have a larger impact, the agent completes the applicable challenge before giving you an executable plan; if it cannot, it states the block directly. |
| Research mixes summaries, memory, and inference | Separate source, date, fact, inference, and what remains unverified. |
| The agent invents a fixed folder or parallel structure | Use the existing directory, source-of-truth location, or platform delivery location; otherwise provide manually savable content. |
| “The content is ready” becomes permission to push or publish | External writes, public release, access changes, spending, and data deletion each need their own explicit authorization. |
| Acceptance keeps growing without new evidence | Every added check must map to an unresolved risk. Stop when affected scenarios pass. |
1How the agent works
This instruction does not tell an agent to slow down forever. It asks it to judge consequence and reversibility first, then choose a method that is just enough for the job.
The common failure
Some agents act as soon as they hear a task. Others wait for approval at every step. Both blur the one question you should care about: which decisions need you, and which authorized actions can safely be completed without burdening you?
What the agent does
- Classify the consequence first. Authorized, low-risk, reversible work without side effects can proceed. Value trade-offs, public action, spending, access, deletion, and irreversible work are named before asking.
- Match effort to risk. If relevant reading, one change, and one focused check are enough, it does not add an unnecessary plan, extra paperwork, or repeated checks just for show.
- Bring in only necessary discoveries. Fix a finding if it blocks this task’s acceptance, was caused by this change, or makes the delivery inconsistent. Record other discoveries separately.
- Know when to stop. Stop when the result checks out, important in-scope questions are resolved, and the needed updates are aligned. More rounds do not create stronger evidence by themselves.
Why this matters
This precedence order saves you from reteaching the agent that safety outranks formatting and that sources of truth outrank pretty rewrites. It also protects speed: simple work with no unresolved risk does not get forced into a heavyweight workflow.
Where it helps
Every workspace task: code changes, research, document organization, README writing, release preparation, and long-lived rules. Creative work stays flexible; safety, privacy, and required formats still remain.
2Full-picture plan qualification: see the whole plan before deciding it can run
The five sections are not there to make a plan longer. They let you see scope, deliverables, evidence, counterexamples, and sources before action. Only work where a mistake would have a larger impact needs plan qualification and an applicable challenge.
What you will receive
| Result | What it means | What happens next |
|---|---|---|
| Executable | There is enough evidence, a clear set of must-not-fail conditions, and a way to check the result. | Obtain the approval appropriate to the consequence. Executable is not user authorization. |
| Blocked | A core source, capability, or safety condition is still missing, so the agent does not hand you a pretend-complete plan. | It names the gap, the safe checks already completed, and the condition needed to continue. |
When this extra layer is warranted
Not merely because there are several files. Low-risk single-file edits, a new file with a clear location, independent simple changes, read-only work, and an already approved plan do not trigger it. It is for work that is hard to reverse, can contaminate data or versions when it fails, or must preserve one core promise across several surfaces.
What the agent does
It states must-not-fail conditions such as “a failed check cannot be marked successful,” “unrecognized content cannot be guessed over,” and “the state must be knowable after interruption.” Where a mistake would have a larger impact, someone who did not write the plan starts from the original request and tests interruption, conflict, concurrency, version reversal, boundary escape, recovery, and false-green cases. Only then does the agent deliver the full plan. A problem affecting safety, permissions, data integrity, or core acceptance cannot simply be renamed “accepted risk.”
How the five sections help
End-state snapshot states scope, status, and what must not fail. Deliverables name real resources and actions. Success evidence includes failure state and recovery. Acceptance tests include a counterexample that can disprove the plan. Goal links connect the work to its sources. Without any one of these, the agent cannot honestly call the plan complete.
3Be direct without pretending to know
This instruction asks the agent to lead with the conclusion, then add only the background, method, and next step that matter. It also separates a short answer from a formal delivery: not every task deserves a report.
Ask only when there is a real choice
The agent does not hand every technical detail back to you as a question. Only when two or more reliable paths would materially change the result does it show viable options, their impact, and an objective recommendation. If there is no real trade-off, it makes the judgement.
What the agent does
| Situation | Appropriate reply |
|---|---|
| Simple, low-risk, clear answer | Complete it directly. Do not repeat the conclusion just to fill a format. |
| Everyday analysis, comparison, or repair | Lead with a plain-language 🔎 takeaway within three lines, then add only the reasons, method, and next step that help. |
| There are truly two or more value trade-offs | Offer reliable options, their impact, and an evidence-based recommendation. If there is no real choice, make the judgement. |
| The user explicitly asks for one format | Return only that structure, with no preface, summary, or follow-up question. |
| Creative work, ideation, or fiction | Do not force a five-section plan, engineering workflow, or calculation steps. Safety, privacy, and required format still apply. |
Why this matters
You see the conclusion sooner and can trace why the agent reached it. If the user supplies keys, headings, enums, or a schema, this instruction preserves them exactly instead of breaking downstream compatibility in the name of “better wording.”
4Read before judging; leave unknowns unknown
This instruction does not let a timestamp, search hit, summary, or memory substitute for actual content. That does not mean reading the entire world every time. It means establishing enough coverage, then naming what remains uncovered.
Three core rules
| Rule | What the agent does | What you get |
|---|---|---|
| Verifiable external facts | Check dates, versions, prices, law, people, companies, and platform behavior first. Mark what cannot be verified. | Changing information is not presented as settled fact. |
| Target content and sources of truth | Read direct context. For a large scope, use search and an index to map coverage, then say what was not covered. | The agent knows the real location it is changing and does not treat a summary as the source. |
| Handoffs and earlier conclusions | Use a summary only as a lead. Before changing or claiming completion, read back authoritative sources, actual files, saved output, and tool evidence. | A new chat or agent does not mistake an old claim for fact. |
5Before and after: make a change easy to check
When you need to paste a change yourself, the agent should not merely say “done.” It gives a findable anchor, clearly separate before/after content, and one way to check the result.
When you need to paste the change yourself
The agent first tells you which sentence or section to find, then separates the before and after content. You can see what changed, where to put it, and how to read it back to check.
You do not need the whole source every time
- The agent can safely edit files. List the file, key difference, and acceptance result; do not paste the whole source again.
- You must paste manually. Use the anchor, before/after content, and check shown above.
- Deletion, move, batch overwrite, or an irreversible action. State the target and impact clearly, then get confirmation before acting.
6Show working when it helps; answer directly when it does not
Calculations, JSON, and diagrams share the same principle: follow the existing structure, choose a method that can be checked, and do not add steps merely to look thorough.
Scale calculation to the risk
Check simple calculations and answer directly. Show full working and substitution checks only when the calculation is multi-step, error-prone, high-risk, or you ask for the process. That keeps financial work, unit conversion, discounts, tax, and data calculation traceable without making every easy answer long.
Structured output
| Delivery | What this instruction requires |
|---|---|
| JSON | Follow the existing schema. Omit optional fields with no data unless the schema requires null. Invent no fields and verify that the result parses. |
| Mermaid | Use sequenceDiagram for interaction and flowchart for process or branches. Quote ambiguous text and validate syntax. |
| Lists, tables, and reports | Put the conclusion the reader needs first, then keep only the useful detail. Do not invent fields or rename existing keys. |
7Workspace access needs workspace boundaries
This instruction sets action boundaries for agents that read and write projects, run commands, and touch external services. It does not replace sandboxing, permissions, or confirmation dialogs, but it tells the agent to use those protections correctly.
Five boundaries that matter most
| Area | What this instruction requires |
|---|---|
| Scope and files | Read the target and direct context first. Change only task-related content. Stop on concurrent or unexpected changes; never undo user work. |
| Safe writing | Do not assume a folder name or wrap file edits in an external shell. Do not bypass an ambiguous path, workspace escape, lock, or permission problem. |
| Secrets and destructive actions | Do not put tokens, keys, or certificates in replies, logs, or commands. Do not use dangerous recursive deletion, force reset, or bulk overwrite of unknown files. |
| External tools and platforms | Check official documentation before changing integrations, authentication, deployment, paid actions, or fast-changing interfaces. Do not guess a high-risk contract. |
| External side effects | Push, publish, deploy, send messages, schedule, change access, spend money, and delete data each need explicit authorization before execution. |
Optional: Agent Handoff Kit and Innovation Loop
This instruction governs how an agent reasons, acts, and checks inside a workspace in this task. It works on its own. Add other tools only when a longer project actually needs them.
Agent Handoff Innovation Loop (optional): helps a long project keep direction, research validation, requirements, and plans connected. A short task does not need this extra layer just to look complete.
In short: this instruction guides today’s work; the Kit carries work safely across chats; Innovation Loop supports longer exploration and validation.
Set up
Choose a tool you already use that can act inside a project or folder you authorized. Copy the full prompt in your chosen language into that tool’s project or workspace instruction location. Do not paste both language versions into one place.
Common agentic AI tools
| Tool | Simplest place to put it | Official guide |
|---|---|---|
| Claude Code | Put the chosen language version in a root CLAUDE.md. | Memory / CLAUDE.md |
| OpenAI Codex | Put the chosen language version in a root AGENTS.md. | AGENTS.md |
| Cursor | Use the chosen language version in Project Rules or AGENTS.md. | Rules |
| Antigravity | Add the chosen language version to the workspace’s always-on rule location. | Rules & Workflows |
How to check after pasting
- Give the agent a low-risk small task. Check that it reads relevant material, changes only what is needed, and reads the result back.
- Give it a research question with missing information. Check that it separates fact, inference, and what is unverified.
- Give it a task with an external side effect or where a mistake would have a larger impact. Check that it completes the applicable challenge before giving an executable plan; if a condition is missing, it should explain the block instead of giving a halfway plan.
FAQ
Q1: Will this instruction make the agent slow?
It should not. It explicitly matches effort to consequence, uncertainty, and reversibility: small clear work completes directly; only uncertain work or work where a mistake would have a larger impact gains plan qualification and challenge.
Q2: Does it support ordinary web ChatGPT or Claude chat?
No. This instruction is for agents that can act in an authorized workspace. General web chat has no reliable project read/write or execution boundary, so claiming the same result would not be honest.
Q3: Can I use only some rules?
Do not remove rules by hand. They support each other. If your tool genuinely cannot hold the full text, try the full version first, then adjust only for a specific problem you have actually observed.
Q4: How can I tell whether a plan is only “well formatted”?
Where a mistake would have a larger impact, look for must-not-fail conditions, the failure state, recovery route, authoritative read-back, and a counterexample that could disprove the plan. Without these, the agent should not give you an executable plan; it should explain what is blocking it instead.