このリポジトリのアーキテクチャを、(1) 主要なディレクトリの責務 / (2) 入口となるエントリポイント / (3) ビルド・テストコマンド の3点に絞って 200 字で要約して。具体ファイル名で。

Explore サブエージェントを使って、ユーザー認証のコードがどこにあるか調べて。エントリポイント、ミドルウェア、ハンドラの3層に分けて、各ファイルパスと行数を返して。

このリポジトリで、cyclomatic complexity が高そうなエンドポイントを3つ挙げて。理由と、リファクタの優先度（高/中/低）も。

users API が500を返すバグを調査して直して。手順は: (1) 失敗するテストを書いて再現する (2) 原因を特定する (3) 最小修正を入れる (4) テストを green にする。各ステップの実行ログを残して。

main で動いていた認証フローが、いま壊れている。`git log -- src/auth/` を見て、機能的に怪しい変更を上から3つ挙げて、それぞれの怪しさの根拠を簡潔に。

次のログを見て、もっとも可能性が高い原因仮説を3つ。各仮説について、どのファイルを開けば検証できるかも示して。

[ここにログをペースト]

Plan Mode に切り替えて、`src/api/users.ts` の 100行を超えた部分を別モジュールに切り出す案を3つ提示して。それぞれの (1) 影響範囲 (2) テストへの影響 (3) リスク を比較表で。

`src/legacy/` 配下で、外部から import されていないファイルを列挙して。各ファイルについて『最後に変更された日』と『削除して安全か』も判定して。

`src/billing/` のうち、テストが薄いファイルを上位5つ挙げて。各ファイルで『最低書くべきテストケース』を3つずつ提案して。

`__snapshots__/UserCard.test.ts.snap` の内容を、明示的な expect アサーションに書き換えて。重要そうなフィールドだけを抜き出して、ビューロジックの本質的な検証になるように。

`git diff main...HEAD` を見て、このブランチを 2〜3 個の独立した PR に分割する案を出して。各 PR の (1) タイトル (2) 含めるファイル (3) なぜ独立できるか を表で。

現在のブランチの PR 本文を作って。フォーマット: 3行のサマリー（なぜ／何が変わる／影響範囲）+ Test Plan（チェックボックス箇条書き）。スクショは [TODO] で空欄。

`gh pr view 1234 --json files` でファイル一覧を取得し、変更を読んで、レビューコメントを下書きして。各コメントは `[P0|P1|P2] ファイル:行 — 指摘内容 — 提案` の形で。

このリポジトリの CLAUDE.md を作って。含めるのは: (1) パッケージマネージャ・言語バージョン (2) ビルド／テスト／lint コマンド (3) 触るな系の注意 (4) アーキテクチャ概要を3行で。200行以内。

README の Setup セクションを、現在の `docker-compose.yml` と `Makefile` の内容に合わせて書き直して。実際にコマンドを叩いた結果と一致するようにする。

`tests/api/` 以下のテストを読み、エンドポイントごとに OpenAPI 風の仕様（path, method, params, body, responses）を `docs/api.md` に書き出して。

[このスクショ] のレイアウトを Tailwind + shadcn/ui で再現して。色とスペーシングは見た目に近く、コンポーネントは `src/components/ui/` に入れる。

[before.png] と [after.png] の2枚を見て、UI の変更点を箇条書きで列挙して。スペーシング・色・コピー・配置の4観点で。

claude -p "このブランチの変更を3行で要約して。フォーマット: ・なぜ ・何が変わる ・影響範囲" --output-format text

/loop 5m PR #1234 の CI 状態をチェックして、緑になったら教えて。失敗したら失敗ジョブと最初のエラー行も。

/schedule cron='0 10 * * 1' --prompt 'package.json の依存で deprecation 警告が出るものを列挙し、移行案を Slack に投稿'