daily-standup

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Morning Standup

每日站会

Compile Benjamin's personal actionable todo list for today from Jira, Slack, and GitHub.

Key principle: Every item in the output must represent something Benjamin personally needs to act on today. If a ticket is assigned to someone else, already resolved, or doesn't require Benjamin's action — exclude it.

从Jira、Slack和GitHub中收集Benjamin的个人可执行今日待办事项列表。

核心原则： 输出中的每一项都必须代表Benjamin今日需要亲自执行的任务。如果工单已分配给他人、已解决，或不需要Benjamin采取行动——请将其排除。

Configuration

配置

yaml

jira:
  cloudId: "4a4bd20b-0645-4d11-9c98-8d0285630fd4"
  userId: "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08"
  baseUrl: "https://hgdata.atlassian.net/browse/"
  projects:
    - key: RGI
      board: 1236
    - key: MITB
      board: 1036
      label: Engineering-Applications

slack:
  supportChannel: "C09E1666N78"  # eng-applications-support
  userId: "U09ATNQ9UV7"  # Benjamin Gelis
  priorityUsers:
    - Claire Renaud
    - Matthieu Courtin

github:
  username: "BenjaminG"
  orgs:
    - MadKudu
    - HGData

persistence:
  directory: "~/.claude/standups"
  format: "YYYY-MM-DD.md"

yaml

jira:
  cloudId: "4a4bd20b-0645-4d11-9c98-8d0285630fd4"
  userId: "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08"
  baseUrl: "https://hgdata.atlassian.net/browse/"
  projects:
    - key: RGI
      board: 1236
    - key: MITB
      board: 1036
      label: Engineering-Applications

slack:
  supportChannel: "C09E1666N78"  # eng-applications-support
  userId: "U09ATNQ9UV7"  # Benjamin Gelis
  priorityUsers:
    - Claire Renaud
    - Matthieu Courtin

github:
  username: "BenjaminG"
  orgs:
    - MadKudu
    - HGData

persistence:
  directory: "~/.claude/standups"
  format: "YYYY-MM-DD.md"

Execution Steps

执行步骤

1. Gather Slack Data

1. 收集Slack数据

Query #eng-applications-support channel:

mcp__slack__conversations_history channel_id: "C09E1666N78" limit: "15"

From the results:

When priority recaps contain multiple team sections (Applications, Data, Core, etc.), only extract items under the Applications section — that is Benjamin's team. Ignore Data, Core, and other sections.
Note any unresolved @mentions of Benjamin (U09ATNQ9UV7)
Note any questions or requests directed at Benjamin or his team that need a response
Collect all Jira issue keys mentioned in Slack messages for validation in step 3

查询#eng-applications-support频道：

mcp__slack__conversations_history channel_id: "C09E1666N78" limit: "15"

从结果中：

当优先级回顾包含多个团队板块（应用、数据、核心等）时，仅提取应用板块下的内容——这是Benjamin的团队。忽略数据、核心及其他板块。
记录所有未回复的@Benjamin（U09ATNQ9UV7）提及
记录所有指向Benjamin或其团队、需要回复的问题或请求
收集Slack消息中提到的所有Jira问题编号，用于步骤3的验证

2. Gather Jira Data

2. 收集Jira数据

RGI Project — All non-Done issues assigned to Benjamin:

bash

acli jira workitem search --jql 'project = RGI AND assignee = "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08" AND status not in (Done)' --fields "key,summary,status,priority" --csv

MITB Project — Only issues with Engineering-Applications label assigned to Benjamin:

bash

acli jira workitem search --jql 'project = MITB AND assignee = "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08" AND status not in (Done) AND labels = "Engineering-Applications"' --fields "key,summary,status,priority" --csv

For each issue returned, fetch details, full comments, and attachments to build comprehensive context.

Important: Fetch all issue data in a single Bash call using a loop rather than individual parallel calls, to avoid cascading failures when one call errors:

bash

mkdir -p /tmp/standup-attachments
for key in KEY1 KEY2 KEY3; do
  echo "=== $key ==="
  acli jira workitem view $key --json 2>&1 | jq '{key: .key, status: .fields.status.name, priority: .fields.priority.name, assignee: .fields.assignee.displayName, summary: .fields.summary}'
  echo "--- comments ---"
  acli jira workitem comment list --key $key --json 2>&1
  echo "--- attachments ---"
  acli jira workitem attachment list --key $key --json 2>&1
  echo
done

Processing attachments: For issues that have image attachments (png, jpg, gif, webp), download the most recent 2-3 images per issue:

bash

undefined

RGI项目 —— 所有分配给Benjamin且未完成的工单：

bash

acli jira workitem search --jql 'project = RGI AND assignee = "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08" AND status not in (Done)' --fields "key,summary,status,priority" --csv

MITB项目 —— 仅包含分配给Benjamin且带有Engineering-Applications标签的工单：

bash

acli jira workitem search --jql 'project = MITB AND assignee = "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08" AND status not in (Done) AND labels = "Engineering-Applications"' --fields "key,summary,status,priority" --csv

