daily — the one command to remember
Route the user to the right skill for their moment in the day. You are a router:
ask at most two short questions, then hand off. Do not do the station's work
yourself — the destination skill owns it.
Parse the argument first
(if any) selects a station. Match case-insensitively against the
station words and synonyms:
| Station | Words |
|---|
| START | , , , |
| WORK | , , , |
| FILE | , , , |
| REPORT | , , |
| WRAP | , , , , |
| SAVE | , , |
- Match a station word → jump straight to that station (no menu).
- Match a SAVE word → run the Save state flow (below). SAVE is NOT a
numbered station and never shows the menu; it captures the resume-point and
returns.
- No argument, or no match → show the menu. An unrecognized word is NEVER an
error; show the menu with a one-line note ("didn't recognize '<word>'").
Welcome back (read state, before the menu)
On
bare and on
, BEFORE showing the menu or handing
off to START, read the saved work-state. Run from any cwd inside the project:
bash
python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" show --json
-
If the output is the literal text
(a string, NOT JSON — it is
printed under both plain and
modes),
skip silently and go straight
to the menu / START. Never announce "no state."
-
Otherwise
the output and read
,
,
,
, and
. Compute the relative age yourself from
(e.g.
"2h ago") — it is NOT stored in the file. Then print one
welcome-back line,
the station in CAPS with its emoji, ticket if present:
Last session (2h ago): 🔧 WORK on #6125 — cause confirmed. Suggested next → grill-then-plan.
Station emoji: ☀️ START · 🔧 WORK · 📋 FILE · 📣 REPORT · 🌙 WRAP.
Then continue: on bare
go to
Auto board (below) before the menu; on
hand off to START. This is a read only — it never writes or commits.
Auto board (bare , after welcome-back)
On
bare only, after the welcome-back line (or after skipping it when
there is no state),
auto-render the work board as a supplement before the menu —
so the user sees their resume-point AND their open work in one glance, without
picking a station. Invoke the
skill (
; the
twin
only if the project is GitHub-context or the
user asks).
- If the board cannot load (not logged in / offline / not installed),
print a single line — "board unavailable: <reason>" — and continue. A board
failure must never block : the local log still shows. This is the
local-first / board-as-a-component property — the resume-point is always available,
even offline.
Then show the menu below. (
already renders the board as its station,
so it is unchanged; this only adds the board to the bare, no-argument path.)
The menu (bare /daily)
Present exactly five options and wait:
Where are you in your day?
1. ☀️ Starting my day — what's on my plate
2. 🔧 Working / stuck — route me to the right tool
3. 📋 Filing findings — turn findings into tickets
4. 📣 Reporting status — reshape work for leadership
5. 🌙 Wrapping up — daily summary from my commits
(Next time: /daily start · work · file · report · wrap)
💾 Save state anytime: /daily save "<note>"
The
line teaches the station shortcuts; the 💾 line teaches the save
accelerator — both graduate users from the menu. Save is a footer, not a sixth
option: the circle stays five stations (ADR 0004).
Stations
1. START
First run the
Welcome back read above (
daily-state.py show --json
) and, if
state exists, print the one-line welcome-back BEFORE the handoff — so the user sees
where they left off, then their board. Skip silently if there's no state.
Then invoke the
skill from the ado-backlog plugin
(
). Mention the GitHub equivalent (
's
) ONLY if the user asks for GitHub.
2. WORK
Ask ONE question — "What's happening?" — with these options, then hand off:
| The user is… | Hand off to |
|---|
| designing something new | |
| facing an effort too big for one session (foggy, multi-session) | () to chart it; () to continue a map already charted (maps live in ) |
| dealing with something broken | — then follow the debug chain below |
| advising how a system should work | |
| auditing names / labels / mappings | (or for as-is vs to-be) |
| explaining a complex problem | |
| asking why code/a ticket exists | |
| wanting a second opinion | (plans/local diffs) or (completed work) |
| reviewing a GitHub pull request | — context, safe workspace, scrutinize, then send-back / fix-it / chat-only |
| facing an unfamiliar legacy codebase | |
| facing an unfamiliar Dynamics 365 / Dataverse org | |
| wanting a repeatable test-case suite (feature / change / fixed bug) | |
Debug chain (ADRs 0003 + 0011): after
produces a diagnosis, ask:
"Does the fix involve a design choice (multiple viable approaches with
trade-offs)?"
- No (mechanical fix) → fix → → offer (regression case) → .
- Yes → to capture the decision FIRST → fix →
→ offer (regression case) → .
It runs both ways: if a user enters
directly to design a fix for
a current malfunction whose cause isn't verified yet, it hands off to
first, then grills against the confirmed cause (ADR 0011). The invariant either
way:
never plan a fix on an unverified cause.3. FILE
Get work into the tracker. Two shapes — pick by what the user has:
| The user has… | Hand off to |
|---|
| a batch of findings (audit / spreadsheet / review / pasted list) | — the extract → triage → classify → create pipeline |
| specific item(s) to create directly (one bug, a few stories, a ready list) | — files them straight into ADO |
Ask ONE question only if the shape is unclear:
"A batch of findings, or specific
tickets to create directly?" Default tracker is
ADO; if the user wants GitHub,
use the github-backlog twins —
findings-to-github-issues
or
.
Either route keeps the safety gates: a dry-run before any real create, and explicit
approval before writing to the org.
4. REPORT
5. WRAP
Invoke
. Run it every day — it builds the summary from git
commits, so a day without invoicing still yields a Tribletext-ready record.
After
finishes, write the end-of-day snapshot. Ask the user (in
one turn) for
,
, the active
(topic, ticket if any), and
the
step, then call:
bash
python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" set \
--station wrap --status <in-progress|blocked|paused|done> \
--topic "<what you were on>" --next-action "<next step>" \
[--ticket <id>] [--next-reason "<why>"] [--blocker "<text>" ...] \
--note "<end-of-day note>"
After the snapshot, offer the optional learn beat that closes the arc:
Harvest today's lessons into the workflow with /reflect? (y/n)
If the user accepts, hand off to the
skill; if they decline, skip
silently. Then run the
Commit offer below. This is the resume-point the next session
reads on
.
Save state (the action)
Reached by
,
, or
(see the argument
table) — and surfaced as the 💾 menu footer. NOT a station: it captures the
resume-point and returns; it never shows the menu or hands off to a station skill.
-
Find where it writes — show the user the resolved path so there are no
surprises:
bash
python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" resolve-path
The script resolves
flag →
env → git root
(
git rev-parse --show-toplevel
). If the script reports it is
not in a git
repo, ASK the user where to write (or to use cwd) and pass it via
;
never fail.
-
Write the state — pass only the fields you know; unset fields are preserved
(read-modify-write), and
is stamped by the script:
bash
python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" set \
--station <start|work|file|report|wrap> \
--status <in-progress|blocked|paused|done> \
--topic "<active work>" --next-action "<next step>" \
[--ticket <id>] [--next-reason "<why>"] [--blocker "<text>" ...] \
--note "<the note the user passed to /daily save>"
and
are the required fields; the rest are optional.
The note from
goes in
(appended to the body).
-
Offer commit (see below), then return to whatever the user was doing.
Commit offer (assisted, never automatic)
After ANY write (
or
), the skill writes the file first, then
explicitly asks — it never commits on its own:
Commit & push so the next session/machine sees it? (y/n)
- No / declined → leave the file on disk uncommitted. Done. (For a same-machine
resume this is usually fine — the file is already there.)
- Yes → stage only (never other files), commit, and push.
Git lives in the skill, never in the script. Respect this workspace's git rules:
if the resolved path is a non-repo root or one of several sub-repos, confirm the
target repo with the user before committing.
Graceful degradation
Stations 1 and 3 route to skills in OTHER plugins. If the target plugin is not
installed, say so explicitly and print the install command for the user's harness —
never fail silently:
ado-backlog is not installed. Install it with:
- Claude Code: /plugin install ado-backlog@workflow-daily-work
- Antigravity: stage the ado-backlog skills into your skills dir
(see the plugin's .antigravity/INSTALL.md)
Rules
- At most two questions before handoff (station + the one station question).
- Never do the destination skill's job inline.
- Unknown argument → menu, never an error. // route to
the Save flow, not a station.
- The work-state file is read on bare and , and written on
and . owns ALL YAML; the skill owns
git. Reads never write; writes always offer commit and never commit unprompted.
- A bundled PreToolUse hook (, registered in
) also appends every message to
(via ) — active automatically on plugin enable,
best-effort, and it never blocks a commit. So is fed both by on
save/wrap AND automatically by each commit.
- If prints , skip the welcome-back silently —
it is never an error.
- The full map lives in PLAYBOOK.md at the marketplace repo root — for humans;
this skill is self-contained and never needs to read it.