AGENTS.md
+107 −33
https://raw.githubusercontent.com/verygoodplugins/mcp-automem/HEAD/AGENTS.md
− ## Pull Request & Copilot Review Process (Mandatory)− **Copilot Review Completeness Rule** (applies to every agent, including Claude Code, Cursor, Codex, Grok, etc.):− - Every PR must receive a GitHub Copilot review.− - When opening a PR in a **published / ready (non-draft) state**, immediately trigger review with the `/copilot-review` comment (our standard convention):− ```bash− gh pr comment <PR> --body "/copilot-review"− ```− - A PR is **not ready for human merge** until:− - Copilot has submitted a completed review on the current head.− - **Zero** unresolved, non-outdated Copilot review threads remain.− - Every thread was either:− - Fixed with the smallest correct code change, replied to, and resolved, **or**− - Well-addressed with a specific, code-based reply explaining why no change was made (resolved where appropriate).− - **If a comment identifies a real issue, fix it.** Strong bias toward making the fix.− - After any fix push on the PR branch, re-trigger with `/copilot-review` and repeat the process.− - Use the `copilot-review` skill (or equivalent systematic process) to walk threads when they exist.− - In the final PR summary / handoff, explicitly state how many threads were addressed and confirm the review is clean.− This rule exists because open Copilot comments on merged PRs create technical debt and surprise the next person who touches the code.− **Grok's personal standing rule (internalized as default behavior):** I will never hand off a PR I'm involved with while Copilot threads are dangling. I treat the review as a hard gate. "Well-addressed" always includes an actual reply + resolution. If a fix is warranted, I make the fix. I re-trigger `/copilot-review` after pushes until the review is clean on the final head. I use the `copilot-review` skill (or equivalent) to systematically process threads rather than doing ad-hoc fixes.− # Guided setup wizard (creates .env, prints config snippets)− npx @verygoodplugins/mcp-automem setup− - **ID fetch:** `memory_id` → routes to `GET /memory/{id}` and ignores other params.− - **Tag enumeration:** `tags` + `exhaustive: true` → routes to `GET /memory/by-tag` for paginated exact-match listing. Pair with `limit` (≤200) and `offset`. Returns `has_more`/`limit`/`offset`. Use this for cleanup/audit workflows where ranked recall undercounts.− - **Ranked retrieval (default):** hybrid search across vector, keyword, tags, recency/state controls, score filters, and graph expansion. Supports `query`/`queries`, `embedding`, `limit`, `time_query`, `tags`, `tag_mode`, `tag_match`, `exclude_tags`, expansion options including `expand_respect_tags`, `state_mode`, `recency_bias`, `scope_fallback`, `min_score`, `adaptive_floor`, context hints, and pagination (`offset`, `sort`, `format`). Responses preserve diagnostics such as `state_mode`, `ta− 3. Do not hand-edit generated policy artifacts: `templates/claude-code/hooks/automem-session-start.sh`, `templates/claude-code/hooks/automem-stop-nudge.sh`, `templates/claude-code/hooks/automem-track-store.sh`, `plugins/automem/scripts/session-start.sh`, `plugins/automem/scripts/stop-nudge.sh`, `plugins/automem/scripts/track-store.sh`, `templates/codex/memory-rules.md`, `templates/cursor/automem.mdc.template`, `templates/CLAUDE_DESKTOP_INSTRUCTIONS.md`, `templates/CLAUDE_MD_MEMORY_RULES.md`, `te− 1. Update version in `package.json`− 2. Update `CHANGELOG.md` with changes− 3. Build: `npm run build`− 4. Test: `npm test`− 5. Publish: `npm publish` (requires npm login)− **Pre-publish checks:**− - `npm run build` succeeds− <!-- automem-template-version: 0.15.0 -->+ Four JSON files are checked with Prettier's `json-stringify` parser instead of its default+ `json` parser, through an `overrides` block in `.prettierrc`: `manifest.json`, `server.json`,+ `.claude-plugin/marketplace.json` and `.release-please-manifest.json`. Release Please rewrites+ all four on a release PR, and each of its JSON updaters ends in `jsonStringify` —+ `JSON.stringify(parsed, replacer, detectIndent(content).indent)` — which puts every array+ element on its own line. The default parser collapses any array that fits `printWidth`, so the+ two tools disagree permanently and `format:check`, which the `test` job runs *before* Build,+ fails the release PR. That cost a hand-fix commit on the 0.16.0 release. `json-stringify`+ prints what `JSON.stringify` prints, which is why `package.json` was never affected — Prettier+ infers that parser for it by default. Keeping these four on it means Prettier still validates+ them and the release PR's diff stays at the version line. Add any new `json`-type `extra-files`+ entry to that `overrides` block as well.+ ### Template version markers+ Every memory-policy artifact carries a `<!-- automem-template-version: x.y.z -->` comment+ (plus `automem-mdc-version` in the Cursor template) that must equal `package.json`'s version.+ Three things keep it that way, and all three are load-bearing:+ - `prebuild` — `scripts/sync-memory-policy.ts` then `scripts/sync-template-versions.mjs` —+ pegs every marker on each `npm run build`.+ - The `test` job's **Verify build leaves no uncommitted changes** step fails CI when building+ dirties the tree. Without it CI masked drift: the job builds before it tests, so `prebuild`+ repaired the markers in the runner and the drift assertion in `tests/cli/smoke.test.ts`+ passed on a tree that was stale in git. The breakage only showed up as a dirty+ `git status` on a developer machine.+ - Release Please rewrites the markers on the release PR it creates. Each marker line ends+ with a trailing Release Please annotation comment, and `release-please-config.json` lists+ all 13 marker-bearing files under `extra-files` with the `generic` updater, so the markers+ move in the same commit as the `package.json` bump. Before that wiring the markers lagged a+ whole release behind (0.16.0 shipped with 0.15.0 markers; #257 fixed it by hand), and the+ CI guard above would have failed every release PR.+ That holds for a release PR Release Please creates or updates — not for one that is+ **already open when a new `extra-files` entry lands**. `maybeUpdateExistingPullRequest` in+ release-please compares the rendered PR body and, when it is byte-identical, logs+ `remained the same` and returns without pushing *any* of the file updates. A `chore:` or+ `docs:` merge adds no changelog line, so the body does not change and the open release PR+ never gains the new paths. That is exactly what happened when #258 merged while #248 was+ open. After adding an `extra-files` entry, check `gh pr view <n> --json files` on any open+ release PR; if the new paths are absent, close it and delete its branch so Release Please+ cuts a fresh one from current main.+ Never hand-edit a marker — change the generator and re-run `npm run build`. A new+ marker-bearing file needs a `generic` `extra-files` entry as well; `tests/cli/smoke.test.ts`
Showing the first 40 of each.
