Repository instructions
Current contribution rules, test commands, and architectural constraints belong beside the code, where maintainers can review changes.
GUIDE · PROJECT CONTEXT
Give the next review the context it needs.
The most useful project memory explains a decision and points to its source. It helps a reviewer understand the code without turning every past conversation into an unquestioned instruction.
Keep three kinds of context distinct.
Project decisions
Retain the reason for a decision, its scope, date, and supporting issue or document. Update it when the design changes.
Review evidence
Keep the commit, the finding, the checks performed, and the maintainer’s resolution. A past finding may no longer apply to today’s code.
Persistence and retrieval are different.
A saved conversation remains available to inspect. Retrieval selects some context for a particular task. Neither guarantees that every retained detail reaches a model’s bounded context window.
When evaluating a review, ask which repository revision it read, what additional context it retrieved, and whether a source was unavailable. Missing memory should remain visible instead of being reported as successful recall.
Write decisions that can be checked.
“Never change the cache” is too broad to help a reviewer. A useful note says that the invoice cache is partitioned by account, identifies the code or design document that owns the rule, and explains that removing the partition could expose another customer’s invoices.
When a later change replaces that cache, retire or revise the note. The current code and an explicit maintainer decision should resolve the conflict; the mere age or repetition of a memory does not establish correctness.
| Field | Example |
|---|---|
| Decision and scope | Invoice cache keys include the account identifier. |
| Reason | Prevent records from one customer appearing in another customer’s result. |
| Source | The project’s cache design document and isolation checks. |
| Recheck when | Cache keys, tenant identity, or the storage design changes. |
Choose what to retain and check a real review.
Redgold’s managed setup connects the supported project context to a review workflow. Confirm the enabled sources and controls during onboarding. Retained memory is not a promise of private-model training or perfect recall.
- Agree which project owns the context and which users may access it.
- Retain decisions and references; leave credentials out of memory and public review comments.
- Confirm what can be inspected, corrected, and removed in the configured workspace.
- Try a small change where a documented project constraint matters, then inspect the finding and its source.
- Keep maintainer review and normal CI even when the retrieved context looks relevant.