takt 0.33.2 → 0.35.0

package/builtins/skill/references/engine.md

@@ -2,7 +2,7 @@
 
 ## チームメイトの起動方法
 
-全ての movement は Task tool でチームメイトを起動して実行する。
+全ての step は Task tool でチームメイトを起動して実行する。
 **あなた（Team Lead）が直接作業することは禁止。**
 
 ### Task tool の呼び出し
@@ -11,8 +11,8 @@
 Task tool:
   subagent_type: "general-purpose"
   team_name: "takt"
-  name: "{movement_name}"
-  description: "{movement_name} - {piece_name}"
+  name: "{step_name}"
+  description: "{step_name} - {workflow_name}"
   prompt: <プロンプト構築で組み立てた内容>
   mode: permission_mode
 ```
@@ -24,18 +24,18 @@ Task tool:
 - `/takt coding --permit-edit タスク` → `permission_mode = "acceptEdits"`（編集は自動許可）
 - `/takt coding タスク` → `permission_mode = "default"`（権限確認あり）
 
-## 通常 Movement の実行
+## 通常 step の実行
 
-通常の movement（`parallel` フィールドを持たない）は、Task tool で1つのチームメイトを起動する。
+通常の step（`parallel` フィールドを持たない）は、Task tool で1つのチームメイトを起動する。
 
 1. プロンプトを構築する（後述の「プロンプト構築」参照）
 2. Task tool でチームメイトを起動する
 3. チームメイトの出力を受け取る
-4. Rule 評価で次の movement を決定する
+4. Rule 評価で次の step を決定する
 
-## Parallel Movement の実行
+## Parallel step の実行
 
-`parallel` フィールドを持つ movement は、複数のチームメイトを並列起動する。
+`parallel` フィールドを持つ step は、複数のチームメイトを並列起動する。
 
 ### 実行手順
 
@@ -44,13 +44,13 @@ Task tool:
 3. 全チームメイトの完了を待つ
 4. 各サブステップの出力を収集する
 5. 各サブステップの出力に対して、そのサブステップの `rules` で条件マッチを判定
-6. 親 movement の `rules` で aggregate 評価（all()/any()）を行う
+6. 親 step の `rules` で aggregate 評価（all()/any()）を行う
 
 ### サブステップの条件マッチ判定
 
 各サブステップの出力テキストに対して、そのサブステップの `rules` の中からマッチする condition を特定する。
 
-判定方法（通常 movement の Rule 評価と同じ優先順位）:
+判定方法（通常 step の Rule 評価と同じ優先順位）:
 1. `[STEP:N]` タグがあればインデックスで照合（最後のタグを採用）
 2. タグがなければ、出力全体を読んでどの condition に最も近いかを判断する
 
@@ -58,15 +58,15 @@ Task tool:
 
 ## セクションマップの解決
 
-ピースYAMLのトップレベルにある `personas:`, `policies:`, `instructions:`, `output_contracts:`, `knowledge:` はキーとファイルパスの対応表。movement 内ではキー名で参照する。
+ワークフロー YAML のトップレベルにある `personas:`, `policies:`, `instructions:`, `output_contracts:`, `knowledge:` はキーとファイルパスの対応表。step 定義内ではキー名で参照する。
 
 ### 解決手順
 
-1. ピースYAMLを読み込む
-2. 各セクションマップのパスを、**ピースYAMLファイルのディレクトリ**を基準に絶対パスに変換する
-3. movement の `persona: coder` → `personas:` セクションの `coder` キー → ファイルパス → Read で内容を取得
+1. ワークフローYAMLを読み込む
+2. 各セクションマップのパスを、**ワークフローYAMLファイルのディレクトリ**を基準に絶対パスに変換する
+3. step の `persona: coder` → `personas:` セクションの `coder` キー → ファイルパス → Read で内容を取得
 
-例: ピースが `~/.claude/skills/takt/pieces/default.yaml` の場合
+例: ワークフロー YAML が `~/.claude/skills/takt/workflows/default.yaml` にある場合
 - `personas.coder: ../facets/personas/coder.md` → `~/.claude/skills/takt/facets/personas/coder.md`
 - `policies.coding: ../facets/policies/coding.md` → `~/.claude/skills/takt/facets/policies/coding.md`
 - `instructions.plan: ../facets/instructions/plan.md` → `~/.claude/skills/takt/facets/instructions/plan.md`
@@ -86,7 +86,7 @@ Task tool:
 6. ナレッジ（knowledge: で参照される .md の内容）
 7. インストラクション内容（instruction: で参照される .md、または instruction_template のインライン内容）
 8. ユーザーのタスク（{task} が template に含まれない場合、末尾に自動追加）
-9. 前の movement の出力（pass_previous_response: true の場合、自動追加）
+9. 前の step の出力（pass_previous_response: true の場合、自動追加）
 10. レポート出力指示（report フィールドがある場合、自動追加）
 11. ステータスタグ出力指示（rules がある場合、自動追加）
 12. ポリシーリマインダー（ポリシーがある場合、末尾に再掲）
@@ -94,11 +94,11 @@ Task tool:
 
 ### ペルソナプロンプト
 
-movement の `persona:` キーからセクションマップを経由して .md ファイルを解決し、その全内容をプロンプトの冒頭に配置する。ペルソナはドメイン知識と行動原則のみを含む（ピース固有の手順は含まない）。
+step の `persona:` キーからセクションマップを経由して .md ファイルを解決し、その全内容をプロンプトの冒頭に配置する。ペルソナはドメイン知識と行動原則のみを含む（ワークフロー固有の手順は含まない）。
 
 ### ポリシー注入
 
-movement の `policy:` キー（単一または配列）からポリシーファイルを解決し、内容を結合する。ポリシーは行動ルール（コーディング規約、レビュー基準等）を定義する。
+step の `policy:` キー（単一または配列）からポリシーファイルを解決し、内容を結合する。ポリシーは行動ルール（コーディング規約、レビュー基準等）を定義する。
 
 **Lost in the Middle 対策**: ポリシーはプロンプトの前半に配置し、末尾にリマインダーとして再掲する。
 
@@ -115,7 +115,7 @@ movement の `policy:` キー（単一または配列）からポリシーファ
 
 ### ナレッジ注入
 
-movement の `knowledge:` キーからナレッジファイルを解決し、ドメイン固有の参考情報としてプロンプトに含める。
+step の `knowledge:` キーからナレッジファイルを解決し、ドメイン固有の参考情報としてプロンプトに含める。
 
 ```
 ## ナレッジ
