Prompt Patterns

A collection of prompt patterns that consistently produce better results with AI coding agents. Each pattern is documented with real examples from building krowdev and parallel research pipelines.

Foundations: see Getting Started with Agentic Coding. For day-zero project setup, see Setting Up Claude Code. For project rules that prompts can reference, see CLAUDE.md Patterns.

The Research-First Pattern

Before asking an agent to build something, have it research the codebase first.

The pattern:

Read through src/components/ and src/lib/ to understand the
existing patterns. Then propose an approach for adding [feature]
that is consistent with the current codebase style.

Why it works: Agents make better decisions when they understand existing conventions. Without this step, they default to generic patterns that clash with your codebase.

Real example — WebTerminal refactor:

The entire codebase research methodology is research-first at scale. Before rewriting the input model, the agent analyzed 11 reference implementations:

Read the source code in reference-sources/xterm.js/.
Answer these questions with specific file paths and line numbers:
1. Where does the prompt live? (inline in buffer vs separate element)
2. How is user input captured? (raw key events, textarea, contenteditable?)
3. When can the user type? (only after prompt? during output? always?)
Write findings to analysis/xterm-js.md.

This produced findings like “all real terminals use a hidden <textarea> for input capture” — a concrete architecture decision that would have taken days to reach by reading source code manually.

When it fails: On small, well-understood tasks. If you ask an agent to rename a variable, the research step just wastes time. Use it for architecture decisions, not mechanical changes.

The Constraint Pattern

Explicitly state what the agent should not do.

The pattern:

Add input validation to the signup form.
- Do NOT add any new dependencies
- Do NOT refactor existing code
- Do NOT change the component API
- Only modify src/components/SignupForm.tsx

Why it works: Agents tend to over-engineer. Without constraints, they’ll add error handling for impossible cases, create helper utilities for one-time operations, and “improve” code you didn’t ask about. Constraints keep the scope tight.

Real example — krowdev reader mode:

When building the CSS reader toggle, the prompt constrained the scope explicitly:

Add a reader-mode toggle (human/agent/all) to the header.
- Use the SAME segmented-control pattern as the origin filter
- Do NOT add any JavaScript framework — Svelte only
- Do NOT change the origin filter behavior
- CSS data-attribute toggling only, no JS class manipulation
- Must work without JS (progressive enhancement)

Without the constraint “use the SAME pattern as origin filter,” the agent would have invented a new toggle pattern. With it, the reader toggle was visually and architecturally consistent from the first try.

When it fails: When you over-constrain. Listing 15 constraints turns the prompt into a specification, and the agent spends more effort satisfying constraints than solving the problem. Three to five constraints is the sweet spot.

The Rubber Duck Pattern

Ask the agent to explain your own code back to you before modifying it.

The pattern:

Explain what src/lib/auth.ts does, step by step.
Then identify the bug that causes session tokens to expire early.

Why it works: Forces the agent to build a mental model before acting. If the explanation is wrong, you catch the misunderstanding before it becomes a broken commit.

Real example — krowdev content collections:

Before restructuring from separate blog/wiki/research collections into a unified kb collection, the agent was asked to explain the existing system first:

Read src/content.config.ts and explain:
1. What collections exist and what schema each uses
2. How entries are routed to URLs (which pages reference which collections)
3. What would break if I merged blog and wiki into one collection

The agent’s explanation revealed that the research collection had a separate loader pattern (glob with custom ID generation) that would need special handling — something that wasn’t obvious from just reading the schema. This saved a migration that would have broken research URLs.

When it fails: When the code is too simple to need explanation. Don’t ask an agent to explain a 5-line utility function. Use this for code you don’t fully understand yet, or code with non-obvious interactions.

The Incremental Delivery Pattern

Break large tasks into checkpoint steps where you review before continuing.

The pattern:

We're going to add reader mode in phases. Start with Phase 1 only:

Phase 1: Add .md endpoints for each KB entry (static markdown files).
Phase 2: Add CSS reader toggle to the header.
Phase 3: Add JSON-LD structured data.

Do Phase 1 now. I'll review before we continue.

Why it works: Agents that build everything at once produce harder-to-review output. By breaking into phases, you catch problems before they compound. Each phase builds on reviewed, working code.

Real example — krowdev reader mode was built in exactly this pattern. Phase 1 (.md endpoints) was reviewed and tested before Phase 2 (CSS toggle) was started. Phase 2 introduced the data-reader-mode attribute pattern. Phase 3 (JSON-LD) built on the attribute pattern to conditionally render structured data. If Phase 1 had been wrong, Phase 2 and 3 would have amplified the mistake.

When it fails: When the phases are too small. “Phase 1: create the file. Phase 2: add the first function. Phase 3: add the second function” is micromanagement, not incremental delivery. Each phase should produce a reviewable, testable artifact.

The Before/After Pattern

Show the agent what you have and what you want, with concrete examples.

The pattern:

Current behavior:
  Terminal grows taller when output is added.
  Prompt is a fixed div pinned at the bottom.

Desired behavior:
  Terminal has fixed dimensions (like a real terminal window).
  Prompt is inline text in the buffer, not a separate element.
  Output scrolls within the fixed viewport.

Change terminal-input.js to match the desired behavior.

Why it works: “Fix the terminal” is vague. “Current X, desired Y” is unambiguous. The agent knows exactly what success looks like and can validate its own output against the stated goal.

When it fails: When the before/after is too abstract. “Current: bad. Desired: good.” isn’t a before/after — it’s a wish. Include observable behaviors, not adjectives.

Sources

• Anthropic, Claude Code: Prompt engineering
• Anthropic, Claude Code best practices
• OpenAI, Codex prompting