What you get
A repository where any agent session starts with the same project context, including conventions, decisions, and current state, so agents stop contradicting each other.
Who this is for
This scenario is for anyone who has watched a second agent undo the work of the first because it did not know the conventions. Shared memory is the difference between agents acting like a team and agents acting like strangers.
How the phases connect
Capture inventories what agents need to know. Document structures it into files agents load at startup. Handoff keeps state current between sessions. Govern makes memory updates reviewed, diffed, and honest, so the files never drift into fiction.
The rule that keeps memory honest
Memory is code. It gets reviewed, diffed, and tested like code. A context file that no longer matches the repository is worse than no context file, because the agent will trust it. The validation checklist includes the test: a fresh session must answer the three project questions correctly from memory alone.
Prerequisites
- A Git repository the agents share
- An agent that loads a startup context file
- Willingness to review memory updates like code
Skill tree
The phases read left to right on desktop and top to bottom on mobile. Capability nodes are tool-neutral; the skills under them are the concrete options.
Goal
Share Project Memory Across Coding Agents
Capture
Capability
Project ContextKeep shared knowledge about the project available to every agent and session.
Document
Capability
DocumentationWrite the files that let humans and agents understand, use, and maintain the work.
Handoff
Capability
Project ContextKeep shared knowledge about the project available to every agent and session.
Govern
Capability breakdown
Each node states why it exists, what it takes in, what it produces, what can go wrong, and how it is accepted.
Each agent session starts from scratch. Without durable context, agents repeat mistakes, contradict each other, and forget decisions.
Input
- -Project conventions, decisions, and current state
- -Existing memory files and README content
Output
- -Maintained memory files agents read at session start
- -Decision log with rationale
- -Clear task-state tracker
Risks
- -Memory files that drift from reality
- -Treating chat history as project memory
- -One agent overwriting another agent's context
Acceptance
- -A new agent session can answer "what is this project and what is next?" from memory alone
- -Updates to memory are reviewed, not silently overwritten
- -Memory is structured so it can be diffed and searched
Undocumented work is unmaintainable. Documentation is the interface between the builder, the user, and the next agent that inherits the project.
Input
- -The built thing and its conventions
- -Reader profiles (user, maintainer, agent)
Output
- -README with run instructions
- -Maintenance and contribution notes
- -Machine-readable context files
Risks
- -Docs that describe intentions instead of current reality
- -Assuming readers know what the author knew
- -Duplicating knowledge that then drifts apart
Acceptance
- -A new person can run and extend the project from docs alone
- -Docs are updated in the same change that updates code
- -Agents have a designated context file to read first
The final step decides whether work is done. Validation turns "looks finished" into a checklist of observable, repeatable checks.
Input
- -Acceptance criteria from planning
- -The delivered output or site
Output
- -Completed checklist with pass/fail per item
- -Evidence (screenshots, logs, URLs)
- -Fix list for failed items
Risks
- -Subjective "good enough" instead of explicit criteria
- -Validating only what is easy to check
- -Marking items passed without evidence
Acceptance
- -Every criterion is a yes/no check, not a feeling
- -Failed items produce a concrete fix and a re-check
- -Validation is repeatable by a different agent
Recommended build
A ready combination of skills for this scenario, with the order and checks included.
Multi-Agent Memory
Durable shared context for repositories where several agents and sessions work on the same code.
- Skills
- 3 skills
- Steps
- 7 steps
Execution order
The recommended sequence from the Multi-Agent Memory build.
- 1
Inventory what agents need to know about the project
- 2
Design the memory files and the startup read order
- 3
Seed the files with current conventions and decisions
- 4
Add the decision log and task state tracker
- 5
Require handoff notes when sessions end mid-task
- 6
Review memory diffs in the same merge as the code changes
- 7
Run the fresh-session test after each significant update
Validation checklist
Common failures
Memory files drift from the actual codebase
Refresh memory from the latest diff at the start of each session
Agents overwrite each other's updates
Route memory updates through review like any code change
Memory becomes a dumping ground nobody reads
Keep files short and structured, and audit what agents actually read
Give this brief to your agent
Copy the structured brief, adapt the out-of-scope list, and ask the agent to return the checklist with evidence.
Agent task brief
Goal: A repository where any agent session starts with the same project context, including conventions, decisions, and current state, so agents stop contradicting each other. Scenario: Share Project Memory Across Coding Agents Categories: Memory, Coding, Collaboration Difficulty: intermediate Prerequisites: - A Git repository the agents share - An agent that loads a startup context file - Willingness to review memory updates like code Capabilities in execution order: Phase: Capture - Project Context Phase: Document - Documentation Phase: Handoff - Project Context Phase: Govern - Validation Recommended build: Multi-Agent Memory Execution steps: 1. Inventory what agents need to know about the project 2. Design the memory files and the startup read order 3. Seed the files with current conventions and decisions 4. Add the decision log and task state tracker 5. Require handoff notes when sessions end mid-task 6. Review memory diffs in the same merge as the code changes 7. Run the fresh-session test after each significant update Validation checklist: - [ ] A fresh session can answer project purpose, conventions, and next steps from memory alone - [ ] Decision log entries have dates, authors, and rationale - [ ] Memory files pass a diff review on every update - [ ] No two files contradict each other on conventions - [ ] Handoff notes exist for sessions that end mid-task Out of scope: - Single short sessions that end the same day - Projects where agents never touch shared files Evidence required: - Checklist with pass/fail per item - Screenshots at the agreed viewports - Build or run log from a clean checkout