对于每个返回的工单，获取详情、完整评论和附件，以构建全面的上下文信息。

重要提示： 使用循环通过单次Bash调用获取所有工单数据，而非单独的并行调用，以避免因单次调用失败导致的连锁故障：

bash

mkdir -p /tmp/standup-attachments
for key in KEY1 KEY2 KEY3; do
  echo "=== $key ==="
  acli jira workitem view $key --json 2>&1 | jq '{key: .key, status: .fields.status.name, priority: .fields.priority.name, assignee: .fields.assignee.displayName, summary: .fields.summary}'
  echo "--- comments ---"
  acli jira workitem comment list --key $key --json 2>&1
  echo "--- attachments ---"
  acli jira workitem attachment list --key $key --json 2>&1
  echo
done

处理附件： 对于包含图片附件（png、jpg、gif、webp）的工单，下载每个工单的最新2-3张图片：

bash

undefined

For each image attachment found in the JSON output above:

针对上述JSON输出中找到的每个图片附件：

curl -L -u "$JIRA_EMAIL:$JIRA_API_TOKEN"
"$JIRA_BASE_URL/rest/api/3/attachment/content/$ATTACHMENT_ID"
--output "/tmp/standup-attachments/$KEY-$FILENAME"


Then use the **Read tool** to view each downloaded image (Claude is multimodal and can read images). Screenshots often contain the actual QA feedback, bug reproductions, or UI states that explain what needs to happen next.

**Env vars required for attachment download:** `JIRA_EMAIL`, `JIRA_API_TOKEN`, `JIRA_BASE_URL`. If not set, skip attachment download and note it in the output.

From the full comments, attachments, and details, extract for each issue:
- **Full comment thread context:** Read ALL comments (not just the latest), understand the conversation arc — who raised what, what was discussed, what was decided
- **Visual context from screenshots:** If images are attached, view them and describe what they show (e.g., "Screenshot shows missing chart legend in conversion volume view")
- **Next action:** What Benjamin specifically needs to do next (review, fix, respond, deploy, etc.)
- **Whether actionable now** or waiting on someone else

**Cleanup:** After generating the standup report, remove temp files:
```bash
rm -rf /tmp/standup-attachments

curl -L -u "$JIRA_EMAIL:$JIRA_API_TOKEN"
"$JIRA_BASE_URL/rest/api/3/attachment/content/$ATTACHMENT_ID"
--output "/tmp/standup-attachments/$KEY-$FILENAME"


然后使用**读取工具**查看每个下载的图片（Claude支持多模态，可读取图片内容）。截图通常包含实际的QA反馈、Bug复现步骤或UI状态，能解释下一步需要执行的操作。

**附件下载所需环境变量：** `JIRA_EMAIL`、`JIRA_API_TOKEN`、`JIRA_BASE_URL`。如果未设置这些变量，请跳过附件下载，并在输出中注明。

从完整的评论、附件和详情中，为每个工单提取以下信息：
- **完整评论线程上下文：** 阅读**所有**评论（不仅是最新的），理解对话脉络——谁提出了什么问题、讨论了什么内容、做出了什么决定
- **截图中的视觉上下文：** 如果有附件图片，查看并描述其内容（例如："截图显示转化量视图中缺少图表图例"）
- **下一步操作：** Benjamin具体需要执行什么操作（评审、修复、回复、部署等）
- **是否可立即执行**，还是需要等待其他人的操作

**清理：** 生成站会报告后，删除临时文件：
```bash
rm -rf /tmp/standup-attachments

3. Check Jira Notifications (Watched Issues)

3. 检查Jira通知（关注的工单）

Fetch recently updated issues Benjamin is watching — these surface activity on issues he cares about but may not be assigned to:

bash

acli jira workitem search \
  --jql 'watcher = currentUser() AND updated >= -3d ORDER BY updated DESC' \
  --fields "key,summary,status,assignee" --csv

For each watched issue returned:

Skip issues already fetched in step 2 (assigned to Benjamin) — avoid duplicate work
Fetch the last 3 comments to understand what changed:

bash

acli jira workitem comment list --key <KEY> --json 2>&1 | jq -r '.comments[-3:] | .[] | "[\(.author.displayName)] \(.body)"'

From the results, determine if Benjamin needs to act:

Someone asked Benjamin a question or requested input in the comments
A status change requires Benjamin's attention (e.g., moved to review, blocked)
A teammate's work that Benjamin needs to unblock or approve

Filtering: Only include watched issues where Benjamin has a concrete action item. Exclude purely informational updates (e.g., someone else resolved it, automated status transitions).

获取Benjamin关注的最近更新的工单——这些工单是他关心但未被分配的活动工单：

bash

acli jira workitem search \
  --jql 'watcher = currentUser() AND updated >= -3d ORDER BY updated DESC' \
  --fields "key,summary,status,assignee" --csv

对于每个返回的关注工单：

跳过步骤2中已获取的工单（分配给Benjamin的）——避免重复工作
获取最后3条评论以了解变更内容：