@@ -124,17 +124,17 @@ movement の `knowledge:` キーからナレッジファイルを解決し、ド
 
 ### インストラクション
 
-movement の `instruction:` キーから指示テンプレートファイルを解決する。または `instruction_template:` でインライン記述。テンプレート変数（{task}, {previous_response} 等）を展開した上でプロンプトに含める。
+step の `instruction:` キーから指示テンプレートファイルを解決する。または `instruction_template:` でインライン記述。テンプレート変数（{task}, {previous_response} 等）を展開した上でプロンプトに含める。
 
 ### 実行コンテキスト情報
 
 ```
 ## 実行コンテキスト
 - ワーキングディレクトリ: {cwd}
-- ピース: {piece_name}
-- Movement: {movement_name}
+- ワークフロー (YAML の name): {workflow_name}
+- Step: {step_name}
 - イテレーション: {iteration} / {max_movements}
-- Movement イテレーション: {movement_iteration} 回目
+- Step 実行回数（テンプレート変数は {movement_iteration} のまま）: {movement_iteration} 回目
 ```
 
 ### テンプレート変数の展開
@@ -144,10 +144,10 @@ movement の `instruction:` キーから指示テンプレートファイルを
 | 変数 | 値 |
 |-----|-----|
 | `{task}` | ユーザーが入力したタスク内容 |
