mcpField
A
aim-write

aim-write

github.com/djalmajrAgent workflows471 installsUpdated 5w ago
Repository

About aim-write

aim-write is a skill for saving canonical, user-approved knowledge as durable wiki pages in ai-memory. It guides page placement, metadata, cross-project scope, and recall checks while distinguishing permanent knowledge from routine session notes.

Key features

  1. 01Writes durable wiki pages
  2. 02Selects instance and workspace
  3. 03Applies path and kind conventions
  4. 04Supports shared rules across projects
  5. 05Checks that pages can be recalled

Use cases

  1. 01Recording a lasting project decision
  2. 02Saving a gotcha or reusable rule
  3. 03Sharing conventions across repositories

MCP support

The skill uses a configured ai-memory MCP server to write pages, then relies on aim-query for a recall check.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/djalmajr/skills --skill aim-write

After installing, type/aim-writein Claude Code to confirm it loaded.

Details

From the project README

aim-write

Persist a durable wiki page. Use only for canonical knowledge the user explicitly wants remembered — routine session notes are captured automatically by the hooks; do not hand-write those, and do not use a handoff for a permanent annotation.

Steps

  1. Pick the instance. From the repo's MCP config. If multiple ai-memory servers are configured, ask which endpoint to write to.

  2. Pick workspace/project. Default to the repo's .ai-memory.toml; confirm if writing elsewhere.

  3. Choose a path + kind. Use folder conventions so kind is derived and recall stays clean:

    • decisions/ADR-NNNN-<slug>.md → decision
    • _rules/<slug>.md → rule
    • gotchas/<slug>.md → gotcha
    • otherwise a topical path (e.g. runbooks/<slug>.md, <area>/<slug>.md). You can also set kind explicitly via frontmatter node_type / the tool arg.

    The _rules/ prefix matters — use the underscore. Pages under _rules/ (and pinned _slots/) are ai-memory's highest-signal tier: they're surfaced verbatim in memory_briefing / memory_explore / the dashboard, keyed by path GLOB '_rules/*'. A plain rules/ folder (no underscore) is just a normal page — it gets none of that and is only found by explicit query/read. So write durable rules to _rules/, never rules/.

    Shared / cross-project rules (e.g. global agent conventions reused across every repo) belong in a dedicated scope — the reserved default/_global scope — under _rules/ there (write with scope: "global"). Recall is per-(workspace, project), so other projects reach them cross-scope via memory_query scopes:[…] / memory_read_page (see aim-query), not automatically.

  4. Write the body as markdown with frontmatter (title, node_type, tags, optional source:). Link related pages with [[path.md]] (paths carry .md; links resolve by exact path). Never put live secrets/credentials in a page — redact (<see secret manager>).

  5. Call memory_write_page (or the equivalent admin write) with workspace/project/path/body.

  6. Confirm the page is recallable (a quick aim-query for its topic).

Keep pages focused and distilled — one fact/decision/gotcha per page reads and recalls best.

Comments

Markdown supported