用途：在用户需要为某个 Linear 项目撰写当日收尾/晚间“build-in-public”动态时使用。该技能把一天原始工作转成简短、高信号量的更新，强调进展、决策与解除的阻塞，而不是活动量；它不是演示，也不是状态报告，读者是 PM/项目负责人而非开发同事。
主要能力：以 Linear 项目为范围锚点，先用项目 ID 解析出项目名与团队；拉取当天该项目中指派给本人且发生变动的 issue，按已交付与进行中拆分；结合 git/PR 作为交付证据，并用 devsql 本地会话历史补充决策理由与无外部输出的埋头工作日。随后按规则合成：以共享基础/前置工作为标题、描述“现在为真”的移动而非努力、至少一条连接到业务解锁点、决策要带“因为 Z”的理由、每条具体事项尾部附工作项标签。
使用方式：项目以 $ARGUMENTS 传入；未给项目 ID 时先索取。文档给出的命令包括：linear project view "$ARGUMENTS" --json | jq -r '{name, team: .teams.nodes[0].key}'；linear issue query --project "<name>" --assignee "@me" --updated-after "$(date +%F)" --all-states --limit 50 --json；gh pr list --author "@me" --state all --search "updated:>=$(date +%F)"；git log --author="$(git config user.email)" --since="00:00" --oneline；以及 devsql 查询本地当日会话。
输出与限制：最终产出一个可粘贴的 markdown 代码块，标题为首名加日期，正文用 • 列 2-3 条完整要点，结尾按情况用单行 ⏭️ Next 或 ◦ 子条目（含交接或 🚧 阻塞）。约束包括：不要写“开始/着手”类表述；不要捏造活动、功能、指标或理由；PR/提交必须映射到本项目内的 Linear issue；来源不可用时改为请用户粘贴内容；jargon 与活动堆砌被明确禁止。若 humanizer 不可用，可原样交付草稿。