bash

acli jira workitem comment list --key <KEY> --json 2>&1 | jq -r '.comments[-3:] | .[] | "[\(.author.displayName)] \(.body)"'

从结果中判断Benjamin是否需要采取行动：

有人在评论中向Benjamin提问或请求输入
状态变更需要Benjamin的关注（例如：转入评审、被阻塞）
队友的工作需要Benjamin解除阻塞或批准

过滤规则： 仅包含Benjamin有明确操作项的关注工单。排除纯信息性更新（例如：其他人已解决、自动状态转换）。

4. Gather GitHub Data

4. 收集GitHub数据

Benjamin's open PRs across all repos:

bash

gh search prs --author=@me --state=open --limit 20 --json title,number,repository,url,isDraft,updatedAt,createdAt

PRs requesting Benjamin's review:

bash

gh search prs --review-requested=@me --state=open --limit 10 --json title,number,repository,url,author

Enrich with review state — for each non-draft PR from Benjamin's list, fetch the review decision:

bash

for pr in $(echo "$PRS_JSON" | jq -r '.[] | select(.isDraft == false) | "\(.repository.nameWithOwner):\(.number)"'); do
  repo="${pr%%:*}"
  num="${pr##*:}"
  echo "=== $repo#$num ==="
  gh pr view "$num" --repo "$repo" --json reviewDecision,reviews --jq '{reviewDecision, reviewCount: (.reviews | length)}'
done

Possible

reviewDecision

values:

```
CHANGES_REQUESTED
```
— a reviewer requested changes; Benjamin is blocking their wait
```
APPROVED
```
— all reviewers approved; ready to merge
```
REVIEW_REQUIRED
```
or empty (0 reviews) — no one has reviewed yet; Benjamin is waiting on others

From the results:

Match PR titles/branches to Jira issue keys (e.g., a PR title containing "RGI-265" or branch named "feat/MITB-599")
Note which of Benjamin's PRs are drafts vs ready for review
Note PRs from teammates that need Benjamin's review
Flag stale PRs (open > 30 days) — these likely need rebase, cleanup, or closing
Note PR age using
```
createdAt
```
field
Classify each non-draft PR by review state for tier routing:
- ```
CHANGES_REQUESTED
```
  → UNBLOCK OTHERS (reviewers waiting on Benjamin)
- ```
REVIEW_REQUIRED
```
  with 0 reviews → IN PROGRESS with "⏸ Awaiting review"
- ```
APPROVED
```
  → IN PROGRESS or DO NOW (ready to merge)

Benjamin在所有仓库中的公开PR：

bash

gh search prs --author=@me --state=open --limit 20 --json title,number,repository,url,isDraft,updatedAt,createdAt

请求Benjamin评审的PR：

bash

gh search prs --review-requested=@me --state=open --limit 10 --json title,number,repository,url,author

补充评审状态 —— 对于Benjamin的每个非草稿PR，获取评审结果：

bash

for pr in $(echo "$PRS_JSON" | jq -r '.[] | select(.isDraft == false) | "\(.repository.nameWithOwner):\(.number)"'); do
  repo="${pr%%:*}"
  num="${pr##*:}"
  echo "=== $repo#$num ==="
  gh pr view "$num" --repo "$repo" --json reviewDecision,reviews --jq '{reviewDecision, reviewCount: (.reviews | length)}'
done

reviewDecision

的可能值：

```
CHANGES_REQUESTED
```
—— 评审者要求修改；Benjamin的操作阻塞了评审者的等待
```
APPROVED
```
—— 所有评审者已批准；可合并
```
REVIEW_REQUIRED
```
或空值（0条评审）—— 尚未有人评审；Benjamin正在等待他人

从结果中：

将PR标题/分支与Jira工单编号匹配（例如：PR标题包含"RGI-265"或分支名为"feat/MITB-599"）
记录Benjamin的PR是草稿还是已准备好评审
记录需要Benjamin评审的队友PR
标记过时PR（已打开超过30天）—— 这些PR可能需要变基、清理或关闭
使用
```
createdAt
```
字段记录PR的存在时长
根据评审状态对每个非草稿PR进行分层路由：
- ```
CHANGES_REQUESTED
```
  → 🔄 解除他人阻塞（评审者正在等待Benjamin）
- ```
REVIEW_REQUIRED
```
  且0条评审 → 🔨 进行中，标注为"⏸ 等待评审"
- ```
APPROVED
```
  但未合并 → 🔨 进行中或 ⚡ 立即处理（可合并）

5. Validate Slack Items Against Jira

5. 验证Slack项与Jira的一致性

For every Jira issue key found in Slack messages (step 1) that was NOT already fetched in step 2, fetch the issue details, full comments, and attachments:

bash

acli jira workitem view <ISSUE-KEY> --json
acli jira workitem comment list --key <ISSUE-KEY> --json
acli jira workitem attachment list --key <ISSUE-KEY> --json

Download and view image attachments the same way as step 2.

For each Slack-mentioned issue, determine:

