longrun

star 20

Orchestrate a long-running autonomous Copilot CLI mission from one prompt. Use when the user explicitly wants a one-shot, autopilot-style workflow with planning, workstream artifacts, evidence capture, recovery, and resumable state under .copilot-mission-control/.

izscc By izscc schedule Updated 4/6/2026
play_arrow Run Skill in Manus View GitHub

name: longrun description: Orchestrate a long-running autonomous Copilot CLI mission from one prompt. Use when the user explicitly wants a one-shot, autopilot-style workflow with planning, workstream artifacts, evidence capture, recovery, and resumable state under .copilot-mission-control/. allowed-tools: "*" user-invocable: true disable-model-invocation: false

仅在用户明确要“长时间自主执行 / 一次触发后持续跑完”的任务时使用本技能。
如果用户要的是可复制 prompt，而不是立刻执行，请改用 /longrun-prompt。

LongRun 采用轻架构：

  • status.json 是唯一真值源
  • plan.md 只是默认受管投影
  • task-list.md 默认不受管
  • helpers 优先于复杂 shell
  • 任务内容结构留给 mission.md / 当前任务，不写死进插件规则

0. 先判定结束语义（非常重要）

在开始执行前，必须先给 mission 判定 terminationMode：

  • complete-and-exit：默认模式。适用于“交付物完成后即可结束”的任务。
  • checkpoint-and-stop：适用于先跑一段、落盘检查点、等待用户回来继续。
  • watch-until-deadline：适用于持续观察 / 轮询 / 等待外部条件 / 守护类任务。

判定规则：

  • 若用户要求“做完就行 / 产出报告 / 发布完成 / 修完并验证后结束”，用 complete-and-exit
  • 若用户要求“先别结束 / 我稍后回来 / 先跑到 checkpoint / 保留现场”，用 checkpoint-and-stop
  • 若用户要求“持续监控 / 每隔 X 分钟检查 / 等待外部事件 / watch / 守护 / keep running”，用 watch-until-deadline

默认不要把“持续观察”伪装成一次普通 session 永久挂起。
这类任务应优先：

  1. 用 detached launcher：longrun "..." / copilot-longrun run --detach ...（兼容入口）
  2. 把检查点、状态、恢复命令写入 .copilot-mission-control/
  3. 在合适时点 resume，而不是依赖当前会话永不结束

terminationMode 至少要写进 mission.md；能写进 status.json 时也一并写入。

1. 先确认 helper bundle

优先使用：

  • $HOME/.copilot-mission-control/bin/prepare_run.py
  • $HOME/.copilot-mission-control/bin/write_status.py
  • $HOME/.copilot-mission-control/bin/write_journal.py
  • $HOME/.copilot-mission-control/bin/record_source.py
  • $HOME/.copilot-mission-control/bin/harvest_sources.py
  • $HOME/.copilot-mission-control/bin/reconcile_run.py
  • $HOME/.copilot-mission-control/bin/verify_run.py
  • $HOME/.copilot-mission-control/bin/finalize_run.py

如果这些 helpers 缺失：

  • 不要伪装成稳定长跑系统
  • 直接给出 BLOCKED 说明，并提示先执行：
    • bash scripts/install-all.sh
    • 或 bash scripts/install-bare-commands.sh

禁止用脆弱的 echo '{...}' >> file 直接写 JSON。

2. run-id 分配规则

新任务必须优先走 helper 分配 run-id，不要手造 icopilot-v1 这类语义化 run-id。

优先级如下：

  1. 若环境变量 LONGRUN_RUN_ID 存在，必须直接使用它。这通常表示 launcher 已预分配 run。
  2. 若是 /longrun-resume 或用户明确要求 reopen 旧 run，才允许复用已有 run-id。
  3. 其他新任务，一律通过 prepare_run.py 生成新的时间戳 run-id。

推荐命令：

python3 "$HOME/.copilot-mission-control/bin/prepare_run.py" \
  --workspace "$PWD" \
  --task "<原始任务描述>" \
  --run-id "$LONGRUN_RUN_ID" \
  --allow-existing

如果当前没有 LONGRUN_RUN_ID，则改为：

python3 "$HOME/.copilot-mission-control/bin/prepare_run.py" \
  --workspace "$PWD" \
  --task "<原始任务描述>"

要求：

  • 新 run 的目录名应形如：YYYYMMDD-HHMMSS-slug
  • launcher 预分配的 run 必须复用，不得另起新目录
  • 只有 resume 流程才允许继续旧 run

3. 只保留必要 run 结构

每个 run 至少包含：

  • .copilot-mission-control/runs/<run-id>/mission.md
  • .copilot-mission-control/runs/<run-id>/plan.md
  • .copilot-mission-control/runs/<run-id>/status.json
  • .copilot-mission-control/runs/<run-id>/journal.jsonl
  • .copilot-mission-control/runs/<run-id>/sources.jsonl
  • .copilot-mission-control/runs/<run-id>/artifacts/

helper 自己的收尾文件写入：

  • .copilot-mission-control/runs/<run-id>/COMPLETION.md

