swain-init

プロジェクトのオンボーディング

プロジェクトで swain を導入するための初回セットアップです。このスキルは冪等ではありません。ファイルを移行し、ツールをインストールします。セッションごとのヘルスチェックには、swain-doctor を使用してください。

事前確認

各フェーズを始める前に、事前確認スクリプトを実行して環境の状態を収集します。この呼び出し一つで、すべてのインラインチェックブロックを置き換えます。以下の各フェーズでは、シェルコマンドを実行する代わりに JSON 出力を参照します。

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
PREFLIGHT_SCRIPT="$(find "$REPO_ROOT" -path '*/swain-init/scripts/swain-init-preflight.sh' -print -quit 2>/dev/null)"
PREFLIGHT_JSON=$( bash "$PREFLIGHT_SCRIPT" --repo-root "$REPO_ROOT" 2>/dev/null )
echo "$PREFLIGHT_JSON"

以下のすべてのフェーズで使用するため、PREFLIGHT_JSON を保存します。各判断ではこの JSON のフィールドを参照してください。変更を実行する場合を除き、追加のチェックコマンドは実行しないでください。

フェーズ 0：初期化済みかどうかの検出

事前確認 JSON から marker.action を読み取ります。

• "delegate" — 同じメジャーバージョンです。ユーザーに次のように伝えます。

  プロジェクトはすでに初期化されています（swain marker.release_version、init vmarker.last_version）。swain-session に引き継ぎます。

  以下の**フェーズ 7（セッション開始）**に進みます。フェーズ 1〜6 は実行しないでください。

• "upgrade" — より新しいメジャーバージョンが利用可能です。ユーザーに次のように伝えます。

  プロジェクトは swain marker.last_release_version（init vmarker.last_version）で初期化されています。現在：marker.release_version（init vmarker.current_version）。新機能を利用するには、/swain update の実行をご検討ください。 セッションを開始します。

  以下の**フェーズ 7（セッション開始）**に進みます。オンボーディングを再実行しないでください。アップグレードは swain-init ではなく、swain-update が処理します。

• "onboard" — マーカーが見つかりません。オンボーディング全体（フェーズ 1〜6）に進みます。

フェーズ 1：CLAUDE.md → AGENTS.md の移行

目的：@AGENTS.md のインクルードパターンを確立し、プロジェクトの指示を AGENTS.md に配置します（AGENTS.md をネイティブに読み取る Claude Code、GitHub、その他のツールで機能します）。

事前確認 JSON から migration.state を読み取ります。

"fresh" の場合

両方のファイルを作成します。

• CLAUDE.md： @AGENTS.md
• AGENTS.md： # AGENTS.md（空 — ガバナンスはフェーズ 5 で追加）

"migrated" の場合

フェーズ 2 に進みます。

"standard" の場合

1. CLAUDE.md の内容を AGENTS.md にコピーします（すべて保持します）。
2. CLAUDE.md に `` ブロックが含まれている場合は、AGENTS.md のコピーから削除します。フェーズ 5 で改めて追加します。
3. CLAUDE.md を @AGENTS.md に置き換えます。

ユーザーに次のように伝えます。

CLAUDE.md の内容を AGENTS.md に移行し、CLAUDE.md を @AGENTS.md に置き換えました。既存の指示は保持されています。Claude Code はインクルードディレクティブを介して AGENTS.md を読み取ります。

"split" の場合

両方のファイルに内容があります。ユーザーに確認します。

CLAUDE.md と AGENTS.md の両方に内容があります。どのように進めますか？

1. マージ — CLAUDE.md の内容を AGENTS.md の末尾に追加し、CLAUDE.md を @AGENTS.md に置き換える
2. AGENTS.md を保持 — CLAUDE.md の内容を破棄し、CLAUDE.md を @AGENTS.md に置き換える
3. 中止 — 両方のファイルをそのままにして、移行をスキップする

マージする場合：CLAUDE.md の内容（`` ブロックがあれば除く）を AGENTS.md に追加し、CLAUDE.md を @AGENTS.md に置き換えます。

フェーズ 2：依存関係の確認

ステップ 2.1 — uv

事前確認 JSON から uv.available を読み取ります。

false の場合は、インストールします。

curl -LsSf https://astral.sh/uv/install.sh | sh

