continuity-ledger
Preserve session state across /clear in long-running sessions. Use before running /clear, when context usage passes ~70%, or for multi-day implementations and large refactors you pick up and put down. Unlike handoffs (cross-session), a ledger preserves state within one session.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-11
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- continuity-ledger
- description
- Preserve session state across /clear in long-running sessions. Use before running /clear, when context usage passes ~70%, or for multi-day implementations and large refactors you pick up and put down. Unlike handoffs (cross-session), a ledger preserves state within one session.
02 资源文件 1
- 参考文档reference/comparison-and-example.md1.7 KB
03 SKILL.md 正文
Continuity Ledger
Maintain a ledger file that survives /clear. Clear instead of compact: each compaction is lossy compression — after several, you work with degraded context. Clearing then reading the ledger gives fresh context with full signal.
When NOT to Use
- Quick tasks (< 30 min)
- Simple bug fixes
- Single-file changes
- Already using handoffs for cross-session transfer
Process
1. Determine Ledger File
Check if a ledger already exists:
ls thoughts/ledgers/CONTINUITY_CLAUDE-*.md 2>/dev/null
- If exists: Update the existing ledger
- If not: Create new file:
thoughts/ledgers/CONTINUITY_CLAUDE-<session-name>.md- First ensure directory exists:
mkdir -p thoughts/ledgers - Use kebab-case for session name (e.g.,
rbac-refactor,import-migration)
- First ensure directory exists:
2. Create/Update Ledger
Use this template structure:
# Session: <name>
Updated: <ISO timestamp>
## Goal
<Success criteria - what does "done" look like?>
## Constraints
<Tech requirements, patterns to follow, things to avoid>
## Key Decisions
<Choices made with brief rationale>
- Decision 1: Chose X over Y because...
- Decision 2: ...
## State
- Done: <completed items>
- Now: <current focus - ONE thing only>
- Next: <queued items in priority order>
## Open Questions
- UNCONFIRMED: <things needing verification after clear>
- UNCONFIRMED: <assumptions that should be validated>
## Working Set
<Active files, branch, test commands>
- Branch: `feat/xyz`
- Key files: `v2/backend/apps/core/`, `v2/backend/apps/core/tests/`
- Test cmd: `docker exec aprender_dev-web-1 pytest apps/core/tests/ -v`
- Type check: `cd v2/backend && pyright apps/core config`
3. Update Guidelines
When to update the ledger:
- Session start: Read and refresh
- After major decisions
- Before
/clear - At natural breakpoints
- When context usage >70%
What to update:
- Move completed items from "Now" to "Done"
- Update "Now" with current focus
- Add new decisions as they're made
- Mark items as UNCONFIRMED if uncertain
4. After Clear Recovery
When resuming after /clear:
- Read the ledger —
cat thoughts/ledgers/CONTINUITY_CLAUDE-<name>.md - Review UNCONFIRMED items
- Ask 1-3 targeted questions to validate assumptions
- Update ledger with clarifications
- Continue work with fresh context
Template Response
After creating/updating the ledger, respond:
Continuity ledger updated: thoughts/ledgers/CONTINUITY_CLAUDE-<name>.md
Current state:
- Done: <summary>
- Now: <current focus>
- Next: <upcoming>
Ready for /clear - read the ledger to resume.
Reference
How a ledger compares to CLAUDE.md / TodoWrite / handoffs, plus a full worked example (an rbac-capability-rename session) → reference/comparison-and-example.md.
Additional Notes
- Keep it concise - Brevity matters for context
- One "Now" item - Forces focus, prevents sprawl
- UNCONFIRMED prefix - Signals what to verify after clear
- Update frequently - Stale ledgers lose value quickly
- Clear > compact - Fresh context beats degraded context
04 同仓库更多 Skills
writing-standards
Apply AS v2 technical-writing standards (clarity, brevity, active voice, Python/Django conventions). Use when writing a README, a docstring (PEP 257), a commit message, a PR description, an error message, or any technical doc.
verification-gate
Verify before claiming success. Use when about to say something works/is done, after implementing a feature, after a bugfix, or before pushing — run the proof command and confirm output first.
test-driven-development
Write the failing test before the implementation in AS v2 (pytest + Django/DRF). Use when implementing a feature or fixing a bug, before any production code is written.
subagent-development
Orquestra subagents no AS v2 — decompõe a tarefa em domínios independentes, paraleliza e revisa em 2 estágios. Use ao delegar exploração, implementação ou validação cross-arquivo para acelerar o trabalho e poupar o contexto principal.
security-scan
Automated security scanning for AS v2. Use before commits or when reviewing changes for vulnerabilities. Runs dependency audit (pip-audit, npm audit), secret detection (grep patterns), and code pattern scanning (SQL injection, XSS, eval, pickle, hardcoded secrets). Integrates with project hooks system.
resume-handoff
Resume work from a saved handoff document, validating its state against the current codebase before continuing. Use when resuming work from a saved handoff after a context clear or in a new session (path, session name, or GitHub issue).