worktreeとブランチの名前を考えるのが面倒なので、日付とランダムな形容詞・名詞を組み合わせた適当な名前で生成するようにしてる。
Claude Codeのフックでブランチが仮の名前だったらプロンプト内容をもとに自動でブランチの名前を更新するような仕組みを用意してる。
複数のClaude Codeを並列で実行しているが、常に1つは開発生産性の向上のために動かしている。
少しでも開発生産性に課題を感じたら、その課題をざっくり伝えて整理してもらったり、ストックされた課題の解決策をリサーチしてもらったり、実際にdotfilesなどを整備して課題を解決してもらったりしている。
課題を伝えるだけで、あとは自動的に課題を消化しPRを作成してくれるようになれば理想的かもしれない。個人の開発環境であれば、品質を厳密に考えずに進められるのでやりやすいかも。
Ghosttyで複数のworktreeからClaude Codeを並行して実行して、単一のVSCodeでファイルの閲覧・レビューを行うスタイルが定着しつつある。画面の左にGhostty、右にVSCodeを配置している。
VSCodeは常に単一ウィンドウで使用し、確認したいClaude CodeのセッションでBashモードから`code -r .`を実行すると、そのセッションのworktreeに対応した表示になる。
VSCode内蔵のターミナルでClaude Codeを起動すると、それぞれのworktreeごとに新しいウィンドウが必要となり、ウィンドウ数が増加する。複数のセッションで同時にファイルの閲覧やレビューを行うわけではないので、Claude CodeはGhosttyで複数起動し、VSCodeは集約するのが良い。
また、VSCodeのClaude Code拡張のショートカットを使って、Ghosttyで起動したClaude Codeに対してファイルや選択行の参照を挿入できるのも便利。
連休中にモバイルアプリのUIやアニメーションをエージェント開発でどれくらい品質向上できるか試してみた。結構良い感じかもしれない。
Claude Codeで要件定義や実装を進めたけど、特に大きな発見は、Geminiに視覚的な情報をもとにフィードバックをしてもらうことで品質向上しやすいことだった。
Geminiにはプロダクト仕様やデザイン方針のADR情報を与えつつ、実装情報は与えなかった。代わりに、Opusが仮組みしたUIのスクリーンショットや動画を提供したら、Geminiは的確に課題や改善案を提示してくれた。視覚情報を重視してほしかったので、実装を参照しないようCLIではなくWebUIで限られたコンテキストだけを与えるようにした。
GeminiのフィードバックをもとにOpusに実装の調整をさせて、後は十分な品質になるまで繰り返した。
主観かもだけど、例えばレイヤーや影が多重に重なる複雑な表現においても、Geminiは画像や動画から適切に情報を読み取る性能が他のモデルより優れていたと思う。
開発タスクの管理をLinearに寄せてみてる。
Claude Codeをプロジェクト管理用のエージェントとして、mainブランチで常時起動してる。タスク進捗後に次のタスクを聞いたり、状況変化時はタスクを整理させたりしてる。
あとは、タスクと1対1になるようworktreeを切って開発を進めてるけど良い感じだ。
Linear MCPは、marketplaceからプラグイン導入してブラウザ認証で完結するので、導入自体はかなりラクだった。
タスクのラベル付けとか依存関係の指定が安定しなかったので、SKILL.mdを作成して補強して利用してる。
5/ 実現性の向上
アイデアの全体像が見えてきたところで、自身の開発者プロフィールをコンテキストとして与えて調整させる。
スキルや経験を踏まえることで、実現可能性がぐっと高まるアイデアに調整できる。
開発者プロフィールは、ChatGPTの音声対話モードで自分にインタビューさせ、その内容を要約させると楽に作れる。
Jiro retweeted
【キャンペーン】
敬老の日は、MUSEUMでプレゼント！
おじいちゃん、おばあちゃんに「ありがとう」の気持ちを込めて、今年はMUSEUMで「お子さんの手作りグッズ」を贈ってみませんか？
10%OFFキャンペーン中：9月16日（月）まで
note.com/themuseum_jp/n/nf84…
#museum_jp