インストールに失敗した場合は、ユーザーに次のように伝えます。

uv のインストールに失敗しました。手動でインストールできます（https://docs.astral.sh/uv/getting-started/installation/）。swain スクリプトの Python 実行には uv が必要です。

失敗した場合は、フェーズ 2 の残りをスキップします（uv がなくても初期化は続行しますが、uv がないとスクリプトが機能しないことを警告してください）。

ステップ 2.2 — ベンダー提供の tk

事前確認 JSON から tk.path と tk.healthy を読み取ります。

tk.path が null、または tk.healthy が false の場合は、ユーザーに次のように伝えます。

ベンダー提供の tk スクリプトが見つからないか、壊れています。通常、これは swain-do スキルが完全にインストールされていないことを意味します。スキルを再インストールするには、/swain update を実行してください。

ステップ 2.3 — beads から移行する（該当する場合）

事前チェック JSON から beads.exists と beads.has_backup を読み取ります。

beads.exists が true で、beads.has_backup も true の場合は、移行を提案します。

既存の .beads/ データが見つかりました。タスクを tk に移行しますか？ .beads/backup/issues.jsonl を .tickets/ の Markdown ファイルに変換します。

ユーザーが同意した場合は、移行を実行します。

TK_BIN="$(cd "$(dirname "$(find . .claude .agents -path '*/swain-do/bin/tk' -print -quit 2>/dev/null)")" && pwd)"
export PATH="$TK_BIN:$PATH"
cp .beads/backup/issues.jsonl .beads/issues.jsonl 2>/dev/null
ticket-migrate-beads
ls .tickets/*.md 2>/dev/null | wc -l

結果をユーザーに伝え、確認後に .beads/ を削除できることを伝えます。

beads.exists が false の場合は、スキップします。tk は最初の tk create で .tickets/ を作成します。

ステップ 2.4 — Operator の bin/ シンボリックリンク（SPEC-214、ADR-019）

事前チェック JSON から bin_manifests を読み取ります。各エントリについて、bin/ シンボリックリンクを作成します。

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
BIN_DIR="$REPO_ROOT/bin"
SKILLS_ROOT="$REPO_ROOT/.agents/skills"
for manifest_dir in "$SKILLS_ROOT"/*/usr/bin; do
  [ -d "$manifest_dir" ] || continue
  for entry in "$manifest_dir"/*; do
    [ -e "$entry" ] || [ -L "$entry" ] || continue
    cmd_name="$(basename "$entry")"
    script_path="$(cd "$manifest_dir" && readlink -f "$cmd_name" 2>/dev/null || true)"
    [ -z "$script_path" ] || [ ! -f "$script_path" ] && continue
    rel_path="$(python3 -c "import os,sys; print(os.path.relpath(sys.argv[1], sys.argv[2]))" "$script_path" "$BIN_DIR" 2>/dev/null || echo "")"
    [ -z "$rel_path" ] && continue
    if [ -L "$BIN_DIR/$cmd_name" ]; then
      echo "already linked: $cmd_name"
    elif [ -e "$BIN_DIR/$cmd_name" ]; then
      echo "conflict — bin/$cmd_name exists as a real file; skipping"
    else
      mkdir -p "$BIN_DIR"
      ln -sf "$rel_path" "$BIN_DIR/$cmd_name"
      echo "created bin/$cmd_name"
    fi
  done
done

bin/ で使用できるようになった Operator コマンドをユーザーに伝えます。

bin_manifests が空の場合は、何もせずにスキップします。

フェーズ 3：コミット前セキュリティフック

目的：シークレットスキャン用のコミット前フックを設定し、認証情報が git の履歴に記録される前に検出できるようにします。デフォルトのスキャナーは gitleaks です。追加のスキャナー（TruffleHog、Trivy、OSV-Scanner）はオプトイン方式です。

ステップ 3.1 — 既存の設定を確認する

事前チェック JSON から precommit.config_exists を読み取ります。

true の場合： 現在の .pre-commit-config.yaml の内容を提示し、次のように尋ねます。

既存の .pre-commit-config.yaml が見つかりました。どのように進めますか？

1. マージ — 既存のフックに swain の gitleaks フックを追加します
2. スキップ — コミット前の設定を変更せずに残します
3. 置き換え — swain のデフォルト設定で上書きします（既存のフックは失われます）

ユーザーが「スキップ」を選んだ場合は、フェーズ 4 に進みます。

false の場合： ステップ 3.2 に進みます。

ステップ 3.2 — pre-commit フレームワークをインストールする

事前チェック JSON から precommit.framework を読み取ります。

false の場合は、インストールします。

uv tool install pre-commit

uv を利用できない場合、またはインストールに失敗した場合は、次の警告を表示します。

pre-commit フレームワークを利用できません。手動でインストールできます（uv tool install pre-commit または pip install pre-commit）。フックの設定をスキップします。

pre-commit をインストールできない場合は、フェーズ 4 に進みます。

ステップ 3.3 — .pre-commit-config.yaml を作成または更新する

デフォルト設定では gitleaks が有効になります。

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

ユーザーが追加のスキャナーを要求した場合（--scanner フラグを使用した場合、または尋ねられた際に要求した場合）は、該当するフックを追加します。

TruffleHog（オプトイン）：

  - repo: https://github.com/trufflesecurity/trufflehog
    rev: v3.88.1
    hooks:
      - id: trufflehog
        args: ['--results=verified,unknown']

Trivy（オプトイン）：

  - repo: https://github.com/cebidhem/pre-commit-trivy
    rev: v1.0.0
    hooks:
      - id: trivy-fs
        args: ['--severity', 'HIGH,CRITICAL', '--scanners', 'vuln,license']

OSV-Scanner（オプトイン）：

  - repo: https://github.com/nicjohnson145/pre-commit-osv-scanner
    rev: v0.0.1
    hooks:
      - id: osv-scanner

設定ファイルを書き込みます。既存の設定とマージする場合は、新しいリポジトリエントリを既存の repos: リストに追加します。

ステップ 3.4 — フックをインストールする

pre-commit install を実行して、フックを有効にします。

ステップ 3.5 — swain.settings.json を更新する

既存の swain.settings.json（存在する場合）を読み取り、sync.scanners キーを追加します。

{
  "sync": {
    "scanners": {
      "gitleaks": { "enabled": true },
      "trufflehog": { "enabled": false },
      "trivy": { "enabled": false, "scanners": ["vuln", "license"], "severity": "HIGH,CRITICAL" },
      "osv-scanner": { "enabled": false }
    }
  }
}

ユーザーがオプトインしたスキャナーについては、enabled: true に設定します。既存の設定とマージし、他のキーは上書きしないでください。

ユーザーに次のように伝えます。

gitleaks（デフォルト）を使用するコミット前フックを設定しました。スキャナーの設定を swain.settings.json に保存しました。後から追加のスキャナーを有効にするには、swain.settings.json を編集して /swain-init を再実行してください。

フェーズ 4：Superpowers コンパニオン

目的：obra/superpowers がまだ存在しない場合に、インストールを提案します。

ステップ 4.1 — superpowers を検出する

事前チェック JSON から superpowers.installed を読み取ります。

true の場合は、「Superpowers：インストール済み」と報告し、フェーズ 4.4 に進みます。

ステップ 4.2 — インストールを提案する

ユーザーに次のように尋ねます。

Superpowers（obra/superpowers）がインストールされていません。実装や設計作業で swain が連携して使用する、TDD、ブレインストーミング、計画書の作成、検証のスキルを提供します。

今すぐ superpowers をインストールしますか？（yes/no）

ユーザーが no と答えた場合は、「Superpowers：スキップ」と記録し、フェーズ 4.4 に進みます。後からいつでもインストールできます：npx skills add obra/superpowers。

ステップ 4.3 — インストールする

npx skills add obra/superpowers

インストールに成功した場合は、ユーザーに次のように伝えます。

Superpowers をインストールしました。ブレインストーミング、TDD、計画書の作成、検証のスキルを利用できるようになりました。

失敗した場合は、次の警告を表示します。

Superpowers のインストールに失敗しました。手動で再試行できます：npx skills add obra/superpowers

いずれの場合も、フェーズ 4.4 に進みます。

ステップ 4.4 — Tmux

プリフライト JSON から tmux.installed を読み取ります。

true の場合は「tmux：インストール済み」と報告し、フェーズ 4.5 に進みます。

false の場合は、ユーザーに尋ねます。

tmux がインストールされていません。swain は利用可能な場合、タブ名の設定に tmux を使用します。これは任意です。tmux がなくても swain は動作しますが、セッションのタブ名を設定できません。

今すぐ tmux をインストールしますか？（はい／いいえ）

はいの場合：

brew install tmux

インストールに成功した場合は、ユーザーに伝えます。

tmux をインストールしました。ワークスペースのレイアウト機能とタブ名の設定機能を利用できるようになりました。

インストールに失敗した場合は、次のように警告します。

tmux のインストールに失敗しました。手動でインストールできます：brew install tmux

いいえの場合は「tmux：スキップ」と記録し、フェーズ 4.5 に進みます。

フェーズ 4.5：シェルランチャー

目標：ユーザーが単一のコマンドで swain を起動できるように、swain シェル関数のインストールを提案します。テンプレートはランタイムおよびシェルごとに templates/launchers/{runtime}/swain.{shell}（このスキルのディレクトリからの相対パス）に保存されています。追加される内容を正確に確認するには、テンプレートを調べてください。サポートされているランタイムは ADR-017 で定義されています。

ステップ 4.5.1 — シェルを検出する

プリフライト JSON から launcher.shell を読み取ります。

サポートされているシェル：zsh、bash、fish。シェルがこのリストにない場合は、ユーザーに伝えます。

シェルランチャーのテンプレートは zsh、bash、fish 用に用意されています。お使いのシェル（launcher.shell）はまだサポートされていないため、ランチャーの設定をスキップします。

フェーズ 5 に進みます。

ステップ 4.5.2 — 既存のランチャーを確認する

プリフライト JSON から launcher.already_installed を読み取ります。

true の場合は「シェルランチャー：インストール済み」と報告し、フェーズ 5 に進みます。既存の関数は変更しないでください。

ステップ 4.5.3 — ランタイムを検出する

プリフライト JSON から launcher.runtimes を読み取ります。

配列が空の場合は、ユーザーに伝えます。

サポートされているエージェント型 CLI ランタイムが見つかりませんでした（確認対象：claude、gemini、codex、copilot、crush）。先にいずれかをインストールしてから、/swain-init を再実行してください。

フェーズ 5 に進みます。

ステップ 4.5.4 — ランタイムを選択する

• 見つかったランタイムが 1 つの場合： そのランタイムを直接提示します。
• 見つかったランタイムが複数の場合： 番号付きリストを提示し、どれを使うか尋ねます。利用可能であれば、デフォルトは claude にします。

プリフライト JSON から launcher.template_dir を読み取ります。テンプレートのパスを組み立てます。

$TEMPLATE_DIR/$SELECTED_RUNTIME/swain.$SHELL_NAME

ステップ 4.5.5 — テンプレートを表示し、インストールを提案する

テンプレートファイルの内容を読み取り、ユーザーに提示します。

シェルランチャー — シェルに swain コマンドを追加しますか？

検出されたランタイム：[runtime name]。<rc-file> に追加される内容は次のとおりです。

<template content>

インストールしますか？（はい／いいえ）

Crush のテンプレートの場合は、次の注記を追加します。「Crush のサポートは一部に限られています。初期プロンプトを受け付けないため、セッションの初期化は AGENTS.md の自動呼び出しディレクティブに依存します。」

ステップ 4.5.6 — インストールする

ユーザーが承諾した場合は、テンプレートの内容を rc ファイルに追記します（プリフライト JSON から launcher.rc_file を読み取ります。例：cat "$TEMPLATE_FILE" >> "$RC_FILE"）。

ユーザーに伝えます。

シェルランチャーをインストールしました。source <rc-file> を実行する（またはシェルを再起動する）と、swain コマンドが有効になります。

ユーザーが断った場合は「シェルランチャー：スキップ」と記録し、フェーズ 5 に進みます。

フェーズ 5：Swain のガバナンス

目標：swain のルーティングルールとガバナンスルールを AGENTS.md に追加します。

ステップ 5.1 — 既存のガバナンスを確認する

プリフライト JSON から governance.installed を読み取ります。

true の場合、ガバナンスはすでにインストールされています。ユーザーに伝え、フェーズ 5.5 に進みます。

ステップ 5.2 — 許可を求める

ユーザーに尋ねます。

swain のガバナンスルールを AGENTS.md に追加する準備ができました。これらのルールでは、次のことを行います。

• 成果物のリクエスト（仕様書、ストーリー、ADR など）を swain-design にルーティングする
• タスクの追跡を swain-do（tk を使用）にルーティングする
• 実装前プロトコル（コーディング前の計画）を徹底する
• 組み込みの代替機能より swain スキルを優先する

AGENTS.md にガバナンスルールを追加しますか？（はい／いいえ）

いいえの場合は、フェーズ 5.5 に進みます。

ステップ 5.3 — ガバナンスを適用する

swain-doctor/references/AGENTS.content.md から正規のガバナンス内容を読み込みます（.claude/skills、.agents/skills、skills ディレクトリを検索してファイルを見つけてください）。そのファイルの全内容を AGENTS.md に追記します。

ユーザーに次のように伝えます：

ガバナンスルールを AGENTS.md に追加しました。これにより、swain のスキルを適切に振り分け、規約を徹底できます。`` マーカーの外側は自由にカスタマイズできます。

フェーズ 5.5：README の作成と成果物の提案（SPEC-207）

目標：すべての swain プロジェクトに README を用意し、成果物ツリーが空の場合は、README から成果物を作成することを提案します。

ステップ 5.5.1 — README の有無を確認する

プリフライト JSON から readme.exists を読み込みます。

ステップ 5.5.2 — README がない場合に作成する

プリフライト JSON の readme.has_code と readme.has_artifacts を使って、プロジェクトの状況を判断します。

• コードも成果物もない — オペレーターに「このプロジェクトは何をするものですか？」と尋ねます。その回答をもとに README を作成します。
• コードはあるが、成果物はない — コード（エントリーポイント、package.json／pyproject.toml／go.mod など）からプロジェクトの目的を推測します。README の草案を提示し、オペレーターに編集してもらいます。
• 成果物はあるが、README はない — アクティブなビジョン、設計、ジャーニー、ペルソナから内容をまとめます。草案を提示し、オペレーターに編集してもらいます。

草案をオペレーターに提示します。承認、編集、スキップのいずれかを選べます。スキップされた場合は、サマリーに「README: skipped」と記録します。swain-doctor は今後のセッションで README がないことを警告します。

ステップ 5.5.3 — README から初期成果物を提案する

プリフライト JSON から readme.active_count を読み込みます。

readme.active_count < 3 で README.md が存在する場合、README を読み込み、意味解析によって意図に関する記述を抽出します。初期成果物を提案します。

• ビジョン — プロジェクトが何をするのか、なぜそれを行うのかを説明する README の記述をもとにします。
• ペルソナ — README の対象読者と、そこで説明されている課題をもとにします。
• ジャーニー — 利用の流れ、例、「はじめに」の手順をもとにします。
• 設計 — アーキテクチャや構造に関する記述をもとにします。

各提案を個別に提示します。オペレーターはそれぞれを承認、編集、却下できます。承認された成果物は swain-design を使って作成します。却下された提案は何もせず破棄します。

意味抽出： README 全体を文章として読み込みます。慣習に基づくセクションや、オペレーターが配置するマーカーは使用しません。インストール手順、機能の説明、動作に関する記述、アーキテクチャの記述など、README 内のどの記述も意図の情報源になり得ます。

フェーズ 6：最終処理

ステップ 6.1 — .agents ディレクトリを作成する

.agents/ が存在しない場合は作成します（mkdir -p .agents）。このディレクトリは、swain-do の設定と swain-design スクリプトのログに使用されます。

ステップ 6.1.1 — .agents/bin/ を初期化する（ADR-019）

.agents/bin/ を作成し、スキルツリー内のエージェント向けスクリプトすべてへのシンボリックリンクを配置します。

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
AGENTS_BIN="$REPO_ROOT/.agents/bin"
SKILLS_ROOT="$REPO_ROOT/.agents/skills"
mkdir -p "$AGENTS_BIN"
OPERATOR_SCRIPTS="swain swain-box"
for skill_scripts_dir in "$SKILLS_ROOT"/*/scripts; do
  [ -d "$skill_scripts_dir" ] || continue
  for script in "$skill_scripts_dir"/*; do
    [ -f "$script" ] && [ -x "$script" ] || continue
    script_name="$(basename "$script")"
    case "$script_name" in test-*) continue ;; esac
    echo " $OPERATOR_SCRIPTS " | grep -q " $script_name " && continue
    rel_path="$(python3 -c "import os,sys; print(os.path.relpath(sys.argv[1], sys.argv[2]))" "$script" "$AGENTS_BIN" 2>/dev/null)" || continue
    ln -sf "$rel_path" "$AGENTS_BIN/$script_name"
  done
done

まだ .gitignore に記載されていない場合は、.agents/bin/ と .agents/session.json を追加します（利用プロジェクトでこれらを追跡しないでください）。

ステップ 6.2 — swain-doctor を実行する

swain-doctor スキルを呼び出します。.tickets/ の健全性を検証し、古いロックを確認し、レガシーのスキルディレクトリを削除して、ガバナンスが正しく導入されていることを確認します。

ステップ 6.3 — オンボーディング

swain-help スキルをオンボーディングモードで呼び出し、インストールした内容をユーザーに案内します。

ステップ 6.4 — .swain/init.json マーカーを書き込む

すべてのオンボーディングフェーズが完了した後、.swain/init.json マーカーファイルを書き込みます。プリフライト JSON から marker.current_version をスキルのバージョンとして、marker.release_version をリリースバージョンとして読み込みます。

.swain/init.json がすでに存在する場合（一部の再初期化）は、ファイルを読み込み、履歴配列に追記します。それ以外の場合は、新しいファイルを作成します。

{
  "history": [
    {
      "version": "4.0.0",
      "release": "v0.29.0-alpha",
      "timestamp": "2026-03-26T18:30:00Z",
      "action": "init"
    }
  ]
}

アップグレード（今後 swain-update が使用する場合）では、代わりに "action": "upgrade" を含むエントリーを追記します。

ファイルを書き込み、.swain/ が .gitignore に含まれていることを確認します（プロジェクト内の状態であり、共有するものではありません）。

Step 6.5 — 概要

実施した内容を報告します。

swain init が完了しました。

• CLAUDE.md → @AGENTS.md インクルードパターン：[完了／スキップ／設定済み]
• tk（チケット）の確認：[完了／見つかりません]
• Beads の移行：[完了／スキップ／Beads が見つかりません]
• プリコミットセキュリティフック：[完了／スキップ／設定済み]
• Superpowers：[インストール済み／スキップ／すでに存在]
• tmux：[インストール済み／スキップ／すでに存在]
• シェルランチャー：[インストール済み（ランタイム）／スキップ／すでに存在／ランタイムが見つかりません／サポートされていないシェル]
• AGENTS.md の Swain ガバナンス：[完了／スキップ／すでに存在]
• README：[作成済み／すでに存在／スキップ]
• README からの成果物の提案：[N 件を提案、M 件を承認／スキップ／該当なし]
• Init マーカー：書き込み済み（.swain/init.json）

Step 6.6 — セッションを開始する

オンボーディングが正常に完了したら、以下の Phase 7（セッション開始） に進みます。

Phase 7: セッション開始（ADR-023）

このフェーズは毎回実行されます。初回オンボーディング後（Phase 6）と、すでに初期化済みの場合の高速パス（Phase 0）の両方が対象です。以前の swain-session 起動シーケンスに代わるものです。

Step 7.1 — 高速な挨拶

高速な挨拶スクリプトを実行します。読み取り専用の状態をすべて取得するため、スクリプト内部でセッションの事前チェックを行い、その後、軽量な変更（タブ名の設定、ロックのクリーンアップ）を適用します。サブプロセスの連鎖はなく、事前チェックは 1 回だけです。

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-session-greeting.sh" --json

挨拶は構造化 JSON を出力します。

{
  "greeting": true,
  "branch": "trunk",
  "dirty": false,
  "isolated": false,
  "bookmark": "Left off implementing the bootstrap script",
  "focus": "VISION-001",
  "tab": "project @ branch",
  "warnings": []
}

挨拶から内部的に呼び出されるセッションの事前チェックでは、前回のセッション状態も収集します。直接アクセスするには、以下を実行します。

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
PREFLIGHT_JSON=$( bash "$REPO_ROOT/.agents/bin/swain-session-preflight.sh" --repo-root "$REPO_ROOT" 2>/dev/null )

挨拶の JSON を受け取った後：

1. 挨拶の内容をオペレーターに提示します。ブランチ、変更状態、ブックマーク（ある場合）、フォーカスレーン（ある場合）、警告を含めます。

2. bookmark が null でない場合は、表示します。

   セッションを再開します — 前回：{bookmark}

3. isolated が false の場合、この時点ではワークツリーを作成しないでください。ワークツリーの作成は、swain-do のタスク振り分け時まで保留されます（SPEC-195）。

$TMUX が設定されていない場合（JSON に tab がないことで検出）、tmux がインストールされているか確認します。

• tmux がインストールされていない場合： インストールを提案します（brew install tmux）。
• tmux はインストールされているが、セッション内にいない場合： [note] tmux セッション内ではありません — セッションのタブおよびペイン機能は利用できません と表示します。

Step 7.2 — セッション状態の初期化

セッションの事前チェックの JSON から prev_session を読み取ります（または、挨拶で公開されなかった場合は事前チェックを直接呼び出します）。prev_session.exists が true の場合は、そのフォーカスレーン、離席時のメモ、決定数を表示します。オペレーターに「前回のセッションを続けますか、それとも新しく始めますか？」と尋ねます。

新しく始める場合（または前回のセッションがない場合）：

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-session-state.sh" init \
  --focus "<FOCUS-ID>" \
  --session-roadmap "$(pwd)/SESSION-ROADMAP.md" \
  --repo-root "$REPO_ROOT"

Step 7.3 — フォーカスレーン

フォーカスレーンを使用すると、推奨事項を単一のビジョンまたはイニシアチブに絞り込めます。オペレーターが作業内容を決めたときに設定します。

挨拶の JSON に focus の値が含まれている場合： オペレーターに確認します。

フォーカスレーン：{focus}。このフォーカスで続けますか、それとも変更しますか？

フォーカスが設定されていない場合： オペレーターに取り組みたい内容を尋ねます。名前を成果物 ID に対応付けます。

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/chart.sh" --ids --flat 2>/dev/null | grep -i "<name>"

一致するものが 1 件の場合は、それを使用します。複数ある場合は、オペレーターに уточ明を求めます。一致するものがない場合は、その旨を伝え、作成を提案します。

フォーカスを設定します。

bash "$REPO_ROOT/.agents/bin/swain-focus.sh" set <RESOLVED-ID>

フォーカス成果物のコンテキストを表示します。

bash "$REPO_ROOT/.agents/bin/artifact-context.sh" <RESOLVED-ID> 2>/dev/null

フォーカスレーンは .agents/session.json の focus_lane キーに保存され、セッション中は保持されます。

ステップ 7.4 — セッションの目的テキスト

オペレーターが自由入力で起動した場合（例：swain new bug about timestamps）、ランチャーは SWAIN_PURPOSE をエクスポートし、初期プロンプトを受け付けるランタイムには、インラインで /swain-init Session purpose: new bug about timestamps も渡します。

挨拶スクリプト（swain-session-greeting.sh）は $SWAIN_PURPOSE を読み取り、ブックマークを決定的に書き込みます（SPEC-297）。挨拶 JSON の purpose フィールドには、取得したテキストが表示されます。

挨拶 JSON の purpose フィールドが null でない場合：

• オペレーターに次のように表示します：**セッションの目的：** <text>。

初期プロンプトを再解析したり、自分で swain-bookmark.sh を呼び出したりしないでください。挨拶スクリプトがすでに両方を実行しています。インラインのプロンプトテキストは表示コンテキスト専用であり、信頼できる情報源は環境変数です。

Worktree / ブランチの変更

エージェントが worktree に入る、またはブランチを切り替えるときは、--path を指定してブートストラップを再実行し、タブ名を更新します：

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-session-bootstrap.sh" --path "$NEW_WORKDIR" --skip-worktree --auto

init の再実行

すでにセットアップ済みのプロジェクトでユーザーが /swain-init を実行すると、フェーズ 0 はプリフライト JSON の marker.action フィールドを読み取り、フェーズ 7（セッション開始）に進みます。オンボーディングの各フェーズは実行されず、対話型プロンプトも表示されません。これにより、ユーザーは /swain-init を単一のエントリーポイントとして習慣化できます。

オンボーディングをやり直すには、.swain/init.json を削除して再実行します。