@fingerskier/augment 0.5.0 → 0.5.1

package/integrations/codex/SKILL.md

@@ -1,107 +1,107 @@
----
-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.
-
-## 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).
+---
+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.
+
+## 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).

package/integrations/examples/claude-mcp-config.json

@@ -1,17 +1,17 @@
-{
-  "mcpServers": {
-    "augment": {
-      "command": "npm",
-      "args": [
-        "exec",
-        "--prefix",
-        "C:\\Users\\you\\.augment\\npm-exec",
-        "--",
-        "augment-mcp"
-      ],
-      "env": {
-        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
-      }
-    }
-  }
-}
+{
+  "mcpServers": {
+    "augment": {
+      "command": "npm",
+      "args": [
+        "exec",
+        "--prefix",
+        "C:\\Users\\you\\.augment\\npm-exec",
+        "--",
+        "augment-mcp"
+      ],
+      "env": {
+        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
+      }
+    }
+  }
+}

package/integrations/examples/codex-mcp-config.json

@@ -1,17 +1,17 @@
-{
-  "mcpServers": {
-    "augment": {
-      "command": "npm",
-      "args": [
-        "exec",
-        "--prefix",
-        "C:\\Users\\you\\.augment\\npm-exec",
-        "--",
-        "augment-mcp"
-      ],
-      "env": {
-        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
-      }
-    }
-  }
-}
+{
+  "mcpServers": {
+    "augment": {
+      "command": "npm",
+      "args": [
+        "exec",
+        "--prefix",
+        "C:\\Users\\you\\.augment\\npm-exec",
+        "--",
+        "augment-mcp"
+      ],
+      "env": {
+        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
+      }
+    }
+  }
+}

package/integrations/examples/grok-mcp-config.toml

@@ -0,0 +1,18 @@
+# Example Grok Build MCP config fragment.
+# Paste into ~/.grok/config.toml (user) or .grok/config.toml (project),
+# or run: npx -y @fingerskier/augment install grok --scope user --memory-root "..."
+
+[mcp_servers.augment]
+command = "npm"
+args = [
+    "exec",
+    "--prefix",
+    "C:\\Users\\you\\.augment\\npm-exec",
+    "--",
+    "augment-mcp",
+]
+enabled = true
+startup_timeout_sec = 60
+
+[mcp_servers.augment.env]
+AUGMENT_MEMORY_ROOT = "C:\\Users\\you\\Dropbox\\augment-memories"

package/integrations/grok/AGENTS.md

@@ -0,0 +1,61 @@
+# Augment Memory Workflow
+
+When the Augment MCP server is configured, use it as the local project memory.
+
+## Session Start
+
+1. Call `init_project` (via the `augment` MCP tools).
+2. Call `search` with the user's task summary.
+3. Read exact memories when search results identify likely governing context.
+
+## 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.
+
+## 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).

package/integrations/pi/skills/augment-decoction/SKILL.md

@@ -1,37 +1,37 @@
----
-name: augment-decoction
-description: Distill recurring cross-project Augment memory into generic SPEC/ARCH records and optionally remove fully subsumed originals from Pi. Use when the user asks to "decoct", "glean", generalize, or clean up repeated memories across projects.
----
-
-# Augment Decoction for Pi
-
-Decoction extracts durable, project-independent knowledge from recurring
-memories. It is separate from sleep: sleep consolidates settled work within one
-project, while decoction finds patterns across projects and writes them under
-`.generic/`.
-
-1. Call `augment_decoction_glean` with `action: "discover"`. If no cluster
-   spans at least four distinct projects, report that and stop.
-2. Pick a cluster and call `augment_read_memory` for every source. Synthesize
-   one generic record:
-   - use SPEC for a reusable contract or rule;
-   - use ARCH for a reusable decision or tradeoff;
-   - retain only claims supported across the projects;
-   - put every source used in `derived_from`.
-3. Suggest source removal only when the generic preserves the original's entire
-   durable content. Do not suggest a source that also contains project-specific
-   facts, history, caveats, or unresolved work.
-4. Call `augment_decoction_glean` with `action: "write"`, the complete draft,
-   and the reasoned `suggested_removals`. For an existing generic, read it fresh
-   and pass both of its expected hashes.
-5. Report the generic path and any warnings. Warnings are advisory and do not
-   block the write.
-6. Show each suggested cleanup path and reason verbatim. Ask for explicit user
-   approval of the exact paths; never infer approval from approval of the
-   generic itself.
-7. Only after approval, call `augment_decoction_cleanup` with the generic path
-   and the approved source paths. Report every deletion and any failure.
-
-Cleanup hard-deletes the selected originals after retargeting inbound links to
-the generic. It has no journal or rollback. The user may approve a subset or
-decline cleanup entirely.
+---
+name: augment-decoction
+description: Distill recurring cross-project Augment memory into generic SPEC/ARCH records and optionally remove fully subsumed originals from Pi. Use when the user asks to "decoct", "glean", generalize, or clean up repeated memories across projects.
+---
+
+# Augment Decoction for Pi
+
+Decoction extracts durable, project-independent knowledge from recurring
+memories. It is separate from sleep: sleep consolidates settled work within one
+project, while decoction finds patterns across projects and writes them under
+`.generic/`.
+
+1. Call `augment_decoction_glean` with `action: "discover"`. If no cluster
+   spans at least four distinct projects, report that and stop.
+2. Pick a cluster and call `augment_read_memory` for every source. Synthesize
+   one generic record:
+   - use SPEC for a reusable contract or rule;
+   - use ARCH for a reusable decision or tradeoff;
+   - retain only claims supported across the projects;
+   - put every source used in `derived_from`.
+3. Suggest source removal only when the generic preserves the original's entire
+   durable content. Do not suggest a source that also contains project-specific
+   facts, history, caveats, or unresolved work.
+4. Call `augment_decoction_glean` with `action: "write"`, the complete draft,
+   and the reasoned `suggested_removals`. For an existing generic, read it fresh
+   and pass both of its expected hashes.
+5. Report the generic path and any warnings. Warnings are advisory and do not
+   block the write.
+6. Show each suggested cleanup path and reason verbatim. Ask for explicit user
+   approval of the exact paths; never infer approval from approval of the
+   generic itself.
+7. Only after approval, call `augment_decoction_cleanup` with the generic path
+   and the approved source paths. Report every deletion and any failure.
+
+Cleanup hard-deletes the selected originals after retargeting inbound links to
+the generic. It has no journal or rollback. The user may approve a subset or
+decline cleanup entirely.

