このページはAIアシスタント向けの実行手順書です。Claude Code、Codex、Cursorなど、ウェブページを読み取り、理想的にはリポジトリのローカルコピーで作業可能なアシスタントを対象とします。この手順書に従って、1つまたは複数のリポジトリに対してCoroidを設定します。サインイン、アクセス権付与、シークレット入力、変更承認など、人間のみが実行できる作業では必ずユーザーの確認を求めます。
アシスタントに渡してください
Coroidが作業するリポジトリでアシスタントを開き、以下のプロンプトを入力してください：
Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.複数のリポジトリの場合は、それらをすべて含むディレクトリでアシスタントを開き、プロンプト内で名前を指定してください。アシスタントが検査と確認を行い、ユーザーが対応が必要な各ステップで具体的な指示を出します。
アシスタントの基本ルール
Coroidはホスト型のAIソフトウェアファクトリーであり、作業内容の記述からユーザーのリポジトリ内でテスト済みかつレビュー済みのpull requestを生成します。以下のルールに従って作業を進めてください：
- ユーザーが実行し、アシスタントが準備します。ユーザーに代わってサインアップ、サインイン、利用規約への同意、アプリインストール、アクセス権付与は決して実行しないでください。具体的な手順と場所を伝え、ユーザーが完了を確認するまで待機してください。
- 会話内にシークレット情報を含めないでください。パスワード、個人用アクセストークン、プロバイダーキー、MCPトークンを要求決して実行しないでください。ユーザーはシークレットをCoroidポータルまたは自身のシェルに入力します。万が一チャットに貼り付けられた場合は、ユーザーにそれを無効化して新しいものを作成するよう伝えてください。
- 変更前に必ず確認を求めてくださいユーザーのリポジトリ内のコミット、ブランチ、プルリクエスト、Coroidプロジェクト、招待状などに関する作業です。
- 次のステップに進む前に各ステップを確認してください。チェックに失敗した場合は、そのステップの注記に従い、合格するかユーザーがスキップを選択するまで作業を続けないでください。
- 推測ではなく製品の仕様に従ってください。ポータルにこの実行手順書で説明されていない項目が表示された場合は、ユーザーに見えた内容を伝え、ポータルの指示に従ってください。設定を勝手に作り出さないでください。
- 設定記録を残してください最終的に各ステップとその結果を記録します。
各ステップでは、関連ページと詳細情報が連携します。https://coroid.ai/llms.txtドキュメント全体がインデックス化されます。
ステップ1：計画を合意する
以下の質問を一度に、またはまとめてユーザーに尋ねてください：
| 質問 | その理由 |
|---|---|
| どのリポジトリでCoroidを利用するべきですか？ | リポジトリごとに1つのプロジェクトを設定します。 |
| GitHubまたはGitLab？個人が所有する場合と組織が所有する場合があります。 | Coroidの接続方法や承認者を決定します。 |
| Coroidがプルリクエストを作成するべきでしょうか（同期済み）、それとも最初はCoroid内でのみ作業を続けるべきでしょうか（ローカルのみ)? | 「ローカルのみ」モードではリポジトリにデータが書き込まれることは決してありません。 |
| 既にCoroidの組織が存在し、どのプランを利用していますか？ | 無料プランでは1つのプロジェクトのみ利用可能で、他のメンバーを追加することはできません。 |
| 他に誰がその作業をレビューし、どの役割で行うのか？ | メンバーを招待するにはProfessionalプランが必要です。 |
| Coroidは組織独自のモデルプロバイダーキーを使用すべきか？ | 任意設定です。Coroid経由のモデルにはこれらは不要です。 |
次に計画内容を再確認します：ユーザーの介入が必要な下記の手順と対象となるリポジトリです。
詳細はプランと価格、制限とクォータおよび同期済みまたはローカルのみ。
ステップ2：各リポジトリがクリーンなクローンからビルドおよびテストできるかを確認する
Coroidのタスクはすべて、クリーンで使い捨て可能なLinuxワークスペースで実行されます。つまり、新しいクローンを作成し、キャッシュもインストール済みのツールも一切含まない環境です。プロジェクトのビルドやテストができないエージェントは自身の作業内容を検証できず、変更とは無関係な理由で検証に失敗するのです。
ローカルでリポジトリを操作できる場合は、各リポジトリに対して以下の手順を実施してください。
- 使用言語、パッケージマネージャー、およびモノレポかどうかを特定します。
- README、CI設定ファイル、マニフェストに記載されているインストール・ビルド・テストコマンドを見つけ出します。
- 実行前に必ず確認を求めてください。その後、空の一時ディレクトリにリポジトリをクローンし、他の設定なしでインストール・ビルド・テストを実行します。ユーザーの作業用コピーにはキャッシュや問題を隠すファイルが含まれているためです。
.envこれらのファイルが問題を隠してしまいます。 - 新しいクローンでは存在しないが、実行に必要な項目をすべて記録してください。
- テストで必要となるデータベース、キャッシュ、キューなどのサービスです。
- コード生成、マイグレーション、フィクスチャなど、テスト前に実行する手順です。
- 環境変数や
.envコミットされていないファイルです。 - プライベートパッケージレジストリです。
- エージェント環境に含まれていないランタイムです。 エージェント環境に含まれていないランタイムです。
デプロイ、パブリッシュ、または共有環境に影響を与えるコマンドは決して実行しないでください。テストスイートが遅い場合や有料サービスを利用する場合は、事前にユーザーに確認を取ってください。
各リポジトリごとに簡潔な準備状況チェック結果を報告してください。具体的には、使用したコマンド、スイートの実行時間、合格項目、および提案される修正策を含む各不足事項です。
| 不足事項 | 提案される修正策 |
|---|---|
| テストにはデータベースや別のサービスが必要です。 | スイートをサービス付きで実行するためのDockerfileまたはComposeファイルです。 |
必要な.envコミットされていないファイルです。 | コード内にテストの既定値を記述するか、非機密な値を含むコミット済みのテスト設定ファイルを作成します。 |
| テストには実際のシークレットが必要です。 | テスト内でその依存関係をモック処理します。シークレットをコミットしては決して実行しないでください。 |
| 依存関係がプライベートレジストリから取得される場合です。 | ユーザーに伝えてください。Coroidはプロジェクト設定としてそれらの認証情報を必要とします。 |
| サブディレクトリからのみコマンドが正常に動作する場合です。 | 正確なディレクトリ名とワークスペースフィルターを記録してください。 |
ランタイムが欠如している場合も障害にはなりません。ツールチェーンを内包するコンテナで対応可能です。ローカルでリポジトリにアクセスできない場合は、ユーザーから得られる情報を収集し、クリーンクローンによるチェックが実施されていないことを記録してください。
以下を参照してください：ビルドおよびテスト設定および言語サポートとエージェント環境。
ステップ3：Coroidのエージェントが読み取る指示書を作成する
各タスクの実行前に、Coroidのエージェントはリポジトリ内のメモリファイルを読み取ります：AGENTS.md、CLAUDE.mdまたはGEMINI.mdをルートディレクトリに配置し、.cursor/rules。ステップ2で検証したコマンドをここに記載します。
指示書を提案してください。AGENTS.md、または既存の指示書への追加内容として、以下の事項を明記してください：
- クリーンクローンから検証したインストール・ビルド・テストコマンド、およびそれらを実行するディレクトリです。
- テストで必要な手順やサービスです。
- 1つのパッケージや1つのファイルなど、最も限定された有用なテストセットの実行方法です。
- コード自体には記載されていない規約や制限事項：固定モジュール、触ってはいけない領域、追加してはいけない依存関係などです。
コードにすでに記載されている内容は省略し、ファイルを簡潔に保ってください。もしCLAUDE.mdまたは.cursor/rulesに同じ指示が記載されている場合は、それらをAGENTS.mdにまとめ、別のファイルから@AGENTS.md行でインポートします。
ユーザーに差分を表示します。承認を得たら、新しいブランチでコミットし、pull requestを開くか、またはユーザー自身にコミットさせます。最初のタスクを実行する前に、必ずベースブランチに反映させる必要があります。各タスクはそのブランチのチェックアウトからメモリファイルを読み込むためです。ステップ2でユーザーが承認した修正も同様の手順で処理します。
参照：プロジェクトコンテキスト設定およびプロジェクトコンテキスト。
ステップ4：アカウントと組織（ユーザー）
Coroidの組織にオーナーまたは管理者として既に所属している場合は、このステップをスキップしてください。
ユーザーに以下を依頼してください：
- でサインアップし
https://client.coroid.ai/auth/signup勤務用メールアドレスを使用して、 アドレスを確認してください - 利用規約に同意する
- 組織を作成する
確認：ユーザーがhttps://client.coroid.ai/projectsを開けることを確認してください。このセットアップを完了するにはオーナーまたは管理者の権限が必要です。なぜなら、ソースコントロールを接続し、プロバイダーキーを追加できるのはこれらの役割のみだからです。
参照：アカウントと組織を作成する。
ステップ5：ソースコントロールを接続（ユーザー）
開始前に、ユーザーと共にアクセス要件を確認してください。他者の承認を待つことで途中でインストールが停止し、このステップが1分で済むはずが1日かかることがよくあります。
GitHub
ユーザーは設定 → 接続 → ソースコントロール
(https://client.coroid.ai/settings/connections/source-control)。
| オプション | 以下の場合に使用する | GitHub上でユーザーが必要とするもの |
|---|---|---|
| GitHubアプリ(推奨) | ほぼ常に | リポジトリを所有するアカウントまたは組織にアプリをインストールする権限が必要です。組織の場合、通常はオーナーが該当し、他のメンバーはインストールを依頼してオーナーの承認を得ることができます。 |
| パーソナルアクセストークン | アプリがユーザーでは取得できない承認を必要とする場合 | 従来のrepoスコープを持つトークン、またはコンテンツおよびプルリクエスト選択したリポジトリに対して |
| URLで接続、接続なし | 公開リポジトリで、ローカルのみ | なし |
GitHubアプリ：GitHubのインストール画面で、ユーザーはリポジトリのみを 選択を選び、ステップ1で合意したリポジトリを指定します。インストールしたユーザーが退職してもアプリは正常に動作し、Webhookイベントを受信します。これによりCoroidがプルリクエスト上にチェック結果を公開できるのです。トークンではGitHubのチェックを公開できません。
パーソナルアクセストークン：ユーザーはGitHubで有効期限付きのトークンを作成し、Coroidポータルに貼り付けます。合意したリポジトリに限定された細かいスコープのトークンを使用することを推奨します。プルリクエストはトークンの所有者の名前で表示され、その人物のアクセス権が失われると接続が切断されます。
GitLab
GitLabは非公開プレビュー中であり、有効にしたアカウントでのみ表示されます。
この機能はapiスコープのパーソナルアクセストークンで接続します。もしソースコントロールにGitLabが表示されない場合は、ユーザーにCoroidへ連絡するよう伝え、それに基づいて計画を立てないでください。
ブランチ保護
Coroidは通常のプルリクエストを作成するため、ブランチ保護や必須チェック、レビュールールが引き続き適用されます。保護機能を有効にしたままにすることを推奨します。これらのルールで署名付きコミットやステータスチェックが求められる場合で、Coroidがそれらを生成できないと、プルリクエストは作成されてもマージ不可能な状態のままになります。ユーザーにその旨を伝え、ルールを変更しないでください。
確認事項：ソースコントロールの下でプロバイダーが接続済みと表示されているかを確認してください。実際の証拠はステップ6で、プロジェクト一覧にリポジトリが表示されることです。
参照：コードを接続する、GitHub、GitLabおよびリポジトリおよびブランチの設定。
ステップ6：プロジェクトを作成する（ユーザー）
リポジトリごとに1つのプロジェクトを作成し、1つのリポジトリに対して2つ以上のプロジェクトを作成しないでください。ユーザーはプロジェクト → 新規作成 (https://client.coroid.ai/projects/new) そして、各リポジトリについて：
- 接続済みのプロバイダーから取得するか、または次のように使用しますURLで接続パブリックリポジトリの場合
- 選択しますリポジトリモード：同期モードでは、Coroidがブランチをプッシュしてプルリクエストを開きます。ローカルのみモードでは、誰かが選択するまでCoroidはリポジトリに書き込みを行いません同期を開始
- デフォルトブランチを確認します
- プロジェクトを作成します
チームがデフォルトブランチ以外にマージする場合、例えばdevelopプロジェクトのリポジトリ設定でベースブランチを設定してください。誤ったベースブランチでは、誰もレビューしないブランチにプルリクエストが送信されてしまいます。
リストにリポジトリが含まれていない場合、その原因はほとんどの場合以下のいずれかです：
- GitHubアプリにそのリポジトリへのアクセス権が付与されていない
- トークンのスコープが狭すぎてリストできない
- そのリポジトリは、接続された組織とは異なる組織に属しています。
こちらをご覧ください：最初のプロジェクトを作成およびリポジトリとブランチの設定。
ステップ7：Coroidが検出した内容を確認
ユーザーに各プロジェクトの概要ページを開いて、その中のリポジトリ詳細情報やセットアップを完了：
- ステータスおよびブランチ：リポジトリがクローンされ、指定したベースブランチに配置されています。概要ページに「まだリポジトリがクローンされていない」と表示される場合、ユーザーはリポジトリをクローン。
- スタック：Coroidが検出した言語、フレームワーク、パッケージマネージャー、テストツールです。これらを事前チェックの結果と照合してください。初回同期後にスタックが空または不適切な場合、ユーザーはそこから再スキャンを実行できます。
- セットアップを完了：「依存関係のインストールが正常に完了しなかった」などの項目は、ステップ2で指摘された同じ問題を示しています。ユーザーと共にそれらを解決してください。
その後、ユーザーはプロジェクトの設定 → ナレッジ → コンテキストを開きます。ステップ3で作成されたメモリファイルがリポジトリソースの下に記載され、有効になっている必要があります。もし作成と表示される場合、そのファイルはまだ接続されたブランチに反映されていません。
こちらをご覧ください：プロジェクトコンテキスト設定およびビルドおよびテスト設定。
ステップ8：組織設定（オプション）
ユーザーがこれらを今すぐ設定するかどうかを確認してください。すべてに適切なデフォルト値が用意されています。
- メンバー、以下の場所で設定します：設定 → メンバー：プルリクエストをレビューする人々で、オーナー、管理者、メンバー、またはレビュアーとして指定されます。ポリシーやプロバイダーキーの変更が必要な人には管理者権限のみを推奨します。Professionalプランが必要です。
- プロバイダーキー、以下の場所で設定します：設定 → プロバイダーキー：組織専用のモデルプロバイダーアカウントを利用するためのみに使用します。ユーザーはポータル内でキーを入力します。プロバイダー側で利用上限を設定した制限付きのキーを推奨します。
- 他の組織からの設定：そこで設定バンドルをエクスポートし、以下の場所でインポートします：設定 → データ → 設定をエクスポート。シークレットはプレースホルダーとして送信されるため、プレビュー内の各項目に注意が必要です。
needsRebindプレビュー内の各項目に確認が必要です。
詳細はこちら：アカウントと組織を作成する、プロバイダーキーおよび設定のエクスポートとインポート。
ステップ9：自分自身をCoroidに接続する（オプション）
クライアントがリモートMCPサーバーをサポートしている場合、以下のURLのCoroid MCPサーバーを通じてCoroidにアクセスできます：https://api.coroid.ai/mcp。セットアップはこれに依存しませんが、プロジェクトを自分で確認したり、後でユーザーが作業を実行するのを支援したりできます。
- ユーザーは設定 → 自動化 → Coroid MCPサーバー
(
https://client.coroid.ai/settings/automation/coroid-mcp)。該当組織で利用できない場合は、このステップをスキップしてください。 - クライアント設定では各クライアントごとのコマンドを確認できます。OAuthを使用する場合、ユーザーはブラウザでアクセスを承認します。個人用アクセストークンを使用する場合、ユーザーは以下の場所で作成します：アクセストークンそして自身のシェル内の環境変数に保存します。あなたがその値を直接確認する必要はありません。
- 機能する最小限のアクセス権を推奨します：
mcp.readセットアップを確認するための権限に加え、mcp.work.writeタスクを作成する場合のみ、これらのプロジェクトに限定し、有効期限を設定して自動化ポリシーを設定してから、クライアントが無人で実行できるようにします。
確認方法：を呼び出し、list_projects、次にget_projectステップ6で指定した各プロジェクトに対して実行し、リポジトリとブランチを確認します。
MCPにはapi.coroid.aiのみを使用してください。クライアントポータルのホスト名では利用できません。
詳細はこちら：CoroidをMCPサーバーとして利用する。
ステップ10：最初のタスクを作成する
最後に、新しく作成したプロジェクトのいずれかでユーザーと共に小さな最初のタスクを作成します。良い最初のタスクとは、実際のもので小さく、既存のテストに近く、明確な完了基準があるものです。認証、決済、データ移行、終わりのない整理作業、まだ誰も決定していない設計判断が必要なものは避けてください。
実装方法ではなく成果物を記述します：作業完了時に何が真であるべきか、どのファイルが関連するか、触ってはいけない部分を明記します。ユーザーは以下の場所からそれを送信します：新規作業 (https://client.coroid.ai/work/new)、システムは仕様書を読み取り、計画を承認します。作業の実行にはエージェント時間が使われ、FreeプランではUTC時間で1日あたり2時間まで利用可能なので、いつ実行するかはユーザーが決定します。
詳細はこちら：最初のタスクを実行するおよび仕様書。
ステップ11：引き継ぎ
ユーザーにセットアップ記録を渡します。
- 各リポジトリのプロジェクト、リポジトリモード、およびベースブランチ
- ソースコントロールの接続方法と、その接続を管理する主体：アプリのインストーラー、またはアクセストークンのオーナーと有効期限
- リポジトリごとの修正済み項目、未解決の項目（例えば、開いているプルリクエストが存在する場合）
AGENTS.md)、およびユーザーが保留に選択した項目 - 設定済みまたはスキップされたオプション設定と、下書き状態の最初のタスク
次に、ユーザーを以下の場所へ誘導します。結果をレビューしてマージする最初のpull requestで提供される内容について
次へ
アカウントと組織を作成する— 同じ設定を手作業で行う場合