-| `{previous_response}` | 前の movement のチームメイト出力 |
-| `{iteration}` | ピース全体のイテレーション数（1始まり） |
-| `{max_movements}` | ピースの max_movements 値 |
-| `{movement_iteration}` | この movement が実行された回数（1始まり） |
+| `{previous_response}` | 前の step のチームメイト出力 |
+| `{iteration}` | ワークフロー全体のイテレーション数（1始まり） |
+| `{max_movements}` | ワークフローの max_movements 値 |
+| `{movement_iteration}` | この step が実行された回数（1始まり） |
 | `{report_dir}` | レポートディレクトリパス（`.takt/runs/{slug}/reports`） |
 | `{report:ファイル名}` | 指定レポートファイルの内容（Read で取得） |
 
@@ -160,11 +160,11 @@ movement の `instruction:` キーから指示テンプレートファイルを
 
 ### persona フィールドがない場合
 
-`persona:` が指定されていない movement の場合、ペルソナプロンプト部分を省略し、インストラクションの内容のみでプロンプトを構成する。
+`persona:` が指定されていない step の場合、ペルソナプロンプト部分を省略し、インストラクションの内容のみでプロンプトを構成する。
 
 ## レポート出力指示の自動注入
 
-movement に `report` フィールドがある場合、プロンプト末尾にレポート出力指示を自動追加する。
+step に `report` フィールドがある場合、プロンプト末尾にレポート出力指示を自動追加する。
 
 ### 形式1: name + format（キー参照）
 
@@ -226,7 +226,7 @@ report:
 
 ## ステータスタグ出力指示の自動注入
 
-movement に `rules` がある場合、プロンプト末尾にステータスタグ出力指示を自動追加する。
+step に `rules` がある場合、プロンプト末尾にステータスタグ出力指示を自動追加する。
 
 ### 注入する指示
 
@@ -261,7 +261,7 @@ parallel のサブステップにも同様にタグ出力指示を注入する
 
 チームメイトの出力からどの rule にマッチするかを判定する。
 
-### 通常 Movement の Rule 評価
+### 通常 step の Rule 評価
 
 判定優先順位（最初にマッチしたものを採用）:
 
@@ -275,9 +275,9 @@ parallel のサブステップにも同様にタグ出力指示を注入する
 
 タグが出力に含まれない場合、出力テキスト全体を読み、全ての condition と比較して最もマッチするものを選択する。
 
-### Parallel Movement の Rule 評価（Aggregate）
+### Parallel step の Rule 評価（Aggregate）
 
-親 movement の rules に `all()` / `any()` の aggregate 条件を使用する。
+親 step の rules に `all()` / `any()` の aggregate 条件を使用する。
 
 #### all() の評価
 
@@ -316,7 +316,7 @@ parallel のサブステップにも同様にタグ出力指示を注入する
 
 ### 基本ルール
 
-- 同じ movement が連続3回以上実行されたら警告を表示する
+- 同じ step が連続3回以上実行されたら警告を表示する
 - `max_movements` に到達したら強制終了（ABORT）する
 
 ### カウンター管理
@@ -325,13 +325,13 @@ parallel のサブステップにも同様にタグ出力指示を注入する
 
 | カウンター | 説明 | リセットタイミング |
 |-----------|------|-------------------|
-| `iteration` | ピース全体の movement 実行回数 | リセットしない |
-| `movement_iteration[name]` | 各 movement の実行回数 | リセットしない |
-| `consecutive_count[name]` | 同じ movement の連続実行回数 | 別の movement に遷移したとき |
+| `iteration` | ワークフロー全体の step 実行回数 | リセットしない |
+| `movement_iteration[name]` | 各 step の実行回数 | リセットしない |
+| `consecutive_count[name]` | 同じ step の連続実行回数 | 別の step に遷移したとき |
 
 ## Loop Monitors
 
-ピースに `loop_monitors` が定義されている場合、特定の movement サイクルを監視する。
+ワークフローに `loop_monitors` が定義されている場合、特定の step 間サイクルを監視する。
 
 ### 動作
 
