How to Build a Claude Context Stack for Your Next Feature

This is an activity edition:

Activity: We’ll walk through creating a context/ folder (project.md, tech.md, flows.md, examples.md) to guide Claude in generating an actual feature.

Outcome: A reusable system prompt setup for any greenfield task.

Reply to this email with the word SHOWME and I’ll send you access to the code repo.

Alternately, follow along below to build it yourself.

When you’re building with an LLM, the quality of your output is only as good as the clarity of your input. The trick? Don’t just write prompts. Engineer your context.

In this issue, we’ll walk through how to set up a Claude context stack: a small, modular set of .md files that you can reuse across features to build faster, with better control and far less friction.

What’s a Claude Context Stack?

A Claude Context Stack is a small folder (usually named context/) that contains everything the LLM needs to understand your:

Product goals
Tech stack and libraries
Naming conventions
Output formatting
Security or performance constraints
Examples of what good looks like

It’s not code. It’s code for your prompts.

Think of it like an internal design system or coding style guide but for how Claude should think.

Recommended Structure

Here’s a simple context stack that works well for most web apps and internal tools:

context/
├── project.md        # What we’re building and why
├── tech.md           # Stack, packages, folders, linting
├── flows.md          # Key user journeys or app logic
├── components.md     # UX, UI and naming rules
├── examples.md       # Ideal completions (few-shot)

Each file is small, being around typically 100–300 words. Together, they give Claude the system-level awareness that a senior engineer would build up over weeks.

A Closer Look at Each File

Here’s how to populate each file and what Claude does with it.

`project.md`

What’s the goal? Why are we building this? Who is it for?

## Project Name  
Client Onboarding Portal  

## Objective  
Build a portal where new B2B clients can submit onboarding information, upload documents, and track their approval status.

## Scope  
Frontend UI + backend endpoints. Must be usable on desktop and mobile.

Claude uses this to keep scope tight and align output to user intent.

`tech.md`

What stack are we using and how should the code be structured?

## Frontend  
- Next.js 14 (App Router)  
- TailwindCSS  
- shadcn/ui  

## Backend  
- Next.js API routes  
- PostgreSQL (via Prisma)  
- Clerk for auth  

## Output Requirements  
- Use British English spelling  
- Format code with Prettier  
- ESLint config is standard Airbnb

Claude uses this to avoid irrelevant boilerplate and guesswork.

`flows.md`

What are the key interactions or use cases we’re building for?

## Flow: New Client Onboarding  

1. User signs in with magic link (Clerk)  
2. User completes company profile  
3. Uploads identity documents (PDF, JPG)  
4. Backend sends profile for internal review  
5. User sees “pending” or “approved” status in dashboard

Claude uses this to maintain logic coherence and link endpoints to real journeys.

`components.md`

What UI elements or naming patterns should we reuse?

## Components  

- `FormCard`: used for form steps in onboarding  
- `StatusPill`: shows current review state  
- `DocumentUploader`: drag-and-drop file input with preview  

## Naming Conventions  
- Use PascalCase for React components  
- Prefix client-only components with `Client`

Claude uses this to stay consistent in UI output and file organisation.

`examples.md`

Show Claude what good output looks like, few-shot style.

### Prompt  
Create a POST endpoint that receives form data and writes it to a PostgreSQL database using Prisma.

### Completion  
```ts
import { prisma } from '@/lib/db';

export async function POST(req: Request) {
  const body = await req.json();
  const client = await prisma.client.create({ data: body });
  return Response.json(client);
}

Claude uses this to mirror structure, tone, and level of detail in future completions.

Why It Works

Claude Code isn’t just a text generator. It’s a context-anchored reasoning engine. The more structured and reusable your inputs are, the more consistent and useful your outputs will be.

A good context stack helps you:

Avoid repeating yourself
Stop rewriting the same prompt 50 times
Reduce hallucinations
Improve review quality (context is in version control!)
Make your workflows sharable and scalable

Try This: Your First Claude Context Stack

Pick a feature you’ve been meaning to build. Create a context/ folder and add these, using the design patterns set out above:

project.md
tech.md
flows.md

Then, write a single prompt:

"Generate the React component for the onboarding form, using the patterns and stack defined in context."

Watch what Claude does with it.