Skip to content

Memory System ​

The SNIPER memory system tracks conventions, anti-patterns, and decisions that agents learn over time. This accumulated knowledge is injected into future spawn prompts, allowing agents to improve across protocol executions.

How Memory Works ​

Memory operates in three channels:

Conventions ​

Rules that agents must follow. Each convention has:

  • Rule -- the specific convention (e.g., "All API routes use Zod validation middleware")
  • Applies to -- which agent roles this convention affects
  • Enforcement -- where the convention is enforced (spawn_prompt, review_gate, or both)
  • Status -- confirmed (verified across multiple executions) or candidate (needs more evidence)
  • Examples -- positive and negative code examples

Anti-Patterns ​

Practices to avoid. Each anti-pattern has:

  • Description -- what the anti-pattern looks like
  • Severity -- critical, high, medium, or low
  • Fix pattern -- what to do instead
  • Detection hint -- pattern for automated scanning during review gates

Decisions ​

Architectural or design decisions that agents should respect. Each decision has:

  • Title and description -- what was decided
  • Rationale -- why it was decided
  • Status -- active or superseded

Memory Files ​

Memory is stored in .sniper/memory/, with retrospectives in .sniper/retros/:

8 lines
.sniper/memory/
  conventions.yaml       # Confirmed and candidate conventions
  anti-patterns.yaml     # Known anti-patterns with severity
  decisions.yaml         # Active architectural decisions
  signals/               # Runtime signals from hooks and agents
.sniper/retros/          # Protocol retrospective reports
  retro-001.yaml
  retro-002.yaml

Configuration ​

In v3, there is no dedicated memory config section. Memory behavior is driven by the auto_retro flag in protocol YAML files (e.g., auto_retro: true in full.yaml) and the retro-analyst agent. The visibility config exposes a single flag:

3 lines
yaml
# In .sniper/config.yaml
visibility:
  auto_retro: true        # Enable automatic retrospectives after protocol completion

When auto_retro is enabled in the protocol, the retro-analyst agent runs automatically after the review phase completes, updating memory files in .sniper/memory/.

Memory Prioritization ​

When memory entries are extensive, they are prioritized for inclusion in spawn prompts:

  1. High-severity anti-patterns (always included)
  2. Conventions with enforcement: both or enforcement: review_gate
  3. Active decisions
  4. Medium-severity anti-patterns
  5. Conventions with enforcement: spawn_prompt only
  6. Low-severity anti-patterns

Managing Memory ​

Memory is stored as YAML files in .sniper/memory/ and managed automatically by the framework. You can also edit the files directly.

Viewing Memory ​

Run /sniper-status to see a summary of memory entries, or inspect the YAML files directly:

5 lines
.sniper/memory/
  conventions.yaml      # Coding conventions
  anti-patterns.yaml    # Known anti-patterns to avoid
  decisions.yaml        # Architecture/design decisions
  retros/               # Retrospective reports

Adding Entries ​

Add entries directly to the YAML files. Each entry follows this format:

6 lines
yaml
# .sniper/memory/conventions.yaml
- id: conv-001
  text: "Use barrel exports for all module directories"
  status: confirmed       # confirmed | candidate
  source: manual
  created: 2026-01-15

Automatic Memory Updates ​

The retro-analyst agent automatically updates memory after protocol completion:

  • High-confidence findings (appeared in 3+ files) are added with status: confirmed
  • Medium-confidence findings are added with status: candidate
  • Duplicate entries are skipped

Retrospectives ​

When auto_retro is enabled, a retrospective runs automatically after each review gate passes.

How Retrospectives Work ​

  1. A retro-analyst agent is spawned with context from:

    • Completed story files from the implementation
    • Review gate results
    • Existing memory (for deduplication)
    • Code changes (git diff summary)
  2. The agent analyzes patterns:

    • What conventions were followed consistently?
    • What anti-patterns appeared?
    • What estimation errors occurred?
    • What positive patterns should be codified?
  3. Results are written to .sniper/memory/retros/retro-{N}.yaml

Auto-Codification ​

When auto_codify is enabled:

  • High-confidence findings (appeared in 3+ files, consistent pattern) are automatically added to memory with status: confirmed
  • Medium-confidence findings are added with status: candidate -- promote them by changing status to confirmed in the YAML file
  • Duplicate entries are skipped

Manual Retrospectives ​

Retrospectives run automatically when auto_retro is enabled. If disabled, the retro-analyst agent can be triggered by re-running the protocol's review phase.

Memory in Spawn Prompts ​

When an agent is spawned, the memory layer is filtered by role and formatted:

13 lines
markdown
## Project Memory -- Conventions You Must Follow

- **conv-001:** All API routes use Zod validation middleware
  Example: router.post('/users', validate(createUserSchema), handler)
  NOT: router.post('/users', handler)  // no validation

## Anti-Patterns -- Do NOT Do These

- **ap-001 (high):** Direct DB queries in handlers. Instead: use repository pattern

## Key Decisions

- **dec-001:** Use Zod for validation -- type-safe runtime validation

Conventions are filtered by the applies_to field, so backend developers see backend conventions and frontend developers see frontend conventions.

Workspace Memory ​

When workspace mode is enabled, workspace-level memory also exists at {workspace_path}/memory/. Workspace conventions apply across all repos and are labeled [WORKSPACE] in spawn prompts.

Cross-repo patterns that appear consistently in 2+ repos can be promoted to workspace memory. This can happen automatically during retrospectives (if auto_promote: true) or manually.

Next Steps ​