Is it assigned to Benjamin? If assigned to someone else, it's not Benjamin's action item.
Is it still open? If status is Done/Resolved/Closed, exclude it entirely.
Does it require a response from Benjamin? (e.g., someone asked him a question, requested a review, or awaits his input)
What is the current actual status? Use comments and status to get the real state, not just what Slack says.

Filtering rules:

Exclude issues assigned to others unless Benjamin has a specific pending action (reply, review, unblock)
Exclude resolved/closed issues entirely
Exclude issues where the Slack message is informational only (no action needed from Benjamin)

对于步骤1中在Slack消息中找到但未在步骤2中获取的每个Jira工单编号，获取工单详情、完整评论和附件：

bash

acli jira workitem view <ISSUE-KEY> --json
acli jira workitem comment list --key <ISSUE-KEY> --json
acli jira workitem attachment list --key <ISSUE-KEY> --json

按照步骤2的方式下载并查看图片附件。

对于每个Slack中提及的工单，判断：

是否分配给Benjamin？ 如果分配给他人，则不属于Benjamin的操作项。
是否仍处于打开状态？ 如果状态为已完成/已解决/已关闭，则完全排除。
是否需要Benjamin回复？（例如：有人向他提问、请求评审或等待他的输入）
当前实际状态是什么？ 使用评论和状态获取真实状态，而非仅依赖Slack中的描述。

过滤规则：

排除分配给他人的工单，除非Benjamin有明确的待执行操作（回复、评审、解除阻塞）
完全排除已解决/已关闭的工单
排除Slack消息仅为信息性内容（Benjamin无需采取行动）的工单

6. Load Previous Standup

6. 加载上一次站会内容

Check for the most recent standup file in

~/.claude/standups/

bash

