Templates — 再利用したいものから選ぶ

aachatには3種類のtemplateがあります。既存Projectの文書を揃えたいのか、担当Agentごと新しいProjectを始めたいのか、公開フォームからクライアントを迎えたいのかで選びます。

どれも開始時に使う材料です。後からtemplateを編集しても、既存Projectへ継続同期する仕組みではありません。

既存Projectで文書kindを再利用する

複数のProjectでbrief・spec・reportの書き方を揃えたいときに使います。kindは文書の構造と表示規則を定め、_template.mdは執筆の出発点となる本文です。kindの導入ではProject作成、Agent割り当て、会話コピー、既存文書本文の移行は行いません。

1. 対象Projectの Docs で Discover templates を開くか、Project Settingsの Kind Definition で Install from Discover を開きます。AdminまたはCollaboratorの書き込み権限が必要です。Discover → ドキュメントテンプレートの詳細ページの インストール からも、Team slugとProject名を指定して導入できます。
2. カタログを検索して選択します。先にkind一覧と説明を読みます。
3. 導入します。同じkind名がある場合は“Conflicting kinds detected”と表示されるので、既存側と導入側の名前を確認してから Overwrite conflicting kinds を選びます。既存定義を維持したい場合はキャンセルします。
4. 導入されたkindと文書雛形を確認し、選んだkindのtemplateから文書を作って実際の仕事の内容を記入します。表示されたfieldと検証diagnosticを確認します。

たとえばbrief kindを導入した後、その雛形を使ってProject内のdocs/brief/website-refresh.mdを書きます。例文は実際の目的と制約に置き換えてください。ローカルpathは次のとおりです。

aachat/teams/<team>/projects/<project>/docs/brief/website-refresh.md

Shared Documentsの手順で保存します。

導入は衝突しないkindをmergeし、同名kindは明示的な上書きを要求します。既存定義が不正な状態で強制導入すると、その定義を置き換える場合があるため、先に確認・保存してください。既存文書の本文は書き換えませんが、kindのschemaを置き換えると検証と表示は変わることがあります。カタログ側の後日の更新が導入済み定義へ自動反映されることはありません。

kind templateを公開する入口は2つあり、どちらもAgent公開とは別です。

• 公開管理から準備する: 公開管理の Publish something new で ドキュメントテンプレート と元のProjectを選びます。自分のPCのRuntimeがProjectのkind定義をkinds.yamlとして書き出し、公開用に整えます。人間が内容を確認して公開します。同じProjectから公開し直すと同じテンプレートを更新します。手順はDiscoverを参照してください
• Kind Definitionから直接公開する: Project Settingsの Kind Definition の Publish as Template で、選択した定義をそのまま共有します。Name、Slug（2〜64文字の小文字英数字と単一のハイフン）、Tagsを入力します。未保存の変更や検証エラーがあると公開できません

どちらの場合も、schemaと雛形・例文にprivate情報がないことを確認します。導入に失敗したらProject権限と検証エラーを確認してください。衝突は既存定義を残すか上書きするかを決める必要があり、同じ要求を繰り返すだけでは解消しません。

DiscoverのProject TemplateからProjectを開始する

カタログの実践例に近い仕事を、担当Agentの構成ごと始めたい場合に使います。開始すると、templateが指定する担当Agentを自分のAgentとして準備し、全員の参加、Lead、PROJECT.md、文書kind、Workflowを揃えてから、Leadへ最初の依頼を送ります。Leadは手動で選びません。

Discoverホームの棚と左ナビの Project templates は、公開中のtemplateが1件以上あるときだけ表示されます。ページ自体は /ja/discover/project-templates で開けます。

事前条件:

• サインインし、Projectを作るteamのactiveメンバーであること。
• 新しく準備するAgentがある場合は、GitHub連携を一度許可できること（Agentは自分のGitHubアカウントのprivate repositoryとして作られます）。
• Leadをすぐ動かすには、自分のruntimeがaachat upで接続されていること。未接続でもProjectは作成でき、LeadのSessionは接続を待ちます。

手順:

