Github

Claude Code 開発者が教える CLAUDE.md と実践 Tips 元スレッド（個人セットアップ編）: Boris Cherny @bcherny（53K いいね、780万ビュー） 元スレッド（チーム Tips 編）: Boris Cherny @bcherny（49K いいね、850万ビュー） 紹介ポスト: すぐる @sugurukun_ai 設定再現リポジトリ: 0xquinto/bcherny-claude はじめに Claude Code の開発者である Boris Cherny 氏が、自身のセットアップと Claude Code チーム全体の使い方を X で公開し、合計 10 万いいね以上を獲得して大きな話題になった。 この記事では、2つのスレッドの内容を統合して「CLAUDE.md の育て方」と「Claude Code を最大限活用する 10 の Tips」をまとめる。 CLAUDE.md とは CLAUDE.md は、Claude Code がセッション開始時に自動的に読み込むプロジェクトの指示書。新入社員に渡すオンボーディングドキュメントのようなもので、以下を記述する: プロジェクトの技術スタック・アーキテクチャ コーディング規約・命名ルール よく使うコマンド 過去に Claude が犯した間違いと対策 やってはいけないこと 配置場所 ファイル スコープ ~/.claude/CLAUDE.md 全プロジェクト共通（個人設定） プロジェクトルート/CLAUDE.md そのプロジェクト限定（チーム共有・Git 管理） Boris Cherny のセットアップ（スレッド1） 1. 並列セッション Boris はターミナルで 5 つの Claude を同時に並列実行している。さらに claude.ai/code 上でも 5〜10 個を並行稼働させ、システム通知で完了を監視する。 ...

Claude Projects × GitHub 同期 — AI のメモリより精度が高いナレッジ管理 紹介ポスト: yriica 「ClaudeのProjects内のFilesにGitHubリポジトリを同期できることが判明。GitHubリポジトリに日報含めいろんなデータをプッシュしておいたことで、その内容をふまえた上でClaudeでチャットができるようになった。AIのメモリ機能よりもこちらのほうが回答精度が高い。」 はじめに Claude.ai（ブラウザ版）の Projects 機能に、GitHub リポジトリのファイルを直接同期できる機能がある。日報、議事録、設計メモなど、普段の業務で Git に蓄積していたドキュメントが、そのまま Claude の高精度なコンテキストとして機能する。 これは「AI のために特別なことをした」のではなく、普段の業務として Git にドキュメントを蓄積していたものが、AI 活用で大きなアドバンテージになったという事例。 Claude Projects の GitHub 連携とは 基本機能 Claude.ai の Projects には「プロジェクトナレッジ」としてファイルを追加できる。ここに GitHub リポジトリを接続すると: リポジトリ内のファイル名と内容が Claude に読み込まれる 「Sync now」ボタンで最新のコミット内容に更新できる 複数リポジトリを1つのプロジェクトに追加可能 プライベートリポジトリにも対応（GitHub App 経由で権限付与） 設定方法 チャット内から追加する場合: 左下の「+」ボタンをクリック ドロップダウンから「Add from GitHub」を選択 ファイルブラウザで特定のファイルやフォルダを選択 メッセージ送信時に Claude がコンテンツを処理 プロジェクトナレッジとして追加する場合: プロジェクト知識セクションの右上「+」をクリック 「GitHub」を選択 リポジトリを検索、または URL を貼り付け ファイルブラウザで対象を指定 プロジェクトナレッジに追加 同期の仕組み 特定ブランチのファイル名とコンテンツのみが同期される コミット履歴、PR、Issue などのメタデータは取得されない 「Sync now」ボタンで手動更新（自動同期ではない） 大きな変更がある前に同期を実施するのがベストプラクティス 制限事項 複数リポジトリ追加時は Claude のコンテキストウィンドウに収まる必要がある 現在ベータ版 トークン制限を考慮した戦略的なファイル選択が重要 なぜ「メモリ機能より精度が高い」のか Claude にはチャットの中から情報を学習する「メモリ」機能があるが、GitHub 同期とは根本的に性質が異なる。 ...

