AGENT SKILL

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

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)

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:

  1. Read the ledger — cat thoughts/ledgers/CONTINUITY_CLAUDE-<name>.md
  2. Review UNCONFIRMED items
  3. Ask 1-3 targeted questions to validate assumptions
  4. Update ledger with clarifications
  5. 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

matheusnorjosa
matheusnorjosa/aprender_sistema

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.

内容创作者写作与文案
★ 0
matheusnorjosa
matheusnorjosa/aprender_sistema

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.

★ 0
matheusnorjosa
matheusnorjosa/aprender_sistema

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.

测试与质量
★ 0
matheusnorjosa
matheusnorjosa/aprender_sistema

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.

★ 0
matheusnorjosa
matheusnorjosa/aprender_sistema

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.

★ 0
matheusnorjosa
matheusnorjosa/aprender_sistema

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).

人力资源
★ 0