Advanced: Chaining Prompts to Build Complex Software Features

Single prompts handle single tasks. Real features span design, data, API, UI, tests, and review — and no single prompt produces a coherent result across all of them. The skill is chaining: a sequence of prompts where each one builds on the last, and the AI carries forward a shared mental model of the feature.

1. Introduction

You have spent this section building prompt patterns for one piece of the puzzle at a time — debugging, testing, refactoring, generating endpoints, writing docs. This final tutorial puts them together into a deliberate sequence. Once you can chain prompts, you can deliver entire features end-to-end with the AI as a fast pair-programmer at every stage.

We'll walk through one complete feature: "customers can save items to a wishlist". Six chained prompts, each building on the previous.

2. The Concept Explained

A chained prompt sequence works because LLMs maintain context across turns. The first prompt fixes the design; the second prompt builds against it; the third extends it; and so on. Each later prompt references "the schema you proposed in step 2" or "the endpoint shape you wrote in step 3" without re-explaining it. That shared state is the entire reason this works.

Six prompts in sequence. The arrow back from Review to Design is the loop most teams forget — it is where lasting quality comes from.

Think of yourself as a tech lead and the AI as the rest of the team — designer, backend engineer, frontend engineer, QA. You break the feature into stages, hand each stage off, integrate, and review. The chain is not magic; it is just delegation.

3. The Problem Without This Technique

Without a deliberate chain, the AI tries to deliver the whole feature in one turn — and produces an unreviewable wall of files with subtle inconsistencies between them.

Weak prompt

build a wishlist feature for my e-commerce app

The AI invents a schema, sketches an API, writes a UI, and writes a few tests — but the React component refers to a route that doesn't quite match the Express handler, and the schema doesn't have an index where you need one. Each piece looks fine alone; together they don't compose.

4. The Solution

A six-prompt chain (one feature, one chat)

--- PROMPT 1: DESIGN ---
Feature: customers can save products to a wishlist and view the saved
list on a /wishlist page. Auth required. Wishlist is per-user.

Stack: Node.js 20 + Express + Prisma + PostgreSQL backend; React 18 +
TypeScript + Tailwind frontend; React Query v5 for data.

Write the design doc in 200 words: user story, in/out of scope, the
2–3 key decisions you would flag for me before building (e.g. soft
delete vs hard delete, public/shared wishlists yes/no).

--- PROMPT 2: SCHEMA ---
Decisions confirmed: in scope are add, remove, list. Out of scope:
sharing and notifications. Hard delete is fine for v1.

Produce the Prisma schema additions and a Prisma migration file for:
- A `WishlistItem` table: (id uuid PK, userId uuid FK -> users.id,
  productId uuid FK -> products.id, createdAt timestamptz default now())
- Unique constraint on (userId, productId) so the same product can't be
  added twice.
- Index on userId for fast list queries.

Include any necessary changes to the User model (relation) but not the
Product model.

--- PROMPT 3: API ---
Now build the Express routes (TypeScript) for:
- POST /api/wishlist { productId } → 201 with the item, 409 if already present
- DELETE /api/wishlist/:productId → 204 on success, 404 if not present
- GET /api/wishlist?page=1&perPage=20 → 200 with paginated items, newest first

Auth: assume requireUser middleware injects req.user.id.
Validation: zod. Error shape we use across the app:
  { error: { code, message } }

Use the Prisma schema you proposed in the previous step. Return only the
route file and the zod schemas.

--- PROMPT 4: UI ---
Now build the React component for the /wishlist page using React Query v5.
- WishlistPage component lists items with image, name, price, "Remove" button
- AddToWishlistButton component for use on product cards (heart icon, toggles
  between filled and outlined based on whether the product is in the
  wishlist; uses the GET /api/wishlist endpoint to check)
- Optimistic updates on add and remove
- Loading and empty states
- Tailwind for styling, matches the existing design tokens used elsewhere

Use the exact API shape you defined in the previous step.

--- PROMPT 5: TESTS ---
Produce:
- Jest + supertest API tests for all three endpoints (happy path, 401,
  duplicate add, remove non-existent, pagination)
- React Testing Library tests for the AddToWishlistButton (toggle behaviour,
  optimistic update rollback on failure)

Don't include integration tests — that's a separate task.

--- PROMPT 6: REVIEW ---
Review the entire feature you've produced in this chat as if you were a
senior code reviewer. Output:
- One short summary paragraph
- A bullet list of any inconsistencies between the schema, API, and UI
- Anything that should be a separate PR
- The 3 most likely issues to surface in production once this ships

Six prompts, one chat, one coherent feature. The AI is referencing its own earlier outputs at every step — that is what makes the parts fit together.

5. Step-by-Step Breakdown

Open with a design prompt. Force the AI to write the user story, the scope, and the open questions before any code. This is the constitution for the rest of the chain.
Pin down the data model next. Schema decisions cascade into everything. Get them right (and tracked) before APIs are written.
API after schema, UI after API. The dependency direction matters. Each stage builds against a frozen previous stage.
Generate tests as part of the chain, not after. When you ask for tests within the same chat, the AI has the implementation context and writes specific tests, not generic ones.
End with a self-review prompt. Ask the AI to review the whole feature it just produced. Honest self-review surfaces inconsistencies cheaply.
Loop on findings. Review surfaces gaps. Feed them back into the appropriate stage prompt rather than patching downstream. This is the difference between a good chain and a great one.

Tip: For multi-day features, save the chain transcript as a markdown file in your repo (with sensitive bits redacted). It becomes both documentation and a template for the next person who builds something similar.

6. Practice Exercises

Exercise 1

Take a real feature on your team's roadmap. Decompose it into a six-prompt chain before writing any code. Compare the chain you wrote to how you would have approached it without AI. Has decomposing it into prompts already clarified the design?

Exercise 2

Run the wishlist example above against your favourite AI tool end-to-end. Note where the chain broke down (if at all) and what additional context you had to supply mid-chain. Those gaps are how you make the chain template better next time.

Exercise 3

Build a reusable "feature chain template" file in your prompt library — a markdown document with the six stages and the questions to answer at each. Use it for every non-trivial feature for the next month. Refine as you learn.

7. Key Takeaways

Real features need chained prompts, not single prompts. The chain is the unit of work, not the prompt.
Design first, schema second, API third, UI fourth. Tests and review wrap around the chain.
Keep the chain in one chat. Shared context is the only reason this works at all.
End every chain with a self-review prompt. It's the cheapest way to catch cross-stage inconsistencies.
Save successful chains as templates. A well-thought-out six-prompt chain is a transferable methodology.

Discussion

How to Use AI for DevOps: Docker, CI/CD, Shell Scripts