Prompt Engineering

Establish Domain Knowledge for AI

AI knows general programming but not your domain. Establish how your specific world works — its rules, its vocabulary, its non-negotiables — so it reasons inside it.

Overview

A model can write flawless Python and still misunderstand your data pipeline, because the hard part isn't the language, it's the domain. This setup establishes the domain for Quarry, a batch data pipeline feeding a warehouse. The facts that matter aren't syntax — they're that runs are idempotent, aggregates use UTC day boundaries, and bad rows are quarantined not dropped. The glossary defines run, backfill, DAG, and partition; the never-assume list bars trusting input data. The profile gives the AI the mental model of the domain, not just the code.

Workflow

State the domain rules
Idempotent runs, UTC boundaries, quarantine bad rows — the laws of your world.
Define the vocabulary
Run, backfill, partition: the words that carry domain meaning.
Give the AI the model
It reasons inside your domain instead of applying generic defaults.

Why This Works

The domain, not the language, is what general-purpose models get wrong
Always-remember rules encode the invariants the system depends on
Never-assume rules stop the model trusting things your domain never trusts

Best for

Data, fintech, and other rule-heavy domains
Systems with strong invariants
Projects where the language is easy but the domain is hard

Not for

Explaining a specific algorithm — use the Code Explanation Prompt
A behavior persona for one task — use the System Prompt Generator

Use cases

Data, fintech, and other rule-heavy domains
Systems with strong invariants
Projects where the language is easy but the domain is hard

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: Quarry

> Save this at your repo root as `.cursorrules` (or `.cursor/rules/project.mdc`) so Cursor loads it for every request.

## Project Overview
Quarry is a batch data pipeline that ingests raw event logs, cleans them, and loads daily aggregates into the warehouse for the analytics team.

## Core Facts
- Project type: Software Project
- Primary stack: PostgreSQL, SQLAlchemy, Python, Docker, AWS, PyTest
- This is a software codebase — correctness, readability, and maintainability come before cleverness.

## Tech Stack
- PostgreSQL
- SQLAlchemy
- Python
- Docker
- AWS
- PyTest

## Team Conventions
- Every transform is pure and unit-tested on a fixed sample.
- Pipelines are idempotent — re-running a day produces the same result.
- Schema changes go through a migration and a backfill plan.
- Define models declaratively and use sessions correctly; manage migrations with Alembic. (SQLAlchemy)
- Follow PEP 8 and add type hints on public functions. (Python)
- Keep the app twelve-factor — config via environment, no host-specific assumptions in the image. (Docker)
- Use the platform's managed services and least-privilege IAM; never hard-code credentials. (AWS)
- Use fixtures and parametrize for coverage; keep tests deterministic. (PyTest)

## Naming Rules
- Database: snake_case for tables and columns; plural table names. (PostgreSQL)
- snake_case for functions and variables, PascalCase for classes, UPPER_SNAKE for constants (PEP 8). (Python)

## Architecture Principles
- Keep modules focused — a file or function should do one thing well.
- Prefer clarity over abstraction; introduce indirection only when duplication has actually appeared.
- Changes should come with the test that proves them.

## Glossary
- **Run** — one execution of the pipeline for a given date partition.
- **Backfill** — reprocessing historical partitions after a logic change.
- **DAG** _(abbreviation)_ — the directed graph of pipeline steps.
- **Partition** — one day's slice of data.

## Always Remember
- All aggregates are computed in UTC day boundaries.
- This profile is the source of truth for project facts — prefer it over general assumptions.

## Never Assume
- Do not assume input data is clean — validate and quarantine bad rows.
- Do not assume the schema — reference the migrations or schema file before writing a query.
- Do not assume newer syntax is available — confirm the target Python version.
- Do not hard-code secrets or region assumptions — use the configured environment.
- Do not assume how a module is used elsewhere — check the call sites before changing a signature.
- When a fact is missing from this profile, ask — do not invent it.

## AI Usage Notes
- Cursor reads project rules from the repo, so this travels with the code and every teammate gets the same context.
- 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.