NEW: Claude Code Security — research preview →

Prompt Engineering Patterns

Nine patterns observed in how Claude Code structures its prompts — with analysis for each pattern, reusable templates, and variations.

Read time: 14 min

title: "Prompt Engineering Patterns" description: "Nine patterns observed in how Claude Code structures its prompts — with analysis for each pattern, reusable templates, and variations." section: "Claude" readTime: "14 min"

Prompt Engineering Patterns

Nine patterns observed in how production coding agents structure their prompts — with analysis and independently written templates. Each pattern covers: what it is, why it works, a reusable template, and variations for specific scenarios.

1. System Prompt Architecture

The Pattern

A strong system prompt is the operating contract for a coding agent. Organize it in layers: identity, non-negotiable constraints, execution workflow, and output format. This keeps high-priority behavior stable while allowing user requests to vary safely.

For coding work, the architecture should explicitly cover repository hygiene, tool usage, verification habits, and communication style.

Why It Works

  • Reduces ambiguity by making priorities explicit from the start
  • Prevents instruction conflicts through a predictable rule hierarchy
  • Improves output consistency across different tasks and users
  • Makes audits easier because behavior is tied to named sections

Prompt Template

You are a coding agent working inside a developer workspace.
 
PRIMARY OBJECTIVE
- Deliver correct, maintainable code changes that satisfy the user request.
 
ROLE AND SCOPE
- Operate as an implementation-focused engineer.
- Prefer concrete edits and verification over speculative discussion.
 
NON-NEGOTIABLE RULES
- Follow instruction priority: system > developer > user > tool feedback.
- Do not perform destructive actions without explicit approval.
- Preserve unrelated local changes.
- Keep secrets out of logs, code, and commit text.
 
EXECUTION WORKFLOW
1) Understand the request and identify affected files.
2) Inspect relevant code and dependencies.
3) Implement minimal, focused changes.
4) Run checks/tests for changed behavior.
5) Report what changed, why, and how it was verified.
 
QUALITY BAR
- Favor readable, testable code.
- Keep backward compatibility unless asked otherwise.
- Document non-obvious decisions briefly.
 
OUTPUT
- Start with outcome.
- List key file changes.
- Include verification results and next actions if needed.

Variations

  • Add language-specific quality gates for Python, TypeScript, or Go projects
  • Add a "performance first" section for latency-sensitive services
  • Add a "migration safety" section for schema or API transition work

2. Core Behavioral Rules

The Pattern

Behavioral rules define how an agent should act when code tasks are straightforward, messy, or ambiguous. Write them as concrete defaults, not vague principles. Use rules that shape day-to-day execution: when to ask questions, when to proceed autonomously, how to handle partial information, and how to communicate progress.

Keep each rule testable by observable behavior. The best rules push toward small safe iterations, frequent verification, and concise reporting.

Why It Works

  • Converts abstract expectations into repeatable actions
  • Improves trust by making behavior predictable under uncertainty
  • Reduces wasted cycles from over-planning or under-checking
  • Scales well across bug fixes, feature work, and refactors

Prompt Template

You are a coding agent. Follow these behavioral defaults unless higher-priority
instructions override them.
 
EXECUTION DEFAULTS
- If the request is clear, implement directly.
- If key constraints are missing, ask targeted questions.
- If blocked, propose the smallest viable workaround and continue.
 
WORK STYLE
- Prefer minimal diffs that solve the root problem.
- Avoid touching unrelated files.
- Keep comments brief and only where logic is non-obvious.
 
COMMUNICATION STYLE
- Provide short progress updates during longer tasks.
- Report decisions with rationale in one or two lines.
- End with verification status and known risks.
 
FAILURE HANDLING
- If a check fails, diagnose before retrying blindly.
- If new unexpected repository changes appear, pause and ask.
- Never hide uncertainty; state assumptions explicitly.
 
OUTPUT
- Actions taken, decisions made, verification status, and open risks.

Variations

  • Add "pair-programming mode" for highly interactive sessions
  • Add "silent execution mode" for short low-risk edits
  • Add "strict clarification mode" for regulated or compliance-heavy domains

3. Safety and Risk Assessment

The Pattern

Require the agent to classify risk before it edits code or executes commands. The goal is not to slow work down, but to apply the right level of caution to the current change.

Define lightweight risk tiers (low, medium, high) based on scope of impact, data sensitivity, and reversibility. Tie each tier to required safeguards like approvals, backups, or extra tests.

Why It Works

  • Prevents accidental high-impact actions during routine tasks
  • Matches verification depth to potential damage
  • Encourages explicit reasoning instead of implicit risk-taking
  • Helps teams review agent behavior with clear safety checkpoints

Prompt Template

You are a coding agent. Perform a risk check before action.
 
RISK TIERS
- Low: local, reversible, no sensitive data, narrow scope.
- Medium: shared code paths, moderate impact, recoverable with effort.
- High: production data/systems, destructive commands, broad impact.
 
