If you use AI assistance for coding or writing, you’ve probably done this dance:
- Paste a question.
- Get a decent answer… but it’s missing your conventions.
- Paste more context.
- Repeat until the model finally “gets” your project.
It works, but it’s slow, expensive (token-wise), and fragile. The next day, you start from scratch.
A better pattern is to treat context like an asset.
I call it a Context Pack: a small, reusable document (or folder) that describes your project in a way an assistant can use immediately—without you re-typing the same explanations every time.
This post shows:
- what a context pack is
- how to structure one
- how to prompt with “deltas” instead of re-pasting everything
- a lightweight workflow you can adopt in an afternoon
What a “context pack” is (and isn’t)
A context pack is not your entire repo dumped into the prompt.
It’s a curated, human-readable summary of the pieces that matter for the kinds of help you want:
- architecture and boundaries
- naming conventions
- constraints (“no new dependencies”, “Postgres only”, “must be accessible”)
- examples of “good output”
- the current state of the work (what’s already tried, what failed)
Think of it as the README you wish every tool would read.
Why context packs beat “paste and pray”
When prompts fail, it’s usually because one of these is missing:
- Goal clarity: what “done” looks like
- Constraints: what is not allowed
- Local conventions: your style, tools, and patterns
- Examples: the shape of output you want
- State: what exists already (files, functions, decisions)
A context pack turns those into a single artifact you can reuse.
Benefits:
- Speed: fewer back-and-forth messages
- Consistency: outputs match your codebase and tone
- Lower token cost: you paste a short pack + a small delta
- Less drift: the assistant stops “inventing” frameworks you don’t use
The simplest structure that works
Start with a single file: context-pack.md.
Here’s a template you can copy.
1) Project brief (10–15 lines)
Explain what the project is, who it’s for, and what matters.
# Project: Acme Billing
Acme Billing is a Node.js + Postgres service for managing invoices.
Primary users are internal finance staff.
We prioritize correctness, auditability, and clear error messages.
We deploy to Docker on AWS ECS.
2) Stack + constraints (the “do and don’t” list)
This is the most important section.
## Stack
- Node.js 22, TypeScript
- Postgres 15
- API: REST (Express)
- Testing: Vitest
## Constraints
- No new runtime dependencies without approval
- Prefer SQL migrations over ORM magic
- All endpoints require request validation
- Keep functions under ~40 lines unless there’s a strong reason
3) Conventions (how you like things done)
This is where you encode style and patterns.
## Conventions
- File naming: kebab-case
- Services live in src/services/*
- Routes live in src/routes/*
- Errors: throw AppError(code, message, meta)
- Logging: use logger.info({requestId, ...})
4) Glossary (your domain vocabulary)
A short glossary prevents subtle mistakes.
## Glossary
- "Invoice": finalized bill sent to customer
- "Draft": editable invoice not yet sent
- "Line item": row on an invoice
- "Void": invoice exists but is canceled (kept for audit)
5) Examples of “good output”
Give the assistant a target shape.
## Example: preferred API response
{
"data": {"id": "inv_123", "status": "draft"},
"error": null
}
## Example: preferred error
{
"data": null,
"error": {"code": "VALIDATION_ERROR", "message": "currency is required"}
}
6) Current work (optional, but powerful)
A tiny “where we are” section prevents repeated suggestions.
## Current work
- Implementing /invoices/:id/send
- Already added migrations for sent_at
- Need help designing idempotency
That’s it. One file.
Later, you can split it into a folder (more on that below).
Prompting with deltas (the trick that saves time)
Once you have a context pack, stop re-explaining. Instead:
- paste the context pack once (or attach it)
- then send only what changed: the delta
Here’s a prompt pattern I use constantly.
You are helping on the project described below.
[PASTE CONTEXT PACK]
Task:
- Implement idempotent invoice sending.
Delta / current state:
- We already store sent_at (nullable timestamp).
- There is a unique index on invoices(id).
- Race condition: two requests can send twice.
Constraints:
- No new dependencies.
Output:
- Propose a DB-safe approach.
- Provide the TypeScript code changes (files + functions).
- Include 2 Vitest tests.
Why this works:
- The pack provides stable background.
- The delta tells the assistant what’s new.
- The output format reduces ambiguity.
Upgrading to a “context pack folder”
For bigger projects, a single file gets crowded. The next step is a folder like:
/ai-context/
00-brief.md
10-architecture.md
20-conventions.md
30-glossary.md
40-examples.md
50-open-questions.md
Then your prompt can say:
- “Use the attached
ai-contextdocs.” - “Focus on 20-conventions and 40-examples.”
This keeps the pack maintainable and lets you update sections independently.
A tiny maintenance habit that keeps it useful
Context packs die when they’re stale.
The smallest habit that keeps them alive:
- After you accept an assistant’s output, ask: “Should anything be added to the context pack?”
- If the answer is “yes”, add 1–3 lines.
Examples of good additions:
- a new constraint (“we can’t upgrade Postgres yet”)
- a new convention (“we use zod for request validation”)
- a decision (“we chose outbox pattern for events”)
Two guardrails to prevent bad outputs
Guardrail 1: Add a “refusal” clause
Tell the assistant what to do when the pack is missing information.
## Guardrail
If a required detail is missing, ask a clarifying question before assuming.
Guardrail 2: Require citations to files
In coding tasks, demand file paths and function names.
When you propose changes, always reference concrete files and functions.
If you invent a file that doesn’t exist, call it out as a suggestion.
This simple requirement reduces hallucinated architectures dramatically.
The payoff
A context pack turns AI assistance from “chatting” into a repeatable workflow.
You’ll spend less time re-pasting background, and more time shipping.
If you build one this week, start small:
- one file
- one brief
- one constraint list
- one example
Then iterate.
That’s the whole game.
Top comments (0)