git-lrc — コミット時に AI が無料でコードレビューしてくれるツール リポジトリ: HexmosTech/git-lrc 紹介ポスト: commte これは何か git-lrc は、git commit のタイミングで自動的に AI コードレビューが走るツール。Git フックとして動作し、コミット前の差分を AI（Google Gemini）に分析させ、バグやセキュリティ問題をブラウザ上の UI でインラインコメントとして表示してくれる。 しかも Gemini の無料枠を使うので完全無料。 なぜこれが作られたのか AI エージェント時代の新しい問題 Claude Code や Cursor などの AI コーディングエージェントは、コードを高速に生成する。しかし同時に、黙ってロジックを削除したり、挙動を変えたり、バグを混入させることもある — しかもユーザーに何も言わずに。 問題に気づくのは、たいてい本番環境にデプロイした後。 既存のコードレビューの限界 PR レビュー: チームメンバーの時間を消費する。AI 生成コードの量が増えるとレビューが追いつかない 手動チェック: 大量の差分を毎回目視確認するのは非現実的 CI/CD のテスト: テストがカバーしていない箇所の論理変更は検出できない git-lrc のアプローチ 「コミット」という全開発者が必ず通るポイントにフックすることで、レビュー漏れをほぼゼロにする。エディタや AI ツールキットが何であっても、Git は共通基盤。コミットは必須操作なので、スタックに関係なくレビューが走る。 どう動くのか セットアップ（約1分、1回だけ） 1 2 3 4 5 # インストール（Mac / Linux） curl -fsSL https://hexmos.com/lrc-install.sh | sudo bash # 初期設定（ブラウザで API キーを取得） git lrc setup 必要なのは2つ: ...

name: tmux-focus description: “tmux ウィンドウの Issue/PR 切替: /tmux-focus [-w|-r] ” tmux-focus スキル 現在の tmux ウィンドウの Issue/PR を切り替えるスキル。 使い方 /tmux-focus <number> — Issue モード Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh <number> ウィンドウ名を issue-<number> に変更し、対応する GitHub Issue をブラウザで開く。 /tmux-focus -w <number> — PR worktree モード gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。 Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number> ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。 EnterWorktree ツールで worktree を作成する。 worktree 内で以下を実行: 1 gh pr checkout <number> /tmux-focus -r <number> — PR レビューモード gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。 Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number> ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。 worktree 内でなければ EnterWorktree ツールで worktree を作成する。 worktree 内で以下を実行: 1 gh pr checkout <number> PR のコード差分をレビュー開始する（gh pr diff <number> で差分を取得し、変更内容を分析）。 スクリプトが存在しない場合 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh が存在しない場合は、以下の内容で作成して chmod +x する。 ...

CloudWatch Logs のエラーを自動で GitHub Issues に課題化する ECS で稼働するWebアプリケーションのエラーログを自動的に GitHub Issues に報告する仕組みを構築しました。手動でログを監視する必要がなくなり、エラー発生時に即座にチームが認識・対応できるようになります。 背景 マルチテナントの業務システムを ECS Fargate 上で運用しています。アプリケーションは2つあり、それぞれ異なるフレームワークで構築されています。 アプリ フレームワーク 用途 web Laravel (PHP) 業務管理システム api Django (Python) API サーバー これまで CloudWatch Logs にログは収集していたものの、エラーの検知は手動確認に頼っていました。500エラーや例外発生を見逃すリスクがあり、自動検知の仕組みが必要でした。 アーキテクチャ Subscription Filter + Lambda + GitHub Issues API の構成を採用しました。 CloudWatch Logs (/ecs/{prefix}-ecs-{app}) └── Subscription Filter (エラーパターンマッチ) └── Lambda Function (Docker/arm64, Python 3.12) ├── エラー解析 (HTTP 5xx, 例外, スタックトレース) ├── ±5秒のログコンテキスト取得 ├── 既存 Open Issue 検索 └── 新規 Issue 作成 or 既存 Issue にコメント追加 この構成を選んだ理由 方式 リアルタイム性 柔軟性 コスト Subscription Filter + Lambda (採用) 高 高 中 Metric Filter + Alarm + SNS 中 (1分以上遅延) 低 低 CloudWatch Logs Insights (定期実行) 低 高 低 Subscription Filter はログ出力時にほぼリアルタイムで Lambda を起動するため、エラー発生から数秒で Issue が作成されます。 ...

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する 背景 本番環境の ECS コンテナで発生したエラーは、CloudWatch Logs → Lambda → GitHub Issue という流れで自動起票される仕組みを運用しています。 タイトルは [prod][myapp] errors detected、ラベルは CloudWatchLog で統一されており、1つの Issue に複数のエラーブロックがまとまって届きます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ## Error Report - 2026-02-12 01:32:28 UTC - **Environment**: prod - **Log Group**: `/ecs/myapp-prod-ecs` - **Error Blocks**: 3 ### [1] 2026-02-12 01:32:26 UTC - `application` （スタックトレース） ### [2] 2026-02-12 01:45:10 UTC - `application` （スタックトレース） ### [3] 2026-02-12 02:01:33 UTC - `application` （スタックトレース） この Issue をそのまま放置すると、異なるエラーが混在したまま溜まっていきます。手作業で分類・個別 Issue 化するのは地味に面倒で、後回しにしがちでした。 ...

