Files
claude-skills/.wiki/concepts/using-tasks-session-break.md
vitya 9a518fcb43 feat(using-tasks): session_break marker [v1.2.0]
Add a session_break marker so a task author can mark a task's
completion as a natural session boundary. After the task closes 🟢,
before tasks_claim_next, an autonomous agent prints the verbatim
SESSION BOUNDARY line and stops instead of chaining the next task.
Absent -> behaviour unchanged.

- STATUS.md format: optional **Session break:** field + new
  "### session_break marker" subsection (type bool|string, examples).
- Task completion step 6: after close, before claim-next, check the
  closed task's session_break; print boundary line + stop if present.
- Rules bullet "Honour session_break".
- Wiki concept page concepts/using-tasks-session-break.md + index + log.

MINOR bump: new optional capability, no existing behaviour changed.
Closes [session-break-using-tasks].

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-09 16:34:13 +03:00

2.3 KiB

title, type, tags, updated
title type tags updated
using-tasks session_break marker concept
using-tasks
autonomous-runner
session-boundary
2026-06-09

using-tasks session_break marker

using-tasks v1.2.0 adds a session_break marker so a task author can mark a task's completion as a natural place to stop, rather than have an autonomous agent immediately chain into the next task via tasks_claim_next.

Problem

An autonomous runner closes a task and, by default, claims the next one. There is no signal for "this is a good seam to end the session" — so unrelated tracks get welded into one ever-growing context, and the natural review/hand-off moment is skipped.

Design

  • Marker: session_break in the task's frontmatter (task-system delivery) or the **Session break:** field in the task's STATUS.md block (local board mirror).
  • Type: boolean or string.
    • true → pause after close; next track is "see STATUS.md".
    • "<hint>" → pause after close; the hint names the recommended next track.
  • Enforcement point: using-tasks → Task completion, step 6after the task is 🟢 and committed, before any tasks_claim_next / starting the next task.
  • Behaviour when present: print the SESSION BOUNDARY line verbatim, then stop (do not claim the next task).
  • Behaviour when absent: unchanged — claim / start the next task as usual.

Verbatim message

🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]

[slug] = the closed task's slug. [value | "см. STATUS.md"] = the marker's string value, or the literal см. STATUS.md when the marker is just true. The wording is fixed so the boundary is greppable and recognisable across sessions.

Why a marker, not a heuristic

The decision of what counts as a stopping point belongs to whoever scoped the work (the delegating workshop), not to the runner mid-flight. A heuristic ("stop after N tasks", "stop when tired") would either over- or under-fire. An explicit, opt-in marker keeps the default unchanged and makes the boundary a deliberate authoring choice.

Versioning

MINOR bump (1.1.0 → 1.2.0): new optional capability, no existing behaviour changed.