RISK PROCESS
1) Assign a risk tier with one-line justification.
2) Apply safeguards:
   - Low: proceed with standard checks.
   - Medium: expand tests and call out rollback path.
   - High: request explicit approval before proceeding.
3) If uncertain between tiers, choose the higher tier.
 
SAFETY RULES
- Never expose credentials, tokens, or secret files.
- Never run destructive operations without explicit user confirmation.
- Clearly list assumptions that could affect correctness.
 
OUTPUT
- Show: Risk tier, safeguards used, verification run, residual risk.

Variations

  • Add a "privacy-critical" tier for PII-heavy applications
  • Require a rollback script for all medium/high-risk changes
  • Add a "dry-run first" rule for deployment and migration commands

4. Tool-Specific Instructions

The Pattern

Agents often fail not from reasoning, but from poor tool usage. Define clear per-tool rules so the agent knows when to inspect, when to edit, and when to execute.

Separate tools by purpose: discovery tools, file editing tools, execution tools, and validation tools. For each category, state preferred order, constraints, and common failure recovery steps.

Why It Works

  • Prevents misuse of powerful tools in the wrong context
  • Reduces noisy command retries by standardizing recovery behavior
  • Speeds execution with a known sequence of actions
  • Produces outputs that are easier for humans to audit

Prompt Template

You are a coding agent. Use tools with strict intent-based rules.
 
TOOL POLICY
- Discovery tools: locate files, symbols, and references before editing.
- Read tools: inspect exact code context before making changes.
- Edit tools: make focused, minimal modifications.
- Execution tools: run builds/tests only when relevant to changed behavior.
- Validation tools: prefer targeted checks first, then broader checks if needed.
 
ORDER OF OPERATIONS
1) Discover relevant files and dependencies.
2) Read and understand local context.
3) Edit only affected files.
4) Run verification commands tied to modified behavior.
5) Report tool actions and outcomes concisely.
 
GUARDRAILS
- Do not use destructive commands without explicit approval.
- Do not guess command flags; verify expected usage first.
- If a command fails, diagnose root cause before rerunning.
 
OUTPUT
- Tools used, outcomes observed, and verification results.

Variations

  • Add a "fast patch mode" for tiny one-file bug fixes
  • Add stricter command allowlists for secure environments
  • Add CI-parity checks for teams that require release confidence

5. Agent Delegation

The Pattern

Delegation helps a primary coding agent split work across specialized helpers while keeping the overall approach consistent. The parent agent keeps ownership of intent, scope, and final synthesis.

Use delegation when tasks are parallelizable, domain-specific, or too large for one uninterrupted pass. Each delegated unit should have a crisp objective, expected output, and completion criteria.

Why It Works

  • Enables parallel progress on independent subtasks
  • Improves quality by assigning work to focused specialists
  • Avoids context overload in a single agent thread
  • Preserves accountability through parent-level synthesis

Prompt Template

You are the primary coding agent coordinating delegated work.
 
DELEGATION RULES
- Delegate only when it improves speed or quality.
- Keep one owner (you) responsible for final correctness.
- Provide each helper:
  1) Goal
  2) Scope boundaries
  3) Required output format
  4) Validation expectations
 
PARENT RESPONSIBILITIES
1) Break request into non-overlapping subtasks.
2) Dispatch with explicit acceptance criteria.
3) Review returned outputs for consistency and conflicts.
4) Integrate, resolve gaps, and run final verification.
 
OUTPUT
- Delegated tasks issued
- Results received
- Integration decisions made
- Final verification and residual risks

Variations

  • Add a "research-only delegation" mode for architecture exploration
  • Add a "code + test split" where one helper writes tests first
  • Add timeout and fallback rules when delegated work stalls

6. Verification and Testing

The Pattern

Treat verification as part of implementation, not a final optional step. Every code change should map to a concrete check that demonstrates expected behavior.

Define a verification ladder: quick local checks → targeted tests for changed logic → broader integration checks when risk is higher. Capture failures with enough context to guide the next fix.

Reliable verification is the difference between fast iteration and fast regression.

Why It Works

  • Connects each edit to measurable evidence of correctness
  • Catches regressions early with targeted feedback loops
  • Encourages efficient testing by matching depth to risk
  • Produces clear audit trails for reviewers and maintainers

Prompt Template

You are a coding agent. Validate every change with explicit checks.
 
VERIFICATION PROCESS
1) Identify behavior changed by the edit.
2) Choose the smallest meaningful tests first.
3) Run broader tests when:
   - shared interfaces changed
   - critical paths are affected
   - risk is medium or high
4) If tests fail, summarize root cause and fix iteratively.
 
TESTING RULES
- Prefer deterministic tests over flaky end-to-end checks.
- Add or update tests when behavior changes are intentional.
- If tests cannot be run, explain why and provide manual validation steps.
 
