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.
- package/LICENSE +21 -0
- package/README.md +285 -0
- package/VERSION +1 -0
- package/bin/cli.js +37 -0
- package/commands/forget.md +7 -0
- package/commands/handoff.md +9 -0
- package/commands/memory-audit.md +7 -0
- package/commands/project-init.md +9 -0
- package/commands/project-status.md +9 -0
- package/commands/recall.md +7 -0
- package/commands/remember.md +7 -0
- package/defaults/memory/GLOBAL.md +15 -0
- package/defaults/memory/HANDOFF.md +18 -0
- package/defaults/memory/HOST.md +11 -0
- package/defaults/memory/archive/README.md +3 -0
- package/install.sh +451 -0
- package/manifest.txt +9 -0
- package/package.json +49 -0
- package/plugins/omni-memory.js +70 -0
- package/skills/omni-memory/SKILL.md +230 -0
- package/skills/omni-memory/templates/project/ARCHIVE.md +12 -0
- package/skills/omni-memory/templates/project/CHARTER.md +11 -0
- package/skills/omni-memory/templates/project/DECISIONS.md +19 -0
- package/skills/omni-memory/templates/project/FINDINGS.md +12 -0
- package/skills/omni-memory/templates/project/HANDOFF.md +20 -0
- package/skills/omni-memory/templates/project/INDEX.md +25 -0
- package/skills/omni-memory/templates/project/MEMORY.md +13 -0
- package/skills/omni-memory/templates/project/PROGRESS.md +14 -0
- package/skills/omni-memory/templates/project/ROADMAP.md +12 -0
- package/skills/omni-memory/templates/project/SESSION.md +19 -0
- package/skills/omni-memory/templates/project/SPEC.md +14 -0
- package/snippets/AGENTS.md +10 -0
|
@@ -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,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,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,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 -->
|