Engineering

Configure AI for an Existing Codebase

Set up Cursor, Copilot, or Claude for a repo that already exists. One profile becomes the rules file your AI assistant reads on every request.

Overview

In-editor assistants are only as good as the context they're configured with — and most repos give them none. This setup configures AI for Relay, a microservices logistics backend where each service owns its data and talks over a bus. Choosing the Copilot output target tailors the install note (.github/copilot-instructions.md); switching to Cursor produces a .cursorrules file instead. The profile carries the architecture principles, the cross-service rules, and the never-assume list, so the assistant respects service boundaries instead of reaching across them.

Workflow

Capture the architecture
Service boundaries, the bus, data ownership — the rules an assistant must respect.
Pick the target tool
Copilot, Cursor, or Claude — the install note adapts to where the file goes.
Commit the rules file
The assistant reads it on every request; the whole team gets the same context.

Why This Works

The output target tailors the install path for Cursor, Copilot, or Claude exactly
Architecture principles keep the assistant inside service boundaries
Committing the file means every teammate's assistant shares one source of truth

Best for

Repos using Cursor, Copilot, or Claude Projects
Microservice and multi-team backends
Teams that want shared, version-controlled AI rules

Not for

A throwaway prompt for one question — use the Prompt Template Builder
Carrying a half-finished task into a new chat — use the Context Handoff Builder

Use cases

Repos using Cursor, Copilot, or Claude Projects
Microservice and multi-team backends
Teams that want shared, version-controlled AI rules

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

> Save this at `.github/copilot-instructions.md` in your repo so Copilot Chat picks it up automatically.

## Project Overview
Relay is the backend for a logistics platform, split into services for orders, routing, and notifications that communicate over a message bus. Teams own services independently.

## Core Facts
- Project type: API Platform
- Primary stack: Spring, PostgreSQL, MongoDB, Java, Docker, Kubernetes
- This is an API platform — the public interface is a contract that consumers depend on.

## Tech Stack
- Spring
- PostgreSQL
- MongoDB
- Java
- Docker
- Kubernetes

## Team Conventions
- Services communicate via events on the bus, not direct database access.
- Each service owns its data — no shared tables across services.
- Every cross-service call has a timeout and a fallback.
- Use constructor injection and Spring stereotypes (@Service/@Repository); keep controllers thin. (Spring)
- Model documents, not rows — there are no JOINs; design for the access pattern. (MongoDB)
- Favor immutability and constructor injection; keep null out of public APIs where possible. (Java)
- Keep the app twelve-factor — config via environment, no host-specific assumptions in the image. (Docker)
- Treat pods as ephemeral and stateless; externalize state and config. (Kubernetes)

## Naming Rules
- Database: snake_case for tables and columns; plural table names. (PostgreSQL)
- PascalCase for classes, camelCase for methods/fields, UPPER_SNAKE for constants. (Java)

## Architecture Principles
- The public API is a contract: breaking changes require a version bump, never a silent edit.
- Validate input at the boundary and return predictable, documented error shapes.
- Keep responses backward-compatible; add fields, don't repurpose or remove them.

## Glossary
- **Service** — an independently deployable unit owned by one team.
- **Bus** — the message broker services publish events to.
- **Saga** — a multi-service transaction coordinated by events.
- **Idempotency** — handling a duplicated event without double effect.

## Always Remember
- Each service owns its own data — never reach into another service's database.
- This profile is the source of truth for project facts — prefer it over general assumptions.

## Never Assume
- Do not assume a synchronous call succeeds — handle timeouts and retries with idempotency.
- Do not assume the schema — reference the migrations or schema file before writing a query.
- Do not assume a relational schema or foreign keys — relationships are modeled in documents or by reference.
- Do not change a public endpoint's shape without treating it as a breaking change.
- Do not assume a consumer tolerates extra latency or new required fields — they are part of the contract.
- When a fact is missing from this profile, ask — do not invent it.

## AI Usage Notes
- Copilot reads repo instructions for everyone working in the codebase — commit this file so the context is shared.
- 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.

Used in Playbooks

Complete workflows that include this resource as a step.

AI Code Review Workflow Workflow · 5 steps

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

Explore all resources