Prompt Engineering

Create a Project Glossary for AI

Your domain words mean specific things. A project glossary teaches AI the difference between a basket and a cart, an SKU and a product — so it stops using them loosely.

Open in Project Context Builder

Overview

Every codebase has words that mean something exact: in Harvest Market, a grocery storefront, a reservation is stock held for an in-progress checkout, not a delivery slot, and a basket is the customer-facing name for a cart. When AI doesn't know these, it produces confident, wrong output. This setup builds a profile whose glossary pins down SKU, fulfillment, reservation, and basket — each term carried verbatim, abbreviations flagged, and any term you leave undefined marked rather than guessed. The AI speaks your domain instead of approximating it.

How to use this resource

List the terms AI misuses

One Term: definition per line; abbreviations are detected automatically.
Leave nothing to a guess

Terms without a definition are flagged, never invented.
Embed it in the profile

The glossary travels with the rest of the project context, in every chat.

Why This Works

Verbatim definitions mean the AI uses your exact meaning, not a dictionary one
Undefined terms become honest placeholders — the model asks instead of guessing
Domain-heavy products like commerce are where loose terminology costs the most

Best for

Domain-rich products (commerce, fintech, logistics)
Teams onboarding AI to unfamiliar jargon
Anyone whose terms have precise, non-obvious meanings

Not for

Defining how the AI should behave — use the System Prompt Generator
A single task's instructions — use the Prompt Template Builder

FAQ

How does the glossary handle terms I add without a definition?

Terms you leave without a definition are bracketed as missing rather than invented, so the profile never guesses a meaning it doesn't have. Abbreviations like SKU are detected and flagged automatically (marked _(abbreviation)_), and the Profile completeness line reflects any gaps. project-context-builder packages this text; your assistant then asks about a bracketed term instead of assuming.

Where does the project glossary go once project-context-builder generates it?

You paste the whole profile, glossary included, into your Claude Project instructions once, following the note at the top of the Harvest Market template: open the project, Edit, add it to the project instructions. From then on it applies to every chat in that project. project-context-builder produces the text; it does not push anything into Claude or keep the definitions itself.

Should I use this glossary to tell the AI how to behave or what tone to use?

The glossary is project KNOWLEDGE, not behavior, so it defines what your words mean (Reservation as stock held for an in-progress checkout, Basket as the customer-facing name for a cart) but not how the AI should act. For a persona, tone, or escalation rules, build a System Prompt in the System Prompt Generator instead, as the AI Usage Notes state.

Why does the AI still confuse basket and cart after I added them to the glossary?

Check that the definitions carried verbatim, for example Basket as the customer-facing name for a cart, and that the profile actually reached your Claude Project instructions, not just a single chat. project-context-builder outputs the text and scores Profile completeness (100/100 when nothing is bracketed), but it can't verify your assistant honors each definition, so re-paste and confirm the glossary is present.

Customize This Resource

Opens this project in Project Context Builder. Build to get the full context profile — then adjust the mode, stack, glossary, and output target.

Open in Project Context Builder

Prompt Template

Copy it as-is, or use Open in Project Context Builder to load it pre-filled and customize it with your own context.

# Project Context: Harvest Market

> Paste this into your Claude Project: open the project, Edit, and add it to the project instructions.

## Project Overview
Harvest Market is an online grocery storefront with same-day delivery. It handles carts, inventory, payments, and delivery scheduling for a regional customer base.

## Core Facts
- Project type: SaaS Product
- Primary stack: Next.js, Node.js, PostgreSQL, Redis, Prisma, TypeScript
- This is a multi-tenant SaaS product — tenant data isolation and uptime are non-negotiable.

## Tech Stack
- Next.js
- Node.js
- PostgreSQL
- Redis
- Prisma
- TypeScript
- Stripe

