私は最近、ストリーミング音声認識APIを使ったMac向け文字入力アプリ「Whistt」を開発しています。このアプリのリポジトリでは、今までの経験を踏まえて、作業に必要な開発ドキュメントをAIエージェントに自動で読み込ませる手法を検証しています。 この取り組みの狙いは、少ない人数で、より大きな範囲のソフトウェアを作ることです。そのためには、仕様の決定や技術的判断の経緯を、必要なときにAIに読み込ませる必要があります。 仕様書と意思決定記録の役割を分ける Whisttは、まずバイブコーディングでプロトタイプを実装し、その後で仕様書を整えました。立ち上げ時には、仕様書を先に作り、それをもとに実装を生成する仕様駆動開発（SDD）の進め方は採っていません。 仕様書は当初、Macアプリの一連の操作のうち、自動テスト化できていない部分を手で一つひとつ確認するためのチェックリストとして使っていました。QAフェーズで使うこうした項目は、今まではMarkdownの箇条書きやExcelシートにして、目視で確認していました。これをAIから使いやすいように、振る舞いや条件を一定の書式で書くGherki

ultracode とダイナミックワークフロー Claude Codeのeffortをultracode（UIではxhighの右、maxのさらに上）にすると、ワークフローのランタイムによる自動オーケストレーションが有効になります。 この仕組みはBunのZigからRustへの大規模なリライトで活用されたことで知られています[1]。 Claude Codeのビルトインツールである/deep-researchも、内部で同じワークフローを使っています。 ドキュメントによれば、このとき最大16個のエージェントが並列に起動し、それぞれが独立したセッションを持って動作します。 Claude Codeがユーザーの指示から「ワークフローにする価値がある」と判断した場合に、このランタイムが処理を担います[2]。 このultracodeのオーケストレーションを支えているのが、ダイナミックワークフローです。 画面上では/workflowsでバックグラウンドで動作したワークフローの一覧を確認できます。 デスクトップ版とコマンドライン版でUIは微妙に異なりますが、コマンドライン版の方が情報量が多くなって