memory-retrieve

$npx mdskill add Fr-e-d/GAAI-framework/memory-retrieve

Load only relevant historical context for a task using 3-level progressive disclosure

  • Identifies and loads specific decisions based on user-defined domain and level criteria.
  • Deploys decision files and related category files to provide detailed context.
  • Utilizes `related_to` relationships within loaded files to uncover additional relevant information.
  • Delivers filtered historical context directly to the user or agent for task execution.

SKILL.md

.github/skills/memory-retrieveView on GitHub ↗
---
name: memory-retrieve
description: Load only the minimum relevant memory for a task using 3-level progressive disclosure. Activate before context-building — never load full memory dumps. Never substitute summaries for durable memory.
license: ELv2
compatibility: Works with any filesystem-based AI coding agent
metadata:
  author: gaai-framework
  version: "2.2"
  category: cross
  track: cross-cutting
  id: SKILL-MEMORY-RETRIEVE-001
  updated_at: 2026-04-05
  status: stable
inputs:
  - contexts/memory/index.md        (registry — always read first, contains Decision Registry + file map)
  - contexts/memory/**              (any category registered in index.md — resolved at runtime)
outputs:
  - memory_context_bundle
---

# Memory Retrieve

## Purpose / When to Activate

Activate before `context-building` whenever a task requires historical context.

**Never load full memory. Always filter by relevance.**
**Never substitute summaries for durable memory (decisions, patterns, project).**

---

## 3-Level Progressive Disclosure

```
Level 1 — INDEX SCAN (~5 tokens/entry)
  Read index.md → Decision Registry table (DEC | Domain | Level | Title)
  Agent identifies relevant decision(s) by domain and/or level

Level 2 — INDIVIDUAL ADR FILES (~300 tokens/file)
  Load specific decisions/DEC-{ID}.md files for full entry text
  Load other relevant category files (patterns, project, ops)
  Optionally traverse `related_to` in loaded files to discover adjacent decisions
  Or invoke `memory-search` Mode C for systematic cross-reference discovery

Level 3 — CROSS-DOMAIN SCAN (only for Decision Consistency Gate)
  Grep frontmatter across all DEC-*.md files for conflicts
  Only triggered when recording a new decision (see Decision Consistency Gate in decision-extraction skill)
```

---

## Process

1. **Read memory index** (`contexts/memory/index.md`). This contains:
   - Shared categories table (paths + purpose)
   - Decision Registry: one row per DEC-ID with domain, level, and title
   If `index.md` is absent or empty, fall back to scanning `contexts/memory/` directory structure.

2. **Identify relevant decisions** for the current task:
   - Filter the Decision Registry by **domain** (e.g., `billing`, `matching`)
   - Filter by **level** if scope is known (e.g., only `architectural` for implementation tasks)
   - From story/epic tags or explicit instruction scope

3. **Load memory by durability class:**

   **Durable memory** (decisions, patterns, project, ops, contacts, domains):
   → Load individual `decisions/DEC-{ID}.md` files directly. Full text, never summaries.
   → Summaries exist as INDEX-ONLY aids — they list entries for scanning but MUST NOT substitute for the full decision text.
   → Load only the specific decisions relevant to the task (typically 3-10 files).

   **Ephemeral memory** (sessions):
   → Prefer summaries if available (lower token cost).

4. **For Decision Consistency Gate:**
   → Scan the Decision Registry in index.md for ALL entries in the relevant domain
   → Load the specific `DEC-{ID}.md` files to check for conflicts
   → If uncertain about boundaries, also load decisions from adjacent domains

5. **Freshness Check (Tier 2 files only)**

   Pre-condition: verify that `git` is available on the PATH (`git --version`). If `git` is unavailable, append the following note to the `freshness_warnings` section and skip the remainder of this step — proceed to Step 6 normally:
   > Freshness check skipped: git not available

   For each file in the `memory_context_bundle`:

   a. If the file's frontmatter has no `refresh_tier` field, or `refresh_tier` ≠ 2 → **skip** (Tier 1 files are proactively refreshed via the post-delivery hook; Tier 3-4 are not checked at read time).

   b. If `depends_on` is absent or `depends_on.code_paths` is empty → **skip** (treat as Tier 4 — no check, no warning).

   c. If `updated_at` is absent or unparseable → append to `freshness_warnings`:
   > Freshness check skipped: no valid updated_at — {file_path}
   Then **skip** this file.

   d. For each path in `depends_on.code_paths`:
      - If the path does not exist on disk, append to `freshness_warnings`:
        > Freshness check skipped: {path} not found — depends_on may be stale
        Then skip this path.
      - Run: `git log --oneline --since="{updated_at}" -- "{path}"` (where `{updated_at}` is the file's frontmatter value, quoted exactly as-is).
      - Count the lines returned. If the count > 0, the file is `POTENTIALLY_STALE` for this path.

   e. If any path produced a non-zero commit count for this file, append one `freshness_warnings` entry per changed path in the format below (AC2):

   ```
   ⚠ FRESHNESS WARNING — {file_path}
     refresh_tier: 2
     updated_at: {date}
     changed_dependency: {code_path} ({N} commits since updated_at)
     action: verify content is still accurate before relying on it
   ```

   If no warnings are produced, the `freshness_warnings` section is omitted from the output (0 tokens).

6. **Return `memory_context_bundle`** — curated, minimal set of memory files relevant to the current task, plus any `freshness_warnings` produced in Step 5.

---

## Output

**`memory_context_bundle`** — curated set of memory files relevant to the current task, ready for `context-building`.

---

## Quality Checks

- No full memory injection
- Context is focused on the task
- Agent loads only the specific DEC-{ID}.md files relevant to the task (typically 3-10)
- **Summaries are NEVER substituted for durable memory** (decisions, patterns, project)
- Decision Registry enables decision identification WITHOUT opening individual files
- Token budget: index (~1,500) + 3-10 individual decision files (~300 each) = ~4,500 tokens typical; `freshness_warnings` section adds ~100-200 tokens when Tier 2 staleness is detected, 0 tokens when all files are clean
- Only memory directly relevant to the task is included
- Freshness warnings are emitted for Tier 2 files with changed code dependencies — never silently suppressed.

---

## Non-Goals

This skill must NOT:
- Load all memory files
- Decide what to do with retrieved memory
- Modify memory files
- Substitute summary one-liners for full decision text

**Selective retrieval via progressive disclosure. Memory is never auto-loaded. Durable memory is never summarized away.**

More from Fr-e-d/GAAI-framework

SkillDescription
abort-safe-handlerOrchestrator-level Stage 4 entry gate for /gaai:bootstrap. Presents a pre-loop "Skip Q&A entirely" option, delegates to qa-loop-ui when the user proceeds, and returns a unified abort_safe_result with telemetry on every path. Guarantees no partial state on skip or abort.
ambiguity-detectorTakes surface scan results, optional LLM synthesis open-question entries, and optional tree-sitter AST signals to score project ambiguities (1-10). Outputs structured ambiguity_feed for smart-question-generator. Pure heuristic — no LLM calls. Designed for Stage 3.5 of the /gaai:bootstrap pipeline (between LLM synthesis and Q&A).
approach-evaluationResearch industry standards and best practices, identify viable approaches for a given technical or architectural problem, and produce a structured factual comparison against project-specific constraints. Reports options — does not decide.
architecture-extractConvert raw project structure into clear architectural understanding — module boundaries, data flows, service relationships, and architectural patterns. Activate after codebase-scan during Bootstrap.
bootstrap-llm-synthesisConstruct the LLM synthesis prompt from project surface scan + optional tree-sitter context + optional Q&A answers. Call the LLM. Parse and validate the response into 6-8 structured memory entries with clarity tags and source traceability. Used as Stage 3 of the /gaai:bootstrap pipeline.
bootstrap-memory-ingest-cloudWrite structured memory entries to the Cloud workspace via gaai_memory.store MCP tool with source='bootstrap'. Loops over entries from bootstrap-llm-synthesis, calls the tool per entry, collects success/fail counts. Used as Stage 5 of the /gaai:bootstrap pipeline (Cloud path only).
browser-journey-testValidate user stories by simulating real user journeys in a live browser against deployed application. Activate after implementation to verify actual user experience against acceptance criteria, not just code logic.
build-agents-indexScan all agent and sub-agent definition files in .gaai/core/agents/, extract YAML frontmatter, merge with specialists.registry.yaml, and generate a derived agents-index.yaml at .gaai/core/agents/agents-index.yaml. Activate after adding, modifying, or removing any agent, sub-agent, or specialist entry.
build-skills-indexScan SKILL.md files in .gaai/core/skills/ and .gaai/project/skills/, extract YAML frontmatter, and regenerate separate skills indices for each layer. Core index ships with the OSS framework; project index is project-specific.
ci-watch-and-fixWatch GitHub Actions CI after PR creation, detect failures, extract logs, apply minimal fixes, and re-push — keeping the delivery session alive until CI resolves or escalating after 3 cycles. Activate immediately after gh pr create and before marking the story done.