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.

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.

Workflow

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

Use cases

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

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

# 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.

Related Resources

Explore more resources that work well with this one.