1. Project templatesでtemplateの詳細と担当Agentを読み、プロジェクトを開始 を選びます。templateの定義が不完全（担当・Lead・固定commitの不足）、担当Agentがいない、担当Agentがカタログに登録されていない場合は開始できません。
2. Which team owns the project でteam、Project name に新しいProject名（小文字英数字とハイフンで2〜30文字。stream・dm・repoは不可）、What should this project do? に目的、完了の根拠、判断の境界、重要な参照を書きます。
3. Review project setup を選び、The agents for your project で担当ごとの割り当てを確認します。
   • 同じteam・同じ公開元・同じcommitで以前準備した自分のAgentがあれば、それを再利用します（利用者の変更やruntime設定は保持されます）。なければ新しいAgentを準備します。
   • Change assignments で、同じ公開元から作った自分の有効なAgent（休止中でなく、repositoryがあるもの）を担当に指定できます。別teamで使っているAgentもこのteamに参加します。
   • 以前準備したAgentが削除・休止されている場合は、Prepare a new agent for this role を明示的に選びます。
   • 新しいAgentを準備する場合は Runtime for new agents でruntimeを選びます。接続中のruntimeが一つだけならそれが使われます。
   • 取り込まれる文書template（kind）とWorkflowが表示されます。WorkflowはRunを開始せず、Triggerも作らずに導入されます。
   • GitHub連携が必要なら Connect GitHub once と表示されます。
4. Start this project を一度押します。準備中は Preparing your project と進捗が表示されます。
5. Your project is ready になったら Open project で開きます。担当Agent全員の参加、Lead、PROJECT.md、Docsのkind、Workflowsを確認し、LeadのSessionで接続状況と応答を追います。

Leadの最初のSessionはセットアップを担います。PROJECT.mdと初版REPORT.mdを整え、必要な情報はAskで確認し、2文書が完成したら終了します。その後の仕事はユーザーが依頼します（Projects）。準備の完了は最初の依頼の受付を意味し、成果の完成ではありません。

取り込まれるもの・取り込まれないもの

Project、PROJECT.md（{project_name}と{agent.<key>}を実際の名前へ置換）、自分のAdmin参加、担当Agent全員の参加、Lead、文書kindの_template.md、公開済みWorkflow、Leadへの最初の依頼は、一つのtransactionでまとめて確定します。途中まで作ったProjectが残ることはありません。

新しく準備したAgentは、公開元repositoryの固定commitを自分のprivate repositoryへコピーしたもので、通常のAgentと同じく個人teamにDMが作られます。コピーは1 repositoryあたり20 MiBまでで、submodule、symbolic link、Git LFSを含む公開元は準備できません。

既存の文書インスタンス、Trigger、既存Projectへの再適用は含みません。作成後のProjectは元templateと同期しません。

中断・再開・失敗したとき

• 準備は保存されます。ブラウザを閉じても、teamの Projects 画面の Your project preparations に未完了の準備が表示され、Resume setup で再開できます。応答を受け取れなかった場合も同じ準備を照会するので、同じProjectが二重に作られることはありません。
• 準備中にProject名が使われた場合は Choose another project name で名前を変え、Save name and continue で同じ準備を続けます。
• GitHub認証が必要になった場合は Connect GitHub and continue、一時的な失敗は Retry preparation を使います。
• Cancel preparation で中止できます。すでに準備したAgentとrepositoryは自動削除されず、自分の手元に残ります。
• 送信結果が不明なときは、新しい準備を始める前に Your project preparations とProjects一覧を確認してください。

Project Templateを公開管理で準備し、人間が公開する

Project Templateは、Discoverの公開管理で自分のProjectを元に準備し、人間が内容を確認して公開します。Agentは公開できません。

事前条件:

• サインインしていること。
• 元にするProjectに、AdminまたはCollaboratorとして参加していること。アーカイブ済みのProjectは選べません。
• 自分のPCでaachatを起動し、公開管理の画面で接続済みになっていること。準備はそのPCのRuntimeで進みます。
• templateの担当にするAgentが、Discoverに公開済みであること。準備ではAgentを自動で公開しないため、未公開のAgentがあれば先に公開します（Discover）。

手順:

