Steal Prompt Structure Patterns, Not Content
Steal Prompt Structure Patterns, Not Content
When you find a prompt that works well, the instinct is to copy it. But copying the words misses the point. What makes a prompt effective is its structure - how it organizes instructions, what categories of constraints it includes, and how it handles edge cases and failures.
The words are context-specific. The structure transfers everywhere.
Why Content Copying Fails
Prompt content is context-dependent in ways that are not obvious until you try to reuse it.
A system prompt optimized for a code review agent running on GPT-4o will not work the same way on Claude Sonnet. The models have different defaults, different sensitivities to instruction phrasing, and different ways of handling ambiguity. Even the same model behaves differently across versions.
Beyond model differences, prompts encode assumptions about the task. A prompt that produces reliable results for a customer service agent in a fintech company bakes in assumptions about tone, compliance requirements, and user sophistication. Copy it into a developer tools context and the formality is wrong, the restrictions are confusing, and the output quality drops.
But the structural decisions in that prompt - how it defines scope, how it handles ambiguity, how it specifies output format - those transfer. They are solutions to universal prompt design problems.
The Four Structural Components
Every reliable agent system prompt has four structural components, in this order:
1. Identity and scope. What the agent is and what domain it operates in. This sets the model's orientation before any instructions.
You are a code review agent for a TypeScript codebase.
Your job is to review pull requests for correctness,
performance, and security issues.
2. Constraint envelope. What the agent must not do, before what it should do. Starting with constraints prevents the model from establishing defaults that the constraints have to fight against.
You must not:
- Suggest changes outside the files in the pull request
- Make recommendations about code style (handled separately)
- Request information you were not provided
You must:
- Flag any issue that could affect production behavior
- Distinguish blocking issues from suggestions
3. Output format specification. Explicit structure for what the agent produces. Leaving this implicit produces inconsistent results even when the reasoning is correct.
For each file reviewed, output:
1. File path
2. Issues found (blocking | suggestion | note)
3. For each issue: line reference, description, recommended fix
4. Summary: blocking issue count, suggestion count
4. Edge case and failure handling. What to do when the primary approach does not apply. This is the component most people leave out, and it is the one that causes production failures.
If a file has no issues, output: "No issues found."
If you cannot determine whether something is a bug without more context,
say what context you need rather than guessing.
If the diff is too large to review completely, review the first N files
and state that you stopped at that point.
Patterns Worth Stealing
The Constraint-First Pattern
Most prompts list what the agent should do, then add constraints at the end. Reversing this - constraints before capabilities - produces more reliable behavior.
The reason: language models build context as they read. If the model reads 200 words of capabilities and then hits constraints, it has already established a mode of operation that the constraints are correcting. If constraints come first, they shape how the capabilities are interpreted.
# Constraint-first structure
You must not modify files outside /src/components/.
You must not make network requests without explicit user approval.
You must not run commands that delete or overwrite data.
Within these constraints, you may:
- Read any file in the project directory
- Execute read-only commands (ls, cat, grep, git log)
- Propose changes as diffs for user review
The Decomposition Pattern
For tasks with multiple steps, explicit enumerated steps prevent step-skipping and produce more consistent output:
When asked to implement a feature, follow these steps:
1. Read the relevant existing code to understand context
2. Identify all files that will need to change
3. List the changes needed in each file before writing any code
4. Implement changes one file at a time
5. After each file, verify the change is complete and correct
6. Run tests if available
7. Summarize what was changed and why
The key is that this structure is invariant. Whether the feature is a UI component or a database migration, the steps apply. You steal this pattern, not the specific feature names.
The Fallback Chain Pattern
Define explicit fallback behavior for when primary approaches fail:
To find the correct element:
1. First, use the accessibility API to locate by role and label
2. If not found, search by text content within the target container
3. If still not found, take a screenshot and analyze visually
4. If visual analysis is ambiguous, ask the user to point to the element
5. If the user cannot be reached (background mode), log the failure and skip
Each step has a lower precedence than the one before it. The model never has to decide what "try harder" means - it just moves down the list.
The Verification Step Pattern
After any significant action, require an explicit verification:
After making a change:
- State what you changed
- State the expected outcome
- Verify the expected outcome is present
- If verification fails, do not proceed - report the discrepancy
Example: "I added the import on line 3. The file should now compile
without the 'missing module' error. Running tsc... compilation succeeded.
Proceeding."
This pattern catches cases where the action succeeded syntactically but did not achieve the intended effect.
Building Your Own Pattern Library
The most useful prompt pattern library is one you build from your own successes and failures. When a prompt produces unexpectedly good results, reverse-engineer why:
- What ordering did the instructions follow?
- Were constraints listed before capabilities?
- Were output formats specified explicitly?
- What edge cases were handled?
Document the pattern in abstract terms - not "for code review agents" but "for agents that produce structured output on multiple items." The pattern is reusable; the application is specific.
A library of 10-15 structural patterns covers most agent design problems. The prompts you build from them will be better than prompts copied from online collections, because they are designed for transferability rather than for a specific context.
Fazm is an open source macOS AI agent. Open source on GitHub.