git:20261001.76f18e4 to git:20261007.2d9ecb3

+ description: Design rules and a change process for prompts written for agents, multi-agent pipelines and SKILL.md files, based on official sources. Use when writing, changing or reviewing any of them.

+ # Design rules for prompts, pipelines and Skills written for agents

+ When you write, change or review any of the following, check it against these rules one by one, and make the change by the process in section 4: prompts that a dispatcher (the agent or script that hands out a task) writes to an executor (the subagent or external agent that receives the task), multi-agent pipelines, `SKILL.md` files (including the `description` in the frontmatter), and Skills the executor will read. Each rule lists the official sources behind it. The archive in [references/sources/](references/sources/README.md) keeps verbatim excerpts of the cited passages, with each document's official URL and the sha256 of its full text; the full texts are kept privately for comparison.

+ ## General principles

+ **Every instruction, every role and every step encodes an assumption about what the model can't do on its own.** As models improve, these assumptions go stale; delete the stale ones. To decide whether something stays, ask: would removing it cause the model to make mistakes? If not, delete it, or have the runtime enforce it instead.

+ Sources: [Harness design · Iterating on the harness](references/sources/anthropic/harness-design-long-running-apps.md#iterating-on-the-harness), [Fable 5 · Recommended scaffolding changes](references/sources/anthropic/prompting-claude-fable-5.md#recommended-scaffolding-changes), [Claude Code · Write an effective CLAUDE.md](references/sources/anthropic/claude-code-best-practices.md#write-an-effective-claudemd), [GPT-6 Astra · Up-to-date AGENTS.md](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#up-to-date-agentsmd), [Scaling Managed Agents](references/sources/anthropic/scaling-managed-agents.md) (opening: the context resets an older model needed became dead weight on a newer one).

+ Cutting means cutting constraints on behavior, not context. Context is what only the author knows: the audience, environment facts, the quality bar, and the reasons behind constraints. Give more context rather than less: when a delegated task description is too short, the executor fills the gaps with safe defaults, and duplicates work, leaves parts out or misreads the task. A constraint on behavior is a sentence that tells the executor how to act; test each one before you delete it, as described in 4.5. Always state the goal, the done criteria and the few real boundaries clearly.

+ Sources: [Prompt audit · Step 3](references/sources/anthropic/prompt-audit.md#step-3-classify-every-line---the-deletion-rule) (context and constraints on behavior are judged separately), [Prompt audit · What not to flag](references/sources/anthropic/prompt-audit.md#what-not-to-flag---the-keep-list) ("give the model more context than seems necessary, not less"), [Multi-agent research system · Prompt engineering](references/sources/anthropic/multi-agent-research-system.md#prompt-engineering-and-evaluations-for-research-agents), [Context engineering · The anatomy of effective context](references/sources/anthropic/effective-context-engineering.md#the-anatomy-of-effective-context).

+ **Priority.** The user's explicit instructions take precedence over these rules and over any Skill. Sources: [Using GPT-6 · Instruction following](references/sources/openai/using-gpt-6.md#instruction-following).

+ **Advice that holds for one model only.** Where an official guide names a specific model, its advice was measured only on that model. When the advice for different models conflicts, write a requirement on the result that holds for every model, and do not copy one model's specific instruction. Verification is an example: the Opus 5 guide recommends removing verification instructions, while the Fable 5 guide recommends explicitly asking for verification with subagents at intervals on long tasks. Sources: [Prompting best practices · General principles](references/sources/anthropic/claude-prompting-best-practices.md#general-principles).

+ ## 1. Prompts from the dispatcher to the executor

+ 1. **Describe the result, the purpose and the done criteria, not the steps.** Say what you want, who it is for, and what counts as done. Prescribe a process only when the user or the pipeline explicitly requires one.

+ Sources: [Codex Prompting · Describe the result you need](references/sources/openai/codex-prompting.md#describe-the-result-you-need), [Codex Prompting · Prompting overview](references/sources/openai/codex-prompting.md#prompting-overview), [Fable 5 · Give the reason, not only the request](references/sources/anthropic/prompting-claude-fable-5.md#give-the-reason-not-only-the-request), [Codex Long-running work · Define what done means](references/sources/openai/codex-long-running-work.md#define-what-done-means), [Opus 5 · Capability improvements](references/sources/anthropic/prompting-claude-opus-5.md#capability-improvements) ("performs best when given the complete task specification up front and left to run").

+ 2. **Write the done criteria as observable results and the evidence to hand back.** Verification instructions come in two kinds. Do not write verification rituals such as "double-check your work" or "verify twice before responding". Put real checks that can run into the done criteria: give a command or script that can be run as is, such as the tests, the type checker, the build, or the changed command itself, and ask for its output; when a check cannot run, ask the executor to say which one it did not run and why. Pass on verification requirements the user stated themselves unchanged.

+ Sources: [Reducing cost · Instructions](references/sources/anthropic/reducing-cost-and-improving-performance.md#instructions) ("Verification rituals"), [Opus 5 · Task scope and over-verification](references/sources/anthropic/prompting-claude-opus-5.md#task-scope-and-over-verification), [Opus 5 · Self-correction](references/sources/anthropic/prompting-claude-opus-5.md#self-correction), [GPT-6 Astra · Up-to-date AGENTS.md](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#up-to-date-agentsmd) (instructions to test can lead to unnecessary testing), [Using GPT-6 · Testing and verification](references/sources/openai/using-gpt-6.md#testing-and-verification), [Sonnet 5.5 · Verification on coding tasks](references/sources/anthropic/prompting-claude-sonnet-5-5.md#verification-on-coding-tasks) ("say which one you did not run and why"), [Claude Code · Give Claude a way to verify its work](references/sources/anthropic/claude-code-best-practices.md#give-claude-a-way-to-verify-its-work), [Prompt audit · 1c](references/sources/anthropic/prompt-audit.md#1c-over-specification---describe-the-goal-not-the-method) ("State outcomes, constraints, and how to verify").

+ 3. **For each material, say what it is for and when to use it; do not ask the executor to "read everything before starting".** Give the paths and let the executor read what it needs. Require a full read only when the user or the pipeline explicitly asks for the full text.

+ Sources: [GPT-6 Astra · Up-to-date AGENTS.md](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#up-to-date-agentsmd), [Context engineering · Context retrieval and agentic search](references/sources/anthropic/effective-context-engineering.md#context-retrieval-and-agentic-search), [Harness engineering · Repository knowledge as the system of record](references/sources/openai/harness-engineering.md#we-made-repository-knowledge-the-system-of-record).

+ 4. **Write only the one or two boundaries that prevent real problems, each with its reason, stated once and positively.** The executor follows them literally: a strongly worded boundary makes it stop where it could have continued, and stacked prohibitions and emphasis words dilute the one that really matters. Boundaries that really exist must still be stated.

+ Sources: [Codex Prompting · Set boundaries that prevent real problems](references/sources/openai/codex-prompting.md#set-boundaries-that-prevent-real-problems), [GPT-6 Astra · Decision boundaries](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#decision-boundaries), [Prompting best practices · Add context to improve performance](references/sources/anthropic/claude-prompting-best-practices.md#add-context-to-improve-performance), [Claude Code · Write an effective CLAUDE.md](references/sources/anthropic/claude-code-best-practices.md#write-an-effective-claudemd), [Fable 5 · State the boundaries](references/sources/anthropic/prompting-claude-fable-5.md#state-the-boundaries).

+ 5. **Authorize the executor to finish the work unattended.** It does reversible work within its authorization without asking, first completes the parts that no open question blocks, and hands back to the dispatcher only decisions that the user alone can make, and destructive or irreversible actions.

+ Sources: [Fable 5.1 · Finish the whole task](references/sources/anthropic/prompting-claude-fable-5-1.md#finish-the-whole-task), [Fable 5 · Strong instruction following](references/sources/anthropic/prompting-claude-fable-5.md#strong-instruction-following), [Using GPT-6 · Initiative and follow-through](references/sources/openai/using-gpt-6.md#initiative-and-follow-through), [GPT-6 Astra · Persistence](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#persistence).

+ 6. **Do not prescribe the method.** Leave algorithms, libraries, command order and the number of tests to the executor, unless the user specifies them. What must hold are the invariants, not the implementation. Whether to use subagents is also the executor's decision; when the harness does not spawn subagents by default, or the executor tends to spawn too many (for example, its own reviewer subagents), write one condition for when to spawn or not, with its reason, for example that each extra agent costs more tokens and time, or that some part of the work needs an isolated context.

+ Sources: [Fable 5.1 · Finish the whole task](references/sources/anthropic/prompting-claude-fable-5-1.md#finish-the-whole-task) ("without much guidance on methodology"), [Harness engineering · Enforcing architecture and taste](references/sources/openai/harness-engineering.md#enforcing-architecture-and-taste), [Harness design · The architecture](references/sources/anthropic/harness-design-long-running-apps.md#the-architecture) (the planner constrains only the deliverables and leaves the path to the agents doing the work), [Sonnet 5.5 · Steer initiative and scope](references/sources/anthropic/prompting-claude-sonnet-5-5.md#steer-initiative-and-scope) ("don't launch reviewer sub-agents unless the user asked for a review"), [Opus 5 · Controlling subagent spawning](references/sources/anthropic/prompting-claude-opus-5.md#controlling-subagent-spawning), [Using GPT-6 · Subagent delegation](references/sources/openai/using-gpt-6.md#subagent-delegation), [Codex Subagents · Orchestration and thread controls](references/sources/openai/codex-subagents.md#orchestration-and-thread-controls) (local releases spawn agents only after a direct request or an applicable project or skill instruction).

+ 7. **Do not ask the executor to reproduce its reasoning in the response.** Such instructions may be refused as reasoning extraction.

+ Sources: [Fable 5 · Recommended scaffolding changes](references/sources/anthropic/prompting-claude-fable-5.md#recommended-scaffolding-changes).

+ 8. **An end of turn with text and no tool call is a report, not proof that the task is done.** When the executor hands back with items still open and no blocker stated, the dispatcher names those items in the same session and has it continue; continue the same task at most 2–3 times.

+ Sources: [Opus 5.5 · Unattended agentic runs](references/sources/anthropic/prompting-claude-opus-5-5.md#unattended-agentic-runs).

+ 9. **Do not describe the grader to the executor; state every requirement the grader checks.** Phrases such as "someone will review this later" or "there are hidden tests" describe the checking apparatus, not the requirement, and push the executor's effort toward being watched. Write every item the verifier will check directly into the done criteria.

+ Sources: [Prompt audit · 1c](references/sources/anthropic/prompt-audit.md#1c-over-specification---describe-the-goal-not-the-method) ("State every requirement the grader checks; never describe the grader").

+ ## 2. Pipeline design

+ 1. **Start with one agent; split only for a clear benefit.** Splitting is worth it in only four cases: contexts would pollute each other, the work can genuinely run in parallel, parts need different tools or conflicting instructions, or the work needs independent verification. Multiple agents typically use 3–10 times more tokens.

+ Sources: [Multi-agent systems · Starting with a single agent](references/sources/anthropic/building-multi-agent-systems-when-and-how.md#the-case-for-starting-with-a-single-agent), [Multi-agent systems · Decision framework](references/sources/anthropic/building-multi-agent-systems-when-and-how.md#a-decision-framework-for-multi-agent-systems), [Orchestration · Add specialists only when the contract changes](references/sources/openai/orchestration-and-handoffs.md#add-specialists-only-when-the-contract-changes), [Building effective agents · When to use agents](references/sources/anthropic/building-effective-agents.md#when-and-when-not-to-use-agents).

+ 2. **Split along context boundaries, not by type of work.** The role that already holds a context does the next step that depends on it; do not split the planning, implementation and testing of the same work across different roles, or each handoff loses part of the information. Three kinds of boundary can be split: independent research paths, components with clean interfaces, and verification that looks only at results. Example: the checker that verified how the review findings were resolved goes on to write the revised plan, rather than a new role being dispatched to read the dispute from the start.

+ Sources: [Multi-agent systems · Context-centric decomposition](references/sources/anthropic/building-multi-agent-systems-when-and-how.md#context-centric-decomposition), [Multi-agent research system · Appendix](references/sources/anthropic/multi-agent-research-system.md#appendix) ("game of telephone").

+ 3. **Hand checks to a new session; do not let the author check its own work.** An author evaluating its own output tends to approve it. The verifier gets only the done criteria, the artifact and the original materials, not the discussion along the way; the verifier only reports problems and does not change the artifact, and the author makes the changes from the report.

+ Sources: [Harness design · Why naive implementations fall short](references/sources/anthropic/harness-design-long-running-apps.md#why-naive-implementations-fall-short), [Fable 5 · Recommended scaffolding changes](references/sources/anthropic/prompting-claude-fable-5.md#recommended-scaffolding-changes) ("fresh-context verifier subagents tend to outperform self-critique"), [Claude Code · Run multiple Claude sessions](references/sources/anthropic/claude-code-best-practices.md#run-multiple-claude-sessions), [Claude Code · Add an adversarial review step](references/sources/anthropic/claude-code-best-practices.md#add-an-adversarial-review-step), [Multi-agent systems · The verification subagent pattern](references/sources/anthropic/building-multi-agent-systems-when-and-how.md#the-verification-subagent-pattern).

+ 4. **In the verifier's prompt, state item by item what to check and what counts as a failure, and have it report only problems that affect correctness or the stated requirements.** Write only "check it", and the verifier takes a quick look and approves; ask it instead to "find gaps", and it will report some even when the work is sound, and chasing every finding leads to over-engineering, so mark the other comments as optional. This does not conflict with 1.2: verification is itself the verifier's task.

+ Sources: [Multi-agent systems · The early victory problem](references/sources/anthropic/building-multi-agent-systems-when-and-how.md#the-early-victory-problem), [Harness design · Running the harness](references/sources/anthropic/harness-design-long-running-apps.md#running-the-harness) ("Out of the box, Claude is a poor QA agent"), [Claude Code · Add an adversarial review step](references/sources/anthropic/claude-code-best-practices.md#add-an-adversarial-review-step).

+ 5. **Add independent verification as the task needs it; do not add repeated checks by the same author.** Add an independent verifier only when the task sits beyond what the model does reliably on its own (long runs, large documents, consistency across several sources). What to delete are the extra rounds in which the author rereads and confirms its own output; the author running tests or scripts and fixing what they show is a real check under 1.2, and stays.

+ Sources: [Harness design · Removing the sprint construct](references/sources/anthropic/harness-design-long-running-apps.md#removing-the-sprint-construct) ("The practical implication is that the evaluator is not a fixed yes-or-no decision"), [Opus 5 · Task scope and over-verification](references/sources/anthropic/prompting-claude-opus-5.md#task-scope-and-over-verification) ("The same applies to legacy harness scaffolding that adds separate verification steps"), [Multi-agent systems · The verification subagent pattern](references/sources/anthropic/building-multi-agent-systems-when-and-how.md#the-verification-subagent-pattern), [Sonnet 5.5 · Steer initiative and scope](references/sources/anthropic/prompting-claude-sonnet-5-5.md#steer-initiative-and-scope) ("Don't start extra rounds of review or hardening on your own"), [Skill authoring · Implement feedback loops](references/sources/anthropic/skill-authoring-best-practices.md#implement-feedback-loops) ("Run validator → fix errors → repeat").

+ 6. **In reviews, report everything first, then filter.** The first-pass review prompt sets no severity threshold and does not say "be conservative", or the model follows that literally and reports less; filtering belongs in a later cross-examination or checking step.

+ Sources: [Opus 5 · Capability improvements](references/sources/anthropic/prompting-claude-opus-5.md#capability-improvements) (Code review and bug-finding).

+ 7. **Independent perspectives must really differ, and evidence settles the conclusion.** Several agents on the same model with similar contexts make the same mistakes; discussion tends to converge on what everyone already knows, and a key fact that only one of them holds gets ignored. Agreement among several reviewers is not evidence; when they disagree, an independent role decides on the evidence, not by majority vote or negotiation.

+ Sources: [Multiagent systems research · Failures from conformity](references/sources/anthropic/multiagent-systems-patterns-and-problems.md#failures-from-conformity), [Multiagent systems research · Epistemic failures](references/sources/anthropic/multiagent-systems-patterns-and-problems.md#epistemic-failures).

+ 8. **Give every loop a convergence condition and a maximum number of rounds.** Automatic continuation or revision usually gets 2–3 rounds; at the limit, stop, keep the open items and the evidence, and do not fake a pass.

+ Sources: [Opus 5.5 · Unattended agentic runs](references/sources/anthropic/prompting-claude-opus-5-5.md#unattended-agentic-runs).

+ 9. **Stop to ask only when the user must decide**, and keep going on all other work the question does not affect; for anything that needs the user's approval, first carry it to the point where the user can approve it directly.

+ Sources: [Fable 5 · Strong instruction following](references/sources/anthropic/prompting-claude-fable-5.md#strong-instruction-following), [Fable 5.1 · Finish the whole task](references/sources/anthropic/prompting-claude-fable-5-1.md#finish-the-whole-task) (Delivering work), [Using GPT-6 · Initiative and follow-through](references/sources/openai/using-gpt-6.md#initiative-and-follow-through).

+ 10. **Have the runtime or a tool enforce actions that must happen every time; do not write them as prompt rules.** For example: installing dependencies, verifying commits, checking source SHAs.

+ Sources: [Claude Code · Set up hooks](references/sources/anthropic/claude-code-best-practices.md#set-up-hooks) (hooks are deterministic; instructions in files such as CLAUDE.md are only advisory), [Harness engineering · Enforcing architecture and taste](references/sources/openai/harness-engineering.md#enforcing-architecture-and-taste).

+ 11. **When work must be picked up again, continue in the same session by default.** Open a new session only when that session is unavailable, and hand off through the repository, the git history and progress notes. Do not show the model its remaining context budget, and do not say things like "you have no memory and will hand off soon": this prompts it to wrap up early.

+ Sources: [Harness design · The architecture](references/sources/anthropic/harness-design-long-running-apps.md#the-architecture) (context resets were dropped on a newer model), [Fable 5 · Rare cases of context-budget concern](references/sources/anthropic/prompting-claude-fable-5.md#rare-cases-of-context-budget-concern), [Prompting best practices · Long-horizon reasoning and state tracking](references/sources/anthropic/claude-prompting-best-practices.md#long-horizon-reasoning-and-state-tracking), [Effective harnesses · Getting up to speed](references/sources/anthropic/effective-harnesses-for-long-running-agents.md#getting-up-to-speed), [Long horizon tasks with Codex · Durable project memory](references/sources/openai/run-long-horizon-tasks-with-codex.md#the-key-idea-durable-project-memory).

+ ## 3. SKILL.md and the description

+ 1. **The description says only "what it does" and "when to use it".** Use the words users actually say as triggers, and keep it as short as possible; do not pile up synonyms, and do not describe the scope as wider than it is.

+ Sources: [GPT-6 Astra · Better skills](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#better-skills), [Skill authoring · Writing effective descriptions](references/sources/anthropic/skill-authoring-best-practices.md#writing-effective-descriptions).

+ 2. **Use SKILL.md as a router.** Content needed every time goes in the body; content needed only in some cases goes in `references/`, with a one-line pointer in the body that says when to read it. Keep the body under 500 lines. Put the most important constraints, the ones that apply throughout, at the top of the body: a Skill is not re-read after it loads, and after context compaction only its beginning may be kept.

+ Sources: [Skill authoring · Progressive disclosure patterns](references/sources/anthropic/skill-authoring-best-practices.md#progressive-disclosure-patterns), [Skill authoring · Token budgets](references/sources/anthropic/skill-authoring-best-practices.md#token-budgets), [GPT-6 Astra · Better skills](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#better-skills), [Harness engineering · Repository knowledge as the system of record](references/sources/openai/harness-engineering.md#we-made-repository-knowledge-the-system-of-record) ("give Codex a map, not a 1,000-page instruction manual"), [Claude Code skills · Skill content lifecycle](references/sources/anthropic/claude-code-skills.md#skill-content-lifecycle) (after compaction, only the first 5,000 tokens of each Skill are kept), [Claude Code skills · Claude stops following a skill](references/sources/anthropic/claude-code-skills.md#claude-stops-following-a-skill) ("put the most important instructions near the top of SKILL.md").

+ 3. **Assume by default that the model is already very smart, and write only what it does not know:** the project's own conventions, the reasons behind choices, and the gotchas you have run into.

+ Sources: [Skill authoring · Concise is key](references/sources/anthropic/skill-authoring-best-practices.md#concise-is-key), [Claude Code · Write an effective CLAUDE.md](references/sources/anthropic/claude-code-best-practices.md#write-an-effective-claudemd).

+ 4. **Match the degree of freedom to the risk.** Steps where mistakes are costly and that must be consistent every time are "narrow bridges", for example dispatching, resuming, concurrent writes and delivery checks in the dispatch control plane: use exact commands and runtime checks. The executor's implementation, review and writing are "open fields": give the goal, not the route.

+ Sources: [Skill authoring · Set appropriate degrees of freedom](references/sources/anthropic/skill-authoring-best-practices.md#set-appropriate-degrees-of-freedom).

+ 5. **Say each thing in one place only; save emphasis for the one line that is in fact ignored again and again.** When everything is emphasized, nothing is.

+ Sources: [Claude Code · Write an effective CLAUDE.md](references/sources/anthropic/claude-code-best-practices.md#write-an-effective-claudemd), [Harness engineering · Repository knowledge as the system of record](references/sources/openai/harness-engineering.md#we-made-repository-knowledge-the-system-of-record) ("When everything is important, nothing is").

+ 6. **Review Skills the executor will read against these rules too.** Newer models are more sensitive to instructions in Skills and AGENTS.md, and unclear or conflicting instructions can make them stop early; a Skill is read by different models, so it must hold for every model that will use it.

+ Sources: [Using GPT-6 · Instruction following](references/sources/openai/using-gpt-6.md#instruction-following), [GPT-6 Astra · Better skills](references/sources/openai/rethinking-skills-and-prompts-for-gpt-6-astra.md#better-skills), [Skill authoring · Test with all models you plan to use](references/sources/anthropic/skill-authoring-best-practices.md#test-with-all-models-you-plan-to-use).

+ 7. **Write rules as current requirements, without their history.** Do not turn one slip directly into a permanent rule: first confirm that the same problem would occur in most sessions, then add it under 3.3 as a gotcha you have run into. The rule text says only what to do now: no incident narrative, PR numbers or dates, and no phrasing relative to an older version such as "no longer" or "changed to": the executor never saw the older version, and such words make it guess at an alternative that does not exist. When special cases of one kind pile up, merge them into one principle.

+ Sources: [Prompt audit · Group 2](references/sources/anthropic/prompt-audit.md#group-2---brittle-skill-and-configuration-files) (The recency trap, History narratives), [Prompt audit · 1d](references/sources/anthropic/prompt-audit.md#1d-fossils---text-that-outlived-its-model) (Migration-relative phrasing, Patch accretion), [Codex skill-creator · Core Principles](references/sources/openai/codex-skill-creator.md#core-principles) ("Do not turn a particular example, past failure, or personal preference into a universal requirement"), [Codex skill-creator · Validate and Iterate](references/sources/openai/codex-skill-creator.md#validate-and-iterate) ("Prefer a narrow correction to accumulating universal rules").

+ ## 4. Change process

+ Work in order, and finish each step before starting the next:

+ 1. **List the changes.** For every instruction, role or step you add or change, write down which shortcoming of the model it makes up for, and map it to a rule here or a section of a source. Do not add anything that maps to neither.

+ 2. **Check the related existing content.** For each existing instruction the change touches, confirm whether the current model still needs it, and delete it if not. When two rules in the same Skill conflict in some cases, state which one takes precedence in which case, rather than leaving the executor to reconcile them. Sources: [Reducing cost · Instructions](references/sources/anthropic/reducing-cost-and-improving-performance.md#instructions) ("Contradictory rules"), [Using GPT-6 · Instruction following](references/sources/openai/using-gpt-6.md#instruction-following) (unclear or conflicting Skill instructions can make the model stop early), [Prompt audit · Group 2](references/sources/anthropic/prompt-audit.md#group-2---brittle-skill-and-configuration-files) (Instruction files that contradict each other).

+ 3. **Remove one component at a time.** When cutting roles or steps from a pipeline, change one thing at a time, and record in the project's change log the basis for the change and the data to watch in the next run. Sources: [Harness design · Iterating on the harness](references/sources/anthropic/harness-design-long-running-apps.md#iterating-on-the-harness).

+ 4. **Record the basis.** The PR description or the change log cites the rules in this Skill.

+ 5. **Compare runs.** After deleting or changing instructions, run a few real requests in new sessions against the version before and the version after (or with and without the Skill), compare the behavior, and write the results into the same record. Asking the model "do you still need this?" is not verification; a new session keeps leftover context from authoring from masking gaps in the written text. Sources: [Prompt audit · Step 7](references/sources/anthropic/prompt-audit.md#step-7-verify---removal-is-a-hypothesis-not-a-conclusion) ("Asking the model whether it needs an instruction is not a measurement"), [Claude Code skills · Evaluate and iterate on a skill](references/sources/anthropic/claude-code-skills.md#evaluate-and-iterate-on-a-skill), [Skill authoring · Build evaluations first](references/sources/anthropic/skill-authoring-best-practices.md#build-evaluations-first).

+ Done criteria: every change maps to a rule here or a section of a source; where advice for different models conflicts, the text has been rewritten to hold for every model; rules in the same Skill that may conflict have a stated precedence; every deleted or changed instruction has before-and-after comparison results.

+ ## 5. Updating these rules

+ When a vendor releases a new model or a new prompting guide, update the sources and these rules as described in the [source list](references/sources/README.md#updating-a-source).