Persistent Instructions, Skills, Reverse Prompting, and Prompt Contracts

A normal conversation can solve the current problem but often loses the lesson when the session ends. The user may correct the agent, explain a preference, reject an approach, or identify a recurring error. Unless that information is stored in a persistent layer, the same explanation must be repeated in a future session.

Agent mastery requires a system in which useful corrections compound. The agent should not merely fix the current output. It should improve the operating instructions that shape future outputs.

This lesson introduces four connected mechanisms:

• Persistent instruction files that are loaded at the start of a session.
• Self-modifying rules that convert corrections into durable operating knowledge.
• Agent skills that standardize repeatable workflows.
• Reverse prompting and prompt contracts that convert vague requests into executable specifications.

Together, these mechanisms turn isolated prompting into an evolving operating system.

Major agent environments use files that can be inserted at the beginning of a conversation. The names vary by platform. Examples include Gemini instruction files, Agents instruction files, and Claude instruction files. The name is less important than the mechanism: the content is automatically prepended to the agent's working context.

This means the file behaves like a reusable prompt that is active in every relevant session. It can contain:

• User preferences.
• Style requirements.
• Naming conventions.
• Project rules.
• Technical decisions.
• Behaviors to avoid.
• Steps the agent must perform before or after a task.
• Instructions for updating memory or rules.

A simple demonstration is to place a personal naming preference and a sign-off instruction in the file. A new conversation then follows those instructions even though they were not typed in the current message. The file has become part of the agent's starting context.

The benefit is consistency. Repeated instructions no longer need to be copied into every request.

The more valuable pattern is to make the persistent file update itself when important feedback occurs.

A self-modifying instruction system tells the agent to read the rule file at the beginning of every task and append a new rule when one of the following events occurs:

• The user explicitly corrects the output.
• The user rejects an approach, file structure, design pattern, or method.
• The agent encounters a bug caused by an incorrect assumption.
• The user states a durable preference.

The rule should be written as a clear imperative. A useful structure is:

Category: Always or never perform X because Y.

The reason matters because it helps the agent interpret the rule in future situations instead of following an isolated command without context.

Consider a website example. The agent creates a dark-mode portfolio. The user says, "Quit doing things in dark mode." A normal system changes the current site. A self-correcting system performs two actions:

1. It changes the current site to a light design.
2. It appends a durable rule stating that applications should not be created in dark mode because the user prefers light interfaces.

When a later session begins, the rule is already present. The agent no longer has to make the same mistake and receive the same correction.

This creates cumulative improvement. The first session may contain very few preferences, so the probability of preference-related errors is high. After several sessions, the rule set contains more knowledge. The agent begins to anticipate what the user wants rather than rediscovering it.

The pattern is high leverage because it converts ordinary feedback into persistent system improvement.

More rules are not automatically better forever. A large rule file consumes context before the current task begins. If it grows to hundreds or thousands of instructions, several problems can appear:

• Rules may duplicate one another.
• Old and new rules may conflict.
• Project-specific rules may incorrectly influence unrelated work.
• The agent may have less context available for the active task.
• Performance may decline because the prompt has become crowded.

A clear practical limit may not appear quickly, but the theoretical risk is real. A self-modifying system should therefore learn continuously while remaining organized.

Useful maintenance practices derived from the architecture include keeping rules concise, separating global and local instructions, and moving procedural detail into skills rather than allowing the main rule file to become a complete operating manual.

Persistent context can be organized into layers.

GLOBAL INSTRUCTIONS

Global instructions apply across projects. They can store broad preferences, communication style, recurring design choices, and user-wide operating rules.

LOCAL PROJECT INSTRUCTIONS

Local instructions apply only to a particular workspace. They can contain project architecture, technical constraints, local naming conventions, project-specific decisions, and requirements that should not affect other work.

MEMORY

Memory files store useful preferences or high-level lessons from previous work. They allow the agent to recall information without placing every historical detail in the current conversation.

SKILLS

Skills contain repeatable workflows. They should be loaded when a matching task occurs rather than being inserted in full for every session.

INLINE PROMPT

The current user request contains the immediate task, temporary context, and task-specific definition of done.

The order can be understood as a context stack. Broad global rules are applied first. Local project rules refine them. Relevant memory adds prior knowledge. A skill contributes a validated procedure. The inline request defines the current objective.

The design goal is to put each type of information in the correct layer. Information that must influence every session belongs in global instructions. Information that only matters to one project belongs locally. A repeatable process belongs in a skill. Temporary requirements belong in the current prompt.

