bstack

注意

この SKILL.md しか bstack のファイルがありませんか？ それなら、インストールが不完全で壊れています。 npx skills add broomva/bstack を実行すると、skills.sh はこのファイルだけをコピーし、bin/、scripts/、schemas/、テンプレートを取りこぼします。これは vercel-labs/skills#1523 のリポジトリルートに SKILL.md がある場合の問題です。bstack CLI も、bstack bootstrap も、bstack doctor もありません。 bstack は CLI とガバナンス基盤であり、スキルではありません。

修正 — 正規のものをインストールしてください：

git clone https://github.com/broomva/bstack.git && cd bstack && ./bin/bstack bootstrap

CLI は不要で、エージェント向けのプリミティブ入門だけが必要ですか？ npx skills add broomva/skills --skill bstack を実行してください。

bstack — The Broomva Stack

不可欠なプリミティブが20個。厳選されたスキルが30個。標準的な運用モードが1つ。自律稼働するワークスペースが1つ。

bstack はポータブルなハーネスのメタレイヤーです。既存のスキルを、エージェントが推論によって、doctor がチェックによって、bootstrap がスキャフォールディングによって、そして標準的な運用モード（broomva/autonomous）が実行によって適用する、拘束力のあるプリミティブ契約へと組み合わせます。

基盤とモード

bstack は、相互に補完する2つのレイヤーを提供します：

• 基盤（このスキル、/bstack）：20個のプリミティブ + 30個のスキル + ガバナンス + フック + .control/policy.yaml。/bstack bootstrap がインストールするものです。基盤は機能、つまりワークスペースで利用できるものです。
• モード（broomva/autonomous）：基盤上で動作する標準的な振る舞いです。ユーザーが「go」／「proceed」／「be autonomous」と言うと、/autonomous が、すべてのプリミティブを順番に使う20個の反射パイプラインを実行します。

基盤をインストールしてモードを入れない場合、ワークスペースにはプリミティブがあっても、それらを利用するための入口がありません。モードを呼び出して基盤がない場合は、実現を願うだけです。両方を組み合わせる場合は、/bstack bootstrap で基盤をインストールし、実質的な作業単位では /autonomous を常時の運用モードとして使います。

bootstrap 自体は2つのフローで構成されます。決定論的で構造化されたスキャフォールド（土台）と、エージェントが作成する生成的な調整工程（個別対応のレイヤー）です。2つのフローによるワークスペースのセットアップを参照してください。

クイックスタート

インストールします（bstack は CLI／基盤です。npx skills add ではなく、クローンして bootstrap してください。npx skills add では vercel-labs/skills#1523 の問題により bin/／scripts/ が取りこぼされます）：

git clone https://github.com/broomva/bstack.git && cd bstack && ./bin/bstack bootstrap

次に、エージェントのセッションで：

/bstack bootstrap     → install 30 skills + scaffold governance + wire hooks + run doctor
/bstack doctor        → verify primitive contract compliance (always exits 0)
/bstack repair        → fix specific gaps surfaced by doctor (asks before writing)
/bstack status        → show which skills are installed vs missing
/bstack validate      → check skill SKILL.md frontmatter health
/bstack revamp        → full reconfiguration (force-reinstall + rewire + re-doctor)
/bstack wave dispatch <plan...>   → atomic parallel-agent dispatch from N plan files
/bstack wave status <wave-id>     → forensic per-wave state table
/bstack wave list                 → all waves with summary state
/bstack fleet up <roster>         → launch N coordinating peers into ONE worktree
/bstack fleet status [--fleet id] → per-peer liveness (pid-keyed) + suggestions
/bstack fleet list                → all fleets with counts by liveness class
/bstack fleet down --fleet <id>   → stop + remove a fleet's peers, reclaim state
/bstack bench run                 → two-phase skill-evolution benchmark (P11)
/bstack bench compare             → Phase 1 vs Phase 2 REPORT.md
/bstack bench tasks list          → registered task sets
/bstack bench run --runner live --provider databricks --model ...
                                  → real LLM via OpenAI-compatible provider (≥ 0.11.0)
/bstack workspace register        → add this workspace to ~/.broomva/global/registry.yaml (≥ 0.18.0)
/bstack workspace list            → list all registered workspaces (Federation, Phase 8)
/bstack workspace info            → is the current workspace registered?
/bstack workspace deregister      → remove a workspace by --name or --path
/bstack status --aggregate        → federation rollup: name × bstack_version × composite_ω × verdict
/bstack cross-review <pr> --repo <owner/name>
                                  → P20 cross-model adversarial review via remote
                                    git fetch (≥ 0.20.0, BRO-1227 Fix B)

bstack が適用するもの

20個のプリミティブ。それぞれが、監督のないセッションでエントロピーを招く特定の失敗モードを1つずつ防ぎます：

