Context Prompt

# {{FEATURE_NAME}} — Context Generation Prompt

> Paste everything below the horizontal rule into a new AI chat session.
> Run this ONCE after creating the design folder (init script or manual copy).
> The session will analyze the repository and generate a filled-in context.md.
> It will ask you a few clarifying questions before writing.

---

You are generating the **project context file** for the **{{FEATURE_NAME}}** feature
in the repository at `{{REPO_ROOT}}`.

Your goal is to write `{{DESIGN_FOLDER}}/context.md` — the "things you must know
before editing any file" document that every implementation session reads.

## Step 1 — Read the repository structure

List the full directory tree of `{{REPO_ROOT}}` (exclude `.git/`, `node_modules/`,
`__pycache__/`, `.venv/`, `{{DESIGN_FOLDER}}/`, and other generated/ignored directories).

Identify:
- The primary language(s) and framework(s) used
- The package manager / build tool (e.g. npm, uv, cargo, maven)
- The project entry point(s)
- The test runner and test directory structure

## Step 2 — Read key configuration files

Read the main project configuration file(s) — e.g., `pyproject.toml`, `package.json`,
`Cargo.toml`, `pom.xml`, `go.mod`.

From these, extract:
- Dependencies (especially third-party libraries the feature may interact with)
- Configured tools (linters, formatters, type checkers)
- Scripts / commands (build, test, lint, format)
- Entry points / plugin registrations

## Step 3 — Sample the codebase

Read 3–5 representative source files to understand:
- Naming conventions (files, classes, functions, variables)
- Common patterns (imports, error handling, logging)
- Architecture style (layered, modular, monolithic)
- Any module dependency rules visible from imports

## Step 4 — Ask clarifying questions

Before writing context.md, ask the user **up to 5 targeted questions** about
things you could not determine from reading the code. Examples:

- "I see both X and Y patterns for error handling — which is preferred?"
- "Are there dependency rules between modules? (e.g., A must not import from B)"
- "Any API keys or credentials needed for development?"
- "Are there naming conventions I missed?"
- "Any common mistakes or anti-patterns specific to this project?"

**Wait for the user's answers before proceeding to Step 5.**

## Step 5 — Write context.md

Write `{{DESIGN_FOLDER}}/context.md` using the template structure already in that
file. Fill every section with real observations:

**Repository layout** — Draw the actual directory tree with annotations.

**Key files** — List real files with accurate descriptions, not placeholders.

**Core conventions:**
- **Naming** — Document actual naming patterns observed in Step 3.
- **Required patterns** — Show a real code example from the repo (with a comment
  explaining what makes it the required pattern).
- **What NOT to do** — Include any anti-patterns you discovered plus the user's
  answers from Step 4. Always include:
  `Do NOT trust training data for third-party library APIs — always verify
  against current documentation (see QUICKSTART.md § Reference links and
  prompt.md Step 5.5).`

**Entry points / registration** — Fill from Step 2 findings, or delete the
section if the project doesn't use a plugin/registration system.

**Dependency rules** — Document any module boundary rules from Step 3 + Step 4.

**Post-edit commands** — Populate from the linter/formatter commands found in
Step 2. Use `{files}` as the placeholder for edited file paths. Example: