feat(skills): add project memory workflow

[LanternCX]

What problem are you trying to solve?

Superpowers currently has no core workflow for preserving and reusing durable project memory across sessions.

Closes #551

That shows up in two ways:

• new sessions do not have a structured way to retrieve small, relevant pieces of prior project history before continuing design or implementation work
• completed work leaves behind commits and code, but not a durable memory workflow for preserving why a decision mattered or what future sessions should keep consistent

Superpowers needs a general-purpose memory system. This PR is one concrete solution to that problem.

What does this PR change?

This PR introduces one concrete memory workflow in core Superpowers:

• adds using-memory for incremental retrieval of relevant project history
• adds record-memory for recording closed, reviewable change units as durable memory
• updates README and verification integration to reflect the new memory workflow

It also replaces the older memory-tracker naming and updates the shipped memory type templates so retrieval and recording use separate routing fields.

The core design is:

• one skill for retrieval (using-memory)
• one skill for recording (record-memory)
• one repository-owned memory layout under docs/superpowers/memory/

The resulting directory structure is:

docs/superpowers/memory/
  <type>/
    MEMORY.md
    INDEX.md
    ENTRY.md
    entries/
      YYYY-MM/
        YYYY-MM-DD-N.md

This PR also includes the context-engineering rules needed to keep retrieval cheap and predictable:

• MEMORY.md is the type-definition layer
• INDEX.md is an index-only lookup layer
• entry files are evidence, not discovery metadata
• retrieval follows progressive disclosure instead of broad reads

In practice, using-memory is designed to:

1. scan docs/superpowers/memory/*/MEMORY.md
2. grep only Use When / Avoid When
3. read only small windows around those fields
4. choose candidate types before touching INDEX.md
5. inspect only the smallest useful number of entries
6. stop once the task has enough history to move forward

record-memory follows the complementary write path:

1. confirm the work is one closed, reviewable change unit
2. scan type-local MEMORY.md files
3. route with Record When / Avoid Recording When
4. write a single durable entry and update only that type's INDEX.md

Is this change appropriate for the core library?

Yes.

This is general workflow infrastructure for multi-session agentic development. It is not tied to one domain, one repository layout outside Superpowers' own docs area, or any third-party tool or service. The same need appears in feature work, debugging, refactoring, and long-running design iteration.

What alternatives did you consider?

I considered three broader alternatives before landing on this implementation:

1. using spec and plan documents as the memory system
2. using git commits as the memory system
3. relying on always-loaded markdown files such as AGENTS.md or CLAUDE.md instead of introducing a dedicated workflow

I rejected them because they either make retrieval too expensive, fail to preserve reusable project history in a disciplined form, or cause context rot by mixing historical memory into always-loaded instruction files. This PR's memory workflow is intended to complement existing artifacts, not replace them.

Does this PR contain multiple unrelated changes?

No.

The changes are related parts of one memory-workflow refactor:

• retrieval skill
• recording skill
• type routing/template updates needed to support both
• minimal README / verification updates needed to integrate them coherently

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: feat(skills): add progress bootstrap and tracker for .progress memory #555

#555 explored the same general problem space. This PR narrows the solution to a memory workflow split between retrieval and recording.

Environment tested

Harness (e.g. Claude Code, Cursor)	Harness version	Model	Model version/ID
OpenCode	current local CLI	gpt-5.4	openai/gpt-5.4

Evaluation

• Initial prompt: design a memory-oriented workflow that supports both recording and retrieval while keeping context use small
• Evaluation so far: I have tried parts of this workflow in a few of my own projects, but not with broad or deep usage yet
• Before: the proposal centered on a single progress-style skill and did not clearly teach agents how to retrieve prior memory with minimal context
• After: the workflow is split into retrieval and recording, retrieval now follows a clear incremental path, and the memory type protocol distinguishes lookup routing from recording routing

This PR is intended as a draft. I have tried this workflow in a few of my own projects, but not with broad or deep enough usage to treat the current shape as fully proven.

Rigor

• If this is a skills change: I used superpowers:writing-skills and completed adversarial pressure testing (paste results below)
• This change was tested adversarially, not just on the happy path
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals showing the change is an improvement

Adversarial / review results used during development:

• checked whether retrieval and recording were being incorrectly injected at the same lifecycle point
• checked whether using-memory could be discovered with a minimal description instead of broader workflow injection
• checked whether retrieval was truly incremental instead of degenerating into whole-file reads
• checked whether default memory types were hardcoded into runtime routing instead of discovered from type-local files
• checked whether the new skills matched repository naming and writing style closely enough to feel native

Human review

• A human has reviewed the COMPLETE proposed diff before submission