ls -1 ~/.claude/standups/*.md 2>/dev/null | sort -r | head -1

If a previous standup exists, read it and extract:

All Jira issue keys and their statuses (parse from section headers and item lines)
All PR entries

This data is used in step 7 to generate the diff section. If no previous standup exists (first run), skip the diff.

To detect stale items, also check the 2 standups before that:

bash

ls -1 ~/.claude/standups/*.md 2>/dev/null | sort -r | head -3

An item is stale if it appears with the same status across 3+ consecutive standups.

检查

~/.claude/standups/

中最近的站会文件：

bash

ls -1 ~/.claude/standups/*.md 2>/dev/null | sort -r | head -1

如果存在上一次站会内容，读取并提取：

所有Jira工单编号及其状态（从章节标题和项目行中解析）
所有PR条目

这些数据将在步骤7中用于生成差异部分。如果是首次运行（无上一次站会内容），则跳过差异部分。

为了检测过时项，还需检查前两次的站会内容：

bash

ls -1 ~/.claude/standups/*.md 2>/dev/null | sort -r | head -3

如果某一项在连续3次及以上站会中状态相同，则视为过时项。

7. Merge and Prioritize

7. 合并与优先级排序

Build a single priority-ordered numbered list of Benjamin's personal action items, grouped into urgency tiers. Items are numbered continuously across all tiers (1, 2, 3... N — no resets between tiers).

When a Jira issue has a matching open PR (matched by issue key in PR title or branch), annotate the item inline with

⌥ PR #N

and link.

Tier assignment rules:

Tier	Emoji	Criteria
⚡ DO NOW	💬 🔴	Unresponded Slack @mentions; items reopened/escalated by priority users (Claire, Matthieu); Blocker/Urgent priority; items explicitly requested same-day
🔄 UNBLOCK OTHERS	🟡	Own PRs with `CHANGES_REQUESTED` review decision (reviewers waiting on Benjamin); teammate PRs requesting Benjamin's review; watched issues where someone asked for input
🔨 IN PROGRESS	🟠	Items in active statuses (In Progress, In QA, In Review) waiting on external action (not currently blocked on Benjamin); own PRs awaiting review ( `REVIEW_REQUIRED` with 0 reviews)
📋 UP NEXT	🔴 ⬜	Ready for Development, On Deck items. Use 🔴 for High priority, ⬜ for normal
⏳ WAITING	⏸	Tasks with `status === "standby"` from today's or yesterday's task file (carried over). Sort by `paused_at` ascending (longest-waiting first). These tasks are NOT shown in any other tier.

Within each tier, sort by: Jira priority (Blocker > Critical > High > Medium > Low), then by most recent activity.

构建一份统一的优先级排序编号列表，包含Benjamin的个人操作项，并按紧急程度分层。所有层级的项目连续编号（1、2、3... N —— 层级间不重置编号）。

如果Jira工单有匹配的公开PR（通过PR标题或分支中的工单编号匹配），则在项目行内标注

⌥ PR #N

并添加链接。

层级分配规则：

层级	表情符号	判定标准
⚡ 立即处理	💬 🔴	未回复的Slack@提及；优先级用户（Claire、Matthieu）重新打开/升级的项；阻塞/紧急优先级；明确要求当日完成的项
🔄 解除他人阻塞	🟡	自己的PR被标记为 `CHANGES_REQUESTED` （评审者等待Benjamin）；请求Benjamin评审的队友PR；有人请求输入的关注工单
🔨 进行中	🟠	处于活动状态（进行中、QA中、评审中）且等待外部操作（当前未被Benjamin阻塞）的项；自己的PR等待评审（ `REVIEW_REQUIRED` 且0条评审）
📋 下一步	🔴 ⬜	准备开发、待处理的项。高优先级用🔴，普通优先级用⬜
⏳ 等待中	⏸	今日或昨日任务文件中状态为 `standby` 的项（延续项）。按 `paused_at` 升序排序（等待时间最长的排在前面）。这些项不会出现在其他层级中。

每个层级内的排序规则： 按Jira优先级（阻塞 > 严重 > 高 > 中 > 低）排序，然后按最近活动时间排序。

8. Generate Output

8. 生成输出

Construct links for every issue key as

[KEY](https://hgdata.atlassian.net/browse/KEY)

Format — Priority Stack:

┌─────────────────────────────────────────────────────────────┐
│  🌅  STANDUP — {date}                                       │
│  Last sync: {previous_date} · {N} active · {N} new · {N} standby · {N} msg│
└─────────────────────────────────────────────────────────────┘

⚡ DO NOW
  1. 💬 [Brief description] — [who] [what]
     └─ #channel · date · What to respond
  2. 🔴 [KEY](url) — Summary
     └─ Context from comments/attachments → next action

🔄 UNBLOCK OTHERS
  3. 🟡 [KEY](url) — Summary                     ⌥ [PR #N](gh-url)
     └─ Feedback details / what to address
  4. 🟡 [repo#N](gh-url) — PR title — by [author]
     └─ Brief description of PR purpose

🔨 IN PROGRESS
  5. 🟠 [KEY](url) — Summary                     ⌥ [PR #N](gh-url)
     └─ ⏸ Awaiting review · N days old

📋 UP NEXT
  6. 🔴 [KEY](url) — Summary                    High
     └─ Why it matters
  7. ⬜ [KEY](url) — Summary
     └─ Brief context

⏳ WAITING
  8. ⏸ [KEY](url) — Summary
     └─ Waiting on: {waiting_on} · standby Xh ago
  9. ⏸ [KEY](url) — Summary
     └─ Waiting on: {waiting_on} · standby 1d ago

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
🔔 Overnight: 🆕 KEY reason · ➡️ KEY old → new · ✅ KEY done · ⏸ KEY reason · ▶️ KEY
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

🔍 Analysis: KEY (brief) · KEY (brief)
📦 Backlog: KEY (brief) · KEY (brief)
🧹 Stale PRs: #N(Nd) #N(Nd) ...

Header box rules:

Summary counters: count items in active statuses, new items since last standup, pending Slack messages, standby tasks
```
Last sync: {date}
```
uses the most recent previous standup date. Omit if first standup.
Omit
```
{N} standby
```
from the header if zero standby tasks.

Context line (
└─
) rules:

Every item MUST have a
```
└─
```
context line underneath
The line should answer: "What do I need to do with this?"
Derive context from the full comment thread + attachments + PR status + Slack messages — not from the issue title or a single comment
Read ALL comments on each issue to understand the full conversation arc before summarizing
If image attachments exist, view them and incorporate visual context (e.g., "Screenshot shows missing chart legend on conversion page")
Keep to 1-2 lines, ~20 words max
For Jira items: synthesize the full discussion + visual evidence into a clear next action for Benjamin
For PRs: note age, review status, whether it needs rebase/cleanup
For stale PRs (> 30 days): flag explicitly (e.g., "Open 45 days, likely needs rebase or closing")
Use ⏸ prefix when an item is blocked/waiting on someone else

PR annotation rules:

If a Jira item has a matching PR, append
```
⌥ [PR #N](gh-url)
```
inline on the same line
Mark draft PRs explicitly with "(draft)"
Route Benjamin's PRs by review state:
- ```
CHANGES_REQUESTED
```
  → 🔄 UNBLOCK OTHERS (reviewers waiting on Benjamin to address feedback)
- ```
REVIEW_REQUIRED
```
  / 0 reviews → 🔨 IN PROGRESS, annotated with "⏸ Awaiting review"
- ```
APPROVED
```
  but not merged → 🔨 IN PROGRESS or ⚡ DO NOW (ready to merge)
Teammate PRs requesting Benjamin's review go in the 🔄 UNBLOCK OTHERS tier
Benjamin's open PRs that don't match any Jira issue go in the 🧹 Stale PRs footer line

Overnight diff rules:

Compact single-line format between
```
╌
```
dividers
Use emoji prefixes: 🆕 (new items), ➡️ (status changes), ✅ (completed/resolved), ⚠️ (stale 3+ standups), ⏸ (newly on standby), ▶️ (unblocked since last standup)
All changes on one line, separated by
```
·
```
Compare by Jira issue key and status from previous standup file
Completed = keys in previous standup but absent from today's data
New = keys in today's data but absent from previous standup
Status Changes = keys present in both with different status
Stale = keys with identical status across 3+ consecutive standups
Newly standby = keys that transitioned to
```
standby
```
since last standup — show as
```
⏸ KEY reason
```
Unblocked = keys that transitioned from
```
standby
```
to active since last standup — show as
```
▶️ KEY
```
Omit the entire overnight section if no previous standup exists

Footer section rules:

🔍 Analysis, 📦 Backlog, 🧹 Stale PRs are compact single-line lists
Format:
```
emoji Label: KEY (brief) · KEY (brief)
```
Stale PRs use
```
#N(Nd)
```
format showing PR number and age in days
Omit any footer line with no items

Tier omission: Omit any tier that has no items. Do not show empty tier headers.

为每个工单编号构建链接，格式为

[编号](https://hgdata.atlassian.net/browse/编号)

。

格式 —— 优先级堆叠：

┌─────────────────────────────────────────────────────────────┐
│  🌅  站会 — {日期}                                       │
│  上次同步：{上次日期} · {N} 个活动项 · {N} 个新增项 · {N} 个待处理项 · {N} 条消息│
└─────────────────────────────────────────────────────────────┘

⚡ 立即处理
  1. 💬 [简要描述] — [谁] [什么]
     └─ #频道 · 日期 · 需要回复的内容
  2. 🔴 [编号](链接) — 摘要
     └─ 评论/附件中的上下文 → 下一步操作

🔄 解除他人阻塞
  3. 🟡 [编号](链接) — 摘要                     ⌥ [PR #N](GitHub链接)
     └─ 反馈详情 / 需要处理的内容
  4. 🟡 [仓库#N](GitHub链接) — PR标题 — 作者：[作者]
     └─ PR用途的简要描述

🔨 进行中
  5. 🟠 [编号](链接) — 摘要                     ⌥ [PR #N](GitHub链接)
     └─ ⏸ 等待评审 · 已存在N天

📋 下一步
  6. 🔴 [编号](链接) — 摘要                    高优先级
     └─ 重要性说明
  7. ⬜ [编号](链接) — 摘要
     └─ 简要上下文

⏳ 等待中
  8. ⏸ [编号](链接) — 摘要
     └─ 等待对象：{等待对象} · 待处理X小时
  9. ⏸ [编号](链接) — 摘要
     └─ 等待对象：{等待对象} · 待处理1天

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
🔔 夜间变更：🆕 编号 原因 · ➡️ 编号 旧状态→新状态 · ✅ 编号 已完成 · ⏸ 编号 原因 · ▶️ 编号
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

🔍 分析：编号（简要） · 编号（简要）
📦 待办库：编号（简要） · 编号（简要）
🧹 过时PR：#N(N天) #N(N天) ...

头部框规则：

摘要计数器：统计活动状态项、自上次站会以来的新增项、待处理Slack消息、待处理任务的数量
```
上次同步：{日期}
```
使用最近一次站会的日期。如果是首次站会，则省略。
如果待处理任务数量为0，则从头部中省略
```
{N} 个待处理项
```
。

上下文行（
└─
）规则：

每个项必须在下方有一条
```
└─
```
上下文行
该行应回答："我需要对此做什么？"
从完整评论线程 + 附件 + PR状态 + Slack消息中获取上下文——而非仅从工单标题或单条评论中获取
在总结前，阅读每个工单的所有评论以理解完整对话脉络
如果有图片附件，查看并整合视觉上下文（例如："截图显示转化页面中缺少图表图例"）
保持1-2行，约20个单词以内
对于Jira项：将完整讨论 + 视觉证据整合为Benjamin明确的下一步操作
对于PR：记录存在时长、评审状态、是否需要变基/清理
对于过时PR（>30天）：明确标记（例如："已打开45天，可能需要变基或关闭"）
当项被阻塞/等待他人时，使用⏸前缀

PR标注规则：

如果Jira项有匹配的PR，在同一行内追加
```
⌥ [PR #N](GitHub链接)
```
明确标记草稿PR为"(draft)"
根据评审状态路由Benjamin的PR：
- ```
CHANGES_REQUESTED
```
  → 🔄 解除他人阻塞（评审者等待Benjamin处理反馈）
- ```
REVIEW_REQUIRED
```
  / 0条评审 → 🔨 进行中，标注为"⏸ 等待评审"
- ```
APPROVED
```
  但未合并 → 🔨 进行中或 ⚡ 立即处理（可合并）
请求Benjamin评审的队友PR归入🔄 解除他人阻塞层级
Benjamin的公开PR中未匹配任何Jira工单的项归入🧹 过时PR页脚行

夜间变更差异规则：

在
```
╌
```
分隔符之间使用紧凑的单行格式
使用表情符号前缀：🆕（新增项）、➡️（状态变更）、✅（已完成/已解决）、⚠️（连续3次站会未变更的过时项）、⏸（新增待处理项）、▶️（自上次站会以来已解除阻塞）
所有变更在一行中，用
```
·
```
分隔
根据上一次站会文件中的Jira工单编号和状态进行比较
已完成 = 上一次站会中存在但今日数据中不存在的编号
新增 = 今日数据中存在但上一次站会中不存在的编号
状态变更 = 两次站会中都存在但状态不同的编号
过时 = 连续3次及以上站会中状态相同的编号
新增待处理 = 自上次站会以来转换为
```
standby
```
状态的编号 —— 显示为
```
⏸ 编号 原因
```
已解除阻塞 = 自上次站会以来从
```
standby
```
转换为活动状态的编号 —— 显示为
```
▶️ 编号
```
如果无上一次站会内容，则省略整个夜间变更部分

页脚部分规则：

🔍 分析、📦 待办库、🧹 过时PR为紧凑的单行列表

格式：

表情符号 标签：编号（简要） · 编号（简要）

过时PR使用
```
#N(N天)
```
格式，显示PR编号和存在时长（天）
如果某一页脚行无内容，则省略

层级省略规则： 如果某一层级无项，则省略该层级的标题。不要显示空的层级标题。

9. Persist Report

9. 保存报告

After displaying the output, save the full standup report:

bash

mkdir -p ~/.claude/standups

Write the complete output to

~/.claude/standups/YYYY-MM-DD.md

(using today's date).

If a file for today already exists (e.g., re-running standup), overwrite it with the latest data.

显示输出后，保存完整的站会报告：

bash

mkdir -p ~/.claude/standups

将完整输出写入

~/.claude/standups/YYYY-MM-DD.md

（使用今日日期）。

如果今日的文件已存在（例如：重新运行站会），则用最新数据覆盖。

10. Generate Task File

10. 生成任务文件

After persisting the standup report, generate a structured task file for cross-session tracking.

Create
~/.claude/daily-tasks/YYYY-MM-DD.json
by extracting each numbered item from the standup output:

bash

mkdir -p ~/.claude/daily-tasks

Extraction rules — parse the standup output just generated:

For each numbered item (1..N), extract:
- Item number →
```
id
```
- Tier header above it →
```
tier
```
  (map:
```
⚡ DO NOW
```
  →
```
"do_now"
```
  ,
```
🔄 UNBLOCK OTHERS
```
  →
```
"unblock_others"
```
  ,
```
🔨 IN PROGRESS
```
  →
```
"in_progress"
```
  ,
```
📋 UP NEXT
```
  →
```
"up_next"
```
  )
- Jira key from
```
[KEY](url)
```
  pattern →
```
jira_key
```
  ,
```
jira_url
```
- Summary text after the em dash →
```
summary
```
- Context line (the
```
└─
```
  line) →
```
context
```
- PR annotation
```
⌥ [PR #N](url)
```
  →
```
pr_url
```
- Source: items with
```
jira_key
```
  →
```
"jira"
```
  , Slack-only items →
```
"slack"
```
  , PR-only items →
```
"github"
```
Items without a Jira key (e.g., Slack @mentions, PR review requests) should still be included with
```
jira_key: null
```
.

JSON schema:

json

{
  "date": "YYYY-MM-DD",
  "standup_file": "~/.claude/standups/YYYY-MM-DD.md",
  "updated_at": "ISO-TIMESTAMP",
  "tasks": [
    {
      "id": 1,
      "tier": "do_now",
      "status": "pending",
      "jira_key": "RGI-265",
      "jira_url": "https://hgdata.atlassian.net/browse/RGI-265",
      "summary": "Migrate Evr Insights pages",
      "context": "In QA; Claire feedback on missing chart names",
      "pr_url": null,
      "source": "jira",
      "started_at": null,
      "completed_at": null,
      "carried_from": null,
      "waiting_on": null,
      "paused_at": null
    }
  ]
}

Merge logic — if
~/.claude/daily-tasks/YYYY-MM-DD.json
already exists (re-run):

Read the existing task file

Build a lookup map:

jira_key → {status, started_at, completed_at, waiting_on, paused_at}

for all existing tasks

For each new task being generated: if its
```
jira_key
```
matches an existing task, carry over
```
status
```
,
```
started_at
```
,
```
completed_at
```
,
```
waiting_on
```
,
```
paused_at
```
from the existing entry
Tasks with
```
status === "standby"
```
are routed to the
```
⏳ WAITING
```
tier regardless of what Jira reports for their status
This prevents losing in-progress/done/standby state when re-running standup mid-day

Carry-over from previous day:

Check if yesterday's task file exists:

bash

cat ~/.claude/daily-tasks/$(date -v-1d +%Y-%m-%d).json 2>/dev/null

For tasks that appeared in yesterday's file and reappear today (matched by

jira_key

Set
```
carried_from
```
to yesterday's date string
If yesterday's task had
```
status === "standby"
```
, carry over
```
standby
```
status,
```
waiting_on
```
, and
```
paused_at
```
intact — the task is still blocked

Write the JSON file using the Write tool to

~/.claude/daily-tasks/YYYY-MM-DD.json

Amend standup file: After writing the task file, append an HTML comment reference to the standup markdown file:

<!-- task-file: ~/.claude/daily-tasks/YYYY-MM-DD.json -->

保存站会报告后，生成结构化任务文件用于跨会话跟踪。

创建
~/.claude/daily-tasks/YYYY-MM-DD.json
，从刚生成的站会输出中提取每个编号项：

bash

mkdir -p ~/.claude/daily-tasks

提取规则 —— 解析刚生成的站会输出：

对于每个编号项（1..N），提取：
- 项编号 →
```
id
```
- 上方的层级标题 →
```
tier
```
  （映射：
```
⚡ 立即处理
```
  →
```
"do_now"
```
  ，
```
🔄 解除他人阻塞
```
  →
```
"unblock_others"
```
  ，
```
🔨 进行中
```
  →
```
"in_progress"
```
  ，
```
📋 下一步
```
  →
```
"up_next"
```
  ）
- 从
```
[编号](链接)
```
  模式中提取Jira编号 →
```
jira_key
```
  、
```
jira_url
```
- 破折号后的摘要文本 →
```
summary
```
- 上下文行（
```
└─
```
  行） →
```
context
```
- PR标注
```
⌥ [PR #N](链接)
```
  →
```
pr_url
```
- 来源：带有
```
jira_key
```
  的项 →
```
"jira"
```
  ，仅Slack项 →
```
"slack"
```
  ，仅PR项 →
```
"github"
```
无Jira编号的项（例如：Slack@提及、PR评审请求）仍需包含，
```
jira_key: null
```
。

JSON Schema：

json

{
  "date": "YYYY-MM-DD",
  "standup_file": "~/.claude/standups/YYYY-MM-DD.md",
  "updated_at": "ISO-TIMESTAMP",
  "tasks": [
    {
      "id": 1,
      "tier": "do_now",
      "status": "pending",
      "jira_key": "RGI-265",
      "jira_url": "https://hgdata.atlassian.net/browse/RGI-265",
      "summary": "迁移Evr Insights页面",
      "context": "QA中；Claire反馈缺少图表名称",
      "pr_url": null,
      "source": "jira",
      "started_at": null,
      "completed_at": null,
      "carried_from": null,
      "waiting_on": null,
      "paused_at": null
    }
  ]
}

合并逻辑 —— 如果
~/.claude/daily-tasks/YYYY-MM-DD.json
已存在（重新运行）：

读取现有的任务文件

构建查找映射：

jira_key → {status, started_at, completed_at, waiting_on, paused_at}

，对应所有现有任务

对于每个新生成的任务：如果其
```
jira_key
```
与现有任务匹配，则从现有条目中继承
```
status
```
、
```
started_at
```
、
```
completed_at
```
、
```
waiting_on
```
、
```
paused_at
```
状态为
```
standby
```
的任务无论Jira报告的状态如何，都归入⏳ 等待中层级
这样可以避免在日间重新运行站会时丢失进行中/已完成/待处理状态

从昨日延续的项：

检查昨日的任务文件是否存在：

bash

cat ~/.claude/daily-tasks/$(date -v-1d +%Y-%m-%d).json 2>/dev/null

对于出现在昨日文件且今日再次出现的任务（通过

jira_key

匹配）：

将
```
carried_from
```
设置为昨日的日期字符串
如果昨日任务的状态为
```
standby
```
，则完整继承
```
standby
```
状态、
```
waiting_on
```
和
```
paused_at
```
—— 任务仍处于阻塞状态

使用写入工具将JSON文件写入

~/.claude/daily-tasks/YYYY-MM-DD.json

。

修改站会文件： 写入任务文件后，在站会Markdown文件末尾添加HTML注释引用：

<!-- task-file: ~/.claude/daily-tasks/YYYY-MM-DD.json -->

11. Empty State

11. 空状态

If no tasks found across all sources:

No pending tasks - check backlog or ask PM for priorities.

Still persist the empty standup file so the diff tracks that it was a clean day. Also persist an empty task file with

"tasks": []

如果所有来源中均未找到任务：

无待处理任务 - 请查看待办库或向PM询问优先级。

仍需保存空站会文件，以便差异跟踪记录这是一个无任务的工作日。同时保存空任务文件，其中

"tasks": []

。

Notes

注意事项

Both RGI (1236) and MITB (1036) boards are Kanban (no sprints). Use status to infer tier placement.
Exclude Canceled and Done issues from output
Omit any tier or footer line that has no items
Use 🔴 emoji for High priority items (not bold text)
Requirement Analysis and Backlog items go in the compact footer lines, not in the numbered tiers
Blockers should be surfaced as 🔴 items in the ⚡ DO NOW tier with clear blocking context

RGI（1236）和MITB（1036）看板均为Kanban（无迭代）。使用状态推断层级位置。
从输出中排除已取消和已完成的工单
省略任何无项的层级或页脚行
高优先级项使用🔴表情符号（而非粗体文本）
需求分析和待办库项归入紧凑的页脚行，而非编号层级
阻塞项应作为🔴项显示在⚡ 立即处理层级，并附带明确的阻塞上下文