導入先を決める
/path/to/projectをabsolute pathに置き換え、directoryを用意する。既存projectでも同じcommandでよい。
mkdir -p /path/to/projectagentic-framework v0.2.5 基本構成
複数の AI エージェントが並行して働いても、追跡と再現が壊れないための枠組み。 Codex / Claude Code / hermes のいずれでも同じ規約で動く。この 5 つの図が骨格にあたる。
導入先projectを決め、installerを取得して実行する。ZIPはinstallerが検証・展開・後片付けするため、実ファイルを手で設置する必要はない。
/path/to/projectをabsolute pathに置き換え、directoryを用意する。既存projectでも同じcommandでよい。
mkdir -p /path/to/projectcurl -fsSLo /tmp/agentic-framework-install.sh https://ai.microdotz.net/install.sh
bash /tmp/agentic-framework-install.sh /path/to/projectAGENTS.mdをproject用に編集し、AI profileを選択して、tool checkを実行する。
installerは終了code 2で停止し、通常pathは変更しません。候補と差分の案内は.agentic-framework/incoming/に保存される。
CONFLICTS.mdを読み、既存fileと候補をreviewする。--accept-existingを追加する。Codexでは公式pluginを優先し、利用できない環境ではMCP fallbackを使う。
codex plugin marketplace add upstash/context7
codex plugin add context7@context7-marketplace
# MCP fallback
codex mcp add context7 -- npx -y @upstash/context7-mcpresolve-library-id、次にquery-docsを使う。MIT License（Copyright © 2026 株式会社 点）。 ZIPを手動で確認・取得する ／ GitHub ReleaseとSHA-256を確認する
図 1 ／ 構造
docs/framework/
エージェント運用の規約。プロジェクトが変わっても共通。
docs/knowledge/
「今どうなっているか」。product・engineering に加え、事業・サポート・対外資料まで含む。
docs/planning/
調査と要件定義。確定したら knowledge へ反映して、ここには残さない。
docs/decisions/
なぜ決めたか（情報ソース必須）と、誰が何をしたか。追記型で書き換えない。
性質の違う知識を混ぜないことが要点。stock を書き換えれば経緯が消え、log を書き換えれば履歴が壊れる。 置き場が 1 つに決まっていれば、同じ知識が 2 か所で食い違うことがない。
図 2 ／ 分担
判定は 1 つ。アプリのソースコード（と、その改修の要件定義・開発タスク）に関わるか。 Yes なら GitHub、No なら Linear。この境界があるので、企画と開発が同じ場所で混ざらない。
図 3 ／ 実行
GitHub Issue を継続的にポーリングし、拾った issue ごとにエージェントを起動する。
スタール時は再起動し、実行方針は WORKFLOW.md としてリポジトリで版管理する。
分割した Issue を複数エージェントで同時に進める。 1 台で N スタックを立てられない場合は、クラウドの隔離箱へ昇格する。
隔離: worktree → crabbox全エージェント共通の補助。大量出力・ログ・広域検索・集計・parse を担い、生データを会話へ流さない。 テスト出力やログの解析、着手前の広域調査で使う。
方式は違っても、追跡先と承認境界は同じ。どちらも GitHub Issue を作業単位とし、 人間承認が必要な領域では自動 merge させない。同一 Issue を複数エージェントで並行させないルールも共通。
図 4 ／ 順序
番号は実際の順序を表す。朱で示した段は自動化しない領域 —— 破壊的マイグレーション、認証・secret・権限、課金、本番デプロイ、インフラ、プライバシー・法務、不可逆なデータ削除。 ここだけは人間が承認する。
図 5 ／ 実行環境
左の背骨が agentic-framework。cloud から自宅サーバ、手元の端末まで、ここに並ぶすべての要素が
同じ規約（docs/ と AGENTS.md）を読んで動く。だから実行場所やエージェントが変わっても、
追跡先と承認境界は揺れない。図 1〜4 は、この背骨の中身にあたる。
Tailscale が繋ぐのは自宅サーバと手元の端末だけ。cloud の SaaS には通常のインターネット経由で接続する。
Symphony は Linear の issue を拾って自律実行するが、スケジューラであってチケットの書き手ではない。
成功した実行は Done ではなく Human Review のような handoff で止められるため、
図 4 の人間承認境界はこの層でも保たれる。