常に日本語で応答すること。
正解は一つではない。自分に合うやり方を実験して見つけること。
- git worktreeを3〜5個同時に立ち上げ、それぞれで別のClaudeセッションを並列実行する
- worktreeに名前をつけてシェルエイリアス（za, zb, zc）で瞬時に切り替える人もいる
- 分析専用のworktreeを用意し、ログ確認やBigQueryだけに使う人もいる
- 参考: https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees
- 計画に全力を注ぎ、Claudeに一発で実装させる
- あるメンバーは1つ目のClaudeに計画を書かせ、2つ目のClaudeにスタッフエンジニアとしてレビューさせる
- うまくいかなくなったら無理に押し進めずplan modeに戻って再計画する
- 検証ステップにもplan modeを使う（ビルドだけでなく）
- Claudeを修正するたびに「CLAUDE.mdを更新して同じミスを繰り返さないようにして」と伝える
- Claudeは自分自身のルールを書くのが驚くほどうまい
- CLAUDE.mdは時間をかけて繰り返し編集し、ミス率が下がるまで磨く
- タスク/プロジェクトごとのnotesディレクトリを管理させ、CLAUDE.mdから参照する方法もある
- MEMORIES.mdなど別の記憶ファイルは作らない（Boris本人が「CLAUDE.md 1ファイルで十分」とX上で明言。境界が不明瞭になるため）
- プロジェクト固有のルール →
./CLAUDE.md（git管理・チーム共有）、個人設定 →~/.claude/CLAUDE.md
- 1日に2回以上やることはスキルかコマンドにする
/techdebtコマンドを作り、セッション終了時に重複コードを検出・削除する- Slack・GDrive・Asana・GitHubの7日分を1つのコンテキストに統合するコマンドを作る
- dbtモデルの作成・レビュー・テストを行う分析エンジニア型エージェントを構築する
- 参考: https://code.claude.com/docs/en/skills#extend-claude-with-skills
- Slack MCPを有効にし、バグスレッドを貼って「fix」と一言で済ませる
- 「CIの失敗テストを直して」と言うだけ。やり方は指示しない
- dockerログを指してトラブルシューティングさせる（分散システムでも驚くほど有能）
- 「この変更を厳しくレビューして。テストに合格するまでPRを作らないで」とClaudeに挑戦させる
- 「これが動くことを証明して」と言い、mainとfeatureブランチの差分を検証させる
- イマイチな修正の後は「今わかっていること全てを踏まえて、一からエレガントな解決策を実装して」
- 曖昧さを減らした詳細な仕様を書いてから渡す。具体的であるほど出力が良くなる
- Ghosttyが人気（同期レンダリング、24bitカラー、Unicode対応）
/statuslineでコンテキスト使用量とgitブランチを常時表示する- ターミナルタブを色分け・命名する（tmux利用者も多い）
- 音声入力を使う。タイピングの3倍速で、プロンプトがはるかに詳細になる（macOSならfn×2）
- 参考: https://code.claude.com/docs/en/terminal-config
- より多くの計算リソースを投入したいリクエストには「use subagents」を付ける
- 個別タスクをサブエージェントに委任し、メインのコンテキストウィンドウをクリーンに保つ
- hookでOpus 4.5に権限リクエストをルーティングし、安全なものを自動承認させる
- 参考: https://code.claude.com/docs/en/hooks#permissionrequest
bqCLIでメトリクスを直接取得・分析させる- BigQueryスキルをコードベースにチェックインし、チーム全員が使っている
- CLI・MCP・APIがあるデータベースなら何でも応用可能
- SQLを自分で書かなくて済む
/configで「Explanatory」や「Learning」出力スタイルを有効にし、変更の理由を説明させる- 馴染みのないコードを説明するHTMLプレゼンテーションを生成させる
- 新しいプロトコルやコードベースのASCIIダイアグラムを描かせる
- 間隔反復学習スキルを作る: 自分の理解を説明→Claudeがフォローアップ質問→結果を保存