package/integrations/pi/skills/augment-dream/SKILL.md

@@ -1,36 +1,36 @@
----
-name: augment-dream
-description: Explore globally recalled Augment memories and propose speculative memories or links for explicit user approval. Use when the user asks to "dream" over memory, imagine hypotheses, or surface hidden connections across the current, generic, or foreign projects.
----
-
-# Augment Dream
-
-Dreams are hypotheses, not established facts. Discover and draft freely, but
-never mutate the corpus before the user explicitly approves a named proposal.
-Use a real project as the active project; `.generic` is inspiration or a link
-target only.
-
-1. Call `augment_search` separately for each exploratory query, always passing
-   the active `project_name` and singular `query` argument. Use normal global
-   results as ranked: the current project receives its normal priority, while
-   generic and foreign memories remain eligible. Do not reserve a generic
-   quota or add a generic fallback.
-2. Call `augment_read_memory` with each useful result's numeric memory id, and
-   retain its returned relative path for provenance. Imagine 1-5 coherent
-   candidates:
-   - dream memory: a new record in the active project, with `derived_from`
-     equal to the exact inspiration paths;
-   - dream link: a link from an active-project memory to any current, generic,
-     or foreign memory.
-   Generic-only and foreign-only inspiration are valid.
-3. Call `augment_dream_propose` for each worthwhile candidate. State the
-   speculation plainly in the content and rationale; do not present it as
-   settled truth.
-4. Show each proposal to the user. Only after explicit approval call
-   `augment_dream_apply` with its filename. Call `augment_dream_reject` when
-   the user rejects it. If approval is unclear, leave the proposal pending.
-5. Report the applied speculative memory or link and its `dream:` commit.
-
-Keep evidence and conjecture distinguishable. Do not invent supporting source
-paths, and do not rewrite a foreign memory: foreign projects are inspiration
-and link targets only.
+---
+name: augment-dream
+description: Explore globally recalled Augment memories and propose speculative memories or links for explicit user approval. Use when the user asks to "dream" over memory, imagine hypotheses, or surface hidden connections across the current, generic, or foreign projects.
+---
+
+# Augment Dream
+
+Dreams are hypotheses, not established facts. Discover and draft freely, but
+never mutate the corpus before the user explicitly approves a named proposal.
+Use a real project as the active project; `.generic` is inspiration or a link
+target only.
+
+1. Call `augment_search` separately for each exploratory query, always passing
+   the active `project_name` and singular `query` argument. Use normal global
+   results as ranked: the current project receives its normal priority, while
+   generic and foreign memories remain eligible. Do not reserve a generic
+   quota or add a generic fallback.
+2. Call `augment_read_memory` with each useful result's numeric memory id, and
+   retain its returned relative path for provenance. Imagine 1-5 coherent
+   candidates:
+   - dream memory: a new record in the active project, with `derived_from`
+     equal to the exact inspiration paths;
+   - dream link: a link from an active-project memory to any current, generic,
+     or foreign memory.
+   Generic-only and foreign-only inspiration are valid.
+3. Call `augment_dream_propose` for each worthwhile candidate. State the
+   speculation plainly in the content and rationale; do not present it as
+   settled truth.
+4. Show each proposal to the user. Only after explicit approval call
+   `augment_dream_apply` with its filename. Call `augment_dream_reject` when
+   the user rejects it. If approval is unclear, leave the proposal pending.
+5. Report the applied speculative memory or link and its `dream:` commit.
+
+Keep evidence and conjecture distinguishable. Do not invent supporting source
+paths, and do not rewrite a foreign memory: foreign projects are inspiration
+and link targets only.