メニュー
Use when maintaining project state across sessions — writing or reading a STATE.md / MEMORY.md, recording what was learned, resuming interrupted work, or deciding what to persist for future sessions.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when orchestrating multi-agent or long-running work — spawning sub-agents, fanning out parallel tasks, delegating subtasks, running build-then-review loops, or deciding which model tier should do a piece of work.
Use when building a self-contained shippable artifact from scratch or a major rev — an MCP server, a CLI, a library/SDK, a skills pack, a plugin — anything that gets packaged and released rather than merged into an existing app.
Use when building or redesigning a product UI/visual system — creating a design system, writing or following a DESIGN.md contract, generating screens in a design tool (Stitch/Figma) then porting to code, or doing a branded visual redesign.
Use during hands-on execution of any coding or agent task — especially when following multi-item instructions, deciding how much to deliberate, about to claim something is done, or producing output at risk of reading as generic AI slop.
Use when building or running an automated measurement/audit/reporting pipeline that scores many subjects on a recurring basis and reports to stakeholders — a compliance monitor, a benchmark matrix, a metrics dashboard, a scheduled scan-and-report.
Use when planning, building, or reviewing a software milestone/release/version — any task framed as "ship vX", "build the next milestone", "plan and execute a feature set", "do a research + build pass", or "review what we shipped".
| name | compounding-memory |
| description | Use when maintaining project state across sessions — writing or reading a STATE.md / MEMORY.md, recording what was learned, resuming interrupted work, or deciding what to persist for future sessions. |
A stateless model only compounds if the environment around it remembers. This skill is the discipline that turns scattered notes into memory that actually gets consulted.
Good memory walks: Fail → Investigate → Verify → Distill → Consult. Weak memory stops at stage 1 (notes + guesses, never re-read). The win is reaching stages 3–5: facts that say how they were checked, rules consulted before re-deriving, and a resume pointer.
A state file with sections matching the stages:
## Verified facts # stage 3 — stop guessing; each line says how it was checked
## General rules # stage 4 — consult BEFORE re-deriving
## Open failures # stages 1–2 — work in progress, with a repro pointer
## Lessons learned # stage 4 — distillations
## Last session # stage 5 — resume pointer, not a restart
The single highest-leverage habit: every persisted fact carries how/when it was checked, not just the claim.
- The deploy job pushes schema via flyctl proxy. (Verified-by: read ci.yml:90-152, 2026-06-14)
- Rule count is 70. (Verified-by: grep samples.ts + test asserts toBe(70))
A claim without a Verified-by: is a guess until proven — treat it as stage 1,
not stage 3. Recalled memories reflect what was true when written; re-verify a
named file/flag/count before relying on it.
Persist: non-obvious facts, decisions + their rationale, corrections/feedback, durable gotchas, resume pointers. Don't persist what the repo already records (code structure, git history, things in CLAUDE.md) or what only mattered to one conversation. One fact per memory; link related facts.
See PROVENANCE.md for sources.