The Prompt Chain Pattern: Planning, Building, Debugging, and Shipping

The prompt chain pattern splits a coding session into four explicit phases: plan, build, debug and ship. Each phase demands a different prompt style, different success criteria, and a different relationship with the model. When you treat all four the same way — firing the same kind of vague instruction at every stage — you waste tokens, lose momentum, and end up rewriting more than you ship.

What is a prompt chain?

A prompt chain is a sequence of prompts where each message shifts intent deliberately for its phase. Instead of one monolithic “build my app” instruction that tries to do everything at once, you break the session into stages and adapt your language for each.

The boundaries are not rigid — you may loop back to build after debug, or revisit plan when you discover a constraint mid-way — but naming the phase before you type keeps you intentional. Most wasted sessions happen because the developer writes a build prompt when they should be planning, or a plan prompt when something is broken and they need to debug.

Phase 1: Plan — prompt to think, not to build

The planning phase is where most developers rush. They open a chat and type “build me a dashboard” when they have not defined what success looks like, what data sources they need, or even what stack they plan to use. Planning prompts are cheap — a few hundred tokens — and they save you from building the wrong thing.

I want to build a personal dashboard that shows my GitHub commit streak,
the weather for my city, and a daily quote. I have not built a full-stack
app before.

Please help me scope this:
- What stack would suit a beginner with basic Python?
- What are the core components and external data sources?
- What is the smallest version I could build in one evening?

Ask any clarifying questions before we start coding.

A good planning prompt invites the model to push back. It should surface assumptions you did not know you were making — API rate limits, hosting requirements, authentication needs — before you commit to an implementation. The goal is not code; it is a shared understanding of what you are about to build.

The rubber duck debugging principle applies here: explaining the problem out loud (or in a prompt) forces you to clarify your own thinking. The model acts as the duck, except it talks back with suggestions you might not have considered.

Phase 2: Build — prompt with constraints, not wishes

Once the plan is clear, switch to outcome-oriented build prompts. This is where the patterns from The AI Coding Prompt Playbook apply most directly — specify the stack, the behavioural spec, the output structure and the edge cases before you ask for code.

Build a Flask app with a single /dashboard route that displays:

- A GitHub streak counter using the public events API
- A weather widget via open-meteo.com (no API key)
- A daily quote read from a local quotes.json file

Constraints:
- One HTML page with embedded CSS, mobile-responsive
- Graceful error handling if any external API is unreachable
- Export as app.py in the project root, with dependencies in requirements.txt
- No JavaScript framework — vanilla HTML and CSS only
- Use requests for HTTP calls, not urllib

Give me the complete app.py and requirements.txt. Pause after so I can review.

This prompt names the stack (Flask + requests), the data sources (GitHub Events API, open-meteo, local JSON), the constraints (inline CSS, no JS framework, mobile-responsive), and the output structure (app.py, requirements.txt). The model can produce a working first draft without asking for clarification.

Build prompts should be specific about what you want but silent on how to implement it internally. If you find yourself writing out loop structures or dictating function signatures, you have crossed from specification into micromanagement. Let the model choose the implementation; you govern the contract.

Phase 3: Debug — prompt with evidence, not questions

Debugging is where the prompt chain differs most from a naive approach. The typical debug prompt — “it is not working” — forces the model to guess the problem, the environment, the error message, and the expected behaviour. An evidence-led debug prompt hands all of that over in one message.

My Flask dashboard app runs locally, but the weather API call returns a 500
error when I visit /dashboard.

The relevant code in app.py calls requests.get() on open-meteo.com.
The full terminal traceback is:

  requests.exceptions.ConnectionError:
  Failed to resolve 'api.open-meteo.com'

What is the most likely cause given that my browser loads other websites?
Suggest the specific fix — do not just explain the concept.

The model now has the symptom (500 error), the code (the function making the call), the exact error (DNS resolution failure), and a clue (browser works, requests does not). It can diagnose a local DNS or proxy configuration issue, or a missing dependency like requests itself, without asking for more details.

The key habit to build: before you paste a debug prompt, collect the evidence. Copy the error message, the relevant code block, the inputs that triggered it, and the behaviour you expected. Paste them together. The five seconds it takes to gather that context saves five minutes of back-and-forth.

Phase 4: Ship — prompt to finish, not to expand

The shipping phase is about restraint. The most common mistake here is asking for “just one more feature” and never deploying. Ship prompts are narrow, conservative, and focused on the finish line rather than the roadmap.

Review this Flask app for a production deploy on Railway.app.

Check for:
- Missing error handling on external API calls
- Hard-coded values that should be environment variables
- print() calls that should use logging instead
- Missing entries in requirements.txt or a missing Procfile
- Any absolute file paths that will break on the deployment platform

Do not add new features. Do not refactor the layout. Only surface what would
break or look unprofessional in a deployed app.

Shipping prompts explicitly forbid expansion. This is harder than it sounds — every review reveals something you want to improve. The discipline of the ship phase is knowing that a working 90% app is worth more than a perfect app that never deploys. As Agentic Coding Pro discusses, knowing when to stop prompting is as important as knowing what to prompt for.

Why the chain works

The prompt chain works for two reasons.

First, it maps each phase to a different cognitive mode:

• Planning favours divergent thinking — exploring options, asking questions, surfacing unknowns.
• Building favours convergent thinking — executing a spec, making decisions, producing output.
• Debugging favours analytical thinking — comparing expected versus actual behaviour, isolating variables.
• Shipping favours compliance thinking — checking against a standard, resisting scope creep.

When you use the same prompt style for all four, you force the model into one mode and get poor results for the other three. A build-style prompt (concrete, imperative) works poorly for planning because it commits to decisions too early. A plan-style prompt (exploratory, open-ended) works poorly for shipping because it invites feature creep.

Second, the chain optimises your token budget. A planning prompt runs a few hundred tokens. A debugging prompt with error output and code context may run 800. By keeping phases separate, you never waste tokens asking the model to context-switch — every message is fully focused on its phase.

When the chain breaks

The prompt chain is not a silver bullet. It fails in predictable ways:

• Skipping the plan phase. You discover mid-build that your stack choice cannot handle the data source you need. The resulting rewrite costs more than planning would have.
• Mixing build and debug in the same message. You ask the model to fix a bug and add a feature at the same time. It fixes neither well, and you cannot tell which change introduced new problems.
• Staying in build mode forever. You never write a ship prompt. The project accumulates polished features and never deploys. A graveyard of 90% finished projects is the signature of a developer who never enters the final phase.

The fix is not rigid process. It is awareness. When a session starts to feel unproductive, ask yourself: which phase am I actually in? If the answer does not match the prompt you just wrote, switch.

Put the chain into practice

Next session, try this. Before you type anything, decide which phase you are in. Write a prompt that matches that phase. If you catch yourself writing a build prompt when something is broken, stop and switch to debug mode.

The chain pattern does not make every session perfect. It makes every session intentional. And intentional sessions ship more than reactive ones.