tsono-about

macOSアプリの開発ワークフロー 2026年8月版

更新
目次

前提

マインドマップのmacOSネイティブアプリケーションを作っています。

意識していること

  • 決定論的な操作はスクリプトにして、Codexに使ってもらう。
  • 判断基準はMarkdownに書き、Codexに判断してもらう。

流れ

  1. 新しい機能を思いつく
  2. 自分で仕様の方針を決める（ときにはCodexとアイデア壁打ち）
  3. 自分で仕様の各ケースを思いつく限り列挙する
  4. grill-with-docs スキルを使って仕様詰めを行う
  5. 詰め切ったら to-tickets スキルと group-feature スキルでGitHubのイシューにする（※1）
  6. イシューの内容・粒度をレビューする（※1）
  7. レビュー内容を反映したイシューを作ってもらう（※1）
  8. 初手のissueを implementスキルで専用ワークツリーを作って実装開始（※2）
  9. Implementからレビュー用スキルを読んでレビュー&修正（※2）
  10. ユニットテスト（※3）
  11. E2Eテスト（※3）
  12. Swift Format, SwiftLint, コードの重複確認(jscpd), 未使用コード確認(Perriphery)
  13. 追加した機能の打鍵（※4）
  14. 指摘があれば修正。なければCommit → Push → PRを作る（※5）
  15. @codex review を投げて15分ごと（最大10回）に指摘を確認するようCodexに監視依頼（※5）
  16. 指摘があれば自動で修正を開始→テスト→コミット→プッシュ→@codex review を投稿→監視（※5）
  17. 指摘が仕様の変更に伴う場合は開発者に判断を委ねる（※5）
  18. 指摘がなくなるまで繰り返す（※5）
  19. 指摘がなくなったら、変更内容に関する資料を投稿（※5）
  20. 打鍵をしてからマージ（※4）
  21. ワークツリーを閉じる（機能開発のために作成されたビルドやキャッシュ関連も削除する）（※6）
  22. 次の issueを implement開始（※2）

工夫

※1 Issueでプロジェクト管理をする

group-featureは、to-tickets で作ったIssueをSub Issueとしてまとめた親Issueを作るスキル。親Issueにはfeatureラベルをつけるため、GitHub のProjectでラベル絞り込みをすることで、機能単位と作業単位で分けて進捗管理ができる

Feature Issue = 機能管理

Feature

Sub issue = 作業単位

Sub issue

※2 実装を進めるとき

依存関係のないIssueは並列で実装する

to-ticketsは依存関係でIssueを分割してくれるので、依存がなければ並列でimplementする

作業の競合を確認する

複数のworktreeで作業するため、着手前でbranchや変更ファイルの重なりを確認する。情報収集はスクリプトを用意しており、その判断はMarkdownでルールを決めている。Codexはそれらを使って情報収集及び判断を行う。

※3 テストの実行環境

テストは副作用に応じてホストとVMを分ける

ロジックだけを確認するテストはホストPCで実行し、アプリの前面化、キーボード入力、Pasteboardの操作など、ホストPCに影響するテストは Tart のVMで実行している。これにより、ホストPCの操作への干渉を防ぐ。

どのテストをホストPCとVMのどちらで実行するか、同時に何件まで実行するかという判断基準はMarkdownにルールを書いている。

VMへのソースの転送、VMの起動、テスト、結果の回収、停止はスクリプトを用意しているので、Codexは実行するテストを選び、決まった手順はスクリプトに任せる。

ビルドの同時実行数を制限する

ビルドやVMを使ったUIテストなどは、共通のスクリプトを通すことで同時実行数を管理している（同時に行われるとPCがアチアチになってしまうので）。実行要求は共通のFIFOキューに入り、順番が来るのを待つ。

※4 実アプリでの確認

複数のworktreeで開発していると、別のbranchや古いビルドのアプリを確認してしまうことがあるため、起動用スクリプトを使い、識別用のラベルを表示する。設定とSQLiteも分け、どのコードを打鍵したのかを明確にしている。

起動中のアプリには、アプリ名とbranch名を表示する。

起動中のアプリのタイトルバーに表示したアプリ名とbranch名

※5 PRの説明とレビュー

PRに変更内容を説明する資料を載せる

PRには、何を変えたか、どのように確認したか、まだ人が確認する項目があるかをまとめる。変更の構造が伝わりにくいときは、図も載せる。

PRレビューを監視する

PRを作ったセッションに、PRごとに1つのheartbeat監視を紐づけるスクリプトを作って、それをCodexに実行させている。いつ確認し、どの指摘なら自動で直してよいかという監視ルールはMarkdownに書いている。

  • 15分ごと、最大10回繰り返す
  • 監視によりレビュー指摘を発見したら自動で修正に入る
  • 新しいcommitをpushしたら@codex reviewを投稿して、再び監視
直せる指摘は自動で修正する

仕様変更を伴わない指摘は、再現→修正→テスト→commit→push→スレッド返信→再レビュー依頼まで自動で行う。

仕様変更を伴う指摘は開発者が判断する

Issueや仕様変更を伴う指摘は自動修正せず、開発者に判断を委ねる。

※6 マージ後の片づけ

マージ後のworktreeはすぐに削除せず、退役用スクリプトでキューに入れる。未commitの変更や使用中のprocessなど、削除してよい条件はMarkdownに書き、安全なものだけを削除する。

記事一覧へ戻る