suibianqugenichenghaole Memory Skill
Use memory as a working continuation system, not as a chat scrapbook.
Core job
- Find the smallest useful memory set.
- Keep personal, formal-work, and tooling contexts separate.
- Continue work rather than merely recap it.
- Keep project detail inside project assets.
- Write back only durable conclusions and trusted pointers.
Use and boundary
Use this skill for recall, continuation, classification, write-back routing, and project-memory navigation.
Do not use it to manage PM assets, versions, or snapshots; use the project's asset-operations workflow instead. Do not use it merely to produce a compact project-status summary.
Core routing model
Classify memory by four axes before writing:
- Permission: private, internal, public, or reusable method.
- Domain: formal work, personal project, or tooling.
- Anchor: the stable project, person, or system entry it belongs to.
- Type: fact, confirmed conclusion, discussion, repeated issue, or transferable method.
Recall rule
Read only the minimum useful set: current task context, the topic main record, then the most relevant supporting pointer if needed.
For a known project, use narrow recall first:
- Search the curated-memory entry and topic-memory directory for the project name, alias, or stable topic slug.
- Open the matched topic main record.
- Follow its pointers to project-local working memory, especially
current,decisions,open-questions, andchangelogentries. - If
current.mdnames an active-workstream manifest, read that manifest before the index, decisions record, or downstream artifacts. The manifest defines the governing, context, and blocked assets for the current round. - Read only the project files needed for the task.
Do not begin with broad session, temporary-directory, or whole-workspace scans unless the narrow path fails or the user explicitly asks for history searching.
Active-workstream and lifecycle selection
When a project has both a delivery stage and an asset disposition, treat them as separate axes. Start with the active workstream and its active assets; do not infer that an asset is usable from its version, frozen label, folder, or historical presence alone.
- Do not use
awaiting-curationassets by default. Read one only when the active manifest states its extraction purpose and the content that may be carried forward. - Do not use
deprecatedassets as requirement, state, page, PRD, or implementation inputs. Use them only for traceability, replacement links, or audit evidence. - If an active manifest points to remediation or archive material without an explicit extraction boundary, stop and request a decision instead of silently adopting the old asset.
Project-memory growth rule
When active project memory becomes too long or mixes several durable topics, preserve navigation rather than making future users read history.
Suggest a split when the active continuation file is roughly 150-200 lines, or when it mixes three or more durable topics.
For projects without an active-workstream manifest, use this pattern:
current.md -> index.md -> decisions.md -> relevant topic files
current.md: current executable state, next direction, invariants, and read order.index.md: navigation.decisions.md: stable boundaries and confirmed conclusions.- topic files: long analysis, experiments, references, and detailed history.
Splitting is migration plus navigation, not fact rewriting. Preserve confirmed content and update the read order after moving it.
Cross-project isolation
Do not read another project's business detail merely because it looks similar. Reuse methods and generic templates when useful, but do not borrow unresolved rules, PRDs, or hidden context from another project.
Write-back rule
Write back only when it helps future work continue. Use a retrieval-friendly date for requirement, decision, prototype, and PRD-impacting notes.
Route content by layer:
- active, changing project state -> project-local working memory
- current-round rule, state, interaction, projection, or audit -> the active workstream asset named by its manifest
- stable boundary or decision -> project decisions record
- long analysis or experiment -> project topic file
- durable cross-project pointer or reusable method -> curated memory
If a write-back would bloat the continuation entry or add another unrelated topic, propose navigation or a topic split instead.
PM and runnable-prototype work
For projects with runnable prototypes, use project-local working memory before broad curated memory. Keep implementation detail and current design corrections local; promote only trusted baseline identities, continuation pointers, and reusable methods after an appropriate review boundary.
Read references/pm-react-memory-layers.md when deciding memory layers, freeze-aware promotion, or design-absorption write-back.
On-demand references
references/pm-react-memory-layers.md: project-local priority, layered memory, and freeze-aware promotion.references/write-back-patterns.md: timestamps, retrieval-friendly entries, proactive write-back triggers, and encoding guidance.
Self-check
Before finishing, verify that you used the minimum useful recall set, kept project detail in project assets, separated contexts, dated consequential write-backs, preserved navigation when project memory grew, and did not treat awaiting-curation or deprecated assets as default inputs.