1. 公開管理の Publish something new を選び、種類で プロジェクトテンプレート を選びます。
2. 公開元 で元にするProjectを選び、Runtimeと接続状態を確かめて 公開の準備を始める を押します。
3. 公開準備用Agentが、Projectの文書・文書kind・Workflow・担当Agentの構成を読み、project-template.jsonと参照ファイルを公開用に整えます。準備が終わると、公開する文書・担当・Workflowと、元からの変更点を確認できます。
4. 直したい点は同じ画面の会話欄に書きます。下書きは保存されるので、公開管理の一覧の行や同じURLから続けられます。元のProjectのファイルは変更しません。
5. 内容を確認して この内容で公開する を押します。公開に失敗した場合は同じ画面から再試行できます。
6. Discoverの プロジェクトテンプレート で公開ページを確認します。

画面の共通の流れと上限はDiscoverを参照してください。

保存済みの下書きを確認する

公開管理の一覧でProject templateの行を開くと、保存済みの下書きの確認画面（/discover/admin?template=<id>）が開きます。

• Overview・Agents・Documents・Workflowsを切り替え、文書はkind、Workflowはslugとファイルを選んで読みます。Overviewでは元のmanifestも開いて確認できます。表示された問題を解決し、「保存されたこのリビジョンと同梱ファイルを確認しました。」にチェックして 確認したリビジョンを公開 を選びます。

下書きの保存だけでは公開版は変わりません。一覧の状態は「非公開の下書き」「公開中」「公開中（未公開の編集あり）」で区別されます。確認中に下書きが変わると公開・公開停止は拒否されるので、更新された内容を確認し直します。公開を停止 しても下書きは残ります。slugが他のtemplateと重なると“Project template slug already exists”で公開できません。

定義の制限

• project-template.jsonと参照ファイルを合わせて2 MiBまで。参照は同じディレクトリからの相対パスだけで、絶対パス、..、symbolic linkは使えません。
• 担当Agentは1〜10件で、Leadはちょうど1件。各Agentは公開catalogのrepositoryを参照し、40文字の小文字commit SHAで固定します。同じrepositoryは1回だけです。keyは重複しない小文字の識別子（英数字、-、_、40文字以内）です。
• 文書kindは32件まで、Workflowは16件まで。各Workflowは通常のbundle制限（1ファイル1 MiB、1 bundle 4 MiB、128ファイル）に従います。
• PROJECT.mdと文書templateでは{project_name}と{agent.KEY}を使い、作者自身のAgent名を書きません。Workflowのsteps.<key>.session.agentは引用符付きの"{agent.KEY}"にします。

Client Entry templateでクライアントを迎える

GitHubアカウントを要求せず、専用のクライアント会話を始める場合に使います。Discoverとは別に、team owner/Adminが Team Settings → Client Entry で設定します。

1. consultation-{date}-{short_id}などのProject名patternを持つ、有効なtemplateを作ります。
2. defaultの人間メンバー（Project Admin）とAgent（Collaborator）を選びます。default membersが空ならentry link作成者がAdminとして参加します。
3. templateを選んで有効なentry linkを作り、title・description・message prompt・任意の期限を指定します。一度だけ表示される公開URLを保存します。
4. 別のブラウザprofileでURLを開き、秘密情報のないテスト入力を送ります。専用Project、最初のmessage、guestアクセス、想定したメンバーを確認してからクライアントへ渡します。

このtemplateは名前とmembershipを設定するもので、Discover templateの文書やWorkflowを取り込みません。guestはCollaboratorで、ブラウザのloginは 7日間 有効ですがguest再loginの仕組みはありません。同じemailでも再送信すると別guestと別Projectを作ります。継続する仕事にはGitHubによるProject参加を計画します。詳しい設定とアクセス制約は接続repo / client entryを参照してください。

templateやlinkを無効にすると新規受付を止め、既存Projectは残ります。RotateはURLを交換し、古いURLを無効にします。どちらも既存guestの移行やlogin期限延長は行いません。新規受付の管理と、開始済みの仕事へのアクセス管理を分けて扱います。

カテゴリーは全種類で共通です。aachat tag list（JSON は aachat tag list --json）で語彙を確認し、仕事に合うキーを1〜3個選んでください。ぴったりの語彙がなければ近いものを選び、追加候補を運営へ提案してください。自由なキーや退役したキーは公開時に受け付けません。