一键导入
takt
TAKT ワークフローエンジン。Agent Team を使ったマルチエージェントオーケストレーション。ワークフロー YAML(steps / initial_step)に従ってマルチエージェントを実行する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
TAKT ワークフローエンジン。Agent Team を使ったマルチエージェントオーケストレーション。ワークフロー YAML(steps / initial_step)に従ってマルチエージェントを実行する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Kiro / SDD の新規 spec 作成、kiro-discovery、kiro-spec-init、要件化、 仕様化、feature brief 作成に進む前に使う入口スキル。ユーザーの要求を そのまま kiro-* 系スキルへ渡さず、先に grill-with-docs で用語・境界・ 不可逆な設計判断を詰め、必要に応じて CONTEXT.md と docs/adr/* に残してから kiro-discovery または kiro-spec-init へつなぐ。新しい作業の相談、曖昧な feature idea、Kiro spec の起票、requirements 化の依頼では、ユーザーが 明示的に grilling を省略すると言わない限りこのスキルを使うこと。既存 spec の status 確認、requirements/design/tasks/impl の継続、単純な実装、 既に十分な brief.md がある作業では使わなくてよい。
Kiro / SDD の spec から未登録のユビキタス言語、canonical term、 avoid term、不変条件、境界名、契約名、ADR 候補となる仕様変更を検出し、 domain-modeling / grill-with-docs で確定してから CONTEXT.md と docs/adr/* に反映するスキル。ユーザーが「.kiro/specs を見て未定義語を拾って」、 「Kiro spec から CONTEXT.md を更新して」、「spec の仕様変更を ADR に反映」、 「glossary gap を埋めて」、「ユビキタス言語を逆引きして」などを依頼した 場合に使う。単なる spec status 確認、requirements/design/tasks の生成、 実装、または Kiro に渡す前の要求整理には使わない。
既存のTAKTワークフローとファセットを分析し、改善提案を行うスキル。ワークフローYAMLの構造検証、 ファセット間の整合性チェック、スタイルガイド準拠の確認、未使用ファセットの検出、 ルール設計の最適化提案を実施する。実行ログ(.takt/logs/*.jsonl)が存在する場合は ログベース診断分析も行い、ルール評価効率・ループホットスポット・ABORT率等を報告する。 references/taktのスタイルガイド・エンジン仕様を基準として分析する。 トリガー:「ワークフローを分析」「taktの設定を確認」「ファセットの品質チェック」 「ワークフローのレビュー」「takt analyze」「ワークフローの改善提案」 「ワークフローの整合性チェック」「taktの問題を見つけて」 「ログを分析」「実行ログの診断」「taktのログを見て」「ルール評価の統計」 「ai_fallbackの頻度」「ループの検出」
TAKTファセット(Persona/Policy/Instruction/Knowledge/Output Contract)の 個別作成・編集スキル。各ファセットのスタイルガイドに準拠した単体ファイルを生成する。 references/taktにあるスタイルガイド・ビルトインファセット群を参照資料として活用し、 ファセット種別の判断、テンプレート選択、品質チェックを行う。 トリガー:「ペルソナを作りたい」「ポリシーを追加」「インストラクションを書く」 「ナレッジを定義」「出力契約を作成」「ファセットを編集」「takt facet」 「レビュアーのペルソナ」「コーディングポリシー」
既存のTAKTワークフロー(ワークフローYAML・ファセット群)を最適化するスキル。 トークン消費削減、ステップ統合、ルール簡素化、ファセット再利用促進、 ループ制御の改善、並列化の提案を実施し、最適化後のファイルを直接生成する。 takt-analyzeの診断結果(静的分析・ログ診断)を入力として活用できる。 本スキルは「最適化の実行」のみを担い、診断・分析はtakt-analyzeに委譲する。 references/taktのエンジン仕様・スタイルガイドを基準とする。 トリガー:「ワークフローを最適化」「taktの高速化」「ワークフローを軽くしたい」 「トークンを減らしたい」「ステップを減らしたい」「takt optimize」 「ワークフローの効率化」「ファセットを整理したい」「ワークフローをスリムにして」 「taktのコスト削減」「ワークフローをシンプルにしたい」
references/taktサブモジュール更新時に、takt-*スキル群(takt-task-builder, takt-workflow-builder, takt-facet-builder, takt-analyzer, takt-optimizer)を最新のtaktバージョンに追従させるスキル。 TypeScriptスキーマ(taskRecordSchemas.ts / taskExecutionSchemas.ts)、ワークフローYAML、ファセットMarkdownの差分を検出し、 SKILL.md・参照ドキュメント(task-schema.md等)を体系的に更新する。 トリガー:「taktスキルを更新」「takt-*スキルの鮮度チェック」「taktバージョンアップ対応」 「スキルが古くないか確認」「takt skill updater」
| 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 の構造定義とフィールド説明 |