Large language models are flexible and probabilistic. If given a loosely scoped task, they may approach it differently on different runs. That flexibility is useful for creative reasoning but undesirable when a validated process should be repeated consistently.

An agent skill narrows the range of possible behavior by defining a repeatable workflow. It functions like a standard operating procedure that the agent can invoke when a matching task appears.

A skill commonly includes:

• A name.
• A description explaining when it should be used.
• Instructions for carrying out the workflow.
• Optional tool requirements.
• Optional metadata.

The top section may use a structured header separated by hyphens. This header identifies the skill and allows the agent to know that the capability exists without loading the entire file immediately.

Examples of skills used throughout the module include:

• PDF processing.
• Algorithmic art generation.
• Prompt contracts.
• Reverse prompting.
• Multi-agent orchestration.
• Stochastic multi-agent consensus.
• Model chat or agent debate.
• Agent review.
• Video-to-action conversion.
• Multi-agent browser automation.

A successful prompt can therefore be converted into infrastructure. Instead of copying a long set of instructions every time, the user saves the validated process as a skill. The agent can run the same process repeatedly and share it across projects.

An algorithmic art skill demonstrates how a detailed workflow can standardize a creative task. The skill contains instructions for creating generative art with a particular library and guides the model through the same overall process each time.

The procedure can be copied into an agent, saved as a skill, and run. The agent creates the skill directory, generates supporting templates, builds the application, and opens the result in a browser. The finished interface allows parameters such as particle count, noise scale, turbulence, accent colors, and background colors to be changed or randomized.

The important point is not the specific artwork. The important point is that the result is not a downloaded application. It is a newly created application produced through a standardized workflow. The skill captures a process that another agent can reproduce.

This is the practical value of skills: validated procedures become portable and repeatable without eliminating the model's ability to reason within the procedure.

A skill library may contain many detailed workflows. Loading every skill in full would consume a large portion of the context window. The architecture therefore separates discovery from execution.

The agent can load only the compact name and description of each skill. When the current request matches a skill, the agent loads the full instructions for that specific workflow.

This allows the system to know that many capabilities exist without paying the full context cost of all of them at once. The pattern becomes especially important as the skill library grows.

A useful rule is:

Keep always-needed preferences in persistent instructions. Keep task-specific procedures in skills. Load the detailed skill only when it is required.

Persistent instructions and skills improve repeatability, but they do not solve an underspecified goal. Many disappointing agent results begin with a vague request.

Examples include:

• Build a beautiful website.
• Build a rate limiter.
• Email these people.
• Create Netflix 2.0.
• Make this perfect.

These prompts leave critical decisions unstated. The agent does not know what "beautiful" means, what the rate limiter must protect, which people must be contacted, what a successful email means, or which subset of Netflix is being requested.

The system is forced to make implicit assumptions. The result may be technically competent while still being wrong for the user.

Prompt contracts and reverse prompting are designed to remove these hidden assumptions before implementation begins.

A prompt contract is a structured specification created before a non-trivial task is executed. It contains four major sections:

GOAL

The goal states what the task is intended to achieve. It should describe the desired outcome rather than merely naming an activity.

CONSTRAINTS

Constraints define the non-negotiable boundaries. These can include design preferences, technical limits, required tools, prohibited approaches, length limits, performance standards, or environmental requirements.

OUTPUT FORMAT

The output format defines what the finished result should contain and how it should be organized or delivered.

FAILURE CONDITIONS

Failure conditions state what would make the result unacceptable. They prevent the agent from declaring completion while important defects remain.

For a website, failure conditions might include looking like a generic template, breaking on mobile, using poor animations, or exceeding a file-length limit. For an outreach task, a failure might be sending to fewer recipients than required or omitting mandatory information.

A prompt contract is similar to a project scope. It creates agreement before the work begins. It prevents the user from judging the result against requirements that were never communicated, and it prevents the agent from inventing the meaning of success.

A prompt contract should not become a prison. There are two failure extremes.

If the scope is too vague, the agent must invent too much. The result becomes unpredictable.

If the scope is too restrictive, the agent loses the flexibility to solve the problem intelligently. Every small change becomes a violation of the specification.

A strong contract defines the essential outcome, constraints, format, and failure conditions while leaving room for the agent to make implementation decisions.

The management analogy is a competent contractor who clarifies the assignment before beginning. The contractor does not demand that the client specify every hammer stroke. The contractor does require agreement on what is being built, the boundaries, the expected deliverable, and the conditions that would make the work unacceptable.