iPhone から GitHub Issue を書くだけで Mac の Claude Code が自動実行される仕組みを作った TL;DR GitHub Self-hosted Runner + Claude Code CLI を組み合わせて、iPhone で Issue を作成 → Mac 上の Claude Code が自動で調査・コード修正・PR 作成まで行う仕組みを構築した。2ステージ承認フロー付きで、/claude で調査、/approve で実行という安全な運用が可能。 モチベーション 普段 Mac の前にいないときでも、iPhone からコードの調査や修正を指示したい。GitHub Issue に書くだけで Claude Code が自動的に動いてくれれば、移動中でもコードレビューや修正依頼ができる。 完成した仕組み iPhone GitHub Mac (self-hosted runner) │ │ │ ├─ Issue 作成 ────────────→│ │ │ (claude ラベル付与) │── ワークフロー起動 ─────→│ │ │ ├─ claude -p (読み取り専用) │ │←── 調査結果コメント ──────┤ │ │ + 承認待ちラベル │ │ │ │ ├─ /approve コメント ──────→│ │ │ │── ワークフロー起動 ─────→│ │ │ ├─ claude -p (書き込み許可) │ │←── 実行結果 + PR ────────┤ │ │ - 承認待ちラベル │ トリガー一覧 操作 条件 動作 claude ラベル付き Issue 起票 起票者がリポジトリオーナー Stage 1: 読み取り専用で調査 /claude コメント コメント者がリポジトリオーナー Stage 1: 読み取り専用で調査 /claude --execute コメント コメント者がリポジトリオーナー Stage 1 スキップ、直接実行 /approve コメント コメント者がリポジトリオーナー + 承認待ち ラベル Stage 2: 計画に基づき実行 必要なもの macOS マシン (Apple Silicon / Intel) Claude Code CLI がインストール済み (npm install -g @anthropic-ai/claude-code) Claude Max/Pro プラン (OAuth トークン) または Anthropic API キー GitHub CLI (gh) セットアップ手順 1. Self-hosted Runner のインストール GitHub の個人アカウントでは Runner はリポジトリ単位の登録になる。同一マシンに複数の Runner を並置できる。 ...

nix NIXで管理するpython環境 uv https://docs.astral.sh/uv/ nix: https://github.com/pyproject-nix/uv2nix

supabase https://supabase.com/ 飛躍的に伸びているBaaS「Supabase」の概要と所感 PostgREST https://docs.postgrest.org/en/v12/ AWS https://github.com/supabase-community/supabase-on-aws Terraform: https://supabase.com/docs/guides/deployment/terraform PostGraphile https://www.graphile.org/postgraphile/

uv https://docs.astral.sh/uv/ nix: https://github.com/pyproject-nix/uv2nix インストール 1 % curl -LsSf https://astral.sh/uv/install.sh | sh 1 2 3 4 5 6 7 8 9 10 11 downloading uv 0.5.14 aarch64-apple-darwin no checksums to verify installing to /Users/hdknr/.local/bin uv uvx everything's installed! To add $HOME/.local/bin to your PATH, either restart your shell or run: source $HOME/.local/bin/env (sh, bash, zsh) source $HOME/.local/bin/env.fish (fish) 1 2 3 % source .local/bin/env % which uv /Users/hdknr/.local/bin/uv 1 2 % uv --version uv 0.5.14 (9f1ba2b96 2025-01-02) uvx (uv tool run) uvではdevelop環境で利用するtoolをuv tool(uvx)というコマンド別管理することが可能 ...