@@ -352,7 +352,7 @@ loop_monitors:
 
 ### 検出ロジック
 
-1. movement 遷移履歴を記録する（例: `[plan, implement, ai_review, ai_fix, ai_review, ai_fix, ...]`）
+1. step 遷移履歴を記録する（例: `[plan, implement, ai_review, ai_fix, ai_review, ai_fix, ...]`）
 2. 各 loop_monitor の `cycle` パターンが履歴の末尾に `threshold` 回以上連続で出現するかチェックする
 3. 閾値に達した場合:
    a. judge の `persona` キーからペルソナファイルを Read で読み込む
@@ -365,7 +365,7 @@ loop_monitors:
 
 ### 実行ディレクトリの作成
 
-ピース実行開始時に実行ディレクトリを作成する:
+ワークフロー実行開始時に実行ディレクトリを作成する:
 
 ```
 .takt/runs/{YYYYMMDD-HHmmss}-{slug}/
@@ -378,7 +378,7 @@ loop_monitors:
   meta.json
 ```
 
-このうち `reports/` のパスを `{report_dir}` 変数として全 movement から参照可能にする。
+このうち `reports/` のパスを `{report_dir}` 変数として全 step から参照可能にする。
 
 ### レポートの保存
 
@@ -391,20 +391,20 @@ loop_monitors:
 
 ### レポートの参照
 
-後続の movement のインストラクション内で `{report:ファイル名}` として参照すると、そのレポートファイルを Read して内容をプレースホルダーに展開する。
+後続の step のインストラクション内で `{report:ファイル名}` として参照すると、そのレポートファイルを Read して内容をプレースホルダーに展開する。
 
 ## 状態遷移の全体像
 
 ```
 [開始]
   ↓
-ピースYAML読み込み + セクションマップ解決（personas, policies, instructions, output_contracts, knowledge）
+ワークフローYAML読み込み + セクションマップ解決（personas, policies, instructions, output_contracts, knowledge）
   ↓
 TeamCreate でチーム作成
   ↓
 実行ディレクトリ作成
   ↓
-initial_movement を取得
+initial_step を取得（YAML が `initial_movement` のみの場合はそれを使う）
   ↓
 ┌─→ Task tool でチームメイト起動
 │     ├── 通常: 1つの Task tool 呼び出し
@@ -428,7 +428,7 @@ initial_movement を取得
 │   next を決定
 │     ├── COMPLETE → TeamDelete → ユーザーに結果報告
 │     ├── ABORT → TeamDelete → ユーザーにエラー報告
-│     └── movement名 → ループ検出チェック → 次の movement
+│     └── step名 → ループ検出チェック → 次の step
 │                                              ↓
 └──────────────────────────────────────────────┘
 ```

package/builtins/skill/references/yaml-schema.md

@@ -1,14 +1,20 @@
-# ピースYAML スキーマリファレンス
+# ワークフローYAML スキーマリファレンス
 
-このドキュメントはピースYAMLの構造を定義する。具体的なピース定義は含まない。
+このドキュメントは workflow YAML（旧称ピースYAML）の構造を定義する。具体的な workflow 定義は含まない。
 
 ## トップレベルフィールド
 
 ```yaml
-name: piece-name              # ピース名（必須）
-description: 説明テキスト      # ピースの説明（任意）
-max_movements: 10            # 最大イテレーション数（必須）
-initial_movement: plan        # 最初に実行する movement 名（必須）
+name: workflow-name           # workflow 名（必須）。カテゴリの workflow_categories 下の workflows でもこの名前を使う（互換: piece_categories / pieces）
+description: 説明テキスト      # 任意
+max_movements: 10            # 最大イテレーション数（省略時デフォルトあり）
+initial_step: plan            # 最初に実行する step 名（省略時は steps の先頭）
+
+# ワークフロー全体の provider / runtime 等
+workflow_config:
+  provider_options:
+    codex:
+      network_access: true
 
 # セクションマップ（キー → ファイルパスの対応表）
 policies:                     # ポリシー定義（任意）
@@ -26,25 +32,27 @@ report_formats:               # レポートフォーマット定義（任意）
 knowledge:                    # ナレッジ定義（任意）
   architecture: ../knowledge/architecture.md
 
-movements: [...]              # movement 定義の配列（必須）
-loop_monitors: [...]          # ループ監視設定（任意）
+steps: [...]                  # step 定義の配列（推奨キー名）
+loop_monitors: [...]          # ループ監視設定（任意）。cycle には step 名を並べる
 ```
 
