パルカワ2

最近はFlutterをやっています

最近の開発 2026-08

前回 最近の開発 - パルカワ2

大枠は変わらないが、ちょっと変わってきたので書く。

  • brainstorming スキルで考えていることを書き出してから進めている
    • grilling スキルと一緒に使うと質問がいい感じになるような気がしているが、気のせいかもしれない
  • 生成されるspecは https://crit.md/ を使ってレビューしている。
    • わからないことや見た感じ微妙だなと思ったところに代替案がないか聞いたりして、良さそうなら対応してもらうという感じ。やり取りは、Round 15くらいまで行くこともあるが、最近はFable 5, Opus 5のおかげか減ってきた
  • specが良さそうなら次に writing-plans スキルで plan を作成してもらい、同じように https://crit.md/ を使ってレビューしている。
    • planを頑張っても実際コードを書き始めると違ったということがあるが、最近はFable 5やOpus 5であればムムッとなることを言わなくなった感じがある
    • あとは、Claude Codeがリポジトリ内のドキュメントを参照してるというのもありそう
  • specとplanが終わったら、コンテキストが50%くらいになっていることもあるので一旦clearして進めたい。handoff スキルを使って引き継ぎ資料を作る
    • 本来handoffスキルで作成する引き継ぎ資料はtmpディレクトリに作成されるが、最近は plan.md, spec.md と同じ場所に置くようにCLAUDE.local.mdに記載している。（後述）
  • clear したあとに handoff.md を読み込ませて実装に進ませる。
    • 実装中は、並列で小さめのタスクのplan, specを作成したりしている。小さめのタスクもplan, specが終わったら using-git-worktrees スキルで作業環境を分けて実装している
  • 実装が終わったら、https://crit.md/ を使ってレビューする
  • crit上で自分のレビューが終わったら、create-pr スキルでDraftの状態+Copilotへのレビューアサインが済んだ状態でプルリクエストが作成される
    • AIが生成したものを人に見せる場合は、自分がすべてを見るぞという気持ちでいるので、自動でオープンにしない
    • オープンするとレビュアーがアサインされて通知がいって目に入るので。
    • Copilot のレビューは、Draftで出来るしレビューの日本語が壁みたいにならないので採用したが、最近レビューで助かることはほぼなくfalse positiveなことをよく言ってくるので使うのをやめようか悩んでいる
  • プルリクエストを作成したら改めて自分でタイトルとdescriptionと変更をレビューする。Copilotのレビューはrespond-to-reviewスキルで対応を検討してもらう
    • レビューの対応は検討はしてもらうが判断までは任せておらず、最終的には人間がヨシと言わないと進まないようにはなっている
    • 変更も見る。GithubのUIで改めて見て見逃しがないか見直す。
  • その他、動作確認含めて「すべてヨシ！」となったらプルリクエストをオープンしてレビューお願いしますと言う

上記のように基本的に既存のスキルを利用していて、既存スキルについてこうしたいなと思ったことは CLAUDE.local.md に書いている。

例えば、自分の頭の中にあるものを実装する気はないがとりあえずspecを先んじて書くとかよくやるんですが、superpowersのディレクトリ構成だとspecとplanの関係がわからなくなったりするので、issuesとしてまとめていて結構気に入っている。現状issuesはリポジトリにコミットはしていないけどコミットしようかなの方向に気持ちが傾きつつある。

他には、planしたことが実装時にうまくいかなかったら deviations.md として記録していて、後から見直せるようにしている。何回も同じこと繰り返している場合は CLAUDE.local.md に書いたりする。

またプルリクエストを分けるのは、自分がレビューする時にデカいと見たつもりなのに見れてないことがあったので、細かく分けるのがいいなとなった。最近Stacked PRという神機能がパブリックになったので愛用している。

- brainstorming / writing-plans の成果物は superpowers 既定の置き場を上書きし、変更単位ごとに 1 ディレクトリへ spec と plan を同居させる
  - spec（brainstorming）: `docs/issues/YYYY-MM-DD-<change-summary>/spec.md`
  - plan（writing-plans）: 元にした spec と同じ `docs/issues/YYYY-MM-DD-<change-summary>/` に `plan.md` として作成する（新規ディレクトリを切らず、その spec のディレクトリを再利用する）
  - `YYYY-MM-DD` は作成日、`<change-summary>` は変更内容を表す短いスラッグ
  - spec を伴わず plan だけ書く場合は、同形式で新規ディレクトリを作成する
  - spec・plan は git add / git commit を行わない。
  - spec を作成した後（brainstorming）と plan を作成した後（writing-plans）に、それぞれ crit スキルで `crit <対象ファイル>` を実行してレビューを行う
    - スキル既定の「ユーザーに確認を依頼する」レビュー工程（brainstorming の User Review Gate 等）は crit の実行で置き換える
    - crit のレビューが完了（コメントなしで Finish Review され approved になる）するまで次工程（spec なら plan 作成、plan なら実装）へ進まない
    - crit のコメントに対応する前に、必ず `superpowers:receiving-code-review` スキルを呼び出す。各コメントを技術的に検証・評価したうえで、「修正を適用する」か「`crit comment --reply-to` で技術的な根拠を添えて反論する」かを選ぶ。指摘を鵜呑みにして一括適用しない
- plan の実行中に plan の記述と実際が食い違ったら（設計が成立しない・想定外の既存実装・手順の変更・手戻りなど）、対応する前に plan と同じ `docs/issues/YYYY-MM-DD-<change-summary>/` の `deviations.md` に追記する
  - 記録項目: 対象タスク / plan の記述 / 実際どうだったか / 取った対応 / plan 作成時に何を確認していれば防げたか
  - `deviations.md` も git add / git commit を行わない
- `docs/issues/YYYY-MM-DD-<change-summary>/` の作業（spec / plan / 実装）を扱っている最中に handoff スキルを実行した場合、引き継ぎ資料は OS の一時ディレクトリではなく、対象の issues ディレクトリ配下に `handoff.md` として置く
  - 既に `handoff.md` があれば上書き更新する
  - `handoff.md` も git add / git commit を行わない
- plan 時にタスクを作成する時、レビュアーがレビューしやすいようにプルリクエストの作成は、意味のある単位で分割する。
  - プルリクエストを分割する時、 gh-stack スキルを利用して Stacked PRとして作成する
- プルリクエスト作成後は、人間が作業を行うので、そのまま次のタスクは進めず、人間の指示があるまで停止する。

自分は「AIを生産性向上のためではなく品質向上のために利用する」という気持ちでいて、品質を向上させるには実装より手前で潰せるものは極力潰し切るのがよいと思っているので、自分はこのフローが合っている。

最近触ったが合わなかったもの