Project Heartbeat
Project heartbeat is for controlled continuation, not endless automation.
Use this skill when
- - the project has a real home (for example
Projects/<name>/) - the work can continue in small, concrete steps
- progress should survive interruptions
- some blocked actions can be deferred without stopping the whole project
- you want wake-up cadence plus explicit stop conditions
Do not use this skill when
- - the work is small enough for one session
- there is no canonical project state
- the only remaining step is a human approval or external action
- the project has no clear next step
v0 scope
This version focuses on what is practical now:
- - fit check
- cadence recommendation
- continue conditions
- hard stop vs soft block boundary model
- pending decision backlog contract
- progress logging contract
- continuation integrity rules
- summary + handoff contract
- resume protocol
More advanced ideas such as model-routing and automatic blocked-path rerouting belong in the deferred backlog until the system has more real usage evidence.
A stronger strategic heartbeat mode is also valid when a project has many unfinished modules and should not fall into waiting-human merely because no fresh external input arrived. In that mode, each cycle should first re-evaluate the whole project against its original vision, then choose one smallest high-value move that most helps the system converge toward that vision.
Workflow
- 1. Fit check
- Confirm the project is large enough and structured enough for heartbeat.
- 2. Choose cadence
- Pick a wake interval that matches the project intensity.
-
30 seconds is reasonable for active projects needing close monitoring.
-
5–15 minutes is better for normal ongoing work.
-
30–60 minutes is suitable for low-intensity sustained projects.
- Prefer longer cadences for normal operation; reserve short intervals for debug/active-polish phases.
- 3. Define continue conditions
- Only continue if there is a concrete next step already visible in project artifacts.
- 4. Define boundaries
- Separate:
- hard stop boundaries
- soft block boundaries
- 5. Define progress artifacts
- Every wake cycle should leave behind a durable trace.
- 6. Check continuation integrity
- A cycle does not count as progress unless it produces at least one real artifact update.
- No artifact, no progress.
- 7. Define summary + handoff behavior
- Every cycle should leave a concise human-facing summary.
-
waiting-human and
closed must hand work back explicitly rather than stopping silently.
- 8. Define resume protocol
- Humans should be able to return and understand what moved, what blocked, and what still needs approval.
Boundary model
Hard stop boundaries
Must stop the loop:
- - budget exhausted
- safety boundary reached
- explicit human-only action with no meaningful bypass path
- repeated no-progress cycles
- no clear next step for multiple wake cycles
Soft block boundaries
Do not automatically stop the whole loop if other work remains:
- - repository creation pending approval
- publish pending confirmation
- one branch of work blocked while other internal improvements remain
Soft blocks should be recorded in a pending-decision backlog so they can be surfaced later.
Continuation integrity
A heartbeat loop should not be allowed to survive on continuation language alone.
False continuation
False continuation happens when the agent says it continued, started, or progressed, but the project has no real new artifact to show for that cycle.
Minimum artifact rule
A cycle should count as real progress only if it leaves at least one durable change such as:
- -
STATE.md updated - task/backlog file updated
- INLINECODE5 updated
- INLINECODE6 updated
- a new project/review/decision/doc artifact created
- a real tracked child task started
No-op rule
If a cycle produced no durable artifact, treat it as a no-op. Repeated no-op cycles should escalate toward stop conditions rather than being narrated as progress.
Scripts
scripts/fit_check.py
Quick fit assessment for whether a project is ready for heartbeat-style continuation.
scripts/render_plan.py
Renders a practical heartbeat plan: cadence, continue conditions, stop boundaries, backlog location, and resume guidance.
References
- - INLINECODE9
- INLINECODE10
- INLINECODE11
- INLINECODE12
- INLINECODE13
- INLINECODE14
- INLINECODE15
项目心跳
项目心跳是为了受控延续,而非无休止的自动化。
使用此技能的场景
- - 项目有实际存放位置(例如 Projects/<名称>/)
- 工作能以小而具体的步骤持续推进
- 进度应能承受中断
- 部分受阻操作可推迟而不影响整个项目
- 需要唤醒节奏加上明确的停止条件
不使用此技能的场景
- - 工作规模小到一次会话即可完成
- 没有规范的项目状态
- 仅剩的步骤是人工审批或外部操作
- 项目没有明确的下一步
v0 范围
本版本聚焦于当前实用的功能:
- - 适配性检查
- 节奏建议
- 继续条件
- 硬停止与软阻塞边界模型
- 待定决策积压合同
- 进度记录合同
- 延续完整性规则
- 总结与交接合同
- 恢复协议
更高级的想法,如模型路由和自动阻塞路径重路由,应归入延期积压,直到系统积累更多实际使用证据。
当项目包含许多未完成模块,且不应仅仅因为没有新的外部输入就陷入等待人工状态时,更强的战略心跳模式也是有效的。在该模式下,每个周期应首先根据原始愿景重新评估整个项目,然后选择一个最有助于系统向该愿景收敛的最小高价值行动。
工作流程
- 1. 适配性检查
- 确认项目规模足够大且结构足够清晰,适合心跳模式。
- 2. 选择节奏
- 选择与项目强度匹配的唤醒间隔。
-
30秒适用于需要密切监控的活跃项目。
-
5–15分钟适合正常的持续工作。
-
30–60分钟适用于低强度的长期项目。
- 正常操作时优先选择较长节奏;将短间隔保留给调试/主动优化阶段。
- 3. 定义继续条件
- 仅在项目工件中已可见具体的下一步时才继续。
- 4. 定义边界
- 区分:
- 硬停止边界
- 软阻塞边界
- 5. 定义进度工件
- 每个唤醒周期应留下持久的痕迹。
- 6. 检查延续完整性
- 一个周期必须产生至少一个真实的工件更新,才能算作进度。
- 无工件,则无进度。
- 7. 定义总结与交接行为
- 每个周期应留下简洁的面向人类的总结。
- 等待人工和已关闭状态必须明确交回工作,而非静默停止。
- 8. 定义恢复协议
- 人类应能返回并了解哪些已推进、哪些受阻、哪些仍需审批。
边界模型
硬停止边界
必须停止循环的情况:
- - 预算耗尽
- 触及安全边界
- 明确需要人工操作且无有意义的绕过路径
- 重复出现无进度周期
- 多个唤醒周期后仍无明确下一步
软阻塞边界
如果还有其他工作可做,不会自动停止整个循环:
- - 仓库创建待审批
- 发布待确认
- 一条工作线受阻,而其他内部改进仍可进行
软阻塞应记录在待定决策积压中,以便后续呈现。
延续完整性
心跳循环不应仅靠延续性语言维持。
虚假延续
当代理声称已延续、开始或推进,但项目在该周期内没有实际的新工件可展示时,即为虚假延续。
最小工件规则
一个周期只有留下至少一项持久变更,才算作实际进度,例如:
- - STATE.md 已更新
- 任务/积压文件已更新
- PENDING-DECISIONS.md 已更新
- HEARTBEAT-LOG.md 已更新
- 创建了新的项目/评审/决策/文档工件
- 启动了实际可追踪的子任务
无操作规则
如果一个周期未产生持久工件,则视为无操作。重复的无操作周期应升级至停止条件,而非被描述为进度。
脚本
scripts/fit_check.py
快速适配性评估,判断项目是否适合心跳式延续。
scripts/render_plan.py
生成实用的心跳计划:节奏、继续条件、停止边界、积压位置和恢复指南。
参考资料
- - references/boundaries.md
- references/examples.md
- references/pending-decisions-template.md
- references/heartbeat-log-template.md
- references/continuation-integrity.md
- references/summary-handoff.md
- references/deferred-backlog.md