daily-report

daily-report

Pylot クルーチームの標準レポート形式です。朝の点呼ディスパッチタスク、およびあらゆるスタンドアップ／ステータス報告タスクで使用します。

使用するタイミング

• 点呼またはスタンドアップのタスクを割り当てられた場合
• タスクに「/daily-report に従って本日のチームレポートを書く」とある場合
• チームのステータスレポートを求めるタスク全般

標準セクション

Section 0: 本番環境の健全性（必須 — P0/P1 の検証が必要）

リポジトリごとに1行記載します。必ず最初に記載してください。本番環境の問題を、課題や PR の後ろに埋もれさせてはいけません。

形式：

- 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

有効なインシデントがない場合：All repos: 🟢 green

P0/P1 検証プロトコル

P0/P1 の重大度を主張する課題、またはタイトルや本文に 500、down、broken、production のキーワードを含む課題は、報告に掲載する前に必ず検証してください。 未検証の P0 は Max のデスクワークの時間を無駄にします。実際のインシデントを見落とすよりも有害です。

判断フロー：

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

シナリオ別の出力形式：

シナリオ	形式
停止を確認済み（curl 5xx）	🔴 P0: org/repo — [title] [verified: curl → 503]
未検証（curl 200）	⚠️ UNVERIFIED: org/repo#N claims [keyword] — production returns 200, likely false positive
根拠はあるが URL がない	🟡 NEEDS REVIEW: org/repo#N — [title] — has evidence, cannot auto-verify
URL も根拠もない	⚠️ UNVERIFIED: org/repo#N claims [keyword] — no production URL or evidence; asked filer

報告者へのコメントテンプレート（URL も根拠も見つからない場合に投稿）：

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."

Section 1: オープンな課題

リポジトリごとに、オープンな課題をすべて列挙します。各課題が実際にオープンであることを確認してください。古いデータをそのまま繰り返してはいけません。

課題ごとの形式：

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

オープンな課題が0件の場合は、その旨を明記します。

Section 2: 対応待ちの PR

機能 PR と依存関係 PR は分けてください。同じリストに混在させてはいけません。

機能 PR：

- #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]

依存関係 PR（リスクラベル付きで各1行）：

- #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

リスクラベル：

• CRIT — セキュリティ CVE、既知の不具合、またはドキュメント化された破壊的変更を含むメジャーバージョン
• HIGH — API に影響する変更の可能性があるメジャーバージョンの更新
• MED — 目立った変更を含むマイナーバージョン
• LOW — パッチ更新、定例的なもの

PR 数の見出し：N open (X actionable, Y stale drafts) — 数だけを記載してはいけません。

CI が設定されていないリポジトリは、PR ごとではなく、セクション末尾に一度だけ記載します。

Section 3: 最新の更新

マージしたものは、PR 番号とマージ日を付けて名前を挙げます。「PR を8件マージ」のように数だけ記載しても役に立ちません。

形式：

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

7日間マージがない場合は、その旨と最後のマージ日を記載します。

Section 4: 次に推奨するタスク

具体的なアクションを2～3件記載します。それぞれに以下を含めてください：

• 該当する場合は正確なスラッシュコマンド：/review-pr 47 CLAPES-UC/ipc-med-backend ipcmed-runner
• 順序が重要な場合は実行順に関する注記：「依存関係をマージする前に実行してください — lockfile の競合リスクがあります」
• チームの Direction の目標に結び付けた理由
• リスクの高い依存関係への注意：「ローカルでテストせずに Next.js 16 をマージしてはいけません」

品質ルール

• すべての課題／PR に、クリック可能な完全な URL（https://github.com/org/repo/issues/N または /pull/N）を含めてください
• 経過時間には相対日付と絶対日付の両方を記載します：3d / 2026-04-10 — 3d だけにしてはいけません
• 「特に動きなし」ではレポートになりません。何もなかった場合は、バックログから次に行うべきことを記載してください
• レポートの前にデータの鮮度を確認してください — 推測せず、gh issue list と gh pr list を実行してください
• クローズ済みの課題はオープンではありません — gh issue view N --repo org/repo --json state で確認してください
• P0/P1 の本番環境に関する主張は、報告に掲載する前に必ず curl で検証してください — Section 0 の P0/P1 検証プロトコルを参照してください。未検証の P0 を報告に載せると、実際のインシデントを見落とすよりも多くの時間を無駄にします。

活動のないチーム向けの最小形式

オープンな課題が0件、かつ機能 PR が0件のチームには、通常形式の代わりに10行のステータスカードを使用します。

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

活動のないチームについて、セクションごとの詳細な内訳を作成してはいけません。有用な情報を加えず、ノイズが増えるだけです。

レポートの保存場所

すべてのレポートは $(git rev-parse --show-toplevel)/reports/ に保存します。crew/*/reports/ 内、またはそのサブディレクトリには絶対に保存しないでください。

レポートファイルの作成

上記のすべてのセクションを作成したら、/write-report を使用してファイルを書き込みます。

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

これにより、次のことが保証されます。

• 正しいパス（リポジトリのルートから reports/。crew/*/ は使用しない）
• CONVENTIONS.md に従ったタイムスタンプ付きの正しいファイル名
• Quest DB への自動投稿
• すべてのチームで一貫した命名

Write ツールを使って手動でファイルを書き込まないでください。必ず /write-report を使用してください。