## Five fictional lab stories

Adapt these prompts to non\-sensitive facts in your own work\. They are requests to the agent\, not slash commands\. The stories illustrate checks to perform\, not observed runtime results\.

### 1\. Save a preference deliberately

**Fictional situation\:** Cedar’s maintainer keeps asking for a small testable change before a wider refactor\.

Ask OMP\:

~~~text
Use retain to remember this project preference: explain the smallest testable change before proposing a wider refactor. Then use recall to find it and show its exact ID.
~~~

`retain` requests a save immediately\; it does not wait for the four\-turn batch\. A preference saved here is project\-scoped\, not automatically universal\.

**Check\:** recall returns the intended preference and an ID\. Try again in a fresh session from the same directory\.

**Pitfall\:** the retain acknowledgement counts requested items\. It alone is not proof of a successful write\.

### 2\. Resume the reason\, not just the task

**Fictional situation\:** a new session starts after Cedar’s queue\-design discussion\. You remember the decision\, but not its constraints\.

Ask OMP\:

~~~text
Use recall to find Cedar's durable job-queue decision, rejected alternatives and migration constraints. Show the returned IDs. Separate saved evidence from assumptions before proposing next steps.
~~~

The first prompt can trigger automatic recall\. Ask for on\-demand `recall` later when the topic changes\.

**Check\:** look for the decision’s rationale\, source and date—not merely a confident summary\.

**Pitfall\:** “No relevant memories found” does not mean the entire store is empty\. Try specific project and decision terms\.

### 3\. Connect related lessons

**Fictional situation\:** Cedar has several retry and timeout decisions\. You want the pattern\, including disagreements\.

Ask OMP\:

~~~text
Use reflect to examine Cedar's retry and timeout decisions. Compare their tradeoffs; distinguish agreement, conflict and missing evidence. Use recall for IDs when checking a source.
~~~

Here\, `reflect` retrieves and formats scoped memories for the agent to synthesize\. It is not a separate guaranteed reasoning service or an exhaustive database audit\.

**Check\:** the answer distinguishes retrieved evidence from the agent’s interpretation\.

**Pitfall\:** a fluent synthesis can still omit relevant memories\. The recall limit still applies\.

### 4\. Correct the row\, not the preview

**Fictional situation\:** Cedar’s agreed retry limit changed from three to five\. An old memory still says three\.

Begin with inspection\, without editing\:

~~~text
Recall Cedar's retry-limit decision and show exact IDs. Read each candidate's memory:// address in full, including its bank and store. Do not edit yet. Identify the row that says three retries.
~~~

Ask OMP to read `memory://` followed by an **exact returned ID**\. That is OMP’s internal resource address\, not an HTTP endpoint on this website\. It reveals full content and metadata\; a recall preview can be clipped\.

After selecting the working\-store row\, ask\:

~~~text
Use memory_edit update on the exact working-store ID we just selected. Replace only the three-retry rule with five retries, preserving the rest of its full content. Read back that same ID, then recall the topic again.
~~~

Store rules in this snapshot\:

- `update` and `forget` operate on working rows\. To remove an unwanted row\, ask OMP to forget the exact selected ID\.
- `invalidate` supports working or episodic rows\. Ask OMP to invalidate the selected ID\, optionally linking a verified replacement ID\.
- Extracted `fact` projections are read\-only\: expect `not_editable`\, not an edit\.

**Check\:** inspect the operation’s returned status\, bank and store\. Verify the full row and related recall results afterward\.

**Pitfall\:** an update replaces content wholesale\. Never reconstruct it from a clipped preview\. Episodic update\/forget can report `not_found`\; stale copies may remain elsewhere\. Forgetting one eligible row is not universal erasure\.

### 5\. Turn a verified fix into a technique

**Fictional situation\:** a duplicate\-delivery test failed before Cedar’s fix and passed afterward\. Now there is a lesson worth keeping\.

Ask OMP\:

~~~text
We verified Cedar's duplicate-delivery fix with a failing test before the fix and a passing rerun afterward. Use learn to capture the cause, fix, limits and verification. If the steps generalize, also create a managed skill named webhook-replay-check with prerequisites, steps and failure checks. Exclude credentials.
~~~

`learn` stores a lesson and can also write a skill\. `manage_skill` creates\, updates or deletes managed skills separately\. Generated files live in the `managed-skills` directory under OMP’s agent configuration directory\, separate from authored `skills`\; authored names take precedence\.

**Check\:** recall the lesson and inspect `managed-skills/webhook-replay-check/SKILL.md` under that configuration directory\. If discovery lags\, start a fresh session\.

**Pitfall\:** verify your own technique first\. Skill creation can fail after the lesson is saved\; check both outcomes\. The example’s claimed before\/after test evidence is fictional\, not evidence for your project\.