インスタント・ソフトウェア・ファクトリー

インスタント・ソフトウェア・ファクトリー サウンド付きで視聴。 プロジェクトを継続的に改善する自律的なソフトウェア・ファクトリーを追加しましょう。 必要なものは2つです。 GitHubリポジトリ（Actionsの容量があること）と、強制力のあるブランチ保護。 公開リポジトリは無料プランを利用できます。 プライベートリポジトリは、個人アカウントの場合はPro、組織の場合はTeamまたはEnterpriseが必要です。 スケジューラ：このブートストラップは、Claude Pro、Max、Team、Enterpriseプランで利用可能なClaude Codeルーチンを使用します。 このリポジトリには、Claude Codeを使用してクラウドルーチンを通じてセットアップするためのプロンプトが含まれています。 BOOTSTRAP.mdは、エージェントの責任と運用上の制限を定義します。 セットアップエージェントは、プロジェクトに合わせてプロセス、モデル、スケジュールを選択します。 作業を開始するには 作業させたいリポジトリでClaude Codeを開き、以下を貼り付けます。 このリポジトリにインスタント・ソフトウェア・ファクトリーをセットアップしてください： https://github.com/mikolalysenko/mikolalysenko/instant-factory を一時フォルダにクローンし、そのBOOTSTRAP.mdに従ってください。 ローカルセットアップセッションを分離された環境で実行するには、オプションでclaude --dangerously-skip-permissions を起動して、権限プロンプトをスキップできます。 このフラグは、このブートストラップでは必須ではなく、クラウドルーチンの権限を設定しません。 Claudeの権限ガイダンスを参照してください。 ブートストラップは、リポジトリ、CI、ブランチ保護、履歴内の認証情報、GitHubアクセスを検査してから質問します。 必要に応じてghをインストールし、ローカル認証が欠落している場合は! gh auth login を実行するように求めます。 クラウドアクセスは別途チェックされます。 CIが欠落している場合は、プロジェクトの実際の検証コマンドを使用した最小限のワークフローが提供されます。 既存の失敗は記録され、既存の作業と保護策は保持されます。 予算またはスループットの目標、承認者、ルーチンID、およびQAがカバーすべき製品領域が不足している場合は、それらを尋ねます。 また、不足しているブランチ保護を解決し、承認がどのように機能するかを説明します。 ルーチンは接続されたGitHub IDを使用するため、それらのPRには個別の人間による承認が必要です。 ロールマーカーや手動マージでは、その承認を代替できません。 無人作業が開始される前に、デフォルトブランチは必須チェック、独立したレビュー、および最新コミットに対する人間の承認を強制する必要があります。 セットアップは、人間による承認を待機中のテスト済みPRを生成し、指示はリポジトリに保持されます。 制御された実行は、GitHubアクセス、現在のコミットのレビュー、マージ要件、およびマネージャーのスケジュールとシャットダウン制御を検証します。 本番スケジュールは、セットアップPRがマージされるまで無効のままです。 ルーチンはマージされた指示を使用し、あなたは再開を承認します。 セットアップレポートは、証拠、残りのギャップ、シャットダウン遅延、および残りの手順を記録します。 エージェントの使用とGitHub Actionsの時間の両方の予算を確保してください。 控えめなスループットから始めて、マネージャーのコストと結果の概要を検査し、CIと人間のレビューが追いつける場合にのみアクティビティを増やしてください。 なぜソフトウェア・ファクトリーなのか Vibeコーディングは、物事を存在させるのが得意です。 エージェントに明確な目標を与えれば、午後には動作するプロトタイプを作成できます。 しかし、プロトタイプは製品ではありません。 コードの最初の90%は最初の90%の時間を取り、残りの10%は残りの90%を取ります。 「私のマシンでは動作する」から本番品質への移行は、長い尾を引くフォローアップ作業を意味します。 エッジケース、バグレポート、パフォーマンスの低下、互換性、テスト、CI、リリース、人々が使い始めたら要求する機能、そしてプロトタイプがそこに至るために取ったショートカットのクリーンアップなどです。 その作業には、単一のゴールはありません。 それは、多くの懸念事項にまたがる数百の小さなタスクであり、コードが変更されるたびに新しいタスクが出現します。 各タスクをエージェントに指示することはできますが、その場合はセッションごとに開始し、待機し、結果を確認することになります。 あなたの注意がボトルネックになります。 ソフトウェア・ファクトリーは、各変更に対して新しいプロンプトを必要とせずに、それらの懸念事項に戻り続けます。 あなたは目標と制約を設定し、エージェントはバックグラウンドで調査、実装、レビューを行います。 このセットアップでは、人間がまだ着陸を承認します。 仕組み 各エージェントは、定常的な目標を持つスケジュールされたセッションです。 各実行はリポジトリの現在の状態を読み取り、有用な作業を選択し、それを実行し、結果を記録して終了します。 タスクによっては、サブエージェントやより複雑なワークフローを使用できます。 実行しても何もする価値がないと判断された場合、作業を作成せずに終了できます。 GitHubは共有状態を保持します。 イシューは証拠と提案された変更を運び、PRは実装とレビューを運び、ディスカッションやその他のリポジトリ記録は進捗と決定を保持します。 所有権と引き継ぎもそこに表示されます。 後続の実行は、前のセッションのメモリに依存せずに、記録された作業を引き継ぐことができます。 ブートストラップは8つのロールを作成し、異なる製品領域に個別の注意が必要な場合は追加のQAエージェントも作成します。 エージェント QA あなたと選択された製品領域とユーザーワークフローをテストし、再現可能で重複排除されたバグイシューを開きます。 パフォーマンス ベースラインに対して速度、リソース使用量、CI時間を測定し、証拠とともにイシューを開きます。 CI 失敗とフレークを修正し、弱めることなくチェックを信頼性が高く、高速かつ安価に保ちます。 アーキテクチャ 重複するビジネスロジックを統合し、不要な抽象化とレイヤーを削除し、動作を維持しながら構造を単純化します。 コンポーネントの数を減らします。 実装 イシューを修正し、テスト済みのPRを開きます。 PRレビュー コードを編集せずに最新のコミットを独立してレビューします。 マージ 必須チェック、独立したレビュー、および最新コミットに対する人間の承認後にのみマージします。 マネージャー 作業を優先順位付けして割り当てます。 古いPR、ブロックされたイシュー、および失敗した修正を完了まで追跡します。 各エージェントのコストと結果を追跡し、予算と容量内でモデルとスケジュールを調整し、マージされたPRあたりのコストを報告します。 これらは3種類の作業をカバーします。 機会の調査、変更の実装と統合、およびファクトリー自体の保守。 これらは調整のために同じリポジトリを使用します。 マネージャーは作業を進め、容量を割り当てます。 各エージェントは、共通のルール内で目標を追求する方法を選択します。 マネージャーは、create_trigger を使用して管理するルーチンを作成し、BOOTSTRAP.mdで指定されているように、ローカルのRemoteTrigger update を通じて各ルーチンのリポジトリ、モデル、ツールを設定する必要があります。 その作成パスは重要です。 なぜなら、マネージャーは他の方法で作成されたルーチンを変更できないからです。 各ロールには、必要なツールとコネクタのみが提供されます。 ブートストラップのプラットフォームノートは、インストールされたバージョンと実際の実行に対して検証するためのトライアルの発見をキャプチャします。 なぜ1つの非常に優れたエージェントではないのか？ 有能なエージェントは、タスクを計画し、分割し、明確に定義された目標を処理できます。 仕様と長いセッションは、単一の目標をうまく処理できます。 ソフトウェアプロジェクトには、同時に複数の目標があります。 新機能はパフォーマンス予算を消費する可能性があります。 バグ修正はCIを遅くするテストを追加する可能性があります。 クリーンアップは1つのサブシステムを単純化する一方で、別のサブシステムを複雑にする可能性があります。 これらのトレードオフは、コードが変更されるにつれて変化し続けます。 定常的な目標により、エージェントはそれらのトレードオフに戻ります。 パフォーマンスは、機能が着陸するにつれて測定を続けます。 アーキテクチャは、重複と不要なコンポーネントを減らし続けます。 CIは、他のすべてのエージェントが作業を早くチェックできるように、フィードバックループを十分に速く保ちます。 QAは、ユーザーが行うように製品をテストし続けます。 目標は互いを強化します。 より単純なコードは、実装とレビューを容易にします。 より高速なCIにより、すべてのエージェントが作業を早くチェックできます。 目標が競合する場合、エージェントは証拠を記録し、マネージャーはプロジェクトの目標と利用可能な容量に対して優先順位を付けます。 必須チェック、独立したレビュー、および人間の承認は、結果の変更を引き続き管理します。 ローカルセッションをジャグリングすることでこれを近似できますが、その場合は開始し続け、マシンを利用可能にしておく必要があります。 スケジュールされたルーチンにより、進捗がリポジトリに記録され、インタラクティブセッション間で作業が継続されます。 Cronとセッションの組み合わせ 私はまだインタラクティブな作業を行います。 新機能や大規模な変更については、ファクトリーがバグ、パフォーマンス、アーキテクチャ、CIに取り組んでいる間に、ブランチ上でローカルにセッションを開始します。 その機能は、同じチェックを通過します。