Back to Details

daily

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

daily — the one command to remember

daily — 只需记住这一个命令

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.
根据用户当前的工作阶段，将其路由到对应的skill。你是一个路由工具：最多提出两个简短问题，然后转交任务。不要自行完成对应阶段的工作——目标skill负责处理这些工作。

Parse the argument first

优先解析参数

$ARGUMENTS
(if any) selects a station. Match case-insensitively against the station words and synonyms:
StationWords
START
start
, 
morning
, 
begin
, 
plate
WORK
work
, 
working
, 
stuck
, 
doing
FILE
file
, 
filing
, 
findings
, 
tickets
REPORT
report
, 
status
, 
update
WRAP
wrap
, 
done
, 
end
, 
finish
, 
invoice
SAVE
save
, 
pause
, 
checkpoint
  • 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>'").
$ARGUMENTS
（如果存在）用于选择阶段。不区分大小写匹配阶段词汇及其同义词：
阶段匹配词汇
START
start
, 
morning
, 
begin
, 
plate
WORK
work
, 
working
, 
stuck
, 
doing
FILE
file
, 
filing
, 
findings
, 
tickets
REPORT
report
, 
status
, 
update
WRAP
wrap
, 
done
, 
end
, 
finish
, 
invoice
SAVE
save
, 
pause
, 
checkpoint
  • 匹配到阶段词汇 → 直接跳转到该阶段（不显示菜单）。
  • 匹配到SAVE词汇 → 执行「保存状态」流程（见下文）。SAVE不属于编号阶段，且永远不会显示菜单；它仅记录恢复点后返回。
  • 无参数或无匹配 → 显示菜单。未识别的词汇永远不会视为错误；显示菜单时附带一行提示（“未识别 '<word>'”）。

Welcome back (read state, before the menu)

欢迎回归（读取状态，在菜单之前）

On bare 
/daily
 and on 
/daily start
, 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 
    no state yet
    (a string, NOT JSON — it is printed under both plain and 
    --json
    modes), skip silently and go straight to the menu / START. Never announce "no state."
  • Otherwise 
    json.loads
    the output and read 
    updated
    , 
    station
    , 
    status
    , 
    focus
    , and 
    next
    . Compute the relative age yourself from 
    updated
    (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 
/daily
go to Auto board (below) before the menu; on 
/daily start
hand off to START. This is a read only — it never writes or commits.
当执行**无参数的
/daily
或
/daily start
**时，在显示菜单或转交至START阶段之前，先读取已保存的工作状态。在项目内任意工作目录运行：
bash
python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" show --json
  • 如果输出是字面文本
    no state yet
    （字符串，而非JSON——在普通模式和
    --json
    模式下均会打印），则静默跳过，直接进入菜单/START阶段。永远不要提示“无状态”。
  • 否则使用
    json.loads
    解析输出，读取
    updated
    、
    station
    、
    status
    、
    focus
    和
    next
    字段。自行根据
    updated
    计算相对时长（例如“2小时前”）——该值不会存储在文件中。然后打印一行欢迎回归信息，阶段名称大写并附带对应emoji，若存在工单则一并显示：
    上次会话（2小时前）：🔧 WORK 处理 #6125 — 原因已确认。建议下一步 → grill-then-plan.
    阶段对应emoji：☀️ START · 🔧 WORK · 📋 FILE · 📣 REPORT · 🌙 WRAP.
之后继续执行：无参数
/daily
会先进入下文的「自动看板」，再显示菜单；
/daily start
则直接转交至START阶段。此操作仅为读取——不会写入或提交任何内容。

Auto board (bare 
/daily
, after welcome-back)

自动看板（无参数
/daily
，欢迎回归之后）

On bare 
/daily
 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 
my-work
 skill (
ado-backlog:my-work
; the 
github-backlog
twin 
github-my-work
only if the project is GitHub-context or the user asks).
  • If the board cannot load (not logged in / offline / 
    ado-backlog
    not installed), print a single line — "board unavailable: <reason>" — and continue. A board failure must never block 
    /daily
    : 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. (
/daily start
already renders the board as its station, so it is unchanged; this only adds the board to the bare, no-argument path.)
仅在执行无参数
/daily
时，在欢迎回归信息之后（或无状态时跳过该信息之后），在显示菜单前自动渲染工作看板作为补充——让用户一眼看到自己的恢复点和未完成工作，无需选择阶段。调用**
my-work
** skill（
ado-backlog:my-work
；若项目为GitHub环境或用户要求，则使用github-backlog的对应工具
github-my-work
）。
  • 如果看板无法加载（未登录/离线/未安装
    ado-backlog
    ），打印一行提示——“看板不可用：<原因>”，然后继续执行。看板加载失败绝不能阻塞
    /daily
    ：本地日志仍会显示。这是本地优先/看板作为组件的特性——即使离线，恢复点始终可用。
之后显示下文的菜单。（
/daily start
会在其阶段内渲染看板，因此无变化；此步骤仅为无参数路径添加看板功能。）

The menu (bare /daily)

菜单（无参数
/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 
Next time
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).
展示恰好五个选项并等待用户选择：
你当前处于工作的哪个阶段？

  1. ☀️  开启我的一天      — 查看今日待办
  2. 🔧  工作中/遇到阻碍      — 为我路由到合适工具
  3. 📋  整理工作成果      — 将成果转化为工单
  4. 📣  汇报工作状态     — 为管理层梳理工作内容
  5. 🌙  收尾今日工作          — 根据提交记录生成每日总结

