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:

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:

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:

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:

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:

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:

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.