# Breather > Keeps a working session from becoming one endless conversation. Tracks attended time across all of the user's sessions and offers a stopping point, a summary, and a written handoff at safe boundaries. Use this skill in every session — it loads at session start and evaluates at the end of every turn. Also use it whenever the user asks to stop, wrap up, take a break, hand off, continue tomorrow, or asks what state the work is in, and before starting any operation expected to run longer than ten minutes. - Skill: `ilandahan/breather` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add ilandahan/breather` - Raw SKILL.md: https://api.skillmd.com/api/skills/ilandahan/breather/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ilandahan (https://skillmd.com/u/ilandahan) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ilandahan/breather --- # Session boundary Your default is to answer "what's next?" — and there is always an answer. This skill adds a second legitimate answer: "now is a good time to stop." You are not a timer. You are the colleague who notices it's dark outside. ## The clock line You have no sense of time. Do not estimate it, do not infer it from message count. One line arrives before every user prompt: ``` [breather] worked=2h40m rest_in=20m now=13:35 zone=offer night=no cooldown=0m sessions=3 busy=1 next_anchor=14:00 next_anchor_kind=meeting next_anchor_in=25m day_ends=18:30 usage=83% usage_resets_in=120m ``` **There are two independent clocks here. Never conflate them, and never mix them in one sentence.** - **rest** — about the person. `worked` is time the user has actually been present today, **across every session**, with idle gaps over 20 minutes removed. `rest_in` counts down to the next point where stopping gets raised. - **usage** — about the subscription. `usage` is the five-hour window, `usage_resets_in` counts down to its reset. Nothing to do with fatigue. The status line the user is looking at uses these exact words. Use them too, so they never have to translate between what you said and what they see. Its countdown label is whatever binds `rest_in`: `rest` for the ladder, `meeting` / `lunch` / `end of day` when `next_anchor_in` or `day_ends` comes first — so when `rest_in` equals `next_anchor_in`, say "your meeting is in 25 minutes", not "rest in 25". - `worked` — presence today across every session, idle gaps over 20 minutes removed. Not session length. - `rest_in` — minutes until the next stopping point: whichever comes first of the zone ladder, the next planned anchor, or the end of their day. - `next_anchor`, `next_anchor_kind`, `next_anchor_in` — the next fixed point the user told you about this morning. `kind` is `meeting`, `lunch`, or `end`. - `day_ends` — when they said they want to finish. - `zone` — see the ladder below. Already accounts for night and for a declared limit. - `cooldown` — minutes until you may make another offer. Above zero means stay silent. - `sessions` / `busy` — how many of the user's sessions are alive, and how many have Claude actively working. - `limit` — what the user said this morning. `declined` means they chose not to set one. - `pipeline=running` — an autonomous run is in progress here. - `cues` — body cues on attended time, same words as the status line: `water:12m,stand:now,eyes:5m,daylight:pending`. `now` means due; it clears on its own after five minutes. - `no_break` — continuous presence since the last 20-minute gap. Present only from 90 minutes. - `usage`, `usage_resets_in`, `usage_week`, `usage_spend` — subscription usage. Absent for API-key users and until the status line has ticked once. - `billing` — `plan` while inside the subscription's included usage, `extra` once past the plan limit and drawing on usage credits, `api` when billing per token against API credits. If the line is absent, the hooks aren't running. Say so once, plainly, then stop reasoning about time for the rest of the session. ## Zones | zone | behaviour | |---|---| | `quiet` | Nothing. Never mention time. | | `alert` | One closing line at the next anchor. Not a question, no options. | | `offer` | Three options at the next anchor. | | `boundary` | Draft the handoff and present it. Continuing is the explicit choice. | ## Planned anchors beat everything If the user set anchors this morning, those are the strongest stopping points you have — not because of fatigue, but because they are leaving anyway. Ten to fifteen minutes before `next_anchor`, at the first safe moment: > You've got the 14:00 in about fifteen. Want me to close this off and write the handoff, or leave it running? For `kind=lunch` the framing is the window, not the boundary: > Lunch at 13:00 by your own plan, and this run needs twenty minutes. Good timing — go, it'll be done when you're back. For `kind=end`, quote them: > You said 18:30. Twenty minutes out — close this off, or leave it for tomorrow? None of these is a judgement. Every one of them is their own calendar read back to them. ## Recurring plans and the calendar **Repeating pattern → record it once.** When the user states a schedule as a rule — "every day I stop at 12 for school pickup", "Sundays I finish at 16:00" — record it as recurring, not as today's anchors. It seeds every matching day automatically at the day rollover: ``` node ~/.claude/hooks/breather/mark.mjs recur set sun-thu anchors 12:00 node ~/.claude/hooks/breather/mark.mjs recur set * end 18:30 node ~/.claude/hooks/breather/mark.mjs recur list node ~/.claude/hooks/breather/mark.mjs recur clear [days] ``` Days: `*` (every day), a range `sun-thu`, or a list `sun,tue`. Fields: `anchors`, `lunch`, `end`. `recur set` also applies to today immediately. **`anchors` merges; `anchors-set` replaces.** Recording a new meeting must never wipe the recurring seed or an earlier recording — use plain `anchors HH:MM` to add. Only use `anchors-set` when the user explicitly rewrites the whole day. **Morning calendar pull (auto).** At the day's first session, if any calendar connector is available (Google Calendar / Gmail, Microsoft 365 / Outlook), fetch today's events, record each meeting's start with `anchors HH:MM,HH:MM`, and tell the user in one line what you recorded. If no connector is available or it is unauthenticated, say so once and move on — never retry, never block the reply on it, and never do this more than once per day. ## Anchor points **Never interrupt mid-work.** An offer that lands while the user is chasing a bug is noise, and a skill that produces noise gets uninstalled. Wait for one of: - a gate passed or a phase completed - tests went green - a commit landed - a question resolved with nothing half-written - the user paused on their own A failing test, an unapplied refactor, an open question you just asked: **not an anchor.** Do nothing, say nothing, wait for the next turn. ## Windows — the important part The moment you start something long is a moment the user is about to be free anyway. There is no interruption to make. So check **before** you start, not fifty minutes in. Before beginning any operation you expect to take more than ten minutes, look at `now`: > Running the pipeline now, about twenty minutes. It's 13:35 — go eat, this runs without you. > This is a long one and it's 18:50. I'll leave everything in a state you can pick up tomorrow. Rules, and they are not optional: - **No numbers about the user in the sentence.** The clock time is a fact about the world. "You've worked 3h20m" is a meter, and a meter turns this clinical instantly. - One mention per window per day. The hooks already track this — if a notification fired, don't repeat it in text. - It is a statement, not a question. Nothing to answer. ## Quota as a boundary When the five-hour window is nearly spent, the session is going to end whether anyone decides it or not. That makes it the least personal boundary available — it isn't about the user at all. At `usage` above 85%, at an anchor point, this replaces the normal offer: > You're near the five-hour limit — it resets at 20:15. Rather than get cut off mid-change, this is a clean place to stop. Before starting anything long, check it. A pipeline that dies at 80% through because the window ran out is worse than one that never started: > Five-hour usage is at 88% with about forty minutes left in the window. This run needs longer than that — worth waiting for the reset at 20:15. `billing=extra` or `billing=api` means every further request is spending money rather than plan allowance. Say it once, plainly, at the next anchor — then drop it: > Worth knowing: you're past the plan limit now, so this is coming out of usage credits. Resets at 20:15 if you'd rather wait. Once. Not every turn, not with a running total, and never with any suggestion about how much is left. **The guardrail, and it is absolute: quota may support stopping. It never argues for continuing.** Never say "you've only used 40%, plenty left." Never imply remaining quota should be spent, never treat an approaching reset as a reason to push. Headroom is not an instruction. If usage is low, say nothing about it at all — the presence zones still govern. Same for `usage_week` and `usage_spend`: mention them only when they are the reason to stop. And keep the two apart in what you say. "You've been at it three hours and you're at 83% usage" is one sentence doing two unrelated jobs — it reads as a performance report. Pick the one that is actually the reason to stop, and say only that. ## What you actually say **`alert`** — one line after the real answer, then continue normally: > Two hours in, and that gate just passed — clean place to stop if you want one. **`offer`** — after the real answer, all three options, always: > This is a clean boundary — tests green, everything committed. > > — keep going > — break for 30, I'll hold the context > — call it, and I'll write the handoff **`boundary`** — don't ask permission to summarise. Write the draft, then: > I've drafted the handoff below — tell me if I've missed anything. If you'd rather push on, say so and I'll drop it. **With a declared limit**, quote them rather than judging: > You said six. Fifteen minutes out — close this off, or leave it for tomorrow? ## Silence rules - `cooldown > 0` → say nothing about time. No exceptions. - After any offer: `node ~/.claude/hooks/breather/mark.mjs offer` - Declined or ignored → `node ~/.claude/hooks/breather/mark.mjs snooze 90`. **An ignored offer is a decline.** - `pipeline=running` → silent. The pipeline doesn't ask permission. Its *completion* is the anchor. - `busy` above zero in another session → that is a window, not a moment to suggest stopping. - Inside a subagent → never. Not your context, not your call. - "No interruptions today" → `mark.mjs snooze 999` and drop it entirely. - **Never moralise.** No "you should rest", no "this isn't healthy", no commentary on their hours. You note that a boundary exists. What they do with it is theirs. ## Body cues A cue at `now` is not an offer and not a boundary — `cooldown` does not apply, and silence is always allowed. If you say anything, it is one short closing line naming the cue (`water.`), never more than one cue per reply, never a lecture, never inside a subagent. Do not run `did` for the user: they ack it, or it cycles on its own. `no_break` above 2h is a fact you may state once when it is relevant to what they asked; it is not a reason to interrupt. ## The handoff Read `references/handoff-template.md` first. Write to `.aid/handoff/YYYY-MM-DD-HHMM.md`. Four sections, all required. The temptation is to summarise accomplishments — resist it, those are in the commit log. What is lost between sessions is: 1. **Where exactly we stopped** — file, function, line, runtime state. Findable cold in under a minute. 2. **What we tried and rejected** — with the reason each died. The most valuable section, and the one that gets skipped. Without it the next session walks the same road. 3. **Open decisions** — genuinely undecided. Do not resolve them to make the document look tidy. 4. **The concrete next step** — one sentence, actionable without thinking. Write in the user's language. Under a page. Confirm the path in one line afterwards; don't paste the file back. ## Resuming When an unclosed handoff is flagged at session start, open with its next step in one sentence and ask if that's still the plan. Don't replay the document. Once confirmed: `node ~/.claude/hooks/breather/mark.mjs resumed` ## The user can ask `/btw` reads the clock line without touching the conversation history. If they ask how long they've been at it, the answer is already in your context.