下次可直接使用：/daily start · work · file · report · wrap
💾 随时保存状态：/daily save "<备注>"
“下次可直接使用”一行用于教授阶段快捷指令；💾一行用于教授保存快捷键——两者帮助用户脱离菜单操作。保存是页脚提示，而非第六个选项：始终保持五个阶段（ADR 0004）。

Stations

各阶段详情

1. START

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 
my-work
 skill from the ado-backlog plugin (
ado-backlog:my-work
). Mention the GitHub equivalent (
github-backlog
's 
github-my-work
) ONLY if the user asks for GitHub.
首先执行上文的「欢迎回归」读取操作（
daily-state.py show --json
），若存在状态，在转交任务前打印一行欢迎回归信息——让用户看到之前的进度，再查看看板。无状态则静默跳过。
然后调用ado-backlog插件中的**
my-work
** skill（
ado-backlog:my-work
）。仅当用户要求GitHub时，才提及GitHub的等效工具（github-backlog的
github-my-work
）。

2. WORK

2. WORK

Ask ONE question — "What's happening?" — with these options, then hand off:
The user is…Hand off to
designing something new
grill-then-plan
facing an effort too big for one session (foggy, multi-session)
chart-map
(
/decision-map:chart
) to chart it; 
work-map
(
/decision-map:work
) to continue a map already charted (maps live in 
docs/decision-map/
)
dealing with something broken
debug-mantra
— then follow the debug chain below
advising how a system should work
study-design-verify
auditing names / labels / mappings
naming-audit
(or 
fit-gap-analysis
for as-is vs to-be)
explaining a complex problem
problem-description
asking why code/a ticket exists
ticket-trace
wanting a second opinion
scrutinize
(plans/local diffs) or 
dual-verifier
(completed work)
reviewing a GitHub pull request
review-pr
— context, safe workspace, scrutinize, then send-back / fix-it / chat-only
facing an unfamiliar legacy codebase
drive-to-legacy
facing an unfamiliar Dynamics 365 / Dataverse org
crm-archaeology
wanting a repeatable test-case suite (feature / change / fixed bug)
generating-test-cases
Debug chain (ADRs 0003 + 0011): after 
debug-mantra
produces a diagnosis, ask: "Does the fix involve a design choice (multiple viable approaches with trade-offs)?"
  • No (mechanical fix) → fix → 
    post-mortem
    → offer 
    generating-test-cases
    (regression case) → 
    management-talk
    .
  • Yes → 
    grill-then-plan
    to capture the decision FIRST → fix → 
    post-mortem
    → offer 
    generating-test-cases
    (regression case) → 
    management-talk
    .
It runs both ways: if a user enters 
grill-then-plan
directly to design a fix for a current malfunction whose cause isn't verified yet, it hands off to 
debug-mantra
first, then grills against the confirmed cause (ADR 0011). The invariant either way: never plan a fix on an unverified cause.
提出一个问题——“当前情况是？”，提供以下选项，然后转交任务：
用户当前正在…转交至
设计新功能
grill-then-plan
面对超出单会话处理范围的任务（模糊、需多会话完成）
chart-map
（
/decision-map:chart
）用于梳理任务；
work-map
（
/decision-map:work
）用于继续已梳理的任务（任务图存储在
docs/decision-map/
）
处理故障问题
debug-mantra
— 然后遵循下文的调试流程
提供系统工作方式建议
study-design-verify
审核命名/标签/映射关系
naming-audit
（或使用
fit-gap-analysis
对比现状与目标状态）
解释复杂问题
problem-description
询问代码/工单存在的原因
ticket-trace
需要第二意见
scrutinize
（针对计划/本地差异）或
dual-verifier
（针对已完成工作）
审核GitHub拉取请求
review-pr
— 提供上下文、安全工作区、审核功能，然后支持退回/修复/仅沟通
面对不熟悉的遗留代码库
drive-to-legacy
面对不熟悉的Dynamics 365 / Dataverse组织
crm-archaeology
需要可重复的测试用例套件（功能/变更/修复的Bug）
generating-test-cases
调试流程（ADRs 0003 + 0011）： 在
debug-mantra
得出诊断结果后，询问： “修复是否涉及设计选择（存在多种可行方案且需权衡利弊）？”
  • 否（机械性修复） → 修复 → 
    post-mortem
    → 提供
    generating-test-cases
    （回归用例） → 
    management-talk
    。
  • 是 → 先使用
    grill-then-plan
    记录决策 → 修复 → 
    post-mortem
    → 提供
    generating-test-cases
    （回归用例） → 
    management-talk
    。
