Implementation Memory

Implementation Memory

Overview

Implementation memory is a compact, fixed-size set of rules that improves future /build executions. It captures durable lessons from completed builds, code review feedback, test failures, and user feedback, then applies only the relevant lessons to later implementation work.

This is procedural memory, not history. It stores rules for how to implement better next time. It does not store product context, design history, changelog entries, ADRs, raw retrospectives, PR transcripts, or conversation logs.

This mechanism is harness-agnostic by design. It uses a plain markdown file in the repo (docs/implementation-memory.md) intentionally. It is not tied to any agent's native memory system. Any AI agent that can read markdown and follow instructions can consume and update it.

This is an internal flow mechanism. Users do not invoke it as a slash command or choose it as a standalone workflow. Existing build commands and build-oriented assistant rules call it automatically at the defined points in the /build flow.

Capture Points

Implementation memory can be fed from multiple workflow stages — not only /build:

Source	When	What to extract
/build (post-implementation review)	After PASSED WITH FIXES NEEDED or user validation	Procedural lessons from fix tasks, debug cycles, review findings
/review (code review)	After review feedback is resolved	Recurring review findings that apply beyond one PR
/learn (COE)	After corrective actions are defined	Operational lessons that should influence future implementation

All sources use the same Quality Memory Review process, admission checks, and rejection rules.

Internal Flow Hooks

Use this mechanism in these places:

1. Before /build task execution: read the current spec/tasks first, then select only active memory rules whose Applies when field AND Tags/File patterns match the current work.
2. After implementation review (semi-automatic trigger): when the verdict is PASSED WITH FIXES NEEDED, the agent MUST automatically extract up to 2 candidate learnings from the fix findings and present them to the user for Accept / Reject / Edit. This is the primary memory population path. When the verdict is PASSED, prompt the user to test the delivered behavior and bring back failures or feedback.
3. After user validation or explicit request: run a Quality Memory Review using implementation results, implementation review, test/debug feedback, and user feedback to decide whether memory should be updated.
4. After /review findings are resolved: if the review surfaced recurring patterns (same finding across 2+ PRs or explicitly flagged as "this keeps happening"), extract candidates and present for Accept / Reject / Edit.
5. After /learn corrective actions: if a COE produces an implementation-level corrective action (not an org/process action), extract a candidate and present for Accept / Reject / Edit.
6. Periodic nudge: after 3 builds without a memory update (tracked via Last build without update counter at the bottom of the memory file), include in the end-of-build summary: "You have had N builds without memory update. Would you like a quick Quality Memory Review?"