Menu
TAKT ワークフローエンジン。Agent Team を使ったマルチエージェントオーケストレーション。ワークフロー YAML（steps / initial_step）に従ってマルチエージェントを実行する。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | takt |
| description | TAKT ワークフローエンジン。Agent Team を使ったマルチエージェントオーケストレーション。ワークフロー YAML（steps / initial_step）に従ってマルチエージェントを実行する。 |
| user-invocable | true |
$ARGUMENTS を以下のように解析する:
/takt {workflow} [permission] {task...}
--permit-full — 全権限付与（mode: "bypassPermissions"）--permit-edit — 編集許可（mode: "acceptEdits"）"default"（権限確認あり）例:
/takt coding FizzBuzzを作って → coding ワークフロー、default 権限/takt coding --permit-full FizzBuzzを作って → coding ワークフロー、bypassPermissions/takt /path/to/custom.yaml 実装して → カスタムYAML、default 権限手順を開始する前に、以下の2ファイルを Read tool で読み込む:
~/.claude/skills/takt/references/engine.md - プロンプト構築、レポート管理、ループ検出の詳細~/.claude/skills/takt/references/yaml-schema.md - ワークフロー YAML の構造定義あなたは Team Lead（オーケストレーター） である。 ワークフロー YAML に定義された状態遷移に従って Agent Team を率いる。
initial_step から開始し、Rule 評価で決まった次の step に進む重要: ユーザーが明示的に指示するまで git commit を実行してはならない。実装完了 ≠ コミット許可。
| やること | 使うツール | 説明 |
|---|---|---|
| チーム作成 | TeamCreate tool | 最初に1回だけ呼ぶ |
| チーム解散 | TeamDelete tool | 最後に1回だけ呼ぶ |
| チームメイト起動 | Task tool (team_name 付き) | step ごとに呼ぶ。結果は同期的に返る |
TeamCreate / TeamDelete でチームメイトを個別に起動することはできない。 チームメイトの起動は必ず Task tool を使う。 Task tool は同期的に結果を返す。 TaskOutput やポーリングは不要。呼べば結果が返ってくる。
引数の第1トークンからワークフロー YAML ファイルを特定して Read で読む。
第1トークンがない場合（ワークフロー名未指定）:
→ ユーザーに「ワークフロー名を指定してください。例: /takt coding タスク内容」と伝えて終了する。
ワークフロー YAML の検索順序:
.yaml / .yml で終わる、または / を含む → ファイルパスとして直接 Read~/.takt/workflows/{name}.yaml （ユーザーカスタム、優先）~/.claude/skills/takt/workflows/{name}.yaml （Skill 同梱ビルトイン）YAML から以下を抽出する（→ references/yaml-schema.md 参照）:
name, max_steps, initial_step, steps 配列workflow_config（ワークフロー全体の provider / runtime 等）personas, policies, instructions, output_contracts, knowledgeワークフロー YAML のセクションマップ（personas:, policies:, instructions:, output_contracts:, knowledge:）から全ファイルパスを収集する。
パスは ワークフロー YAML ファイルのディレクトリからの相対パス で解決する。
例: ワークフローが ~/.claude/skills/takt/workflows/default.yaml にあり、personas: に coder: ../facets/personas/coder.md がある場合
→ 絶対パスは ~/.claude/skills/takt/facets/personas/coder.md
重複を除いて Read で全て読み込む。読み込んだ内容はチームメイトへのプロンプト構築に使う。
今すぐ TeamCreate tool を呼べ:
TeamCreate tool を呼ぶ:
team_name: "takt"
description: "TAKT {workflow_name} ワークフロー"
initial_step（なければ steps の先頭）の名前を確認し、steps から該当する step 定義を取得する。
以下の変数を初期化する:
iteration = 1current_step = 上記 initial の step 定義previous_response = ""permission_mode = コマンドで解析された権限モード（"bypassPermissions" / "acceptEdits" / "default"）step_history = []（遷移履歴。Loop Monitor 用）実行ディレクトリ: いずれかの step に report フィールドがある場合、.takt/runs/{YYYYMMDD-HHmmss}-{slug}/ を作成し、以下を配置する。
reports/（レポート出力）context/knowledge/（Knowledge スナップショット）context/policy/（Policy スナップショット）context/previous_responses/（Previous Response 履歴 + latest.md）logs/（実行ログ）meta.json（run メタデータ）レポート出力先パスを report_dir 変数（.takt/runs/{slug}/reports）として保持する。
次に 手順 5 に進む。
iteration が max_steps を超えていたら → 手順 8（ABORT: イテレーション上限）に進む。
current_step のプロンプトを構築する（→ references/engine.md のプロンプト構築を参照）。
プロンプト構築の要素:
persona: キー → personas: セクション → .md ファイル内容policy: キー → policies: セクション → .md ファイル内容（複数可、末尾にリマインダー再掲）knowledge: キー → knowledge: セクション → .md ファイル内容instruction: キー → instructions: セクション → .md ファイル内容（テンプレート変数展開済み）通常 step の場合（parallel フィールドなし）:
Task tool を1つ呼ぶ。Task tool は同期的に結果を返す。待機やポーリングは不要。
Task tool を呼ぶ:
prompt: <構築したプロンプト全文>
description: "{step_name} - {workflow_name}"
subagent_type: "general-purpose"
team_name: "takt"
name: "{step の name}"
mode: permission_mode
Task tool の戻り値がチームメイトの出力。手順 5a に進む。
parallel step の場合:
1つのメッセージで、parallel 配列の各サブステップに対して Task tool を並列に呼ぶ。 全ての Task tool が結果を返したら 手順 5a に進む。
// サブステップの数だけ Task tool を同時に呼ぶ（例: 2つの場合）
Task tool を呼ぶ（1つ目）:
prompt: <サブステップ1用プロンプト>
description: "{サブステップ1名} - {workflow_name}"
subagent_type: "general-purpose"
team_name: "takt"
name: "{サブステップ1の name}"
mode: permission_mode
Task tool を呼ぶ（2つ目）:
prompt: <サブステップ2用プロンプト>
description: "{サブステップ2名} - {workflow_name}"
subagent_type: "general-purpose"
team_name: "takt"
name: "{サブステップ2の name}"
mode: permission_mode
レポート抽出（current_step に report フィールドがある場合のみ）:
チームメイト出力から ```markdown ブロックを抽出し、Write tool で {report_dir}/{ファイル名} に保存する。
詳細は references/engine.md の「レポートの抽出と保存」を参照。
Loop Monitor チェック（ワークフローに loop_monitors がある場合のみ）:
step_history に current_step の名前を追加する。
遷移履歴が loop_monitor の cycle パターンに threshold 回以上マッチした場合、judge チームメイトを起動して遷移先をオーバーライドする。
詳細は references/engine.md の「Loop Monitors」を参照。
Task tool から返ってきたチームメイトの出力から matched_rule を決定する。
通常 step:
[STEP:N] タグがあるか探す（複数ある場合は最後のタグを採用）parallel step:
all("X"): 全サブステップが "X" にマッチしたら trueany("X"): いずれかのサブステップが "X" にマッチしたら trueall("X", "Y"): サブステップ1が "X"、サブステップ2が "Y" にマッチしたら truematched_rule が決まったら 手順 7 に進む。 どの rule にもマッチしなかったら → 手順 8（ABORT: ルール不一致） に進む。
matched_rule の next を確認する:
next が "COMPLETE" → 手順 8（COMPLETE） に進むnext が "ABORT" → 手順 8（ABORT） に進むnext が step 名 → 以下を実行して 手順 5 に戻る:
previous_response = 直前のチームメイト出力current_step = next で指定された step を steps（互換: steps）配列から取得iteration を +1 するTeamDelete tool を呼ぶ
| ファイル | 内容 |
|---|---|
references/engine.md | プロンプト構築、レポート管理、ループ検出の詳細 |
references/yaml-schema.md | ワークフロー YAML の構造定義とフィールド説明 |
Create or improve Claude Code and Codex skills. Use only when the request is explicitly about the skill itself: creating a new skill, editing a SKILL.md file, testing a skill draft in .claude/skills/.../SKILL.md or .agents/skills/.../SKILL.md, improving an existing skill, debugging why a skill is not triggering, running evals or benchmarks for a skill, or turning an already-described workflow into a reusable skill. Trigger on phrases like existing skill, skill draft, SKILL.md, skill trigger, skill eval, make this into a skill, or turn this workflow into a skill. Do not use for ordinary implementation work unless the user explicitly mentions a skill, SKILL.md, or converting the task into a skill. That exclusion includes generic coding tasks, generic automation/workflow setup, CI setup, GitHub Actions workflows, debugging, code review, database migrations, schema changes, and production incident response when the user is just asking for help with the task itself.
Use when designing or reviewing domain-model accessors that expose internal state for persistence, serialization, tests, or framework integration. Applies the breachEncapsulationOf naming pattern so unavoidable getters are visibly treated as encapsulation breaches, not casual domain APIs. Trigger for getter naming conventions, persistence-only getters, serialization accessors, Tell Don't Ask pressure, or requests to prevent getter misuse.
Use only when the user explicitly asks for Clean Architecture design, implementation, or review. Applies a domain, use case, interface adapter, and infrastructure layer model, with persistence and RPC adapters outside the domain and use-case rules. Do not trigger for generic architecture advice, hexagonal architecture, onion architecture, or ordinary design review unless Clean Architecture is named.
Use when CQRS changes aggregate boundaries or state shape. Helps reduce oversized command aggregates by moving read concerns to read models, keeping only command-decision state in aggregates, and using events for state transitions. Trigger for large aggregates, heavy command updates, aggregates containing query-only data, or boundary redesign during CQRS adoption.
Use when explaining why CQRS often needs event sourcing or durable events for reliable command-to-query synchronization. Covers calculated value sync, database trigger limits, polling scalability, double commits, and making events the source of truth. Trigger for CQRS synchronization, read-model update strategy, CQRS without ES, or double-commit concerns.
Use when evaluating whether CQRS is worth adopting, especially tradeoffs among consistency, availability, scalability, operational complexity, and event sourcing. Trigger for read/write separation decisions, eventual consistency concerns, CQRS architecture review, or choosing between a unified model and CQRS.