此流程双向生效：如果用户直接进入
grill-then-plan
为当前未确认原因的故障设计修复方案，会先转交至
debug-mantra
，再针对已确认的原因进行梳理（ADR 0011）。无论哪种情况，不变原则是：绝不在未验证原因的情况下规划修复方案。

3. FILE

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)
findings-to-ado-backlog
— the extract → triage → classify → create pipeline
specific item(s) to create directly (one bug, a few stories, a ready list)
ado-create-work-items
— 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 
github-create-issues
. Either route keeps the safety gates: a dry-run before any real create, and explicit approval before writing to the org.
将工作内容录入跟踪系统。根据用户现有内容选择两种方式：
用户现有…转交至
批量成果（审核/表格/评审/粘贴的列表）
findings-to-ado-backlog
— 提取 → 分类 → 归类 → 创建的流水线
需直接创建的特定事项（一个Bug、几个故事、已准备好的列表）
ado-create-work-items
— 直接录入ADO
仅当内容类型不明确时提出一个问题：“是批量成果，还是需直接创建特定工单？” 默认跟踪系统为ADO；若用户需要GitHub，则使用github-backlog的对应工具——
findings-to-github-issues
或
github-create-issues
。两种方式均保留安全机制：实际创建前会进行试运行，且写入组织前需明确确认。

4. REPORT

4. REPORT

Invoke 
management-talk
.
调用
management-talk
。

5. WRAP

5. WRAP

Invoke 
invoice-generator
. Run it every day — it builds the summary from git commits, so a day without invoicing still yields a Tribletext-ready record.
After 
invoice-generator
finishes, write the end-of-day snapshot. Ask the user (in one turn) for 
station
, 
status
, the active 
focus
(topic, ticket if any), and the 
next
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 
reflect
skill; if they decline, skip silently. Then run the Commit offer below. This is the resume-point the next session reads on 
/daily start
.
调用
invoice-generator
。每日运行一次——它会根据git提交记录生成总结，即使当天无需开票，也会生成可用于Tribletext的记录。
invoice-generator
完成后，写入当日结束快照。向用户一次性询问
station
、
status
、当前
focus
（主题，若有则包含工单）和
next
步骤，然后调用：
bash
python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" set \
  --station wrap --status <in-progress|blocked|paused|done> \
  --topic "<当前工作内容>" --next-action "<下一步操作>" \
  [--ticket <工单ID>] [--next-reason "<原因>"] [--blocker "<阻塞原因>" ...] \
  --note "<当日结束备注>"
快照完成后，提供可选的「复盘」环节以结束流程：
是否将今日经验整合到工作流中？使用/reflect？(y/n)
如果用户同意，转交至
reflect
skill；若拒绝，则静默跳过。然后执行下文的「提交建议」。此快照将作为下次会话执行
/daily start
时读取的恢复点。

Save state (the 
save
action)

保存状态（
save
操作）