#	プリミティブ	解消する問題
P1	会話ブリッジ	セッションの記憶喪失
P2	コントロールゲート	モデルが許可していない破壊的な操作
P3	線形チケット	作業の不可視化
P4	PR パイプライン	未レビューコードのマージ
P5	並列エージェント	順次処理によるボトルネック。同じファイルで衝突する、対処不能なセッション
P6	ナレッジの記録管理	ナレッジグラフの劣化
P7	スキルの鮮度チェック	npx skills add のスナップショットが気付かれないまま劣化すること
P8	ブランチ＋ワークツリーの整理	squash-merge の蓄積
P9	CI ウォッチャー＋生産的な待機（broomva/p9 スキル — 名前は番号に一致します）	待機中に何もせず過ごす時間（CI、デプロイ、ビルド — PR CI が参照実装です）
P10	ワークツリーの衛生管理規律	PR ライフサイクル全体にわたるダーティーツリーのずれ
P11	経験的フィードバックループ	コンパイルは通るものの、動作しないコードを出荷すること
P12	継続的なループの規律（broomva/persist スキル）	コンテキストウィンドウの劣化により、長期的な作業の質が低下すること
P13	夢サイクルの規律	リプレイなしで階層をまたぐ統合を行い、上位階層のルールを破損すること（シャドウドリームの失敗モード）
P14	依存関係チェーンの推論規律	「依存関係の連鎖を深く考える」が、上流・下流の具体的な列挙を伴わない決まり文句になること
P15	アクション前の状態スナップショット	古い状態や単一セッションの状態（未コミットの作業、進行中の PR、古いデプロイ、別セッションのワークツリー）に基づいて計画を立てること
P16	結晶化の規律（Bstack Engine）	繰り返し役立つパターンがユーザーの頭の中だけにあり、スキル／プリミティブ／ポリシーのインフラとして昇格されないこと
P17	レンズに基づくリクエストの明確化（broomva/role-x スキル、予定）	フラットなディスパッチによるファンアウトでドメインコンテキストの読み込みに失敗すること。適切な quality_bar を形作る型付きレンズ（法務レビュー、デザイン、調査など）がないまま、エージェントがタスクを実行すること
P18	対象者に合わせたフォーマット選択の規律	対象者に関係なく何でもデフォルトで Markdown にすること、誰も読まない長大な仕様書、SVG を HTML に埋め込むのが適切な場面で ASCII の疑似図と Unicode による色の近似を使うこと
P19	オーケストレーション手段の選択規律	暗黙的な反射間の引き継ぎ（「続けてください」）、作業内容に合わない手段の使用（1 時間を超える作業に /goal、30 分のタスクに persist、イベント待ちに /loop）、手段の欠落によって自律的な作業の流れが途切れること
P20	モデル横断型の敵対的レビューゲート（broomva/cross-review スキル）	同一モデルによるエコーチェンバー、作成者が自分の成果物を自己検証すること、異なる評価者が 7/10 以上の評価を付けていないために、AI の粗悪な成果物（過剰に複雑な抽象化、テンプレートの貼り付け、不要なラッパー）がマージされること

リファレンス全文は references/primitives.md を参照してください。

プリミティブの運用化に関するリファレンス（プリミティブを適用するエージェントが必要に応じて読み込みます）：

• 経験的（P11）— dogfood パターンの料理本：references/dogfood-patterns.md。技術スタックごとの操作サーフェスのマトリクス（Tauri+sidecar / Next.js / Expo RN / Rust CLI / REST API / MCP サーバー）です。スキルツールキット（ビジュアルデプロイ検証には Interceptor が必須。gstack / cliclick / screencapture / curl+jq をスタックごとに組み合わせる）、スタックごとの標準的な作業の流れ、注意点、Dogfood Plan の契約、レシートのテンプレートを説明しています。bstack doctor §13 はスタックに対応するプランの存在を検証します（rule-of-three に達するまでは情報提供のみ）。

v1.0.0 へのロードマップ — アーキテクチャ上の契約、ギャップの一覧、v0.3.1 以降の 9 フェーズの完了計画は、specs/2026-05-18-substrate-completion.md（正本）と references/substrate-completion-overview.md（エージェントが読みやすい概要）にあります。今後の bstack リリースはすべて、v1.0.0 まで「完了とはどのような状態か」を示す仕様として、この仕様書を参照します。

エージェントの文章における命名規則（すべてのエージェントに適用）

各プリミティブには、エージェント向けの文章で使う短い名前が付いています。応答、PR の本文、コミットメッセージ、コードコメント、ナレッジグラフのエントリーなど、人が読むあらゆる場面でプリミティブに言及する際は、Name (Pn) の形式を使ってください。たとえば、「Snapshot (P15) を適用する」、「Dep-Chain (P14) を介して」、*「Bookkeeping (P6) を実行する」*のように記し、P15／P14／P6 だけの表記は使わないでください。番号は正式な識別子（名前が変わっても不変）であり、名前は人が読むための呼び名です。応答内で最初に言及するときは完全な形式を使います。同じ応答内で2回目以降に言及する場合は、単独の Name（「Snapshot によりクリーンな状態が確認されました」）にしてもかまいませんが、Pn だけの表記は使わないでください。アンカー、セクション ID（#p15-state-snapshot-before-action）、プリミティブ数を示す見出し（「20 個の還元不能なプリミティブ」）は、URL の安定性と算術上の理由から、数値表記のままにします。避けるべき失敗例：Pn だけでは応答が数字だらけになり、セッションをまたいで読む人が参照先を調べないと理解できません。以下の短縮名インデックスが、参照の手がかりになります。