+**互換 alias:** `movements` は `steps` と同義（両方書く場合は内容が一致している必要がある）。`initial_movement` は `initial_step` と同義（両方書く場合は同じ名前である必要がある）。
+
 ### セクションマップの解決
 
-各セクションマップのパスは **ピースYAMLファイルのディレクトリからの相対パス** で解決する。
-movement 内では**キー名**で参照する（パスを直接書かない）。
+各セクションマップのパスは **workflow YAML ファイルのディレクトリからの相対パス** で解決する。
+step 定義内では**キー名**で参照する（パスを直接書かない）。
 
-例: ピースが `~/.claude/skills/takt/pieces/coding.yaml` にあり、`personas:` セクションに `coder: ../personas/coder.md` がある場合
-→ 絶対パスは `~/.claude/skills/takt/personas/coder.md`
-→ movement では `persona: coder` で参照
+例: workflow が `{スキルルート}/workflows/coding.yaml` にあり、`personas:` セクションに `coder: ../personas/coder.md` がある場合
+→ 絶対パスは `{スキルルート}/personas/coder.md`（`スキルルート` は Claude Code では `~/.claude/skills/takt`、Codex では `~/.agents/skills/takt` など、インストール先に応じて置き換える）
+→ step では `persona: coder` で参照
 
-## Movement 定義
+## Step 定義（`steps` の各要素）
 
-### 通常 Movement
+### 通常の step
 
 ```yaml
-- name: movement-name          # movement 名（必須、一意）
+- name: step-name              # step 名（必須、workflow 内で一意）
   persona: coder               # ペルソナキー（personas マップを参照、任意）
   policy: coding               # ポリシーキー（policies マップを参照、任意）
   instruction: implement       # 指示（instructions マップのキー参照、またはインライン、任意）
@@ -62,32 +70,32 @@ movement 内では**キー名**で参照する（パスを直接書かない）
 複数ポリシー指定（配列）:
 
 ```yaml
-- name: movement-name
+- name: step-name
   policy: [coding, testing]
 ```
 
 参照形式:
 
 ```yaml
-- name: movement-name
+- name: step-name
   instruction: implement
 ```
 
 インライン形式:
 
 ```yaml
-- name: movement-name
+- name: step-name
   instruction: |
     指示内容...
 ```
 
 **`instruction`（正式） / `instruction_template`（deprecated）**: どちらも同じ参照解決ルート（セクションマップ → パス → 3-layer facet → インライン）を使う。`instruction_template` も互換のため受理されるが、新規定義では `instruction` を使う。
 
-### Parallel Movement
+### Parallel step（親 + `parallel`）
 
 ```yaml
-- name: reviewers              # 親 movement 名（必須）
-  parallel:                    # 並列サブステップ配列（これがあると parallel movement）
+- name: reviewers              # 親 step 名（必須）
+  parallel:                    # 並列サブステップ配列（これがあると parallel step）
     - name: arch-review
       persona: architecture-reviewer
       policy: review
