opencode-omni-memory-plugin 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,230 @@
1
+ ---
2
+ name: omni-memory
3
+ description: Automatically retrieves and maintains native Markdown memory, project specifications, roadmaps, progress, findings, decisions, and session handoffs. Use when starting work in a repository, resuming after a break or compaction, before implementation or planning, when the user references earlier work or preferences, and whenever the user asks to remember, recall, forget, audit memory, initialize project state, inspect status, or hand off work.
4
+ ---
5
+
6
+ # Omni Memory
7
+
8
+ Maintain durable knowledge and resumable project state without an external memory service. Keep stable memory separate from mutable project control documents and temporary session journals.
9
+
10
+ ## Storage model
11
+
12
+ ### Global scope
13
+
14
+ - `~/.config/opencode/memory/GLOBAL.md` — durable cross-project preferences and conventions; loaded automatically.
15
+ - `~/.config/opencode/memory/HANDOFF.md` — cross-project continuation state; retrieve only for configuration or multi-project work.
16
+ - `~/.config/opencode/memory/hosts/<hostname>.md` — machine-specific facts; retrieve only when the task depends on the host environment.
17
+ - `~/.config/opencode/memory/archive/` — inactive global detail; search on demand.
18
+
19
+ ### Project scope
20
+
21
+ Use the Git worktree root as `<project-root>`. Outside Git, use the directory from which OpenCode was launched.
22
+
23
+ - `<project-root>/.opencode/project/MEMORY.md` — durable project facts; loaded automatically.
24
+ - `<project-root>/.opencode/project/HANDOFF.md` — concise branch/session continuation delta; loaded automatically.
25
+ - `<project-root>/.opencode/project/INDEX.md` — artifact map and relationship to existing documentation.
26
+ - `<project-root>/.opencode/project/CHARTER.md` — protected goals, constraints, non-goals, and success definition.
27
+ - `<project-root>/.opencode/project/SPEC.md` — agent-maintained working specification.
28
+ - `<project-root>/.opencode/project/ROADMAP.md` — milestones and sequencing.
29
+ - `<project-root>/.opencode/project/PROGRESS.md` — current whole-project snapshot.
30
+ - `<project-root>/.opencode/project/FINDINGS.md` — hypotheses and verified discoveries.
31
+ - `<project-root>/.opencode/project/DECISIONS.md` — material decisions and supersession history.
32
+ - `<project-root>/.opencode/project/sessions/` — temporary journals for concurrent sessions.
33
+ - `<project-root>/.opencode/project/archive/<milestone>/` — completed detail archived by milestone.
34
+
35
+ Templates are bundled under `templates/project/`. Most templates map to a single file of the same name. The two directory-backed templates instantiate under a path rather than at the root: `SESSION.md` seeds each journal at `sessions/YYYY-MM-DD-HHMM-<agent>-<topic>.md`, and `ARCHIVE.md` seeds each milestone summary at `archive/<milestone>/`. Do not overwrite an existing artifact when initializing or expanding project state.
36
+
37
+ `MEMORY.md` and `HANDOFF.md` load automatically only because the host `opencode.json` `instructions` array injects `~/.config/opencode/memory/GLOBAL.md`, `.opencode/project/MEMORY.md`, and `.opencode/project/HANDOFF.md`. If those paths or filenames change in one place, update the other; nothing else auto-loads. The companion `omni-memory` plugin additionally injects a compact orientation bootstrap into the first user message of each session and defends memory/handoff pointers during compaction; treat its bootstrap as already-loaded guidance, not as a reason to reload this skill.
38
+
39
+ ## Silent session orientation
40
+
41
+ Substantive project work is any task that may read, change, or produce durable project state: implementation, debugging, refactoring, planning, review, or a memory command. Skip orientation entirely for pure question-answering, trivial single-file edits with no durable outcome, and scratch work outside a project root; do minimal targeted retrieval instead. Match orientation depth to task risk rather than running the full sequence for small local edits.
42
+
43
+ At the beginning of substantive project work:
44
+
45
+ 1. Determine the project root. If Git is available, determine the current branch, commit, worktree, and dirty state.
46
+ 2. Use the automatically loaded global memory, project memory, and handoff without announcing routine retrieval.
47
+ 3. Read `INDEX.md` and `CHARTER.md` when present.
48
+ 4. Retrieve only task-relevant portions of the spec, roadmap, progress, findings, decisions, archives, existing project docs, and session journals.
49
+ 5. Compare the handoff with current repository state. Current verified state overrides stale handoff details.
50
+ 6. Mention orientation only when a conflict, stale assumption, concurrent session, missing prerequisite, or blocker changes how work should proceed.
51
+
52
+ For cross-project or OpenCode-configuration work, also retrieve global `HANDOFF.md`. For machine-sensitive work, determine the hostname and retrieve the matching host file if present.
53
+
54
+ ## Retrieval strategy
55
+
56
+ Keep the automatically injected global memory, project memory, and project handoff to roughly 2–4K tokens combined. Search detailed active files and archives on demand rather than injecting them all.
57
+
58
+ Before consequential use of a source-sensitive memory, verify it against its cited source. Low-risk user preferences may be trusted until contradicted.
59
+
60
+ When intended behavior conflicts, use this precedence:
61
+
62
+ 1. Current explicit user instruction
63
+ 2. Protected project charter
64
+ 3. Explicit contracts, schemas, and accepted contract tests
65
+ 4. Agent working specification
66
+ 5. Existing or legacy project documentation
67
+ 6. Current implementation behavior
68
+
69
+ Current code is evidence of what exists, not automatic proof of what should exist. Record material conflict resolutions in `DECISIONS.md`.
70
+
71
+ ## Meaningful-transition updates
72
+
73
+ Update persistent state after a material transition, not after every edit or user turn.
74
+
75
+ Transitions include:
76
+
77
+ - A material decision or working-specification change
78
+ - A milestone becoming active, blocked, completed, or superseded
79
+ - A new blocker or major change in next actions
80
+ - A finding becoming verified, rejected, or promoted
81
+ - Verification materially changing confidence or completion status
82
+ - An explicit remember, forget, correction, audit, status, or handoff request
83
+ - An explicit user correction of agent behavior, or a second occurrence of the same failure, workaround, or misrouting (capture the lesson once, consolidated, in the narrowest correct scope)
84
+
85
+ Map transitions to artifacts:
86
+
87
+ - Decision → `DECISIONS.md`, and update spec or roadmap if affected
88
+ - Requirement or acceptance change → `SPEC.md`, with a decision entry when material
89
+ - Milestone change → `ROADMAP.md` and `PROGRESS.md`
90
+ - Current execution-state change → `PROGRESS.md`
91
+ - Discovery → `FINDINGS.md`; promote verified durable conclusions when appropriate
92
+ - Continuation change → `HANDOFF.md`
93
+ - Durable reusable fact → project or global memory
94
+
95
+ Reread each target file immediately before editing it. Consolidate instead of blindly appending. Do not write state when nothing material changed.
96
+
97
+ ## Durable-memory retention
98
+
99
+ Good memory candidates:
100
+
101
+ - Explicit cross-project user preferences
102
+ - Stable environment or host facts
103
+ - Confirmed architecture and dependency constraints
104
+ - Stable conventions not obvious from standard tooling
105
+ - Canonical build, test, release, migration, or recovery commands
106
+ - Non-obvious recurring pitfalls and verified resolutions
107
+ - Corrections to existing memory
108
+
109
+ Do not retain:
110
+
111
+ - Secrets, tokens, credentials, private keys, or sensitive personal data
112
+ - Raw logs, full transcripts, large command outputs, or source-code copies
113
+ - Temporary status, one-off failures, speculative ideas, or unverified assumptions
114
+ - Sensitive exploit detail in committed project state; store only sanitized conclusions and remediation references
115
+ - Facts easily rediscovered from a canonical source unless the memory captures a non-obvious implication
116
+
117
+ Choose scope conservatively:
118
+
119
+ - Global memory only for facts intended to follow the user across repositories.
120
+ - Host memory for machine-specific facts that may differ across systems.
121
+ - Project memory for repository-derived architecture, commands, conventions, and pitfalls.
122
+ - Global handoff only for configuration or work spanning multiple projects.
123
+
124
+ Use compact bullets. Add `Source: <path or decision>; verified YYYY-MM-DD` only where provenance or staleness matters, and obtain the real current date (for example via `date +%F`) rather than guessing it. Rewrite or remove superseded claims. Keep active memory concise; archive inactive detail.
125
+
126
+ Promote rules out of memory: when an entry is really a standing behavior rule (routing, delegation, tooling, verification), its durable home is the governing configuration — the matching `AGENTS.md` section, agent definition, skill, or command. Encode it there and shrink the memory entry to a one-line pointer. Memory stages lessons; configuration is the rulebook.
127
+
128
+ Only the primary agent writes memory or project-state artifacts. Subagents never edit `memory/` or `.opencode/project/`; they return candidate lessons, decisions, and findings in their reports, and the primary agent persists what survives these retention rules. When delegating, do not instruct subagents to update memory.
129
+
130
+ ## Project artifact contract
131
+
132
+ ### Charter
133
+
134
+ The charter is protected. The agent may clarify wording that preserves meaning, but may change goals, hard constraints, non-goals, or success criteria only after explicit user direction.
135
+
136
+ ### Working specification
137
+
138
+ The agent may autonomously evolve `SPEC.md` within the charter. Important requirements use stable IDs such as `REQ-001` and include status, acceptance criteria, and implementation or verification evidence.
139
+
140
+ Existing project documentation and the working specification are independent documents with distinct roles, not synchronized copies. `INDEX.md` must identify relevant existing docs and explain their relationship. Resolve disagreements according to the precedence rules and record material choices.
141
+
142
+ ### Roadmap and progress
143
+
144
+ Roadmap milestones use stable IDs such as `M1` and link to requirements. `PROGRESS.md` is a rewritten current snapshot of completed, active, blocked, and next work; it is not an append-only activity journal.
145
+
146
+ ### Findings
147
+
148
+ Findings use stable IDs such as `FND-001` and move through:
149
+
150
+ `hypothesis → verified → promoted`
151
+
152
+ A hypothesis may instead become `rejected`. Record evidence, impact, and destination when promoted into memory, spec, roadmap, or a decision.
153
+
154
+ ### Decisions
155
+
156
+ Material decisions use stable IDs such as `DEC-001` and record rationale, evidence, consequences, affected requirements, and any superseded decision. Keep the decision ledger live rather than deleting history, but bound its active size: keep active decisions in full, and when a decision is superseded compress it to a one-line stub that records its ID, outcome, superseding ID, and date, then move its full rationale detail to `archive/<milestone>/`. The stub preserves the supersession trail while keeping the active file within budget.
157
+
158
+ ## Lazy project initialization
159
+
160
+ Do not create project state merely because a repository was opened. On the first durable project fact, or when `/project-init` is requested:
161
+
162
+ 1. Create `.opencode/project/` if needed.
163
+ 2. Create the minimal `INDEX.md`, `MEMORY.md`, and `HANDOFF.md` from templates.
164
+ 3. Add `.opencode/project/sessions/` to the project `.gitignore` because session journals are temporary concurrency state.
165
+ 4. Create charter, spec, roadmap, progress, findings, and decisions only when the project needs them, unless full initialization is explicitly requested.
166
+ 5. If legacy `.opencode/memory/PROJECT.md` exists, merge unique durable facts into the new `MEMORY.md`; do not discard unmatched content.
167
+
168
+ In a non-Git directory, treat the launch directory as the project root. Branch, commit, and Git-history fields then remain unavailable.
169
+
170
+ ## Branches and concurrent sessions
171
+
172
+ Use the same canonical artifact paths on every branch. Git branches and worktrees naturally carry branch-specific versions of `HANDOFF.md` and operational state. Include the current branch and commit in each handoff.
173
+
174
+ When multiple sessions may write the same branch:
175
+
176
+ 1. Create a temporary journal using `sessions/YYYY-MM-DD-HHMM-<agent>-<topic>.md`.
177
+ 2. Write session-local observations there until canonical reconciliation is safe.
178
+ 3. Before canonical edits, reread current files and other active journals.
179
+ 4. During handoff, merge relevant journal content into canonical artifacts.
180
+ 5. Delete only journals whose useful content was fully reconciled. Never delete another active session's journal merely because it exists.
181
+
182
+ Temporary journals are intentionally not committed. All canonical project state is eligible to join the user's normal Git commit. Never create a Git commit automatically.
183
+
184
+ ## Handoff procedure
185
+
186
+ Maintain `HANDOFF.md` as a continuation delta at meaningful transitions. It must not duplicate the whole progress document.
187
+
188
+ An explicit `/handoff` performs full reconciliation:
189
+
190
+ 1. Inspect branch, commit, dirty files, current task state, and active session journals.
191
+ 2. Reconcile memory, decisions, spec, roadmap, progress, and findings.
192
+ 3. Run only verification that is already required or reasonably necessary to make the handoff truthful; do not invent expensive checks solely for ceremony.
193
+ 4. Rewrite `HANDOFF.md` with:
194
+ - Updated time, branch, commit, and session focus
195
+ - Current objective
196
+ - Completed work
197
+ - Uncommitted or partial changes
198
+ - Material decisions and findings
199
+ - Checks run and their results
200
+ - Blockers and risks
201
+ - Exact next actions
202
+ 5. Reconcile and remove completed session journals.
203
+ 6. Do not commit.
204
+
205
+ If a session ends abruptly, the most recent meaningful-transition updates are the best-effort checkpoint. Skill-only memory cannot guarantee a final session-close hook. The companion plugin's compaction hook mitigates the compaction case by instructing the summarizer to carry forward memory pointers and un-persisted decisions, findings, and blockers — but it cannot write files itself; persist state at transitions rather than relying on it.
206
+
207
+ ## Milestone archival
208
+
209
+ At milestone completion, keep active files compact by moving completed roadmap detail, resolved findings, old progress snapshots, and milestone handoffs into `archive/<milestone>/`. Keep concise active summaries. Retain `DECISIONS.md` as the live supersession ledger, but compress superseded entries to stubs and archive their full detail as above. Git history remains the complete revision trail.
210
+
211
+ ## Recall, correction, forgetting, and audit
212
+
213
+ - Recall only task-relevant memory and clearly distinguish verified state from remembered context.
214
+ - Correct stale memory in place rather than preserving contradictory active claims.
215
+ - On forget requests, remove direct matches from active memory and relevant archives without deleting unrelated content.
216
+ - A memory audit checks scope, duplication, provenance, staleness, conflicts, sensitive content, active-size budget, and promotion of verified findings.
217
+
218
+ ## Commands and natural language
219
+
220
+ Support both ordinary language and these commands:
221
+
222
+ - `/project-init [full]`
223
+ - `/remember [global|host|project] <fact>`
224
+ - `/recall <query>`
225
+ - `/forget <query>`
226
+ - `/handoff`
227
+ - `/project-status`
228
+ - `/memory-audit [global|project|all]`
229
+
230
+ After automatic state writes, summarize them in one concise final-response line. Do not interrupt work to announce routine retrieval or every checkpoint.
@@ -0,0 +1,12 @@
1
+ # Milestone Archive
2
+
3
+ - Milestone:
4
+ - Archived:
5
+
6
+ ## Completed Roadmap Detail
7
+
8
+ ## Resolved Findings
9
+
10
+ ## Progress Snapshot
11
+
12
+ ## Milestone Handoff
@@ -0,0 +1,11 @@
1
+ # Project Charter
2
+
3
+ Protected intent. Change goals, hard constraints, non-goals, or success criteria only after explicit user direction.
4
+
5
+ ## Objective
6
+
7
+ ## Hard Constraints
8
+
9
+ ## Non-Goals
10
+
11
+ ## Success Criteria
@@ -0,0 +1,19 @@
1
+ # Project Decisions
2
+
3
+ ## Active Decisions
4
+
5
+ ### DEC-001 — Title
6
+
7
+ - Status: active
8
+ - Decision:
9
+ - Rationale:
10
+ - Evidence:
11
+ - Consequences:
12
+ - Affected requirements:
13
+ - Supersedes:
14
+
15
+ ## Superseded (stubs)
16
+
17
+ Compressed entries; full rationale lives in `archive/<milestone>/`.
18
+
19
+ - DEC-000 — superseded by DEC-000, YYYY-MM-DD
@@ -0,0 +1,12 @@
1
+ # Project Findings
2
+
3
+ ## Active Findings
4
+
5
+ ### FND-001 — Title
6
+
7
+ - Status: hypothesis
8
+ - Evidence:
9
+ - Impact:
10
+ - Promotion target:
11
+
12
+ ## Rejected Findings
@@ -0,0 +1,20 @@
1
+ # Project Handoff
2
+
3
+ - Updated:
4
+ - Branch:
5
+ - Commit:
6
+ - Session focus:
7
+
8
+ ## Current Objective
9
+
10
+ ## Completed
11
+
12
+ ## Current Changes
13
+
14
+ ## Decisions and Findings
15
+
16
+ ## Verification
17
+
18
+ ## Blockers and Risks
19
+
20
+ ## Exact Next Actions
@@ -0,0 +1,25 @@
1
+ # Project State Index
2
+
3
+ ## Project
4
+
5
+ - Root:
6
+ - Repository:
7
+
8
+ ## Agent State
9
+
10
+ - `MEMORY.md` — durable project facts
11
+ - `HANDOFF.md` — continuation delta for the current branch
12
+ - `CHARTER.md` — protected intent and constraints, when present
13
+ - `SPEC.md` — agent working specification, when present
14
+ - `ROADMAP.md` — milestone sequence, when present
15
+ - `PROGRESS.md` — current whole-project snapshot, when present
16
+ - `FINDINGS.md` — hypotheses and verified discoveries, when present
17
+ - `DECISIONS.md` — material choices and supersession ledger, when present
18
+
19
+ ## Existing Project Documentation
20
+
21
+ List existing specifications, roadmaps, ADRs, and other references here. Explain their role relative to the agent working specification; do not claim they are synchronized copies.
22
+
23
+ ## Archives
24
+
25
+ Completed milestone detail lives under `archive/<milestone>/`.
@@ -0,0 +1,13 @@
1
+ # Project Memory
2
+
3
+ Durable, verified project knowledge that remains useful across sessions.
4
+
5
+ ## Architecture and Constraints
6
+
7
+ ## Conventions
8
+
9
+ ## Important Commands
10
+
11
+ ## Recurring Pitfalls
12
+
13
+ ## Verified Lessons
@@ -0,0 +1,14 @@
1
+ # Project Progress
2
+
3
+ - Updated:
4
+ - Current milestone:
5
+
6
+ ## Completed
7
+
8
+ ## Active
9
+
10
+ ## Blocked
11
+
12
+ ## Next
13
+
14
+ ## Verification State
@@ -0,0 +1,12 @@
1
+ # Project Roadmap
2
+
3
+ ## Milestones
4
+
5
+ ### M1 — Title
6
+
7
+ - Status: planned
8
+ - Requirements:
9
+ - Dependencies:
10
+ - Completion evidence:
11
+
12
+ ## Current Sequence
@@ -0,0 +1,19 @@
1
+ # Session Journal
2
+
3
+ - Started:
4
+ - Agent:
5
+ - Branch:
6
+ - Commit:
7
+ - Topic:
8
+
9
+ ## Objective
10
+
11
+ ## Observations
12
+
13
+ ## Changes
14
+
15
+ ## Decisions and Findings
16
+
17
+ ## Reconciliation Status
18
+
19
+ - Status: active
@@ -0,0 +1,14 @@
1
+ # Working Specification
2
+
3
+ Agent-maintained implementation specification constrained by `CHARTER.md`.
4
+
5
+ ## Requirements
6
+
7
+ ### REQ-001 — Title
8
+
9
+ - Status: proposed
10
+ - Acceptance criteria:
11
+ - Implementation evidence:
12
+ - Verification evidence:
13
+
14
+ ## Open Questions
@@ -0,0 +1,10 @@
1
+ <!-- opencode-omni-memory-plugin:start -->
2
+ ## Persistent Markdown memory (omni-memory)
3
+
4
+ - Global active memory lives at `~/.config/opencode/memory/GLOBAL.md`. Cross-project handoff lives at `~/.config/opencode/memory/HANDOFF.md`, and host-specific facts live under `~/.config/opencode/memory/hosts/`.
5
+ - Project memory and continuation state live under `<project-root>/.opencode/project/`. `MEMORY.md` and `HANDOFF.md` are loaded automatically when present; detailed charter, spec, roadmap, progress, findings, decisions, sessions, and archives are retrieved on demand.
6
+ - For every substantive task, load the `omni-memory` skill at orientation, use relevant memory silently, and follow its precedence, retention, transition-update, concurrency, and handoff rules. The companion plugin injects a session bootstrap; treat it as already-loaded guidance rather than a reason to skip or re-load the skill.
7
+ - At meaningful decisions, milestone changes, blockers, verification results, or major next-action changes, update the appropriate project-state artifacts. At task completion, perform the skill's conservative durable-memory check.
8
+ - Default repository-derived facts to project memory. Use global memory only for explicitly cross-project preferences, use host memory for machine-specific facts, and use global handoff only for work spanning projects or OpenCode configuration.
9
+ - Do not create or update memory when nothing durable was learned. Never retain secrets, credentials, raw logs, full transcripts, temporary status, sensitive exploit detail, or unverified assumptions.
10
+ <!-- opencode-omni-memory-plugin:end -->