Four everyday situations · two AI experiences
Switch between the tabs. Each comparison comes directly from the seven v1.0.1 sections: see how a different judgement model changes the experience, not just the process.
- 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
Core direction
Facts, safety, and the user’s goal come first. Small clear work uses the smallest sufficient change.
Precedence and sources
Resolve conflicts by level. Check dates, versions, platform behavior, and target content before relying on them.
Replies and collaboration
Keep replies direct. Offer choices only for real trade-offs, with recommendations and risk labels preserved.
Effort and planning
Scale effort to consequence, uncertainty, and reversibility. Focus long work first; use five sections and challenge only for higher impact.
Changes, governance, and delivery
Define one rule in one place. Review governance changes before editing and make delivery readable back.
Execution, safety, and authorization
Stay inside workspace boundaries, protect secrets, and get separate approval for external writes, release, deployment, spending, or deletion.
Acceptance, formats, and context
Checks map to risk. JSON, Mermaid, line-semantic review, and context continuation all stay testable.
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 does not move the real goal forward | Long work gets a level-focus check first. When the work needs a baseline or direction decision, the agent then checks core source coverage, scope, failure state, and counterexamples. |
| The agent reads search summaries or an old handoff and sets a baseline too early | Search, summaries, headers, indexes, and old handoffs may locate sources of truth. If core sources are unread or conflicting, the agent must read more, narrow scope, or ask you to decide. |
| 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. |
| The user asks for line-by-line review, but the agent only checks sections, keywords, or samples | Line-by-line review means line-semantic acceptance: inspect each line for meaning, ambiguity, anchoring, scope leakage, contradiction, and missing counterpart. |
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
It helps with workplace documents and analysis, creative work, coding agents, long-lived governance, and counter-review of high-consequence plans. Creative work stays flexible; safety, privacy, and required formats still remain.
2Level focus and full-picture planning: align first, then decide whether it can run
The five sections are not there to make a plan longer. In v1.0.1, 🎯 level focus first separates the final outcome, this turn's output, core source coverage, and stop condition. Only aligned work where a mistake would have a larger impact needs a full-picture plan and the applicable challenge.
What you will receive
| Result | What it means | What happens next |
|---|---|---|
| 🎯 Aligned | This turn's output, work level, sources, success evidence, and stop condition fit together. | Only then may the agent plan or execute. |
| Misaligned | The goal, level, output, or evidence does not fit; technical steps passing would not count as real progress. | Narrow the goal, level, or evidence first. |
| 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.” When failure could affect safety, secrets, permissions, data or version integrity, irreversible or external state, migration recovery, or a cross-surface core promise, a reviewer 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. Low-risk reversible work uses proportionate checks. 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. Claims about real people, brands, law, medicine, finance, safety, or public statements are still checked. |
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.
Six 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. |
| Unresponsive tools | Check first for partial writes or unknown side effects. Retry only once through an equally safe, authorized, auditable official channel. |
| 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.
General placement rule
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 confirms sources, scope, failure state, and counterexamples 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.