Reverse prompting moves the agent from passive execution to active clarification.

Instead of waiting for the user to provide a perfect prompt, the agent analyzes the request and asks a set of clarifying questions before it begins. The questions are designed to surface:

• Stated requirements.
• Implicit assumptions.
• Decision points.
• Failure modes.
• Taste-dependent choices.
• Missing constraints.

A useful implementation asks approximately five dynamically generated questions for a non-trivial build. The questions should be specific to the request rather than generic.

For a website, the questions might address:

• The primary goal: brand credibility, lead generation, or sales.
• Whether the site should be a single static page or use a framework.
• The desired visual style.
• Whether the agent should generate copy or use existing material.
• The most important user action or outcome.

The user may respond that the objective is brand credibility, the site should be a simple static page, the visual style should resemble a clean high-end software interface in a white theme, and the model may generate the copy.

Those answers remove several assumptions before a single file is written.

Reverse prompting and prompt contracts are most effective when used together.

The sequence is:

1. The user gives a high-level request.
2. The agent analyzes what is explicit and what is missing.
3. The agent asks clarifying questions.
4. The user answers.
5. The agent converts the answers into a structured prompt contract.
6. The user approves or modifies the contract.
7. The agent executes the task.
8. The final output is evaluated against the same contract.

Reverse prompting discovers the missing requirements. The prompt contract formalizes them.

This improves one-shot potential, meaning the probability that the first implementation will be close to the desired result. The agent is no longer guessing blindly about style, purpose, format, or constraints.

A request such as "Build me a beautiful site" is highly subjective. A prompt-contract skill can begin by examining the existing business site, identifying implicit assumptions, and drafting a contract.

A resulting contract may define:

• A single-page marketing site.
• A specific business purpose.
• Smooth scroll animations.
• A maximum amount of code.
• Required sections.
• Hover states and fade-in behavior.
• Mobile compatibility.
• A failure condition if the result resembles a generic template.
• A failure condition if animations are poor or the site breaks on mobile.

The user can review the contract before approving implementation.

A second example chains reverse prompting and the prompt-contract skill. The agent first asks about purpose, architecture, visual style, and copy. It then creates a contract for a light, minimal, high-end site. Because the desired aesthetic and structure have been clarified, the completed site is much closer to the intended outcome: a white interface, restrained design, clear service information, testimonials, and a call to action.

The improved result is not caused by a magical design prompt. It is caused by removing ambiguity before execution.

The same mechanism applies to business work.

For an email task, the agent can clarify:

• Which recipients are in scope.
• What the messages should achieve.
• How much personalization is required.
• Which information must be included.
• What to do when a contact method is missing.
• Whether partial completion is acceptable.

For bookkeeping or reporting, the agent can clarify:

• The time period.
• The categories to include.
• The required calculations.
• The output structure.
• The tolerance for missing data.
• The conditions that require escalation.

For research, it can clarify:

• The required number and type of sources.
• The scope of the question.
• The reporting format.
• The level of evidence required.
• The conditions under which the research should continue.

Prompt contracts are therefore a general method for turning management intent into machine-executable work.

A mature workflow combines the mechanisms in this lesson:

Step 1: Store durable user-wide preferences in a global instruction file.

Step 2: Store project-specific rules in a local instruction file.

Step 3: Instruct the agent to convert meaningful corrections into concise learned rules.

Step 4: Store repeatable procedures as skills rather than expanding the main instruction file indefinitely.

Step 5: When a non-trivial request is vague, invoke reverse prompting.

Step 6: Convert the answers into a prompt contract containing goal, constraints, output format, and failure conditions.

Step 7: Obtain approval before implementation.

Step 8: Execute the task using the relevant skill and tools.

Step 9: Check the output against the contract.

Step 10: Store any durable correction in the appropriate instruction or memory layer.

This process allows knowledge to accumulate without forcing the user to rewrite the same prompt every time.

Persistent instruction files make preferences and rules available across sessions. Self-modifying instructions convert user feedback into durable operating knowledge. Global and local layers prevent unrelated rules from being mixed. Skills capture repeatable workflows and load detailed procedures only when needed.

Reverse prompting lets the agent identify missing requirements. Prompt contracts turn those requirements into explicit goals, constraints, formats, and failure conditions. Used together, these techniques increase consistency, reduce repeated errors, and improve the probability of a satisfactory first implementation.

The central principle is that prompting should become infrastructure. Good instructions should not disappear after one conversation. They should be stored, organized, invoked, tested, and improved over time.