@@ -125,7 +133,7 @@ movement 内では**キー名**で参照する（パスを直接書かない）
 ```yaml
 rules:
   - condition: 条件テキスト      # マッチ条件（必須）
-    next: next-movement         # 遷移先 movement 名（必須、サブステップでは任意）
+    next: next-step             # 遷移先 step 名（必須、parallel 子では任意）
     requires_user_input: true   # ユーザー入力が必要（任意）
     interactive_only: true      # インタラクティブモードのみ（任意）
     appendix: |                 # 追加情報（任意）
@@ -146,13 +154,13 @@ rules:
 
 | 値 | 意味 |
 |---|------|
-| `COMPLETE` | ピース成功終了 |
-| `ABORT` | ピース失敗終了 |
-| movement 名 | 指定された movement に遷移 |
+| `COMPLETE` | workflow 成功終了 |
+| `ABORT` | workflow 失敗終了 |
+| step 名 | 指定された step に遷移 |
 
 ## Output Contracts 定義
 
-Movement の出力契約（レポート定義）。`output_contracts.report` 配列形式で指定する。
+Step の出力契約（レポート定義）。`output_contracts.report` 配列形式で指定する。
 
 ### 形式1: name + format（フォーマット参照）
 
@@ -191,7 +199,7 @@ output_contracts:
 
 ## Quality Gates 定義
 
-Movement 完了時の品質要件を AI への指示として定義する。自動検証は行わない。
+Step 完了時の品質要件を AI への指示として定義する。自動検証は行わない。
 
 ```yaml
 quality_gates:
@@ -200,7 +208,7 @@ quality_gates:
   - ESLint 違反がないこと
 ```
 
-配列で複数の品質基準を指定できる。エージェントはこれらの基準を満たしてから Movement を完了する必要がある。
+配列で複数の品質基準を指定できる。エージェントはこれらの基準を満たしてから step を完了する必要がある。
 
 ## テンプレート変数
 
@@ -209,10 +217,10 @@ quality_gates:
 | 変数 | 説明 |
 |-----|------|
 | `{task}` | ユーザーのタスク入力（template に含まれない場合は自動追加） |
-| `{previous_response}` | 前の movement の出力（pass_previous_response: true 時、自動追加） |
-| `{iteration}` | ピース全体のイテレーション数 |
-| `{max_movements}` | 最大イテレーション数 |
-| `{movement_iteration}` | この movement の実行回数 |
+| `{previous_response}` | 前の step の出力（pass_previous_response: true 時、自動追加） |
+| `{iteration}` | workflow 全体のイテレーション数 |
+| `{max_movements}` | 最大イテレーション数（テンプレート変数名は従来どおり） |
+| `{movement_iteration}` | この step の実行回数（テンプレート変数名は従来どおり） |
 | `{report_dir}` | レポートディレクトリ名 |
 | `{report:ファイル名}` | 指定レポートファイルの内容を展開 |
 | `{user_inputs}` | 蓄積されたユーザー入力 |
@@ -222,7 +230,7 @@ quality_gates:
 
 ```yaml
 loop_monitors:
-  - cycle: [movement_a, movement_b]   # 監視対象の movement サイクル
+  - cycle: [step_a, step_b]           # 監視対象の step 名のサイクル
     threshold: 3                       # 発動閾値（サイクル回数）
     judge:
       persona: supervisor              # ペルソナキー参照
@@ -231,13 +239,13 @@ loop_monitors:
         健全性を判断してください。
       rules:
         - condition: 健全（進捗あり）
-          next: movement_a
+          next: step_a
         - condition: 非生産的（改善なし）
-          next: alternative_movement
+          next: alternative_step
 ```
 
-特定の movement 間のサイクルが閾値に達した場合、judge が介入して遷移先を判断する。
+特定の step 間のサイクルが閾値に達した場合、judge が介入して遷移先を判断する。
 
 ## allowed_tools について
 
-`allowed_tools` は TAKT 本体のエージェントプロバイダーで使用されるフィールド。Claude Code の Skill として実行する場合、Task tool のエージェントが使用可能なツールは Claude Code の設定に従う。このフィールドは参考情報として扱い、`edit` フィールドの方を権限制御に使用する。
+`allowed_tools` は TAKT 本体のエージェントプロバイダーで使用されるフィールド。Skill 経由で実行する場合、実際に利用可能なツールはホスト側の設定（Claude Code の Task tool 設定や Codex のサンドボックス設定など）に従う。このフィールドは参考情報として扱い、`edit` フィールドの方を権限制御に使用する。