Memory skill

Memory Skill

Use memory as a working continuation system, not as a chat scrapbook.

Core goal

Do five things well:

1. find the right memory quickly
2. avoid mixing contexts
3. continue work instead of merely recalling it
4. keep project detail inside project assets
5. write back only when a new stable pointer or conclusion has actually formed

Core routing model

Before doing anything else, classify memory along these four axes.

1) Permission layers (P)

• P1 Private - private personal context; do not expose by default
• P2 Internal - internal analysis, drafts, unannounced work
• P3 Public - confirmed wording safe to repeat to team/public work contexts
• P4 Meta - reusable methods, norms, patterns, and experience

2) Domains (D)

• D1 Formal-work - employed work, formal collaboration, requirements, versions, Q&A
• D2 Personal-projects - personal projects, content creation, private experiments
• D3 Tooling - assistant configuration, workflows, and operating rules

3) Anchors (A)

• A-dbj - formal-work anchor
• A-personal - personal projects and content work
• A-codex - Codex usage, configuration, and method evolution

4) Types (T)

• T1 Facts - stable facts
• T2 Confirmed - confirmed conclusions
• T3 Discussion - draft/process content
• T4 Repeated - repeated questions or misunderstandings
• T5 Transferable - reusable experience and methods

Default routing

• Formal work -> prefer P2/P3-D1-A-dbj
• Personal projects -> prefer P1/P2-D2-A-personal
• Codex/tooling -> prefer P4-D3-A-codex

Recall rule

When continuing prior work, read only the minimum useful set:

• current conversation context
• the main topic record
• the most relevant supporting pointer if there is still a gap

Do not scan broad memory by default.

Formal PM + React rule

When the work belongs to a PM workflow project that also has runnable prototype work, memory is not one bucket. Treat it as a layered system.

Layer 0: current conversation

• temporary turn-local coordination
• never trust this as durable state

Layer 1: global curated memory

• global preferences
• stable workflow pointers
• durable cross-project rules
• compact project entry pointers only

Layer 2: topic or project main record

• one canonical summary record per durable project/topic
• current stage
• stable confirmed conclusions
• high-value pointers
• next continuation entry

Layer 3: project detail assets

• real project files such as rules, handoffs, mappings, pm/baselines, spec, embedded-prd
• this is the detailed source of truth

Layer 4: project-local working memory

• src/docs/project-memory/current.md
• src/docs/project-memory/decisions.md
• src/docs/project-memory/open-questions.md
• src/docs/project-memory/changelog.md
• this is the default first stop for active continuation

Default behavior:

• global memory must not absorb what belongs in Layers 3 or 4
• the topic main record should summarize and point, not become a process dump
• project-local working memory should hold round-level motion without bloating the main record

Project-local priority rule

For PM + React fusion work, always use this read order unless there is a strong reason not to:

1. current conversation context
2. project-local working memory
3. current project artifact pointers or baseline files
4. global curated memory only for orientation, stage, and stable pointer recovery

This is now a hard default, not a soft preference.

If project-local working memory exists:

• read it before broad global memory
• trust it as the active-round source first
• use global memory only to confirm stage, project identity, and durable pointer integrity

If project-local memory and global memory conflict:

• trust the project-local active round state first
• then check whether global memory is stale

If a project does not yet have project-local working memory:

• read the topic main record
• then read the project's current / indexes / pm/baselines entry
• treat adding project-local working memory as a maintenance candidate

Cross-project isolation rule

When continuing project A:

• do not read project B just because it is similar
• do not treat prior pilot projects as required context
• do not use another project's business detail as default truth

What is allowed:

• reuse transferable workflow methods
• reuse reusable components, tokens, or generic baseline templates
• compare patterns only when explicitly needed

What is not allowed:

• reading another project's PRD, handoff, or memory as a hidden prerequisite
• mixing another project's unresolved business logic into the current project

In short:

• methods may be shared
• business truth may not be borrowed casually

PM + React write-back boundary

For PM + React fusion work, use this separation:

Write to project-local working memory when the information is:

• round-specific
• still changing
• implementation-adjacent
• mainly useful for continuing the current project

Write to global memory only when the information is:

• durable across rounds
• likely useful after the active files are not already open
• a stable pointer or stage marker
• a reusable workflow decision

Examples that usually stay local:

• page-level implementation detail
• current screenshot-driven layout corrections
• temporary unresolved design mismatches
• component iteration notes that still belong to one active project round
• open questions that block only the current slice

Examples that may be promoted globally:

• the official template location
• the active project root pointer
• the current effective baseline identity
• a stable rule about where project detail should live
• a reusable workflow method that should apply again later

Freeze-aware write-back rule

Freeze is the main boundary between "keep it local" and "consider promotion".

Before freeze

