Project State
Use this skill to keep durable project context current without bloating AGENTS.md.
Files
Top-level docs:
SPEC.md -- user goal, scope, requirements, success criteria, validation plan
DESIGN.md -- architecture, UX/API decisions, product/design constraints
TODO.md -- active task list, next steps, blocked items, done items
Operational state:
.spec/state.md -- current objective, done, next steps, validation, open questions
.spec/checks.md -- known validation commands and latest meaningful results
.spec/handoff.md -- concise handoff for the next agent/session
Memory:
.mem/hot.md -- stable high-value facts, max 80 lines
.mem/decisions.md -- accepted decisions with date, reason, impact
.mem/open-loops.md -- unresolved questions, blockers, follow-ups
When to Create
Create or update these files when work is multi-step, spans sessions, changes product/architecture/design direction, or leaves meaningful next steps.
Do not create state files for trivial one-file fixes unless the repo already uses them.
Workflow
- At session start, read existing
SPEC.md, DESIGN.md, TODO.md, .spec/state.md, and .mem/hot.md if present.
- Before implementation, record success criteria in
SPEC.md or .spec/state.md when scope is non-trivial.
- During work, update
.spec/state.md with done/next/validation only after facts are verified.
- After decisions, append durable choices to
.mem/decisions.md or DESIGN.md.
- Before stopping, update
TODO.md, .spec/handoff.md, and .mem/open-loops.md when work remains.
Rules
- Keep
AGENTS.md stable; put project-specific state in these files.
- Keep
.mem/hot.md short and factual. No transcripts, guesses, secrets, credentials, tokens, or private user data.
- Write dates as
YYYY-MM-DD.
- Mark uncertainty as
UNKNOWN or an explicit open question.
- Do not store tool output unless it is a concise validation result or reproducible command.
- Prefer updating existing state over creating duplicate docs.
- If a state file is stale or contradicted by code, update it or report the drift.
Minimal State Shape
.spec/state.md:
# Project State
## Current Objective
## Done
## Next Steps
## Validation
## Open Questions
.mem/hot.md:
# Hot Memory
- [YYYY-MM-DD] Stable fact, decision, or preference.
Handoff Shape
Use this before ending multi-step work:
# Handoff
## Current State
## Completed
## Remaining
## Validation
## Risks
1---2name: project-state3description: Manage lightweight project state files such as SPEC.md, DESIGN.md, TODO.md, .spec/, and .mem/. Use when starting multi-step work, planning features, recording decisions, updating next steps, preserving cross-session context, or preparing handoff notes.4---56# Project State78Use this skill to keep durable project context current without bloating `AGENTS.md`.910## Files1112Top-level docs:1314- `SPEC.md` -- user goal, scope, requirements, success criteria, validation plan15- `DESIGN.md` -- architecture, UX/API decisions, product/design constraints16- `TODO.md` -- active task list, next steps, blocked items, done items1718Operational state:1920- `.spec/state.md` -- current objective, done, next steps, validation, open questions21- `.spec/checks.md` -- known validation commands and latest meaningful results22- `.spec/handoff.md` -- concise handoff for the next agent/session2324Memory:2526- `.mem/hot.md` -- stable high-value facts, max 80 lines27- `.mem/decisions.md` -- accepted decisions with date, reason, impact28- `.mem/open-loops.md` -- unresolved questions, blockers, follow-ups2930## When to Create3132Create or update these files when work is multi-step, spans sessions, changes product/architecture/design direction, or leaves meaningful next steps.3334Do not create state files for trivial one-file fixes unless the repo already uses them.3536## Workflow37381. At session start, read existing `SPEC.md`, `DESIGN.md`, `TODO.md`, `.spec/state.md`, and `.mem/hot.md` if present.392. Before implementation, record success criteria in `SPEC.md` or `.spec/state.md` when scope is non-trivial.403. During work, update `.spec/state.md` with done/next/validation only after facts are verified.414. After decisions, append durable choices to `.mem/decisions.md` or `DESIGN.md`.425. Before stopping, update `TODO.md`, `.spec/handoff.md`, and `.mem/open-loops.md` when work remains.4344## Rules4546- Keep `AGENTS.md` stable; put project-specific state in these files.47- Keep `.mem/hot.md` short and factual. No transcripts, guesses, secrets, credentials, tokens, or private user data.48- Write dates as `YYYY-MM-DD`.49- Mark uncertainty as `UNKNOWN` or an explicit open question.50- Do not store tool output unless it is a concise validation result or reproducible command.51- Prefer updating existing state over creating duplicate docs.52- If a state file is stale or contradicted by code, update it or report the drift.5354## Minimal State Shape5556`.spec/state.md`:5758```markdown59# Project State6061## Current Objective6263## Done6465## Next Steps6667## Validation6869## Open Questions70```7172`.mem/hot.md`:7374```markdown75# Hot Memory7677- [YYYY-MM-DD] Stable fact, decision, or preference.78```7980## Handoff Shape8182Use this before ending multi-step work:8384```markdown85# Handoff8687## Current State8889## Completed9091## Remaining9293## Validation9495## Risks96```