## Team Conventions
- Inventory is reserved at checkout, not at add-to-cart.
- Prices and stock come from the server, never trusted from the client.
- Every order state change emits an event.
- Respect the App Router and Server/Client Component boundary — mark client components with "use client". (Next.js)
- Prefer async/await over callbacks; never block the event loop with sync I/O in request paths. (Node.js)
- Use Redis for caching/queues with explicit TTLs; never treat it as the source of truth. (Redis)
- Change the schema through `schema.prisma` and migrations; use the generated client, not raw SQL, unless necessary. (Prisma)
- No `any` — prefer `unknown` with narrowing; keep `strict` mode on and types honest. (TypeScript)

## Naming Rules
- Database: snake_case for tables and columns; plural table names. (PostgreSQL)
- camelCase for variables and functions, PascalCase for types and components. (TypeScript)

## Architecture Principles
- Every data access is scoped to a tenant — never return one tenant's data to another.
- Treat billing, auth, and data-isolation code as critical paths; changes there need extra scrutiny.
- Design for graceful degradation — a failing feature must not take the whole product down.

## Glossary
- **SKU** _(abbreviation)_ — stock-keeping unit; one purchasable product variant.
- **Fulfillment** — picking, packing, and dispatching an order.
- **Reservation** — stock held for an in-progress checkout.
- **Basket** — the customer-facing name for a cart.

## Always Remember
- Stock and pricing are authoritative on the server only.
- This profile is the source of truth for project facts — prefer it over general assumptions.

## Never Assume
- Do not trust client-supplied prices or totals — recompute them server-side.
- Do not assume a component runs on the client — Server Components are the default.
- Do not assume the schema — reference the migrations or schema file before writing a query.
- Do not hand-write SQL when a Prisma query exists — and do not edit generated client code.
- Do not assume a value's type — check the type definition before changing a signature.
- Do not assume a request is for a single global dataset — it is tenant-scoped unless stated otherwise.
- Do not assume the current user has access to a resource — authorization is checked explicitly.
- When a fact is missing from this profile, ask — do not invent it.

## AI Usage Notes
- In Claude, project instructions apply to every chat inside the project — paste this once and start new chats freely.
- This profile is project KNOWLEDGE, not behavior — for a task persona (role, tone, escalation rules), build a System Prompt in the System Prompt Generator.
- It is durable project identity, not work state — to continue an in-progress task in a new chat, use the Context Handoff Builder.
- Profile completeness: 100/100 (Complete) — bracketed gaps, if any, mark missing info that was never invented.

More resources from Project Context Builder

Resource

Build Project Memory for AI

Stop re-explaining your project in every new chat. Capture it once as a context profile the AI keeps across every conversation — stack-inferred conventions and all.

Prompt Engineering

Resource

Create an AI Project Profile

A reusable profile that tells AI everything constant about your project — type, stack, conventions, glossary, architecture principles, and the rules it must never guess.

Prompt Engineering

Resource

AI Onboarding Context for an Existing Codebase

Onboard AI to a codebase the way you'd onboard a new hire: what it is, how it's built, the rules that aren't written down, and the things never to assume.

Engineering

Resources that pair well

Resource

AI Session Handoff — Shift Change for Working Sessions

End a working session like a shift change, not an abandonment: state captured, decisions logged, next step named — ready for the next session to pick up.

Prompt Engineering

Resource

Bug Triage Assistant

Convert scattered bug notes, Slack messages, or user complaints into structured engineering tasks with reproduction steps, severity, and root cause hypothesis.

Engineering

Resource

Convert a Conversation to a Prompt — the Full Anatomy

What a converged conversation contains: a rejected voice, an accepted framing, a hard constraint, a format decision, and a final-version moment — each mapped to its prompt section.

Prompt Engineering

Related tools

Tool

Project Context Builder

Define what AI should permanently know about your project — stack conventions, glossary, and never-assume rules in a profile you paste once.

Context Tools

Guides for this resource

Guide

Build a Project Glossary So AI Uses Your Terms

Give the AI context and it still writes "AI app builder" for your platform and "cart" for your basket — near-synonyms that change your meaning. Build a project glossary so AI uses your terms: define what each word means, name the synonyms to avoid, and paste it in your own tool.

AI Project Context & Handoffs

Tip: Save time by exploring related resources and tools that integrate with this resource.