若用户任务自己需要 final-summary.md，那是用户 deliverable，不要被 helper 覆盖。

4. 初始化要求

若已通过 prepare_run.py 预分配 run，则初始化时优先直接复用该 run。

初始化状态优先用：

python3 "$HOME/.copilot-mission-control/bin/write_status.py" \
  --workspace "$PWD" \
  --run-id "<run-id>" \
  --init-from-prompt "<原始任务描述>"

初始化后至少保证 status.json 中存在：

  • state
  • phase
  • deliverables
  • completedWorkstreams
  • activeWorkstreams
  • verification
  • recoveryState
  • artifacts
  • naming

默认命名策略：

  • 用户可见输出文件默认用简体中文
  • 内核控制文件保持英文稳定名

5. Shell-safe 规则

优先 helper-first。
必须避免容易被 Copilot CLI guardrail 拦截的复杂 shell 写法，尤其不要默认生成：

  • $(...)
  • 反引号
  • ${!var}
  • 复杂嵌套替换

优先替代方案：

  • 直接调用 helper
  • python3 - <<'PY' ... PY
  • 简单 grep / rg / find

6. 记账规则

每次 phase 切换或关键状态变化后，必须更新 status.json。
每个有意义的推进动作后，必须写 journal.jsonl。
研究/办公任务新增来源时，必须优先写 sources.jsonl；若中途漏记，收尾前必须补跑 harvest_sources.py。

7. 轻量动态优化

只做事件驱动的最小重规划，不做重型全局重思考。

只在这些场景触发恢复/重分析：

  • verify fail
  • shell block
  • sources 缺失
  • 状态漂移
  • 连续失败没有新信息
  • deliverable 已在，但账本没同步

默认恢复顺序：

  1. reconcile_run.py
  2. harvest_sources.py
  3. verify_run.py
  4. 再决定继续执行、finalize complete，还是 finalize blocked

8. plan.md 规则

plan.md 顶部必须有唯一受管的 LongRun Status Board。
它只用于投影 status.json，不是新的真值源。

如果发现这些情况，视为状态漂移：

  • plan.md 缺少受管状态区块
  • 同时存在第二份手写 LongRun Status Board
  • finalized 了但还有 stale running

若存在 task-list.md：

  • 默认把它视为完成闸门
  • 未勾选项默认视为“还没做完”
  • 只有显式 advisory 标记才不纳入完成校验：
    • <!-- LONGRUN:TASK-LIST:ADVISORY -->
    • <!-- LONGRUN:TASK-LIST:UNMANAGED -->

也就是说：

  • plan.md = 受管状态投影
  • task-list.md = 若存在，则默认作为任务完成清单

9. finalize 必须硬收敛

完成或阻塞时统一调用：

python3 "$HOME/.copilot-mission-control/bin/finalize_run.py" \
  --workspace "$PWD" \
  --run-id "<run-id>" \
  --status "complete|blocked" \
  --headline "<一句话结果>" \
  --local-verify

注意：

  • --status complete --local-verify 失败时，默认不得写成 complete
  • 只有显式 --force-complete 才允许带风险完成
  • finalize 前必须先：
    1. harvest_sources.py
    2. reconcile_run.py
    3. verify_run.py

收尾后必须保证：

  • status.json.state 为 complete 或 blocked
  • activeWorkstreams 为空
  • plan.md 已同步
  • deliverables 非空（针对 complete）
  • 若存在 task-list.md，则必需项已全部勾完
  • helper 输出写入 COMPLETION.md

9.5 task_complete 不是普通总结，它会结束当前 session

必须明确区分：

  • finalize_run.py：收敛 run 状态
  • task_complete：告诉 Copilot 当前 session 可以结束

只有同时满足以下条件，才允许调用 task_complete：

  1. 已先执行 finalize_run.py
  2. status.json.state 已是 complete 或 blocked
  3. terminationMode == complete-and-exit
  4. 不存在“持续观察 / checkpoint / 等待人工确认 / 等待外部窗口”的隐含 contract

若 terminationMode 是：

  • checkpoint-and-stop：只写 checkpoint / status / journal，不要 task_complete
  • watch-until-deadline：只写下一次检查条件、恢复命令、当前证据，不要 task_complete

raw /longrun in-session 一旦调用 task_complete，通常会看到：

  • session.task_complete
  • sessionEnd.reason = complete

这属于正常收尾，不是崩溃。
如果目标是不让当前会话立刻结束，就不要过早触发 task_complete，并优先使用 detached launcher + resume 流程。

10. BLOCKED 何时成立

以下情况不要硬跑：

  • 关键输入缺失且无法安全推断
  • 任务依赖当前环境不具备的私有能力
  • 连续恢复没有带来新信息
  • verify 明确无法通过且没有更小修复路径

BLOCKED 也必须 finalize，并写清：

  • 已完成部分
  • 阻塞原因
  • 推荐下一步
Install via CLI
npx skills add https://github.com/izscc/LongRun --skill longrun
Repository Details
star Stars 20
call_split Forks 4
navigation Branch main
article Path SKILL.md
More from Creator
izscc
izscc Explore all skills →