OpenSymphony Memory

Use this skill when working in a repository that has OpenSymphony memory enabled. Memory is the post-merge record of completed issue work. It is useful context, but current code, tests, and explicit user instructions remain authoritative.

When to Consult Memory

• At kickoff for any nontrivial Linear issue, after reading the issue body and before writing a plan.
• After discovering the likely files, directories, labels, or subsystem areas you may touch.
• During review rework when feedback resembles a prior issue or failure mode.
• Before updating docs or changing subsystem behavior that may already have topic documentation.

Commands

Run the smallest command that answers the question:

opensymphony memory context --issue COE-456
opensymphony memory related --issue COE-456
opensymphony memory related --paths crates/opensymphony-openhands
opensymphony memory related --area openhands-runtime
opensymphony memory search "subscription credential refresh"
opensymphony memory docs --area openhands-runtime
opensymphony memory brief COE-123

Use opensymphony memory status when you need to know whether memory exists, is pending docs sync, or has capture warnings. Use opensymphony memory lint --public-docs before relying on generated public docs in a public repository.

Rules

• Do not create or update issue capsules during ordinary implementation unless the user explicitly asks; normal capture is run-loop infrastructure when memory.auto_capture is enabled.
• Do not archive Linear issues unless the user explicitly asks. Run-loop auto-archive is disabled by default and still requires successful capture.
• Do not rewrite public docs from private memory by hand; use opensymphony memory sync-docs so the managed sections and indexes stay consistent.
• Do not copy full agent transcripts into memory or docs.
• Do not treat retrieved memory as authoritative over current source files, tests, or upstream specs.

Interpretation

Memory output separates source-derived facts from generated synthesis when the capture has enough evidence. Prefer source refs such as Linear issue IDs, PR URLs, and merge SHAs when making audit claims. Merge SHA is an immutable pointer to the merged code state, not an area inference signal. If memory is stale, missing, or warning-heavy, inspect the linked PRs, current docs, and current repository state before depending on it.