Code-owning is a skill that helps developers take greater ownership of code that an AI has written for them.
This skill is not ready to use out of the box; it must be customized first.
Insert the context that was used to generate the code (plan, spec, doc, ...).
This is the tricky part: you have to define what the developer should pay attention to.
Example:
**A · Purpose + tricky parts** — derived from `specification.md` + the diff; recorded in no doc.
- The screen's purpose: one sentence — what it exists to do. Anchor: the `*.screen.tsx` entry.
- Tricky parts: feature-specific logic where misunderstanding it produces a _wrong change_. Non-obvious AND specific to this feature only — exclude framework, boilerplate, and design-system-standard code.
**B · Cross-cutting changes** — anything in the diff touched _outside this screen's own feature/domain files_. Blast radius beyond the screen; a reviewer challenges every one; usually **no ledger entry**, so the dev's justification IS the record — a change they can't justify gets flagged to remove or document.
| Trigger in `git diff develop...HEAD` | Ask |
| ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| Addition under `src/core/**` | "Why does this belong in shared `src/core` vs kept local?" |
| Config change (`app.config.ts`, `package.json`, `jest.config.js`, `tsconfig*.json`, `babel.config.js`, `metro.config.js`, …) | "Why is this config change needed?" |