• default to local write-back only
• update project-local memory aggressively
• keep global memory compact
• do not promote unstable round churn just because a lot happened

After review freeze

Promotion is allowed only for:

• baseline identity such as v0.1 review
• current trusted continuation pointer
• clearly bounded truth about what the baseline does and does not cover
• durable workflow conclusions learned from the freeze

Do not promote:

• the whole project-memory content
• long round logs
• page-level UI details
• unresolved blockers as if they were stable facts

After stronger delivery freeze

Promotion may include:

• stronger stage marker
• trusted downstream entry
• clearer artifact pairing such as rule / handoff / prototype / PRD baseline links

But even then:

• global memory still stores summary + pointers, not full project archives

Main-record maintenance rule

For project main records:

• keep them as the first landing point
• keep them concise enough to scan quickly
• keep the most stable conclusions only
• move round-level churn into project-local working memory

If a main record starts carrying too many low-level changes:

• summarize the stable part
• move active churn into working-memory files
• keep the pointers and next-step entry obvious

Design absorption memory rule

When screenshots, mockups, or prototype references are absorbed into the workflow:

• keep detailed extraction, component iteration, and page-shape notes in project docs first
• do not dump visual detail into global memory
• promote only the durable conclusions, such as:
  • a stable component family now exists
  • a stable page pattern has been confirmed
  • a stable workflow rule has changed

Good example:

• local docs record the exact page modules, states, and corrections
• global memory records that a formal design-absorption layer exists and where it lives

Escalation rule for stale memory

When a project has both global memory and project-local working memory, ask:

• Is the global note only a pointer and still accurate?
• Is the local working memory clearly newer?
• Did the project stage or baseline identity change enough that global memory now needs a refresh?

If only the local round changed:

• update local working memory
• do not rush to rewrite global memory

If the trusted stage, baseline, or continuation pointer changed:

• update local working memory first
• then write a compact global pointer update

Preferred companion skills

For PM + React fusion work, memory should often coordinate with:

• pm-react-prototype-execution for project-local working memory updates during implementation
• pm-project-ops for locating current baseline and continuation paths
• memory-export-summary when promoting compact global summaries from detailed project assets
• pm-design-absorption when new visual references should improve assets before any memory promotion
• freeze-readiness-check when deciding whether a baseline is stable enough to preserve and promote

Write-back rule

Write back only when it helps future work continue.

Prefer storing:

• stable preferences
• confirmed decisions
• stage changes
• reusable methods
• recurring constraints
• trusted baseline identity
• continuation entry pointers

Avoid storing:

• one-off chatter
• weak guesses
• low-value fragments
• large copies of project-local working memory
• detailed design correction logs that already live in project docs
• entire PRDs, handoffs, or page specs copied into memory

Proactive write-back trigger

Do not wait for the user to explicitly ask for memory updates when a stable continuation signal has clearly formed.

Default proactive behavior:

• update project-local working memory automatically when the active round meaningfully changes
• update the main topic record automatically when the trusted stage, baseline identity, or continuation entry changes
• update global curated memory automatically only when a durable cross-round pointer or reusable workflow rule changes

Good triggers:

• a new preserved review or delivery baseline
• a continuation entry becomes canonical
• a reusable workflow rule is clarified and should apply again later
• a project stops depending on an old path and now has a new official root or official entry

Do not auto-write back:

• every small code edit
• unresolved design tweaking
• temporary blocker churn
• facts that are still likely to change in the next few turns

Retrieval-friendly write-back

If a memory entry should be found reliably later, do not leave it as loose prose only.

Prefer a compact block with:

• Topic
• Aliases
• Domain
• Permission
• SourceType
• Stage
• Confirmed
• Pointers
• Next

For PM workflow topics, SourceType should normally be pm_workflow_project, and Pointers should point to the real project assets rather than copying the full PRD into memory.

For PM + React fusion topics:

• point to the project root and current project-local memory area
• when relevant, point to the current baseline or current handoff entry
• after freeze, point to the preserved review or delivery baseline
• prefer one stable project pointer block over repeated loose mentions

Minimum PM workflow fill:

• Topic
• Aliases
• SourceType: pm_workflow_project
• Pointers

Good operating pattern

For active PM + React work:

1. read the current project's src/docs/project-memory/current.md
2. read only the local files needed to continue
3. update local working memory as the round moves
4. run freeze judgment when the round becomes coherent
5. only then promote compact baseline pointers into global memory

This is the official default pattern now.

Safety rule

Do not casually mix personal context into formal-work outputs. In shared or work-facing contexts, default to the safest layer that still answers the question.

For PM + React fusion work:

• keep project implementation detail in project assets first
• keep global memory compact enough that future work naturally re-enters the project files instead of trusting stale chat-era summaries
• do not let one project's business details become another project's hidden prompt