短縮名インデックス（正式な番号）：Bridge (P1) · Gate (P2) · Tickets (P3) · Pipeline (P4) · Fanout (P5) · Bookkeeping (P6) · Freshness (P7) · Janitor (P8) · Wait (P9) · Hygiene (P10) · Empirical (P11) · Persist (P12) · Dream (P13) · Dep-Chain (P14) · Snapshot (P15) · Crystallize (P16) · Lens (P17) · Audience (P18) · Orchestrate (P19) · Cross-Review (P20)。

正式な記述は、ワークスペースの CLAUDE.md §Bstack Core Automation Primitives と、ワークスペースの AGENTS.md の93行目付近にあります。この SKILL.md では、/bstack の読み込み時に目にするエントリーポイントでもルールを確認できるよう、ここに再掲しています。

スキル名とプリミティブ番号の対応：スキルに数値の名前（たとえば、P9 の Wait を表す p9）が付いている場合、プリミティブの番号付けは、その名前を不変に保つことを前提としています。名前を変更すると、npx skills add broomva/skills --skill p9 を使ったインストールがすべて機能しなくなるためです。機能名が付いたスキル（P6 の bookkeeping、P12 の persist）は、番号ではなく機能に由来する名前を使います。（すべて broomva/skills モノレポにベンダーとして含まれており、--skill <name> の名前が安定した識別子です。）

bstack wave（このバージョンで新登場）。 Orchestrate (P19) のメカニズムキューブにおける「N>1 × 複数セッション間 × 外部トリガー」のセルを補います。共有の可変ファイルへの書き込みなしに並列実行できる、独立したプランファイルが N 個ある場合に使用します（Fanout (P5)）。各プランのフロントマターには worktree と branch を指定します。ラッパーが一括で検証し、worktree を作成して、プランごとに claude --bg を起動します。状態は ~/.cache/bstack/wave/<wave-id>/ に保存されます（Persist (P12) のファイルシステムを状態として使う方式）。プリミティブの統合マップの全容は、設計ドキュメント docs/superpowers/specs/2026-05-13-bstack-wave-design.md（ワークスペースのリポジトリ）を参照してください。0.39.1 以降、各プランのピアは scripts/peer.py を通じて起動されます。名前は <worktree>-<ticket>-<slug>（Fanout P5）で、無人で動作するよう --strict-mcp-config と crossSessionInbound: accept を指定し、wave status の LIVE 列に実際の claude agents --json --all スキーマに基づいてライブセッションと紐付けられます。プランでプロジェクトの MCP サーバーが必要な場合は、wave: の下に mcp: inherit を設定します（または BSTACK_PEER_MCP=inherit を設定します）。不明な wave: キーは、キー名を示して拒否されます。 bstack fleet（≥ 0.40.0）。 同じセルのもう一方です。名簿に基づき、1 つのワークツリーで N 個のピアが連携します。**ルーティングルール — ワークツリーの軸で判断し、どのセルを選んだかを伝えてください。**各ピアに専用のブランチとワークツリーが必要 → bstack wave dispatch <plan...>。ピアが 1 つのワークツリーで連携 → bstack fleet up <roster>。セッション内の独立したサブタスク → 1 つのメッセージ内で Fanout（P5）の Agent 呼び出し。名簿のエントリーでは、slug、省略可能な ticket／prompt／role／model／mcp、および owns（そのピアが所有するパスの glob — ブリーフに引用される担当範囲）を宣言します。この仕組みでハードコードされていたオントロジーは、宣言された設定として定義され、CLI フラグ > BSTACK_FLEET_<KEY> > ~/.bstack/config.yaml の fleet_<key> > デフォルトの順に解決されます。対象は base、peer_contract、allowed_tools、state_dir、ticket_pattern、mcp です。状態とピアごとのブリーフは ~/.cache/bstack/fleet/<fleet-id>/ に保存されます。down は、未回収のピアが 1 つでもいる間、フリートのディレクトリを削除しません。また、エージェント一覧を読み取れない場合、status はクリーンではなく unknown を表示します。どちらのコマンドも scripts/peer.py を共有し、Fanout（P5）の名前の文法（<worktree>-<ticket>-<slug>）、非対話型起動用の 2 つのフラグ（--strict-mcp-config、--settings '{"crossSessionInbound":"accept"}'）、PID をキーとする稼働状態判定を使用します。

標準の運用モード：broomva/autonomous — ユーザーが「go」／「proceed」／「be autonomous」／「automerge」／その他の実行指示だけを伝えた場合、/autonomous が起動し、上記すべてのプリミティブを適切な順序で実行する 20 の反射パイプラインを動かします。基盤があってもモードがなければ休止状態です。モードがあっても基盤がなければ願望にすぎません。両者を組み合わせると、自律的に動作するワークスペースになります。

