Most code review knowledge disappears as soon as the pull request merges. The final diff remains. The comments remain somewhere. The reason the team chose the smaller migration, rejected the clever abstraction, or accepted the awkward edge case becomes much harder to find.
That loss is annoying on small changes and expensive on important ones. The next person sees the code, not the conversation around it. They reopen the same debate, remove a guardrail, or repeat the same migration plan that was already ruled out.
Docapybara gives review context a better resting place. Keep the pull request in GitHub or your normal code host. Use the vault for the durable explanation: what changed, what was debated, what was decided, what still needs attention, and which notes Capy should read before suggesting related changes later.
Create review notes for changes with memory value
Not every pull request needs a separate note. A typo fix can stay a typo fix. Create a review note when the change carries context that will matter later: architecture, security posture, migrations, performance tradeoffs, data shape changes, customer-visible behavior, or a decision that someone might second-guess.
Name the note after the change, not the PR number alone: Review - payment retry backoff change, Review - tenant import migration, Review - editor paste behavior. Put the PR link at the top, then add a short summary in plain English.
If the change connects to an existing decision, link it. Architecture Decision Records, Kept Where Your Agent Can Read Them is the natural companion for review notes that become policy.
Capture the review question, not every comment
A review note should not copy the entire comment thread. It should preserve the questions that shaped the final code. "Should this migration be reversible?" "Do we validate at the serializer or service layer?" "Is this retry safe if the webhook provider sends duplicates?"
Under each question, record the answer and the reason. If the answer was "we don't know yet," write that too. Unknowns are useful when they are named. They are dangerous when they hide inside a merged PR.
Capy can help after the review ends. Paste the important comments or link your own notes, then ask it to extract the durable questions, final decisions, and follow-up items. You still approve the result, but you don't have to do the clerical pass from scratch.
Keep rejected options visible
Rejected options are part of the work. They explain why the code looks the way it does. Without them, a future reviewer may "simplify" the code back toward an option that already failed.
Use a small Rejected options section. Keep it calm and factual: "We considered storing retry state in Redis, but rejected it because restarts would drop in-flight counters." "We considered client-side validation only, but rejected it because imports bypass the UI." No drama, no winner's speech.
This section is especially useful when paired with How to Use AI Notes for Bug Triage and Technical Debt. A rejected option in a review often becomes relevant again during a bug investigation.
Document tests as evidence
Tests are not just a checklist. They are evidence for what the change claims to protect. In the review note, write the meaningful test cases in human language: duplicate webhook, missing address, partial import rollback, slow external API, mobile paste from Google Docs.
Then include what was not tested and why. Maybe the integration environment does not support a provider sandbox. Maybe a load test is planned after rollout. Maybe the risk is low enough that unit coverage is enough. Honest gaps are better than a vague "tests added."
When a future change touches the same area, Capy can find the review note and remind you which behavior was intentionally covered. That makes review less dependent on one person's memory.
Use Capy before review, not only after
Before requesting review, ask Capy to read the relevant project notes and draft a reviewer brief. A useful brief includes the goal, files or components touched, known risks, decisions made, and specific questions for reviewers.
This helps reviewers start in the right place. It also keeps the pull request description from becoming either too thin or too sprawling. The brief can link to supporting notes without dragging the entire history into the PR.
If your change depends on internal endpoints, schemas, or integration behavior, How to Document APIs in Your Notes App is a good adjacent workflow. Reviewers should not have to reconstruct the contract from code alone.
Turn follow-up comments into tracked notes
Review threads often end with "follow up later." Later arrives with no owner and no context. When a review produces follow-up work, add it to the note with status, owner, and the reason it was deferred.
For recurring follow-ups, create an inline database with columns for area, follow-up, source PR, status, and next review date. Keep it on a page called Review follow-ups or inside the project page. The database can live beside the prose because Docapybara supports inline databases directly in markdown pages.
The important part is not the table. It is keeping the deferred work attached to the reason it exists. A backlog item called "clean up import service" is vague. A note that says "defer rollback refactor until after vendor cutoff because current migration is time-sensitive" is useful.
Let review notes feed runbooks and postmortems
Some review notes should become operational documentation. If a change affects deploy order, rollback steps, monitoring, or incident response, link it into the relevant runbook. If a production issue later traces back to the change, link the postmortem back to the review note.
This gives you a chain of memory: decision, implementation, review, rollout, incident, fix. Capy can search across that chain when you ask what happened or whether a new change conflicts with past choices.
For the operational side, read AI Notes for DevOps: Runbooks and Postmortems. The same calm documentation habit applies before and after the deploy.
Keep review documentation lightweight
The system should not make every merge feel ceremonial. Use review notes where the reasoning matters. Keep the template short: summary, questions, decisions, rejected options, tests, follow-up, links. If a section does not apply, skip it. The lightweight shape is the reason it survives busy weeks.
Docapybara is useful because rough notes still count. You can paste the PR summary, ask Capy to shape it, and edit the result into something future-you can trust. The note does not need to be polished. It needs to be findable, honest, and close enough to the code that you actually write it before the context cools.
For more on the agent-working-in-docs idea, see Claude Code for Documents. Try Docapybara free at the signup page if your code reviews keep producing important context that vanishes after merge.