---
name: augment-context
description: Use Augment MCP memories to gather and persist project context during coding sessions.
---

# Augment Context

Use this skill when working in a repository with the Augment MCP server available.

## Session Start

1. Call `init_project`.
2. Call `search` with the user's task summary.
3. Read exact memories when search results identify likely governing context.

## Memory Insights

When the user asks for memory insights, stats, health, or an overview of what
Augment knows, call `memory_insights` (and `memory_graph` when they want to see
how memories connect). In hosts that support MCP Apps these render interactive
dashboard snippets; elsewhere they return a text summary — either way, relay the
findings rather than re-deriving them from raw memories.

## Before Code Changes

1. Search for the file, component, command, error, or behavior being touched.
2. If the work depends on a prior decision, read and follow the relevant `SPEC`
   or `ARCH` memory.
3. If no relevant memory exists but the task creates a durable requirement or
   decision, create one before implementation.

## Memory Triggers

Call `upsert` whenever one of these durable events happens:

- A requirement, API contract, data model, or tool contract is clarified:
  use `SPEC`.
- An implementation approach, tradeoff, transport choice, persistence model, or
  architecture decision is made: use `ARCH`.
- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
- Follow-up work is intentionally deferred: use `TODO`.
- A meaningful implementation milestone is completed: use `WORK`.
- A test scenario, regression case, or verification rule is learned: use `SPEC`
  or `WORK`, whichever is more durable.

## Links

After creating or updating a memory:

1. Use `link` when a memory implements, depends on, blocks, parents, or relates
   to another memory.
2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
   they address.

## Decoction

When the user asks to decoct, glean, or generalize cross-project memory:

1. Call `decoction_glean` with `action: "discover"`, then read every source in
   the selected cluster.
2. Draft one reusable SPEC or ARCH under `.generic/`, keeping only claims
   supported across the projects and listing every source in `derived_from`.
3. Suggest removal only for originals whose entire durable content the generic
   preserves. Call `decoction_glean` with `action: "write"`; report advisory
   warnings without treating them as write failures. When updating an existing
   generic, read it fresh and pass both expected hashes.
4. Show the exact suggested paths and reasons. Call `decoction_cleanup` only
   after explicit approval of those paths; the hard deletes have no rollback.

Decoction is separate from sleep: sleep consolidates settled work inside one
project, while decoction extracts reusable knowledge across projects.

## Generic store

When the user asks to `/augment:generic`, store as generic, promote to generic,
or import knowledgebase/notes into shared memory:

1. Resolve project `.generic` via `list_projects` (or `init_project` with
   `project_name: ".generic"` if missing). Always upsert with that
   `project_id` — never the cwd project.
2. Chunk sources into one focused SPEC (facts/contracts) or ARCH
   (methods/tradeoffs) per durable claim. Never WORK/ISSUE/TODO. No whole-book
   dumps.
3. `search` (and `read` near `.generic/` hits) before write; update in place on
   same name/topic. Tags include origin (`source:knowledgebase`, `domain:…`).
   Provenance lives in the body; do not use `decoction_glean` or force
   multi-project `derived_from`.
4. For more than three memories or a whole-tree import, show a batch
   (kind/name/summary/create-vs-update) and wait for explicit approval before
   any `upsert`. Report each `.generic/...` path written.

This is intentional shared knowledge, not decoction (cross-project recurrence)
or sleep (within-project WORK fold).

## Dreaming

When the user asks to dream over memory or surface speculative connections:

1. Search globally with the current project context, then read the relevant
   current, generic, and foreign memories.
2. Call `dream_propose` for each candidate memory or link. Dream memories land
   in the current real project (`.generic` is never active); dream links start
   there but may target another project. State what evidence inspired the idea
   and what remains unverified.
3. Present each editable proposal. Call `dream_apply` only after explicit user
   approval; otherwise call `dream_reject`.

Never present a dream as established fact.

## Session Finish

For almost every session that did real work (skip only pure Q&A, read-only
inspection, or trivial mechanical ops like 'commit & push'):

1. Upsert a concise `WORK` memory with what changed, key files, and verification.
2. Upsert or update `TODO` memories for known remaining work.
3. Link the final `WORK` memory to the relevant planning/decision memories.

## Guardrails

- Do not store secrets, credentials, tokens, or private keys.
- Do not store huge logs, dependency dumps, generated files, or full source files.
- Keep each memory focused; split large notes before calling `upsert`.
- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
- Use returned search text directly as context; do not ask Augment to summarize.
- Default to upserting when a turn did real work; only skip pure Q&A, read-only
  inspection, or trivial mechanical ops. When unsure, upsert.
- Do not create memories for facts already obvious from the current diff, or that
  duplicate an existing memory (update that one instead).