daily-report

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

daily-report

每日报告

Standard report format for Pylot crew teams. Used in morning rollcall dispatch jobs and any standup/status reporting task.

Pylot团队的标准报告格式，适用于早间点名调度工作及任何站会/状态汇报任务。

When to Use

使用场景

You have been dispatched with a rollcall or standup task
Your task says "write today's team report per /daily-report"
Any task asking for a team status report

你被分配了点名或站会汇报任务
任务要求“按照/daily-report撰写今日团队报告”
任何要求提交团队状态报告的任务

Standard Sections

标准章节

Section 0: Production Health (MANDATORY — P0/P1 verification required)

章节0：生产环境健康状况（必填——需验证P0/P1级问题）

One line per repo. Must appear FIRST — production issues are never buried below issues or PRs.

Format:

- org/repo — 🟢 green: up, no incidents
- org/repo — 🔴 red: 500 errors on /api/products (issue #84, since 2026-04-11) [verified: curl → 503]
- org/repo — 🟡 yellow: degraded response times, investigating
- org/repo — ⚠️ UNVERIFIED: repo#84 claims 500 — production returns 200, likely false positive

If no active incidents:

All repos: 🟢 green

每个仓库占一行。必须放在最前面——生产环境问题绝不能被埋在其他问题或PR之后。

格式：

- org/repo — 🟢 绿色：运行正常，无故障
- org/repo — 🔴 红色：/api/products接口出现500错误（问题#84，始于2026-04-11）[已验证：curl返回503]
- org/repo — 🟡 黄色：响应时间下降，正在排查
- org/repo — ⚠️ 未验证：repo#84报告500错误——生产环境返回200，大概率为误报

若无活跃故障：

所有仓库：🟢 绿色

P0/P1 Verification Protocol

P0/P1级问题验证流程

Any issue claiming P0/P1 severity OR containing keywords
500
,
down
,
broken
,
production
in the title or body MUST be verified before being promoted to the briefing. Unverified P0s waste Max's desk time — they are more harmful than missing a real incident.

Decision tree:

Issue claims P0/P1 or has keywords (500, down, broken, production)?
├── YES → Extract production URL from body (https:// that is NOT a GitHub URL)
│   ├── URL found → run liveness check:
│   │   STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$PROD_URL")
│   │   ├── 5xx or timeout → CONFIRMED outage
│   │   │   → 🔴 P0: org/repo — [title] (issue #N, since DATE) [verified: curl → $STATUS]
│   │   └── 200 → UNVERIFIED — production is up, claim is questionable
│   │       → ⚠️ UNVERIFIED: org/repo#N claims [keyword] — production returns 200, likely false positive
│   └── No production URL → check issue body for evidence:
│       ├── Has evidence (curl output, screenshot, error log, Sentry/Bugsnag link)
│       │   → 🟡 NEEDS REVIEW: org/repo#N — [title] — has evidence, cannot auto-verify
│       └── No evidence → comment on the issue asking for evidence (see template below)
│           → ⚠️ UNVERIFIED: org/repo#N claims [keyword] — no production URL or evidence; asked filer
└── NO → Standard reporting, no verification needed

Output formats by scenario:

Scenario	Format
Verified outage (curl 5xx)	`🔴 P0: org/repo — [title] [verified: curl → 503]`
Unverified (curl 200)	`⚠️ UNVERIFIED: org/repo#N claims [keyword] — production returns 200, likely false positive`
Has evidence, no URL	`🟡 NEEDS REVIEW: org/repo#N — [title] — has evidence, cannot auto-verify`
No URL, no evidence	`⚠️ UNVERIFIED: org/repo#N claims [keyword] — no production URL or evidence; asked filer`

Ask-filer comment template (post when no URL and no evidence found):

bash

gh issue comment $ISSUE_NUMBER --repo $ORG/$REPO --body "Promoting this to P0 in rollcall requires production evidence.
Please add one of:
- curl output showing the error: \`curl -I https://your-production-url.com\`
- Screenshot or error log from production
- Sentry/Bugsnag link

Without evidence, this will appear as ⚠️ UNVERIFIED in the morning briefing."

任何声称是P0/P1级严重程度，或标题/内容中包含
500
、
down
、
broken
、
production
关键词的问题，在提交到简报前必须经过验证。未经验证的P0级问题会浪费Max的时间——比遗漏真实故障的危害更大。

决策树：

问题声称是P0/P1级或包含关键词（500、down、broken、production）？
├── 是 → 从内容中提取生产环境URL（非GitHub的https://链接）
│   ├── 找到URL → 运行存活检查：
│   │   STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$PROD_URL")
│   │   ├── 返回5xx或超时 → 确认故障
│   │   │   → 🔴 P0: org/repo — [标题]（问题#N，始于日期）[已验证：curl返回$STATUS]
│   │   └── 返回200 → 未验证——生产环境正常，报告存疑
│   │       → ⚠️ 未验证：org/repo#N报告[关键词]——生产环境返回200，大概率为误报
│   └── 未找到生产环境URL → 检查问题内容是否有证据：
│       ├── 有证据（curl输出、截图、错误日志、Sentry/Bugsnag链接）
│       │   → 🟡 需审核：org/repo#N — [标题] — 有证据，无法自动验证
│       └── 无证据 → 在问题下留言索要证据（见下方模板）
│           → ⚠️ 未验证：org/repo#N报告[关键词]——无生产环境URL或证据；已向提交人索要
└── 否 → 按标准流程汇报，无需验证

不同场景的输出格式：

场景	格式
已验证故障（curl返回5xx）	`🔴 P0: org/repo — [标题] [已验证：curl返回503]`
未验证（curl返回200）	`⚠️ 未验证：org/repo#N报告[关键词]——生产环境返回200，大概率为误报`
有证据但无URL	`🟡 需审核：org/repo#N — [标题] — 有证据，无法自动验证`
无URL且无证据	`⚠️ 未验证：org/repo#N报告[关键词]——无生产环境URL或证据；已向提交人索要`

向提交人索要证据的评论模板（未找到URL和证据时使用）：

bash

gh issue comment $ISSUE_NUMBER --repo $ORG/$REPO --body "将此问题升级为P0级并纳入点名简报需要生产环境证据。
请补充以下任意一项：
- 显示错误的curl输出：\`curl -I https://your-production-url.com\`
- 生产环境的截图或错误日志
- Sentry/Bugsnag链接

若无证据，此问题将在早间简报中标记为⚠️ 未验证。"

Section 1: Open Issues

章节1：待处理问题

For each repo, list all open issues. Verify each is actually open — do NOT parrot stale data.

Format per issue:

- #N [Title](https://github.com/org/repo/issues/N) — labels: priority-high, bug

If 0 open issues: state it explicitly.

针对每个仓库，列出所有待处理问题。需确认每个问题确实处于打开状态——切勿照搬过时数据。

单个问题格式：

- #N [标题](https://github.com/org/repo/issues/N) — 标签: priority-high, bug

若无待处理问题：需明确说明。

Section 2: PRs Waiting

章节2：待处理PR

Split feature PRs from dep PRs — never mix them in the same list.

Feature PRs:

- #N [Title](https://github.com/org/repo/pull/N) — status: review | 3d / 2026-04-10
- #N [Title](https://github.com/org/repo/pull/N) — status: draft | 15d / 2026-03-26 [STALE]

Dep PRs (one line each with risk label):

- #N [bump lodash 4→5](https://github.com/org/repo/pull/N) — CRIT | 2d / 2026-04-11
- #N [bump eslint 8→9](https://github.com/org/repo/pull/N) — LOW | 5d / 2026-04-08

Risk labels:

CRIT — security CVE, known breakage, or major version with documented breaking changes
HIGH — major version bump with possible API breaks
MED — minor version with notable changes
LOW — patch update, routine

PR count headline:

N open (X actionable, Y stale drafts)

— never a bare count.

Repos with no CI configured: note it once as a section footer, not per-PR.

需将功能PR与依赖PR分开——切勿混在同一列表中。

功能PR：

- #N [标题](https://github.com/org/repo/pull/N) — 状态: 待审核 | 3天 / 2026-04-10
- #N [标题](https://github.com/org/repo/pull/N) — 状态: 草稿 | 15天 / 2026-03-26 [已过期]

依赖PR（每行标注风险标签）：

- #N [升级lodash 4→5](https://github.com/org/repo/pull/N) — CRIT | 2天 / 2026-04-11
- #N [升级eslint 8→9](https://github.com/org/repo/pull/N) — LOW | 5天 / 2026-04-08

风险标签说明：

CRIT — 安全漏洞（CVE）、已知故障，或有明确破坏性变更的大版本升级
HIGH — 可能存在API变更的大版本升级
MED — 有显著变更的小版本升级
LOW — 补丁更新、常规维护

PR数量标题格式：

共N个待处理（X个可推进，Y个过期草稿）

——切勿仅标注数字。

未配置CI的仓库：在章节末尾统一说明，无需逐个PR标注。

Section 3: Latest Updates

章节3：最新更新

Named merges with PR number and merge date. A bare count ("8 PRs merged") is useless.

Format:

- PR #N [Title](url) — merged 2026-04-10
- PR #N [Title](url) — merged 2026-04-09

If nothing merged in 7 days: state it and note the last merge date.

标注已合并PR的编号和合并日期。仅标注“合并8个PR”毫无意义。

格式：

- PR #N [标题](链接) — 合并于2026-04-10
- PR #N [标题](链接) — 合并于2026-04-09

若7天内无合并记录：需明确说明，并标注最后一次合并的日期。

Section 4: Suggested Next Tasks

章节4：建议下一步任务

2-3 concrete actions. Each must have:

Exact slash command where applicable:

/review-pr 47 CLAPES-UC/ipc-med-backend ipcmed-runner

Sequencing note when order matters: "do this BEFORE merging deps — lockfile conflict risk"
Reasoning tied to team Direction goals
Risk callout for dangerous deps: "do NOT merge Next.js 16 without testing locally"

2-3项具体行动。每项需包含：

适用的精确斜杠命令（如：

/review-pr 47 CLAPES-UC/ipc-med-backend ipcmed-runner

）

顺序要求（若有）：“需在合并依赖前完成——存在锁文件冲突风险”
与团队目标相关的理由
高危依赖的风险提示：“未经本地测试，请勿合并Next.js 16”

Quality Rules

质量规则

Every issue/PR MUST include a full clickable URL (
```
https://github.com/org/repo/issues/N
```
or
```
/pull/N
```
)
Ages include absolute dates alongside relative:
```
3d / 2026-04-10
```
— not just
```
3d
```
"Quiet" is not a report — if nothing happened, say what SHOULD happen next from the backlog
Verify data freshness before reporting — call
```
gh issue list
```
and
```
gh pr list
```
, don't guess

Closed issues are NOT open — verify with

gh issue view N --repo org/repo --json state

P0/P1 production claims MUST be verified with curl before promoting to briefing — see the P0/P1 Verification Protocol in Section 0. An unverified P0 in the briefing wastes more time than a missed real incident.

每个问题/PR必须包含完整可点击的URL（
```
https://github.com/org/repo/issues/N
```
或
```
/pull/N
```
）
需同时标注相对时长和绝对日期：
```
3天 / 2026-04-10
```
——切勿仅标注
```
3天
```
不能只写“无动态”——若未发生任何事，请说明待办事项列表中的下一步计划
汇报前需验证数据时效性——调用
```
gh issue list
```
和
```
gh pr list
```
查询，切勿猜测
已关闭的问题不属于待处理状态——需通过
```
gh issue view N --repo org/repo --json state
```
验证
P0/P1级生产环境问题在提交到简报前必须通过curl验证——见章节0的P0/P1级问题验证流程。简报中出现未经验证的P0级问题，比遗漏真实故障更浪费时间。

Minimal Format for Idle Teams

闲置团队极简格式

Teams with 0 open issues AND 0 feature PRs get a 10-line status card instead of the full format:

undefined

无待处理问题且无功能PR的团队，无需使用完整格式，只需提交10行以内的状态卡片：

undefined

{team} — IDLE

{团队名称} — 闲置

Prod: 🟢 green | Issues: 0 | Feature PRs: 0 | Dep PRs: N Last merge: YYYY-MM-DD / PR #N Title Next: {suggested action — e.g., "process dep PRs on weekend, watch for Next.js 16 breaking changes"}


Do NOT produce a full section-by-section breakdown for idle teams — it adds noise without signal.

生产环境：🟢 绿色 | 待处理问题：0 | 功能PR：0 | 依赖PR：N 最后一次合并：YYYY-MM-DD / PR #N 标题下一步：{建议行动——例如：“周末处理依赖PR，关注Next.js 16的破坏性变更”}


切勿为闲置团队生成完整的分章节报告——这只会增加无效信息。

Report Location

报告存储位置

All reports go to

$(git rev-parse --show-toplevel)/reports/

. NEVER inside

crew/*/reports/

or any subdirectory.

所有报告需存入

$(git rev-parse --show-toplevel)/reports/

。禁止存入

crew/*/reports/

或任何子目录。

Writing the Report File

撰写报告文件

Once you have drafted all sections above, use

/write-report

to write the file:

bash

/write-report --group rollcall --id {your-team-name} --type rollcall

This ensures:

Correct path (
```
reports/
```
from repo root, never
```
crew/*/
```
)
Correct timestamped filename per CONVENTIONS.md
Automatic Quest DB posting
Consistent naming across all teams

Do NOT write the file manually using the Write tool — always use

/write-report

完成所有章节的草稿后，使用

/write-report

命令生成文件：

bash

/write-report --group rollcall --id {你的团队名称} --type rollcall

此命令可确保：

路径正确（仓库根目录下的
```
reports/
```
，而非
```
crew/*/
```
）
文件名符合CONVENTIONS.md的时间戳规范
自动提交至Quest DB
所有团队的命名保持一致

请勿使用Write工具手动撰写文件——务必使用

/write-report

命令。