@remnic/plugin-codex 1.0.0

package/skills/remnic-recall/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: remnic-recall
+description: Search Remnic memories by natural-language query. Trigger phrases include "what do you remember about", "recall anything on", "have we discussed".
+allowed-tools:
+  - remnic_recall
+---
+
+## When to use
+
+Use when the user or the current task needs prior context from Remnic. This is the default first step for any non-trivial turn that could benefit from memory.
+
+Triggers:
+
+- "What do you remember about …"
+- "Have we talked about …"
+- "Recall anything on …"
+- A new task begins and the agent wants background.
+
+## Inputs
+
+- `query` (required) — natural-language question or topic string.
+- Optional budget hint from the caller (e.g., "brief", "deep").
+
+## Procedure
+
+1. Build a concise natural-language query from the user's request. Prefer the user's own wording over paraphrase.
+2. Call `remnic_recall` with that query. Ask for 3–8 results unless the caller hinted otherwise.
+3. Skim the returned memories. Discard anything clearly off-topic.
+4. Present 1–5 relevant bullet points to the user, each attributed to its source memory when useful.
+5. If nothing relevant came back, say so plainly and suggest `remnic-remember` if there is something worth storing now.
+
+## Efficiency plan
+
+- One broad recall beats several narrow ones.
+- Reuse results within the same turn — do not re-query for the same topic.
+- Skip recall entirely for trivially local requests (formatting, arithmetic, mechanical refactors).
+
+## Pitfalls and fixes
+
+- **Pitfall:** Quoting irrelevant recalls just because they came back. **Fix:** Filter by topical relevance before surfacing.
+- **Pitfall:** Over-narrowing the query and missing useful context. **Fix:** Start broad; refine only if the first pass was noisy.
+- **Pitfall:** Presenting raw memory blobs. **Fix:** Summarize in the user's own terms.
+
+## Verification checklist
+
+- [ ] `remnic_recall` was called with a natural-language query.
+- [ ] Results were filtered for relevance before surfacing.
+- [ ] User-facing summary is concise (≤ 5 bullets unless requested).
+- [ ] Legacy `engram_recall` alias was not preferred over `remnic_recall`.
+
+> Tool names: canonical name is `remnic_recall`. The legacy `engram_recall` alias remains accepted during v1.x.

package/skills/remnic-remember/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: remnic-remember
+description: Store a durable memory in Remnic so every connected agent can recall it. Trigger phrases include "remember this", "save this for later", "add a note that".
+disable-model-invocation: true
+allowed-tools:
+  - remnic_memory_store
+---
+
+## When to use
+
+Use when the user explicitly asks the agent to remember something, or when a turn produces a durable decision, preference, or finding worth storing for later sessions.
+
+Triggers:
+
+- "Remember that …"
+- "Save this for later."
+- "Add a note that …"
+- End-of-turn consolidation after a non-trivial conclusion.
+
+## Inputs
+
+- `content` (required) — the statement to store, in the user's own words where possible.
+- Optional: category hint (preference, decision, fact, procedure).
+- Optional: related entity or project name.
+
+## Procedure
+
+1. Confirm the content is durable — it should still be useful days or weeks from now.
+2. Strip any secrets, credentials, or transient context (current PID, test run timestamps).
+3. Rephrase only if needed for clarity. Keep the user's voice.
+4. Call `remnic_memory_store` with the text as `content`. Include category/entity hints if the tool schema supports them.
+5. Confirm to the user what was stored, in one line.
+6. Mention that the memory is now available across connected agents (Claude Code, Codex, Hermes, OpenClaw).
+
+## Efficiency plan
+
+- Batch closely related facts into a single memory rather than writing many tiny ones.
+- If a prior memory on the same topic already exists, prefer an update-in-place phrasing over a fresh write.
+- Do not store anything that can be re-derived trivially from source code or docs.
+
+## Pitfalls and fixes
+
+- **Pitfall:** Storing transient state like "user is running tests now". **Fix:** Only commit facts that will still matter tomorrow.
+- **Pitfall:** Accidentally including a secret or token. **Fix:** Redact before calling the tool; reject any content that matches known secret patterns.
+- **Pitfall:** Duplicate memories on the same topic. **Fix:** Recall first; prefer update over re-store.
+- **Pitfall:** Vague entries ("user likes clean code"). **Fix:** Be specific — who, what, when, why.
+
+## Verification checklist
+
+- [ ] Content is durable and specific.
+- [ ] No secrets, credentials, or PII were included.
+- [ ] `remnic_memory_store` was called with the final content.
+- [ ] User received a one-line confirmation.
+- [ ] Legacy `engram_memory_store` alias was not preferred over `remnic_memory_store`.
+
+> Tool names: canonical name is `remnic_memory_store`. The legacy `engram_memory_store` alias remains accepted during v1.x.