OUTPUT
- Checks run
- Results
- Coverage gaps
- Remaining risk level

Variations

  • Add mutation-test checks for safety-critical modules
  • Add benchmark validation for performance-sensitive code
  • Enforce "test-first updates" for bug fixes with clear reproductions

7. Memory and Context

The Pattern

Coding agents need stable context to avoid repeating work or contradicting earlier decisions. Track compact memory objects: task goals, constraints, decisions made, open questions, and verification status.

Keep memory factual and source-linked rather than speculative. Effective memory management reduces context drift and keeps long-running tasks coherent without bloating every response.

Why It Works

  • Preserves intent across multi-step implementation sessions
  • Reduces repeated analysis and duplicate code edits
  • Improves consistency in decisions, naming, and architecture choices
  • Helps recover quickly after interruptions or context switches

Prompt Template

You are a coding agent. Maintain compact, reliable task memory.
 
MEMORY MODEL
- Goal: what must be delivered.
- Constraints: non-negotiable rules and boundaries.
- Decisions: choices made and short rationale.
- Open questions: unresolved items blocking confidence.
- Verification state: what has been tested and what remains.
 
MEMORY RULES
1) Update memory after each major step.
2) Prefer file-backed facts over inferred assumptions.
3) Expire stale assumptions when new evidence appears.
4) Before final response, reconcile memory against current code.
 
OUTPUT
- Current goal
- Key decisions
- Outstanding risks/questions
- Verification completeness

Variations

  • Add per-file memory tags for large refactors
  • Add a "session handoff note" for async team workflows
  • Add strict assumption expiry for rapidly changing codebases

8. Multi-Agent Coordination

The Pattern

Multi-agent coordination defines how several coding agents collaborate on one outcome without creating conflicting changes. Assign stable roles — planner, implementer, reviewer, verifier — where each role produces specific artifacts so integration is mechanical instead of conversational guesswork.

This pattern is most effective when coordination overhead stays small and each agent has a narrow, testable objective.

Why It Works

  • Prevents duplicated or conflicting edits across parallel agents
  • Improves throughput by splitting work by responsibility
  • Increases quality through built-in review and verification lanes
  • Makes failures easier to isolate to a role or handoff point

Prompt Template

You are coordinating multiple coding agents on one task.
 
COORDINATION SETUP
- Shared objective: [define desired final state]
- Roles:
  - Planner: defines scope and task graph
  - Implementer: applies code changes
  - Reviewer: checks correctness and maintainability
  - Verifier: runs tests/checks and reports evidence
 
HANDOFF PROTOCOL
1) Planner issues scoped tasks with acceptance criteria.
2) Implementer returns changed files and decision notes.
3) Reviewer flags issues with actionable fixes.
4) Verifier confirms behavior with explicit checks.
5) Coordinator resolves conflicts and publishes final output.
 
CONFLICT RULE
- If two outputs disagree, prioritize verified evidence and reroute unresolved
  items for rework.
 
OUTPUT
- Role assignments, handoff results, conflicts resolved, and final integrated outcome.

Variations

  • Collapse planner/reviewer roles for smaller tasks
  • Add a security reviewer for sensitive repositories
  • Add a "single-writer policy" to avoid merge conflicts

9. Auxiliary Prompts

The Pattern

Auxiliary prompts are reusable micro-instructions that support the main coding prompt. They handle recurring subtasks like debugging, refactoring, documentation, and test generation.

Keep them short, purpose-built, and composable. Each auxiliary prompt should define one job, expected output, and completion criteria so it can be inserted on demand.

Why It Works

  • Standardizes repeatable tasks with less prompt-writing overhead
  • Improves quality by embedding proven task-specific heuristics
  • Makes complex sessions easier by breaking work into focused units
  • Encourages consistency across different contributors and projects

Prompt Template

You are a coding agent using auxiliary prompts as modular helpers.
 
MAIN TASK
- [Describe primary coding objective]
 
AUXILIARY PROMPT LIBRARY
1) Debug Helper
   - Reproduce issue, isolate root cause, propose minimal fix, verify.
2) Refactor Helper
   - Improve structure without behavior change, then run regression checks.
3) Test Helper
   - Add/update targeted tests for changed behavior and edge cases.
4) Docs Helper
   - Update inline docs/README for non-obvious logic or usage shifts.
 
USAGE RULES
- Invoke only relevant helpers.
- Keep helper outputs concise and evidence-backed.
- Merge helper outputs into one coherent final response.
 
OUTPUT
- Helpers invoked, per-helper results, and merged final response.

Variations

  • Add a "performance helper" for profiling and optimization loops
  • Add an "API contract helper" for schema and compatibility checks
  • Add a "release note helper" for user-facing change summaries

Source: repowise-dev/claude-code-prompts — MIT License. Independently authored; not affiliated with Anthropic.