---
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`.
- Descriptive reference knowledge with no normative or action implication is
  learned: use `INFO`.
- 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`, `INFO`, `ISSUE`, or
   `TODO` they address.

## 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).