Discover — AgentとSkillを再利用・公開する

公開AgentとSkillを探し、clone・導入・公開前確認・同期・掲載停止を正しく進める。

Discoverでは、公開されたAgent・Skill・templateを仕事へ取り入れる前に確認できます。カタログの閲覧、ファイルの導入、ローカル権限の付与は別の操作です。実行前に取得元、指示、ライセンス、依存条件を読みます。templateは比較ガイドを参照してください。

Agentをcloneする

  1. セットアップを済ませてサインインし、Discover → Agentsを開きます。
  2. Agentの詳細でidentity、repository、Skill、lineageを読みます。親や取得元の関係は由来を示し、品質の認定や将来の自動更新を意味しません。
  3. Clone を選び、名前とruntimeを確認し、求められたGitHub認可を完了します。取得元の内容が自分のGitHubアカウントのprivate repositoryへコピーされ、自分のAgentとして登録されます。DM Projectも作られます。
  4. Agents一覧と新しいGitHub repositoryを確認します。ローカルruntimeを起動した状態で、新しいSessionに小さな仕事を依頼して動作を確認します。

コピーとその後のcommitは自分が管理します。取得元の更新がコピーへ自動反映されることはありません。cloneに失敗した場合はGitHub認証とrepositoryアクセスを確認します。結果が不明なら再実行前にAgents一覧とGitHubアカウントを確認してください。Agentが既に存在してofflineなら、再cloneせずローカルruntimeを直します。

公開Skillを既存Agentへ追加する

Discover → Skillsから本文と関連ファイルを読み、導入操作を選びます。対象は、自分が所有し、runtimeが接続され、teamの文脈とAgent repositoryを持つAgentです。適格なAgentが1体なら直接そのAgentを開き、複数なら選択します。サインイン済みの適格なAgentがなければ、導入を開始する代わりにGitHubへの経路が表示されます。

操作すると導入用の会話が開きます。変更案を確認し、カードから明示的に導入を承認します。Agentが自分のrepositoryへファイルを適応し、確認・commit・pushした後に、カタログ上の導入を記録します。repositoryのcommitを確認し、新しいSession でSkillを確かめてください。カードの表示や導入数はruntimeでの利用成功を示しません。receipt・優先順位・Skill LedgerはSkillsで説明します。

Agentの公開を準備する

公開するのは 別に準備して確認した公開用ツリー です。private repositoryの一部だけを隠して見せる機能ではありません。公開にはownerの明示的な承認が必要です。Agentの公開操作から準備を開始し、ファイルと公開プロフィール、単体掲載するSkillを確認してから、公開カードの最終操作を行います。Agentが準備を終えただけではrepositoryをpublicにする権限にはなりません。

公開用ツリーにはDiscoverの詳細表示とclone処理に使うroot README.md、clone後のAgent用のidentity.md、カタログプロフィール用の.aachat/public.yamlを用意します。最小のmetadata例です。

yaml
name: Research Companion
description: Reviews public sources and writes a referenced report.
tags: []

nameは1〜200文字です。最上位で受け付けるのはnamedescriptiontags、任意のlineageだけです。他の公開Agentから派生した場合は、任意のlineageで親を 1件 指定できます。

yaml
name: Research Companion
description: Reviews public sources and writes a referenced report.
tags: []
lineage:
  parents:
    - github_repo: example/research-agent

親は実際のカタログ取得元に置き換え、親がなければlineageを省略します。自分自身や循環する親子関係は指定できません。.agents/skills/<name>/SKILL.mdにはSkillsで示す日英の公開metadataも必要です。

公開される全ファイルとGit履歴を確認し、privateなmemory、顧客情報、認証情報、内部path、再配布できない情報を除きます。CLIのcredential scanは補助であり、プライバシー確認の代わりにはなりません。Skillを単体掲載しない設定にしても、public repository内のファイルは隠れません。

CLIから公開する

人間ownerがaachatとGitHubの認証を使って行う操作です。researcherは自分のAgentのbase nameへ置き換えます。準備済みの公開repository で実行してください。ディレクトリ名から公開先<自分のGitHub-login>/<directory-name>が決まります。privateな作業用Agent repoで誤って実行しないでください。

bash
cd ~/public-agents/research-companion
git status --short
# Review and commit the prepared public files before continuing.
aachat publish researcher

commitが存在し、未commitの変更がないことが必要です。宛先が存在しないか空のprivate repositoryなら、最初の実行では privateのまま 作成・準備してpushします。この初回は--go-publicを付けても同じです。生成されたGitHub repositoryと内容を確認します。宛先が既存のprivate repositoryなら、flagなしではprivateを維持し、後からの編集もpushしません。追加の修正は公開前に準備先へcommit・pushしてください。

そのrepositoryを公開すると決めたときだけ、次を実行します。

bash
aachat publish researcher --go-public

既存のprivate宛先ではGitHubのvisibilityを変更し、Discoverへ登録します。既にpublicならflagなしでも登録します。登録で読むのは公開repositoryのdefault branchのcommitで、ローカル編集を自動pushする操作ではありません。表示されたrepository URLとcommitを確認し、DiscoverでAgentと掲載Skillを開きます。

visibility変更後に登録が失敗した場合は、まずGitHubを確認してください。repositoryは既にpublicかもしれません。metadataやownershipのエラーを直して登録し直します。登録エラーで公開が取り消されたとは判断しません。登録できるのは、自分のGitHubアカウントが所有するrepositoryを扱う人間ownerだけです。

更新・同期・掲載停止

Discoverの自分の公開物の管理ページで対象を選びます。公開repositoryで変更を準備・確認してcommit・pushした後、同期操作で公開commitをカタログへ読み込みます。同期後の内容と版を確認してください。privateな元Agentと公開コピーは別で、同期操作がprivateの変更を公開repoへコピーしたり、公開側の改善を元Agentへ取り込んだりすることはありません。

掲載停止(Stop listing) はAgentとその公開Skillをカタログから除き、公開の紐付けを解除します。GitHub repositoryの削除・private化・他人のclone済みコピーの削除は行いません。GitHub側のvisibilityも変えたい場合は別に操作します。掲載停止で露出したsecretを回収できるわけではないため、漏えいしたcredentialはprovider側で失効させます。

管理操作は公開物のownerに限られます。自分の公開物の管理と、サイト全体のカタログ管理を混同しないでください。

取得元へ改善を返す

cloneしたAgentから upstream proposal Draft を準備できます。人間ownerが全文、含まれる根拠、宛先repositoryを確認して送信すると、取得元repositoryに GitHub Issue を作ります。PRの作成や、どちらかのAgentへのコード適用は行いません。送信後はAgentのproposalカードやinboxで状態とIssue URLを確認します。

確認後にDraftが変わったら最新の内容を再確認します。GitHubの応答が不明でsubmittingのままなら、再送信前に取得元repositoryを確認してください。Issueが作られていないとは限りません。GitHubアカウントの認証と必要なscopeも有効である必要があります。

Discoverには、変更を準備して人間の明示操作後に GitHub Pull Request を作る別の改善会話もあります。この公開・改善カードは、cloneのupstream proposal Issueとは異なる経路です。承認前にカードの宛先と実行内容を確認してください。

関連ページ

  • Agents: 所有、repoの提出、runtime選択
  • Skills: 導入receipt、公開metadata、利用観測
  • Templates: 文書kind、Project開始、client entry
  • Environment: 宣言とローカルsecretの承認