mcpField
C
continuity-ledger

continuity-ledger

github.com/parcadeiAgent 工作流3.9k511 次安装39 周前更新
代码仓库

关于 continuity-ledger

continuity-ledger 用于创建 YAML 交接文档，以便在清除上下文后保留会话状态。它遵循指定的文件命名和元数据格式，是 /create_handoff 的别名。

主要功能

  1. 01创建 YAML 会话交接文档
  2. 02沿用最近交接目录名称
  3. 03记录目标、状态、发现和后续步骤
  4. 04遵循固定元数据格式
  5. 05作为 /create_handoff 的别名

适用场景

  1. 01清除会话前保存工作状态
  2. 02在新会话中继续多日开发任务
  3. 03为复杂工作记录决策和后续事项

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/parcadei/continuous-claude-v3 --skill continuity-ledger

安装后在 Claude Code 中输入/continuity-ledger确认已加载。

详细介绍

连续性日志

**注意：**此技能现在是 /create_handoff 的别名。两者输出相同的 YAML 格式。

创建 YAML 交接文档，以便在 /clear 前保存状态。此操作与 /create_handoff 相同。

流程

1. 文件路径与元数据

首先，从现有交接文档中确定会话名称：

ls -td thoughts/shared/handoffs/*/ 2>/dev/null | head -1 | xargs basename

这会返回最近修改的交接文件夹名称（例如 open-source-release）。将其用作交接文件夹名称。

如果不存在交接文档，则使用 general 作为文件夹名称。

在以下路径创建文件： thoughts/shared/handoffs/{session-name}/YYYY-MM-DD_HH-MM_description.yaml，其中：

  • {session-name} 取自现有交接文档（例如 open-source-release）；如果不存在，则使用 general
  • YYYY-MM-DD 是今天的日期
  • HH-MM 是当前时间，使用 24 小时制（无需秒数）
  • description 是简短的 kebab-case 描述

示例：

  • thoughts/shared/handoffs/open-source-release/2026-01-08_16-30_memory-system-fix.yaml
  • thoughts/shared/handoffs/general/2026-01-08_16-30_bug-investigation.yaml
2. 编写 YAML 交接文档（约 400 个 token）

至关重要：必须严格使用以下 YAML 格式。不要偏离格式，也不要使用其他字段名称。

goal: 和 now: 字段会显示在状态栏中——字段名称必须完全一致。

---
session: {session-name from ledger}
date: YYYY-MM-DD
status: complete|partial|blocked
outcome: SUCCEEDED|PARTIAL_PLUS|PARTIAL_MINUS|FAILED
---

goal: {What this session accomplished - shown in statusline}
now: {What next session should do first - shown in statusline}
test: {Command to verify this work, e.g., pytest tests/test_foo.py}

done_this_session:
  - task: {First completed task}
    files: [{file1.py}, {file2.py}]
  - task: {Second completed task}
    files: [{file3.py}]

blockers: [{any blocking issues}]

questions: [{unresolved questions for next session}]

decisions:
  - {decision_name}: {rationale}

findings:
  - {key_finding}: {details}

worked: [{approaches that worked}]
failed: [{approaches that failed and why}]

next:
  - {First next step}
  - {Second next step}

files:
  created: [{new files}]
  modified: [{changed files}]

字段说明：

  • goal: + now: - 必填，会显示在状态栏中
  • done_this_session: - 本次会话完成的事项，并附上文件引用
  • decisions: - 重要决策及其理由
  • findings: - 关键发现
  • worked: / failed: - 应重复采用的方法与应避免的方法
  • next: - 下一次会话的待办事项

不要使用 session_goal、objective、focus、current 等替代字段名称。 状态栏解析器只会识别完全一致的 goal: 和 now:——其他字段均不起作用。

3. 标记会话结果（必需）

**重要：**在回复用户之前，必须询问本次会话的结果。

使用 AskUserQuestion 工具，并提供以下完全一致的选项：

Question: "How did this session go?"
Options:
  - SUCCEEDED: Task completed successfully
  - PARTIAL_PLUS: Mostly done, minor issues remain
  - PARTIAL_MINUS: Some progress, major issues remain
  - FAILED: Task abandoned or blocked

用户回复后，标记结果：

# Mark the most recent handoff (works with PostgreSQL or SQLite)
PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || echo "${CLAUDE_PROJECT_DIR:-.}")
cd "$PROJECT_ROOT/opc" && uv run python scripts/core/artifact_mark.py --latest --outcome <USER_CHOICE>
4. 确认完成

标记结果后，回复用户：

Handoff created! Outcome marked as [OUTCOME].

Resume in a new session with:
/resume_handoff path/to/handoff.yaml

适用场景

  • 运行 /clear 之前
  • 上下文使用量接近 70% 或更高时
  • 持续数日的实现工作
  • 需要分阶段进行的复杂重构
  • 预计上下文使用量会达到 85% 或更高的任何会话

不适用场景

  • 快速任务（少于 30 分钟）
  • 简单的 Bug 修复
  • 单文件修改

为什么选择 Clear 而不是 Compact？

每次压缩都是有损压缩——经过多次压缩后，工作上下文会逐渐退化。清除上下文并加载交接文档，可以获得全新的上下文，同时保留完整信息。

评论

支持 Markdown