前文（毎セッション、最初に実行）

スキルのインストール状態を検出し、期限を過ぎたスキルを更新して、初回セットアップが必要か確認します。

# ─── Update check ────────────────────────────────────────────
_BSTACK_ROOT=""
[ -d "$HOME/.claude/skills/bstack" ] && _BSTACK_ROOT="$HOME/.claude/skills/bstack"
[ -z "$_BSTACK_ROOT" ] && [ -d "$HOME/.agents/skills/bstack" ] && _BSTACK_ROOT="$HOME/.agents/skills/bstack"
_UPD=""
if [ -n "$_BSTACK_ROOT" ] && [ -x "$_BSTACK_ROOT/bin/bstack-update-check" ]; then
  _UPD=$("$_BSTACK_ROOT/bin/bstack-update-check" 2>/dev/null || true)
fi
[ -n "$_UPD" ] && echo "$_UPD" || true
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"

# ─── First-time setup check ──────────────────────────────────
# If the init marker is missing, bstack hasn't been onboarded on this
# machine. Recommend the wizard. In Claude Code, the agent should follow
# the `## Onboarding` section below to ask the user the 4 wizard
# questions interactively via the AskUserQuestion tool.
_BSTACK_MARKER="${BROOMVA_STATE_DIR:-$HOME/.config/broomva/bstack}/initialized"
if [ ! -f "$_BSTACK_MARKER" ]; then
  echo "ONBOARDING: bstack not yet initialized on this machine."
  echo "  → In Claude Code: agent will guide you (see ## Onboarding section)."
  echo "  → In a shell: run \`bash $_BSTACK_ROOT/scripts/onboard.sh\`"
fi

出力に UPGRADE_AVAILABLE <old> <new> と表示された場合：bstack-upgrade/SKILL.md を読み、記載されたアップグレード手順に従います。JUST_UPGRADED <from> <to> と表示された場合：ユーザーに「Running bstack v{to}」と伝えて続行します。

前文に ONBOARDING: bstack not yet initialized と出力された場合、他の bstack コマンドを実行する前に、以下の ## Onboarding セクションに移動します。新規ユーザーには 4 つの質問からなるガイド付きウィザードが表示されます。マーカーが存在すれば、リピーターは自動的にこの手順を省略します。

# ─── Skill roster check ──────────────────────────────────────
AGENTS_DIR="${HOME}/.agents/skills"
CLAUDE_DIR="${HOME}/.claude/skills"
ROSTER=(autonomous cross-review agentic-control-kernel control-metalayer-loop harness-engineering-playbook p9 agent-consciousness knowledge-graph-memory prompt-library symphony symphony-forge autoany deep-dive-research-orchestrator skills skills-showcase arcan-glass next-forge alkosto-wait-optimizer content-creation finance-substrate seo-llmeo brand-icons pre-mortem braindump morning-briefing drift-check strategy-critique stakeholder-update decision-log weekly-review role-x)
INSTALLED=0; MISSING=()
for s in "${ROSTER[@]}"; do
  if [ -d "$AGENTS_DIR/$s" ] || [ -d "$CLAUDE_DIR/$s" ]; then
    INSTALLED=$((INSTALLED + 1))
  else
    MISSING+=("$s")
  fi
