repo-context.md
Per-repo context template — a human copies it above the generated block in AGENTS.md.
What this is
Per-repo context template — product, architecture, conventions, deliberate deviations from Redline. Review quality is bounded by context: a reviewer that doesn't know FlashList is the standard can't flag FlatList.
How to onboard it
- Installed as:
The top of AGENTS.md, above the <!-- REDLINE:BEGIN --> marker. - Installed by: A human, once, by hand. redline init never writes this file.
How to use it
Keep the deviations list short. If it grows past a few entries, that's a signal the standard itself is wrong for this repo — raise it in the Redline source repo instead of accumulating exceptions here.
- redline init only ever writes below the <!-- REDLINE:BEGIN --> marker in AGENTS.md — everything above it belongs to the repo's own team and is never touched by a re-render.
- Copy this template's content to the top of the target repo's AGENTS.md and fill in the bracketed sections: app shell, state management, styling, the directory map, team conventions, and a running list of deliberate deviations from Redline with the reason for each.
- The marker text itself is frozen deliberately — cli/render/markers.ts still names a script (scripts/render.mjs) this release deleted, and that string cannot change: changing it would make every already-onboarded repo append a second block instead of replacing its first.
Expected output
Whatever a human writes into the top of AGENTS.md. Nothing validates it and nothing renders it — it is context the reviewer reads, and its only measurable effect is on review quality: a reviewer that does not know FlashList is the standard here cannot flag FlatList.
How to edit it
The real source: Edit the target repository's AGENTS.md directly, above the <!-- REDLINE:BEGIN --> marker. Everything above that marker belongs to the repo's team and survives every re-render; everything below it is regenerated.
- Check whether the CLI reads this file at allSeveral of these are reference shapes: the CLI generates the equivalent in code and never opens the checked-in copy. Editing one of those changes nothing about what redline init writes. The onboarding section above says which kind this is.
- Edit the real sourceFor a generated artifact that is cli/commands/init.ts; for a file installed verbatim it is the template itself.
- npm test && node scripts/validate.mjsThe install path is unit-tested against a fake host client, and validate.mjs pins the shapes the merge gate's required check name depends on.
The full file
# Project context <!-- TEMPLATE. Copy the content of this file to the TOP of the target repo's AGENTS.md, above the `<!-- REDLINE:BEGIN -->` marker, and fill the bracketed sections. Everything above the marker is owned by your team and is never overwritten by Redline sync. Everything inside the marker block is generated — do not edit it. Why this file matters: review quality is bounded by context. A reviewer that does not know FlashList is the standard cannot flag FlatList. --> ## What this repo is [One paragraph: product name, what it does, who uses it, which market. e.g. "Customer self-care app for <market>, React Native (Expo) plus shared web components."] ## Architecture - **App shell:** [Expo SDK NN / Next.js NN / Spring Boot N.N / NestJS NN] - **State:** server state via [TanStack Query]; client UI state via [Zustand]. No Redux. - **Navigation:** [expo-router / react-navigation native-stack] - **Styling:** [StyleSheet.create / Nativewind / styled-components] - **API layer:** [BFF at `src/api/`; types generated from OpenAPI into `src/api/types/`] - **Persistence:** [Postgres via Prisma / JPA + Flyway] - **Messaging:** [Kafka topics owned: ...] - **Lists:** [FlashList is the standard; FlatList only for legacy screens.] - **Images:** [expo-image everywhere.] ## Directory map ``` src/ api/ # BFF client + generated types — do not hand-edit generated files components/ # shared UI, design-system components screens/ # one folder per screen hooks/ # shared hooks utils/ # pure functions only, no framework imports ``` ## Team conventions - [TypeScript strict mode; `noUncheckedIndexedAccess` on.] - Error handling only at boundaries (API calls, storage, native modules, user input). - Comments only for non-obvious WHY, never WHAT. - Minimal diffs; no drive-by refactors in feature PRs. - Architecture decisions recorded as ADRs in `docs/adr/NNNN-title.md`. ## Deliberate deviations from Redline <!-- List rules this repo knowingly does not follow, with the reason. Reviewers should not re-raise these. If the list grows past a few entries, the standard is wrong — raise it in the Redline source repo instead of accumulating exceptions here. --> - [e.g. "`any` permitted in `src/legacy/**` until MIG-4412 completes."] ## Review context - PRs may be authored by AI coding agents or contractors — review with the same rigour. - Merge requires one human approval plus green required checks. Automated review is advisory input to the human reviewer; it never approves.