128 lines
3.2 KiB
Markdown
128 lines
3.2 KiB
Markdown
# Agent Memory Rules
|
|
|
|
## Goal
|
|
|
|
Make workspace memory maintenance part of the agent's normal job, not a separate optional workflow.
|
|
|
|
---
|
|
|
|
## Default Agent Behavior
|
|
|
|
For any meaningful prompt, the agent should decide whether the interaction changes project memory.
|
|
|
|
This applies to:
|
|
|
|
- direct user prompts
|
|
- Mattermost sync results
|
|
- translated notes
|
|
- standup generation
|
|
- manager-update drafting
|
|
- debugging discussions
|
|
- corrections to previous understanding
|
|
|
|
The agent should not wait for a separate promotion command when the right update is already clear.
|
|
|
|
---
|
|
|
|
## What Counts As Memory-Worthy
|
|
|
|
Capture information automatically when it is:
|
|
|
|
- project-relevant
|
|
- explicit enough to preserve safely
|
|
- likely to matter in a future session
|
|
- useful for standups, debugging, or supervisor communication
|
|
|
|
Examples:
|
|
|
|
- confirmed story creation, points, scope, or priority
|
|
- confirmed reproduction constraints
|
|
- newly clarified root cause framing
|
|
- approved manager guidance that changes work direction
|
|
- confirmed version, dependency, or rollout facts tied to current work
|
|
- corrections to previously stored project context
|
|
|
|
---
|
|
|
|
## What The Agent Must Do
|
|
|
|
When new memory-worthy information appears, the agent should:
|
|
|
|
1. decide whether it is daily, current-state, durable, or decision-level context
|
|
2. update the smallest correct set of files
|
|
3. correct stale or conflicting existing statements
|
|
4. answer the user using the refreshed context
|
|
|
|
Do not ask the user what to promote unless the ambiguity is real and material.
|
|
|
|
---
|
|
|
|
## File Selection
|
|
|
|
### `ai/logs/YYYY-MM-DD.md`
|
|
|
|
Default destination for:
|
|
|
|
- same-day progress
|
|
- same-day findings
|
|
- scoped reproduction notes
|
|
- story and approval movement
|
|
- context that is important now but may evolve later
|
|
|
|
### `ai/state/current.md`
|
|
|
|
Use when the fact changes the active work window, including:
|
|
|
|
- current priorities
|
|
- currently active story scope
|
|
- current blockers or debugging constraints
|
|
- manager direction that changes the next few days of work
|
|
|
|
### `ai/state/work-items.md`
|
|
|
|
Use for current Jira-linked work that should remain easy to reference across sessions, especially:
|
|
|
|
- Jira IDs
|
|
- approved or explicit titles
|
|
- currently relevant status notes
|
|
- current points or scope notes
|
|
|
|
This file should help standups and manager updates mention work items precisely.
|
|
|
|
### `ai/context/project.md`
|
|
|
|
Use for durable project knowledge that should survive beyond the current work window.
|
|
|
|
### `ai/context/people/jeff.md`
|
|
|
|
Use only when a communication preference or manager expectation becomes stable enough to reuse repeatedly.
|
|
|
|
### `ai/context/decisions/*.md`
|
|
|
|
Use for explicit confirmed decisions with ongoing impact.
|
|
|
|
---
|
|
|
|
## What Not To Store
|
|
|
|
Do not store:
|
|
|
|
- tool failures
|
|
- sync attempts
|
|
- generic urgency messages
|
|
- duplicate paraphrases of the same fact
|
|
- weak guesses
|
|
- operational chatter that does not change project understanding
|
|
|
|
---
|
|
|
|
## Correction Rule
|
|
|
|
If new information supersedes old memory:
|
|
|
|
- update the existing canonical file
|
|
- do not leave stale and corrected versions side by side
|
|
- preserve qualifiers if the fact is only partially confirmed
|
|
|
|
The agent should behave like a senior engineer maintaining project notes, not like a chat assistant accumulating transcripts.
|