Busabase × OpenCodeOpenCodeのナレッジベース
OpenCodeはorganization、user、project、managed configをmergeし、AGENTS.md/instruction filesを読み、primary agents/subagentsへ委譲し、local/remote MCP toolsを呼び出します。これらはexecutionを説明しますがsession summaryをcanonicalにはしません。
設定の優先順位
OpenCode Agentの権限を記録する前に、実際に有効な設定を確定する。
OpenCodeは組織のremote defaults、ユーザー設定、任意の設定パス、project config、`.opencode` directories、inline content、managed settingsを順に統合します。単一ファイルではなく、採用された入力とリポジトリ時点を残します。
.well-known organization defaults
User preference / runtime defaults
Repository-specific config/files
Admin-enforced highest policy
Rulesとinstructions
AGENTS.mdは行動を導くもので、事実台帳ではない。
ProjectとglobalのAGENTS.md、Claude互換のfallback、instructions arrayで参照するfilesやURLsを区別します。Team guidanceはリポジトリに置き、個人設定はglobalへ、変化する事実は管理元から都度取得します。
Package変更後にfocused testsを実行。
Customer approval完了、production green。
Agentの構成
Primary agent、subagent、内部支援Agentでは残る証拠が異なる。
BuildとPlanはprimary、General・Explore・Scoutはsubagent、compaction・title・summaryは内部支援です。誰が実行し、誰へ委譲し、どのtool permissionが適用されたかを記録します。
| Agent role | Typical authority | Evidence |
|---|---|---|
| Build | Write / execute | Diffs、commands、tests |
| Plan | Restricted-write analysis | Plan / repository context |
| General | Delegated multi-step work | Task boundary / artifacts |
| Explore / Scout | Read-only discovery | Inspected files/sources |
| Hidden system agents | Context support | Material summary provenance |
権限の解決
Allow、ask、denyはtoolを動かせるかを決めるが、記録の採否は決めない。
権限はglobal、pattern単位、Agent単位で設定できます。最後に一致した規則が有効になり、auto modeでも明示的なdenyは残ります。重要な操作ごとに適用規則を保存します。
Matched allow / ask / deny
Required prompt accepted
Action/response captured
Diff/test/external readback
Owner accepts shared state
SkillsとMCP
Skillは手順、MCPは外部toolを提供する。現在の業務状態を所有するものではない。
Skillsはproject、global、互換Agentの各directoryから必要時に読み込まれます。MCPにはlocal/remote、OAuth、global/Agent別の制御があります。Skillの版とMCP serverの識別情報を分けて固定します。
Procedure、templates、scripts、checklists
Tools、resources、authorization、response
Accepted outcome、owner、lifecycle
Sessionsとsharing
Shared conversationはcollaboration contextでありdurable system of recordではない。
Session linkはprovenanceとして残し、source refs、repository revision、verification、accountable decisionを持つ1 outcomeだけをpromoteします。
実行証拠
会話全体を複製せず、実際の実行条件を再構成できるようにする。
設定の各層、instructions、Agentの構成、権限、Skills、MCP calls、リポジトリ状態、検証結果を小さな証拠束にまとめます。
config_digest採用された設定と優先順位instruction_refsAGENTS.mdと追加instructionsagent_trace実行Agentと委譲先permission_trace重要なtoolsに適用された規則tool_evidenceBuilt-in toolとMCPの応答repository_refCommit、worktree、diffverificationTestsと外部確認
確認済みの結果
Config filesやsession transcriptではなく、判断できる大きさの結果だけを共有する。
Sessionが要約、共有、削除された後でも、この記録だけで内容と根拠を理解できるようにします。
outcome_key結果を追跡する安定した識別子session_refSessionとAgentの実行経路config_ref採用設定の要約source_refsCode、docs、外部recordsproposed_state共有を提案する短い結論owner採否に責任を持つ担当者decision採用、条件付き、却下、後継ありnext_review_at次回確認日実務上の質問
OpenCodeで知識を扱う時のFAQ
BusabaseはAGENTS.mdを置き換えますか？
いいえ。AGENTS.mdはOpenCodeの行動を導き、Busabaseは選別して審査した結果を保存します。
証拠はどのconfigを参照しますか？
Project fileだけでなく、実際に採用された設定と関連するsource layerを参照します。
Auto modeはdenyを回避しますか？
Current docsでは明示的なdenyはそのまま維持されます。
Subagentは自分の結果を承認できますか？
実行権限と記録の採否は別です。
Shared session linkはcanonical evidenceですか？
来歴として使い、リポジトリと外部確認も一緒に保持します。
1つのresolved runtimeから始める
OpenCodeのaction経路を保存し、必要なstateだけreviewする。
Completed sessionを選び、config/permissionsを解決し、verificationを付けて1 outcomeを提出します。