메뉴
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.