done
echo "bstack: $INSTALLED/${#ROSTER[@]} skills installed (30 total)"
[ ${#MISSING[@]} -gt 0 ] && echo "Missing: ${MISSING[*]}"

件数を報告します。30 個すべてが揃っている場合は、「bstack fully installed.」と伝えます。不足がある場合は一覧を示し、bootstrap コマンドを提案します。

スキルの確認後、ハーネスの検証を実行します。

cd ~/broomva && make bstack-check 2>&1

結果を報告します。チェックに失敗したものがあれば、続行する前に修正します。

Onboarding（初回セットアップウィザード）

前文に ONBOARDING: bstack not yet initialized と出力された場合、ガイド付きウィザードを実行します。方法は 2 つあります。基盤となるスクリプト（scripts/onboard.sh）は同じで、実行役が異なります。

パス A：Claude Code で実行（AskUserQuestion を使ったエージェント主導）

Claude Code のセッション中、エージェントは AskUserQuestion の呼び出しを通じてウィザードの4つの入力項目を収集し（ユーザーはチャットで回答します）、収集したフラグを指定して scripts/onboard.sh を実行します。ユーザーのターミナルで read -r によるプロンプトは表示されません。エージェントが入力手段となります。

4つの質問（ユーザーに表示されるデフォルト値）：

1. ワークスペースのパス — $HOME/broomva（デフォルト）。bstack がガバナンスファイルを生成する場所です。
2. プロファイル — personal / enterprise / autonomous-strict。ゲートの厳格さを決定します。
   • personal — 緩やか。個人開発／実験向け
   • enterprise — 厳格で、監査に対応
   • autonomous-strict — ゲートを信頼する原則。L3 の自動マージが有効です（CI に G-L3-* ゲートが必要です）
3. Life Agent OS との統合 — install / skip。life-os と arcan のバイナリもインストールするかどうかです。
4. ガバナンスパスの自動マージポリシー — human-required / trust-gates：
   • human-required — G-L3-1/G-L3-2 が CI に組み込まれるまでの安全なデフォルト
   • trust-gates — L3 の信頼ゲートを通過すると、L3 パスが自動マージされます

4つの回答を収集した後、エージェントは次を実行します。

bash "$_BSTACK_ROOT/scripts/onboard.sh" \
  --workspace="$A1" \
  --profile="$A2" \
  --life="$A3" \
  --auto-merge="$A4" \
  --skip-prompts

スクリプトは bin/bstack-config を介して選択内容を ~/.bstack/config.yaml に保存し、選択したワークスペースに対して scripts/bootstrap.sh を実行して、初期化マーカーを ~/.config/broomva/bstack/initialized に書き込みます。その後、エージェントはオンボーディングの記録（ワークスペース＋プロファイル＋life＋自動マージ＋ブートストラップの状態）をユーザーに報告し、次のステップとして /autonomous を推奨します。

AskUserQuestion が利用できない場合（Claude Code 以外で実行している場合）：パス B に進みます。

パス B：シェルで実行（対話型の read -r プロンプト）

bash $_BSTACK_ROOT/scripts/onboard.sh

スクリプトは read -r を使って同じ4つの質問をします。その後の動作は同じです。設定を保存し、ブートストラップを実行して、マーカーを書き込みます。

冪等性と再実行

• ~/.config/broomva/bstack/initialized が存在すると、以降の onboard.sh の呼び出しは、プロンプトもブートストラップも実行せず、直ちに 0 で終了します。
• ウィザードをやり直すには、--force を指定して再実行します。
• 選択内容を保存せずに確認するには、--dry-run を実行します。

記録のスキーマ（マーカーファイル）

初期化マーカーは、~/.config/broomva/bstack/initialized にある YAML 形式のフラットファイルです。

# bstack initialization marker
onboarded_at: 2026-05-12T22:49:44Z
workspace: /Users/foo/broomva
profile: personal
life: skip
auto_merge: human-required
bstack_repo: /Users/foo/.agents/skills/bstack
bootstrap_status: ok           # ok | failed | skipped

以降のセッションでは、このファイルを参照して状態を確認します。bootstrap_status: failed も隠さず記録されます。ユーザーはウィザードの回答を失うことなく、ブートストラップに追加対応が必要だと把握できます。

コマンド

bootstrap — 完全なインストールとシステムへの組み込み

scripts/bootstrap.sh は、インストールと組み込みを行うパスです。次の処理を実行します。

1. bin/bstack-skills install に委譲して、関連スキルの一覧をインストールします（references/companion-skills.yaml を読み込み、それぞれを npx skills add broomva/skills --skill <name> としてインストールします）。autonomous は標準の運用モードです
2. assets/templates/ から、不足しているガバナンスファイルをスキャフォールドします。
   • CLAUDE.md（ワークスペースの不変条件、RCS 階層、プリミティブ表 P1–P20、§Ritual vs Substance）
   • AGENTS.md（運用ルール、プリミティブごとのセクション、推論で適用されるすべてのプリミティブの再帰的なトリガー）
   • .control/policy.yaml（ci_watch／ci_heal／auto_merge／ゲート G1–G11）
   • .claude/settings.json（P1、P2、P7 のフック配線）
3. 既存の Makefile に make ターゲットを追加するか、新規作成します。追加するターゲットは bstack-check、control-audit、janitor、bstack-primitive-lint（G-L3-1）、bstack-rule-of-three（G-L3-2）、bstack-l3-trust（L3 ゲートの統合版）です
4. git config core.hooksPath .githooks を使って、pre-commit フック（.githooks/pre-commit）をインストールします
5. bstack doctor を実行してプリミティブ契約への準拠を確認し、make bstack-l3-trust を実行して L3 ゲートの合格を確認します
6. ブートストラップの記録を報告します。インストールしたもの、スキャフォールドしたもの、すでに存在していたものを示します
7. 次の実質的な作業単位で /autonomous を呼び出すことを推奨します。基盤のインストールは完了しており、標準モードをすぐに開始できます

冪等性：ユーザーの既存のカスタマイズを上書きすることはありません。ファイルがすでに存在する場合は、不足しているプリミティブのセクション／ブロック／フックのみを追加し、ファイル全体を置き換えることはありません。

自己適用：既存のワークスペースで /bstack bootstrap を呼び出す場合、ブートストラップ自体も /autonomous の規律に従って実行されます。状態のスナップショット、依存チェーンの追跡、検証計画、PR パイプラインを行います。規律をインストールするブートストラップ自身が、提供する契約を体現します。

二段階フロー：ブートストラップは、決定論的な処理を一度行うだけではありません。上記の構造化されたスキャフォールドは最低限の基盤です。その後、エージェントがその上に生成的な調整処理を行います。モデルと標準的な手順の全容については、以下の二段階のワークスペース設定を参照してください。

2フローのワークスペースセットアップ（構造化＋生成）

bstack bootstrap は単一の決定論的な処理ではなく、2フローの操作です。これは、bstack がドキュメントにすでに適用している Audience（P18）の分割、すなわち決定論的な Category-B の投影フロアと、コンテキストを認識する Category-C の個別作成レイヤーを、ワークスペースのセットアップ自体にも適用するものです。

bstack bootstrap  =  STRUCTURED flow      →   GENERATIVE flow            →   VERIFY
                     (deterministic, no LLM)    (agent-authored, contextual)   (deterministic)
                     scripts + templates        tailoring of THIS workspace    bstack doctor
                     + shipped+deployed hooks
                     + gates + .control

1. 構造化フロー（フロア — 再現可能、LLM 不要）。 bstack bootstrap は冪等なスキャフォールドを実行します。スキルをインストールし、assets/templates/* からガバナンスファイル（CLAUDE.md、AGENTS.md、METALAYER.md、.control/policy.yaml、.control/arcs.yaml、.control/rcs-parameters.toml、schemas/）をスキャフォールドします。フックスクリプトをワークスペースにデプロイします（control-gate／skill-freshness／conversation-bridge — 0.37.2 以降、P6 のカタログ更新も担います — に加え、L0/L1 監査フック）。.claude/settings.json を接続し、L3 レートゲートと CI ゲートをインストールします。このフローは完全かつ正確でなければなりません。接続された各フックには、デプロイ済みのスクリプトが必ず存在します（未解決の参照は禁止）。これは損失のないベースラインです。同じ入力からは、常に同じワークスペースが生成されます。

2. 生成フロー（個別作成レイヤー — エージェントが作成し、最大限まで仕上げる）。 構造化スキャフォールドの後、エージェントがテンプレートでは作成できない、コンテキストを認識した処理を行います。具体的には、エージェントは次のことを行います。

a. 技術スタックとプロジェクトの意図を検出 — 手掛かりは、言語やビルドファイル、既存のコード、README、ユーザーが示した目標です。 b. スキャフォールドされたガバナンスの文章を、このプロジェクトに合わせて調整 — 一般的な CLAUDE.md／AGENTS.md のプレースホルダーを書き換え、汎用テンプレートの文章ではなく、プロジェクト固有の不変条件、規約、アーキテクチャに関する注記を作成します。 c. プロジェクト固有の CI ワークフローを作成 — 構造化フローでは L3 安定性ゲートを提供し、エージェントは検出した技術スタックに合ったテスト／lint／ビルドのジョブを生成します。 d. Dogfood Plan（実証的、P11）に、このプロジェクトの技術スタックにおける実際のエントリサーフェスと証拠のアンカーを記入します（references/dogfood-patterns.md を参照）。 e. RCS/RSI または制御システムのリポジトリの場合 — 必要に応じて、実行可能な L0–L3 基盤と HIERARCHY／インスタンス化マップを配置し、ワークスペースが制御システムを単に記述するのではなく、実際に実行するようにします。一般的なリポジトリでは、この手順をスキップします。 f. 新しいワークスペースの初期ナレッジグラフエンティティ／意思決定ログ（事務管理、P6）を登録します。許可を求めず、自発的に行います。

3. 検証（決定論的）。 bstack doctor は両方のフローを検査します。構造化契約（ガバナンスファイル、接続・デプロイ済みのフック、ゲート、スキーマ）と、生成された出力（エージェントによる調整で不足が残った場合、doctor がその不足を示します）の両方です。生成された出力は常に構造化契約で検証されるため、盲目的に信頼することはありません。

主な原則：

• これは、確立された Audience（P18）の規律を踏襲しています。STRUCTURED フローは Category-B の投影フロア（決定論的、損失なし、再現可能）で、GENERATIVE フローは Category-C の個別作成（コンテキストを認識し、最大限まで仕上げる）です。ドキュメントにすでに適用されている、構造化と生成の同じ分割を、ワークスペースのセットアップにも適用します。
• 構造化フローでは、スクリプトがデプロイされていないフックを接続してはなりません。これは、この作業で修正する未解決フックの障害モードです。「接続済みだが未解決」は禁止です。すべてのフック参照が、実在する実行可能なデプロイ済みスクリプトに解決される必要があります。
• エージェントはまず構造化（冪等なフロア）、次に生成（個別作成）、最後に doctor（検証）の順で実行します。構造化なしの生成（フロアなし）も、生成なしの構造化（汎用的で調整されていないワークスペース）も禁止です。

doctor — プリミティブの契約を検証する

scripts/doctor.sh。8つのチェックセクションがあります。

1. ガバナンスファイルが存在する（CLAUDE.md、AGENTS.md、.control/policy.yaml）
2. CLAUDE.md のプリミティブ表に P1～P20 のすべての行があり、ヘッダーの件数が正しい（「Twenty irreducible…」）
3. AGENTS.md に各プリミティブのセクションがある（### P1: または ### P1 — Short: Long の形式で ### P20 まで）
4. P6、P9、P10、P11、P12、P13、P14、P15、P16、P17、P18、P19、P20（推論によって適用されるプリミティブ）に Reflexive Trigger Rules がある
5. .control/policy.yaml に必須ブロックがある（ci_watch:、ci_heal:、auto_merge:）
6. .claude/settings.json に想定されるフックスクリプトが設定されている（P1、P2、P7）
7. 各プリミティブのメカニズムがディスク上で利用可能
8. L3 信頼ゲートに合格する — ターゲットが存在する場合は make bstack-l3-trust を実行し、G-L3-1 と G-L3-2 の結果を報告し、構造上の違反や rule-of-three 違反があればギャップとして示します

モード：デフォルト（完全なレポート）、--quiet（ギャップのみ）、--strict（ギャップがあれば終了コード 1。CI レーン向け）。デフォルトでは常に終了コード 0 を返します。 各ギャップには、実行可能な → fix: のヒントが含まれます。

bootstrap は最後のステップとして doctor --quiet を自動的に呼び出します。L3 信頼ゲート（チェック 8）は、新しいモードの合理化防止レイヤーと同等の基盤レベルの機能です。どちらも、機械で検証可能な証拠を伴わずにガバナンスが進化してしまう失敗モードを防ぎます。

repair — 対象を絞った修正を適用する

scripts/repair.sh。doctor のギャップ一覧を読み取り、各修正の前にユーザーに確認してから、個別の修正を適用します（テンプレートから不足しているプリミティブセクションを追加、不足しているポリシーブロックを追加、不足しているフックを設定）。冪等です。破壊的な変更は行いません。

status — インストール済み／不足の確認とハーネスの健全性

プリアンブルを再実行します。各スキルについて、名前、レイヤー、インストール済み／不足を表示します。その後、make bstack-check を実行してハーネスの健全性を報告します。

validate — スキルのフロントマターの健全性

scripts/validate.sh。各スキルに適切なフロントマターを含む有効な SKILL.md があることを検証します。その後、bstack-check ハーネスの完全な検証を実行します。

revamp — エージェントの完全な再設定

scripts/revamp.sh。ワークスペースの完全な再設定を開始します。

1. 30個すべてのスキルを再インストールする（強制モード）
2. テンプレートからガバナンスファイルを再生成する（上書き前に確認）
3. フックを再設定する（git pre-commit と Claude Code Stop/Notification/PreToolUse/SessionStart）
4. すべてのプロジェクトで会話ブリッジを強制実行する
5. 完全なコントロール監査を実行する
6. 現在の状態で AGENTS.md を更新する

workspace — 複数ワークスペースのフェデレーションレジストリ（≥ 0.18.0、Phase 8）

bin/bstack-workspace + scripts/workspace.py。このマシン上の bstack が管理するワークスペースのホストレベルの一覧を ~/.broomva/global/registry.yaml で管理します。フェデレーションはオプトインで、読み取り専用です。各ワークスペースは、引き続き自身の状態の信頼できる情報源です。レジストリは、bstack status --aggregate が複合的な ω の健全性を集計するためにたどるインデックスです。

bstack workspace register             # registers $PWD (name = basename)
bstack workspace register --path ~/projects/foo --tag client-x
bstack workspace list --json          # machine-readable for scripts
bstack workspace info                 # is this workspace registered?
bstack workspace deregister --name foo

終了コード：0 正常、2 無効な引数、3 スキーマ／解析エラー、4 対象が見つからない、5 異なるパスでの名前の競合。SLO：登録／一覧表示の p50 は 100ms 未満。

フェデレーションは新しいプリミティブではありません。P21 はありません。既存のプリミティブを組み合わせます。Snapshot（P15）がワークスペースごとの監査シグナルを出力し、v0.16.0 §19 の多層複合 ω がワークスペースごとの判定に使われます。Doctor §20 ではレジストリの健全性を表示します（レジストリファイルの schema_version != 1 の場合を除き、参考情報です）。

スタックレイヤー（30個のスキル）

スキルの一覧と説明については、references/skills-roster.md を参照してください。レイヤー構成については、references/stack-architecture.md を参照してください。反射的トリガーを含むプリミティブ契約の全容については、references/primitives.md を参照してください。

Metalayer integration

bstack は agentic-control-kernel の測定基盤です。ハーネスは次の指標を記録します。

指標	目標	方法
インストール済みスキル	28/28	プリアンブルの一覧
ガバナンスファイル	4/4	CLAUDE.md、AGENTS.md、METALAYER.md、.control/policy.yaml
フックの設定	4/4	Stop、PreToolUse safety、PreToolUse regression、pre-commit
ステータスライン	active	~/.claude/statusline-command.sh
ブリッジの稼働状況	最終更新から 24 時間未満	~/.cache/broomva-bridge-stamp の mtime
制御監査	5/5 セクション	make control-audit の終了コード
インデックス済み会話	≥1 セッション	docs/conversations/Conversations.md が存在する
プリミティブ契約	20/20	bstack doctor の終了コード

bstack を使用する場面

• Broomva の規約に沿って新しいプロジェクトをセットアップする → bootstrap
• 既存のプロジェクトがプリミティブ契約を満たしているか検証する → doctor
• doctor が報告した特定の不足を修正する → repair
• スキルの鮮度や一覧の完全性を確認する → status または validate
• ワークスペースを大規模に整理する → revamp

共有ナレッジサーフェスとしてのプロンプト

bstack は broomva.tech のプロンプトライブラリを、プライベートなリポジトリではなく、エージェント間で共有されるナレッジサーフェスとして扱います。すべての bstack ワークスペースがこのライブラリから得るものは 2 つあります。

1. 再利用可能な指示 — バージョン管理され、パラメーター化されたプロンプト（code-review-agent、deep-research-agent、ai-native-platform-architect、bstack-control-harness-bootstrap など）を、任意のエージェントが取得して適用できます。
2. 評価エンジン — 取得と完了のたびに、型付きの行が prompt_invocation に書き込まれます。ソースの帰属情報（web|cli|skill|api）、レイテンシー、トークン数、コスト、明示的なユーザーフィードバックがすべて、broomva.tech/api/metrics/* の評価サーフェスに反映されます。

反射的なルール（必須）

ユーザーが既知のパターン（コードレビュー、深い調査、プラットフォームの再設計、ハーネスのブートストラップなど）を求めており、かつそのパターンがライブラリに存在する場合は、一から作成せず、ライブラリのものを使用してください。次の 5 段階の指示は必ず守ってください。

# 1. Tag the session
export BROOMVA_SOURCE=skill

# 2. Pull — captures invocation_id on stderr
broomva prompts pull <slug> --json 2>&1 | tee /tmp/broomva-last.json

# 3. Use the prompt body as instructions for the work

# 4. MANDATORY after completing the work
broomva prompts complete <invocation_id> \
  --status completed --model <name> \
  --latency-ms <ms> --tokens-in <n> --tokens-out <m>

# 5. Optional — capture explicit user feedback
broomva prompts feedback <invocation_id> --slug <slug> --signal up --text "..."

ステップ 4 を省略すると、行は pulled のままになり、評価エンジンは実行結果から学習できません。24 時間ごとのスイーパーが最終的にこれを abandoned に変更します。これは品質のシグナルであり、有用な実行ではありません。

検出

broomva prompts list --metrics --sort skill_invokes   # most-invoked first
broomva prompts list --category agent-instructions    # filtered
broomva prompts get <slug> --raw                      # body only

プリミティブ契約との構成

• P1 は会話ログに呼び出し ID を記録し、セッションから評価エンジンへのバックポインターとなります。
• P4 は PR レビュープロンプトの呼び出しをマージ結果に結び付け、プロンプトのバージョンごとの合格率を測定可能にします。
• P6 は、統合に値するプロンプトを research/entities/ のエンティティページに昇格させます（ライブラリは実行時レジストリ、ナレッジグラフは結晶化された形です）。
• P11 で呼び出しを実際の tokens_in/out、latency_ms、error_message を使って完了させることは、測定可能な結果で検証するという P11 と同じ規律です。
• P13 評価エンジンの進化するランキングは夢階層の基盤であり、実行ごとのテレメトリーは密度の高い下位階層のシグナルです。

検出パターン、落とし穴、プリミティブごとの構成を含む統合ガイド全文：references/prompts-integration.md。

自己進化

エージェントがプリミティブを改善する場合のワークフローは次のとおりです。

1. 複数のセッションにわたってパターンを観察する（L3 の安定性予算。急速な変更はシステムを不安定にします）
2. 会話ログに記録する（Stop フック — P1 を介して自動実行）
3. AGENTS.md に結晶化する（1 つの PR で慎重に行う）
4. 機械的にゲート可能な場合は .control/policy.yaml で適用する（1 つの PR で慎重に行う）
5. 新しいルールをチェックするよう Doctor を拡張する（1 つの PR で慎重に行う）
6. 将来のエージェントが改善を引き継ぐ

これは RCS 階層の L3 における f₃ ダイナミクス関数です。安定性に関する正式な制約については、references/primitives.md を参照してください。

関連情報

• references/primitives.md — リフレクシブなトリガーを含む、P1～P20の完全なリファレンス
• references/prompts-integration.md — broomva.tech のプロンプトライブラリの活用方法とタイミング（5段階の自動トレースの必須手順、検出、よくある落とし穴）
• references/skills-roster.md — インストールコマンドを含む30個すべてのスキル
• references/stack-architecture.md — レイヤーの依存関係図
• references/quickstart.md — 5分でできるインストール手順
• bstack-upgrade/SKILL.md — バージョンアップグレードのフロー