package/skills/remnic-search/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: remnic-search
+description: Run a deep full-text search across every Remnic memory. Trigger phrases include "search memories for", "find anything about", "deep search".
+allowed-tools:
+  - remnic_lcm_search
+---
+
+## When to use
+
+Use when a natural-language `remnic-recall` did not surface something the user insists exists, or when the task genuinely needs exhaustive coverage rather than a ranked summary.
+
+Triggers:
+
+- "Search memories for …"
+- "Deep search on …"
+- "I know I told you about X, find it."
+- Follow-up after `remnic-recall` returned nothing useful.
+
+## Inputs
+
+- `query` (required) — literal phrase or keyword string; this is full-text, not semantic.
+- Optional: date range, category filter, or entity constraint if the tool supports it.
+
+## Procedure
+
+1. Ask the user (or the calling skill) for the most literal phrase they expect to match.
+2. Call `remnic_lcm_search` with that phrase.
+3. Group results by date or category when the tool returns enough metadata.
+4. Present the top 5–10 matches with dates and short excerpts.
+5. If still nothing, say so plainly and suggest `remnic-remember` if the content should be captured going forward.
+
+## Efficiency plan
+
+- Use the most specific phrase available; literal matches are cheaper than wildcarding.
+- Prefer one targeted search over several broad ones.
+- When recall already worked, do not re-run a deep search for the same topic in the same turn.
+
+## Pitfalls and fixes
+
+- **Pitfall:** Using `remnic_lcm_search` as the default. **Fix:** Start with `remnic_recall`; escalate to search only when recall fails.
+- **Pitfall:** Pasting huge result dumps. **Fix:** Show the top matches with excerpts, not the raw payloads.
+- **Pitfall:** Over-broad queries like "notes". **Fix:** Require at least one distinctive keyword.
+
+## Verification checklist
+
+- [ ] `remnic_lcm_search` was called only after recall fell short or the task required exhaustive matching.
+- [ ] Results were grouped by relevance/date when possible.
+- [ ] User-facing output shows excerpts, not raw blobs.
+- [ ] Legacy `engram_lcm_search` alias was not preferred over `remnic_lcm_search`.
+
+> Tool names: canonical name is `remnic_lcm_search`. The legacy `engram_lcm_search` alias remains accepted during v1.x.

package/skills/remnic-status/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: remnic-status
+description: Check the health of the Remnic daemon, stores, and connected clients. Trigger phrases include "is remnic running", "check memory status", "daemon health".
+---
+
+## When to use
+
+Use when the user asks whether Remnic is running, when recall or store calls start failing, or when diagnosing cross-agent memory issues.
+
+Triggers:
+
+- "Is Remnic running?"
+- "Check memory status."
+- "Is the daemon up?"
+- Recall/store tools returned connection errors in this turn.
+
+## Inputs
+
+- Optional: specific component to check (daemon, HTTP server, MCP server, store backend).
+
+## Procedure
+
+1. Check the Remnic health endpoint via the MCP bridge or by running `remnic daemon status` in a shell.
+2. Report, in a compact block:
+   - Daemon running state (PID if known).
+   - Listening port(s).
+   - Memory store path.
+   - Connected clients or plugins, if the health payload exposes them.
+3. If the daemon is not running, suggest `remnic daemon start`. Mention the log path for deeper debugging.
+4. If recall/store tools were erroring earlier in the turn, correlate the health state with those errors in one sentence.
+
+## Efficiency plan
+
+- One health call per turn is enough; do not poll.
+- Skip the check for trivially local tasks.
+- Reuse the health payload for downstream troubleshooting within the same turn.
+
+## Pitfalls and fixes
+
+- **Pitfall:** Running `remnic daemon status` on a host where the daemon lives in a container. **Fix:** Prefer the MCP health endpoint, or run the CLI inside the container.
+- **Pitfall:** Reporting "down" based on a single failed tool call. **Fix:** Confirm with the health endpoint before claiming an outage.
+- **Pitfall:** Forgetting the log path. **Fix:** Always include a pointer to logs when reporting a failure.
+
+## Verification checklist
+
+- [ ] Health was checked via the endpoint or CLI, not guessed.
+- [ ] Daemon state, port, store path, and clients were reported concisely.
+- [ ] If unhealthy, the user was given a concrete next step.
+- [ ] No legacy `engram daemon` wording was preferred over `remnic daemon` where the CLI has been renamed.
+
+> CLI names: canonical CLI is `remnic daemon`. The legacy `engram daemon` invocation remains accepted during v1.x.