Reached by 
/daily save
, 
/daily pause
, or 
/daily checkpoint
(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.
  1. 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 
    --path
    flag → 
    DAILY_STATE_FILE
    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 
    --path
    ; never fail.
  2. Write the state — pass only the fields you know; unset fields are preserved (read-modify-write), and 
    updated
    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>"
    --topic
    and 
    --next-action
    are the required fields; the rest are optional. The note from 
    /daily save "<note>"
    goes in 
    --note
    (appended to the body).
  3. Offer commit (see below), then return to whatever the user was doing.
通过
/daily save
、
/daily pause
或
/daily checkpoint
触发（见参数表格）——并作为💾菜单页脚显示。这不属于阶段：它仅记录恢复点后返回；永远不会显示菜单或转交至阶段skill。
  1. 显示写入路径 — 向用户展示解析后的路径，避免意外：
    bash
    python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" resolve-path
    脚本会依次解析
    --path
    参数 → 
    DAILY_STATE_FILE
    环境变量 → git根目录（
    git rev-parse --show-toplevel
    ）。如果脚本报告不在git仓库中，询问用户写入位置（或使用当前工作目录），并通过
    --path
    参数传递；绝不能执行失败。
  2. 写入状态 — 仅传递已知字段；未设置的字段将保留（读取-修改-写入），
    updated
    字段由脚本自动标记：
    bash
    python "${CLAUDE_PLUGIN_ROOT}/scripts/daily-state.py" set \
  --station <start|work|file|report|wrap> \
  --status <in-progress|blocked|paused|done> \
  --topic "<当前工作>" --next-action "<下一步操作>" \
  [--ticket <工单ID>] [--next-reason "<原因>"] [--blocker "<阻塞原因>" ...] \
  --note "<用户传递给/daily save的备注>"
    --topic
    和
    --next-action
    为必填字段；其余为可选字段。
    /daily save "<备注>"
    中的备注会放入
    --note
    字段（追加到内容末尾）。
  3. 提供提交建议（见下文），然后返回至用户之前的操作。

Commit offer (assisted, never automatic)

提交建议（辅助操作，绝不自动执行）

After ANY write (
save
or 
wrap
), 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 
    daily-state.md
    (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.
在任何写入操作（
save
或
wrap
）后，工具会先写入文件，然后明确询问——绝不会自动提交：
是否提交并推送，以便下次会话/其他设备可以看到？(y/n)
  • 否/拒绝 → 保留磁盘上的文件不提交。操作完成。（对于同一设备的恢复，通常已足够——文件已存在。）
  • 是 → 仅暂存
    daily-state.md
    （绝不处理其他文件），提交并推送。Git操作由工具处理，而非脚本。遵循工作区的git规则：如果解析后的路径是非仓库根目录或多个子仓库之一，提交前需与用户确认目标仓库。

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)
(Same pattern for 
github-backlog
.)
阶段1和3会路由到其他插件中的skill。如果目标插件未安装，明确告知用户并打印适用于其工具的安装命令——绝不能静默失败：
ado-backlog未安装。可通过以下方式安装：
- Claude Code:  /plugin install ado-backlog@workflow-daily-work
- Antigravity:  将ado-backlog skills部署到你的skills目录
                （详见插件的.antigravity/INSTALL.md）
（
github-backlog
遵循相同模式。）

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. 
    save
    /
    pause
    /
    checkpoint
    route to the Save flow, not a station.
  • The work-state file is read on bare 
    /daily
    and 
    /daily start
    , and written on 
    /daily save
    and 
    /daily wrap
    . 
    daily-state.py
    owns ALL YAML; the skill owns git. Reads never write; writes always offer commit and never commit unprompted.
  • A bundled PreToolUse hook (
    hooks/commit-log.py
    , registered in 
    hooks/hooks.json
    ) also appends every 
    git commit
    message to 
    daily-state.md
    ## Log
    (via 
    daily-state.py log
    ) — active automatically on plugin enable, best-effort, and it never blocks a commit. So 
    ## Log
    is fed both by 
    --note
    on save/wrap AND automatically by each commit.
  • If 
    daily-state.py show
    prints 
    no state yet
    , 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.
  • 转交任务前最多提出两个问题（阶段选择 + 阶段内的一个问题）。
  • 绝不内联执行目标skill的工作。
  • 未知参数 → 显示菜单，绝不视为错误。
    save
    /
    pause
    /
    checkpoint
    路由到保存流程，而非阶段。
  • 工作状态文件在无参数
    /daily
    和
    /daily start
    时读取，在
    /daily save
    和
    /daily wrap
    时写入。
    daily-state.py
    负责所有YAML操作；工具负责Git操作。读取操作绝不写入；写入操作始终提供提交建议，绝不未提示就提交。
  • 内置的PreToolUse钩子（
    hooks/commit-log.py
    ，在
    hooks/hooks.json
    中注册）会将每个
    git commit
    消息追加到
    daily-state.md
    的
    ## Log
    部分（通过
    daily-state.py log
    ）——启用插件后自动激活，尽最大努力执行，且绝不会阻塞提交。因此
    ## Log
    内容既来自保存/收尾时的
    --note
    ，也来自每次提交的自动追加。
  • 如果
    daily-state.py show
    输出
    no state yet
    ，静默跳过欢迎回归环节——这绝不是错误。
  • 完整的流程映射位于市场仓库根目录的PLAYBOOK.md中——供人类查看；本工具是自包含的，无需读取该文件。