| English | 日本語 | 简体中文 |
TAKT は複数のタスクを蓄積してバッチ実行するためのタスク管理ワークフローを提供します。基本的な流れは次の通りです。
takt add – AI との会話でタスク要件を精緻化し、.takt/tasks.yaml に保存order.md ファイルを編集し、参考資料を添付takt run – すべての pending タスクを一括実行（逐次または並列）takt list – 結果を確認し、ブランチのマージ、失敗のリトライ、指示の追加各タスクは隔離クローン（オプション）で実行され、レポートを生成し、takt list でマージまたは破棄できるブランチを作成します。
takt add）takt add を使用して .takt/tasks.yaml に新しいタスクエントリを作成します。
# インラインテキストでタスクを追加
takt add "Implement user authentication"
# GitHub Issue からタスクを追加
takt add '#28'
takt add --issue 28
タスク追加時に次の項目を確認されます。
main/master 以外の場合、それを base branch として使うかどうかtakt/{timestamp}-{slug} が自動生成）Create as draft?）Issue 参照（例: #28）を渡すと、TAKT は GitHub CLI（gh）を介して Issue のタイトル、本文、ラベル、コメントを取得し、タスク内容として使用します。Issue 番号は tasks.yaml に記録され、ブランチ名にも反映されます。
要件: GitHub CLI（gh）がインストールされ、認証済みである必要があります。
takt add --pr N、takt add --issue N（takt add '#N'も同じ経路）は、PR本文、conversationコメント、review summary、review threadコメント、Issue本文・コメントにあるMarkdown画像構文とHTMLの<img src>からGitHub添付画像を取得します。pipelineでも--pr Nと--issue Nに対応します。
成功した画像は.takt/tasks/<slug>/attachments/image-N.pngなどへ保存されます。同じURLは1ファイルにまとめられ、取得・保存に成功した画像の初出順に欠番のない番号が付きます。本文の元構文を残し、その直後に[Image #N]を補足します。order.mdの末尾には既存の## 添付画像形式でファイル一覧が追記されます。
実行時は実行先の.takt/runs/<run-slug>/context/task/attachments/へコピーされ、同じディレクトリのorder.mdから参照できます。pipelineの一時task specは実行後に削除されますが、run内の画像と指示書は残ります。
対応形式はPNG、JPEG、GIF、WebPで、画像ごとの上限は10 MiBです。Content-Typeとmagic bytesを検証し、GitHub添付以外の外部画像、コード例、HTMLコメント内の画像は取得しません。認証不可、404、通信エラー、サイズ超過、形式不一致などは画像単位で警告してスキップし、タスク登録・pipeline実行を続行します。失敗した参照には補足を付けません。
認証済みghの資格情報を使った取得を優先します。privateリポジトリの添付はトークン認証だけでは取得できない環境があり、成功は保証されません。ブラウザCookieによる取得は行いません。GitLab添付と通常のテキスト入力は自動取得の対象外です。
インタラクティブモードからもタスクを保存できます。会話で要件を整理した後に /go を使い、指示書プレビューを確認して「タスクにつむ」を選ぶと tasks.yaml に保存されます。
Issue #Nの読み込みは会話の文脈を提供します。/go は最新のタスクがそのIssueの作業かを毎回判断します。関連する指示書にはタスク見出し直後の独立した行に Issue: #N が表示され、この紐付けがあるときだけ実行・タスク保存・Issue作成へNを渡します。保存タスクの issue、生成ブランチの takt/N/{slug}、PR本文の Closes #N に同じ番号が使われます。無関係な指示書には紐付けを付けません。誤っている場合は「会話を続ける」で修正できます。/issue 後は差し替えた文脈で判断し直します。「Issueを建てる」で新しいIssue Mを作成しても、Nへの紐付けがあれば保存対象はNのままで、NへMのリンクをコメントします。紐付けがなければ新規作成したMを保存対象にします。
CLI・TUI・MCPから登録する場合は、同じIssue・PR・ブランチのpending・runningタスクがあっても追加の警告や確認なしで登録できます。ワークフロー内の自動投入だけが保存ロック内で同一対象の重複を拒否します。直接の takt add '#N' は従来どおりNを保存し、指示書の紐付け行を必要としません。
生成ブランチ名はローカルref、remote-tracking ref、未取得ブランチを含む設定済みの全remoteへ照会し、別タスククローンの所有メタデータも確認します。衝突したら -2、-3 などの候補も確認し、baseから新しいブランチを作成します。所有情報の保存が競合した場合も既存情報を上書きせず、新しいクローンのブランチを別名へ変更して保存します。照会や保存に失敗した場合は作成を中止します。明示指定した名前は従来のfetch・再利用処理で使用します。
通常のインタラクティブモードでは、「タスクにつむ」を選んだ後の worktree 設定質問で Esc を押すと、その保存を中断して行動選択メニューへ戻ります。確定済みの指示書本文と添付は同じ会話に保持されます。再度「タスクにつむ」を選ぶと質問の先頭から始まり、前回の途中回答は使われません。
MCP client は takt-mcp stdio server を使って、shell command を直接呼ばずに pending タスクを保存し、task/run 状態を確認し、実行中 worktree clone へ追加指示を送れます。takt_enqueue_task は .takt/tasks.yaml に pending レコードを書き込み、takt_list_tasks は要約、takt_get_run は1つの run の詳細、takt_tell_run は再確認後に実行中 clone への書き込みを行います。Issue 作成後に保存が失敗し、Issue 番号まで解決済みなら、Issue は open のまま残り、MCP error result は再試行用の番号を返します。番号抽出に失敗した場合は代わりに Issue URL を返すことがあります。tool は server が許可した project root 内の絶対パス cwd を必須とし、enqueue と tell には空でない本文も必要です。pending タスクの実行には takt run、継続監視と実行には takt watch を使用してください。設定方法と tool 入力の詳細は CLI リファレンス を参照してください。
通常の assistant 会話には、MCP 対応 provider の場合だけ読み取り専用の task 状態 tool が渡されます。新しいタスクには /go、実行中 worktree clone への追加指示には /tell で対象を選び、内容を確認してから送ります。failed タスクの再投入には /requeue または /retry を使用できます。MCP 非対応 provider でも会話は利用できますが、task 状態の参照はできません。
TAKT はタスクのメタデータを .takt/tasks.yaml に、各タスクの詳細仕様を .takt/tasks/{slug}/ に保存します。
tasks.yaml スキーマtasks:
- name: add-auth-feature
status: pending
task_dir: .takt/tasks/20260201-015714-implement-user-authentication
workflow: default
created_at: "2026-02-01T01:57:14.000Z"
started_at: null
completed_at: null
フィールドの説明は次の通りです。
| フィールド | 説明 |
|---|---|
name |
AI が生成したタスクスラグ |
status |
pending、running、completed、failed、exceeded、または pr_failed（workflow は成功したが PR 作成/push に失敗） |
task_dir |
order.md を含むタスクディレクトリのパス |
workflow |
実行に使用する workflow 名 |
worktree |
true（自動）、パス文字列、または省略（カレントディレクトリで実行） |
branch |
ブランチ名（省略時は自動生成） |
base_branch |
クローンと PR の base branch（takt add で選択した場合に設定） |
auto_pr |
実行後に PR を自動作成するかどうか |
draft_pr |
自動作成する PR を draft にするかどうか |
issue |
設定済み issue provider の Issue 番号（該当する場合） |
run_slug |
.takt/runs/ 配下の最新実行ディレクトリのスラグ |
failure |
失敗タスクに記録される失敗詳細（step、error、last_message） |
created_at |
ISO 8601 タイムスタンプ |
started_at |
ISO 8601 タイムスタンプ（実行開始時に設定） |
completed_at |
ISO 8601 タイムスタンプ（実行完了時に設定） |
tasks.yaml には上記のほかに、TAKT が内部管理用に使用するフィールド（slug、source_run_slug、resume_mode、owner_pid、auto_requeue_count、exceeded_* など）が記録されることがあります。
.takt/
tasks/
20260201-015714-implement-user-authentication/
order.md # タスク仕様（自動生成、編集可能）
schema.sql # 添付の参考資料（任意）
wireframe.png # 添付の参考資料（任意）
tasks.yaml # タスクメタデータレコード
runs/
20260201-020152-implement-user-authentication-x7k2pq/
reports/ # 実行レポート（自動生成）
logs/ # NDJSON セッションログ
context/ # スナップショット（previous_responses など）
operations/ # オペレーションジャーナル（journal.json）
meta.json # 実行メタデータ
run ディレクトリのスラグは実行ごとにランダムな6文字のサフィックスを付けて別採番されるため、タスクディレクトリのスラグとは一致しません。タスクの run ディレクトリを探すにはtasks.yaml の run_slug フィールドか .takt/runs/ 配下の最新ディレクトリを確認してください。
takt add は .takt/tasks/{slug}/order.md を自動作成し、task_dir への参照を tasks.yaml に保存します。実行前に order.md を自由に編集したり、タスクディレクトリに補足ファイル（SQL スキーマ、ワイヤーフレーム、API 仕様など）を追加したりできます。
takt run）.takt/tasks.yaml のすべての pending タスクを実行します。
takt run
# workflow の max_steps を無視して別の停止条件まで継続
takt run --ignore-exceed
run コマンドは pending タスクを取得して、設定された workflow を通じて実行します。各タスクは次の処理を経ます。
worktree が設定されている場合）auto_pr 設定時は PR 作成）tasks.yaml のステータス更新（completed、failed、または exceeded）workflow が max_steps に到達した場合、通常の takt run はタスクを exceeded として停止し、exceeded_max_steps、exceeded_current_iteration、resume_point などの再実行メタデータを保存します。--ignore-exceed を付けると、この iteration limit だけを無視して workflow を継続し、exceeded 用の再実行メタデータは保存しません。
MCP client はタスクの enqueue、task/run 状態の確認、実行中 clone への追加指示を行えます。pending タスクの実行には takt run、継続監視と実行には takt watch を使用してください。
takt run と takt watch は同じワーカープールを使用し、デフォルトでは逐次実行します（concurrency: 1）。~/.takt/config.yaml で並列実行を設定できます。
concurrency: 3 # takt run / takt watch の同時実行数（1-10）
task_poll_interval_ms: 500 # takt run / takt watch のポーリング間隔（100-5000ms）
concurrency が 1 より大きい場合、TAKT はワーカープールを使用して次のように動作します。
takt run が中断された場合（プロセスクラッシュ、Ctrl+C など）、running ステータスのまま残ったタスクは次回の takt run または takt watch 起動時に自動的に failed にマークされます。再実行する場合は明示的に requeue してください。
設定で auto_requeue_max_attempts を指定すると、takt run / takt watch は起動時に一度だけ適格な failed タスクを再投入し、実行中の失敗も保存済み回数の上限まで再投入します。watch の常駐中は起動時の一括処理を繰り返さず、SIGINT 後は claim・再投入を行いません。両コマンドとも入力待ち中は claim を抑止します。デフォルトは 0（手動 requeue のみ）です。詳細は設定ガイドを参照してください。
takt watch）.takt/tasks.yaml を監視し、タスクが追加されると自動実行する常駐プロセスを起動します。
takt watch
# workflow の max_steps を無視して別の停止条件まで継続
takt watch --ignore-exceed
watch コマンドの動作は次の通りです。
tasks.yaml の新しい pending タスクを監視concurrency を上限として実行task_poll_interval_ms（既定500ms）で待機を継続running タスクを failed にマークこれは「プロデューサー-コンシューマー」ワークフローに便利です。一方のターミナルで takt add でタスクを追加し、もう一方で takt watch がそれらを自動実行します。
takt list）タスクブランチの一覧表示とインタラクティブな管理を行います。
takt list
リストビューではすべてのタスクがステータス別（pending、running、completed、failed、exceeded、pr_failed）に作成日とサマリ付きで表示されます。タスクを選択すると、そのステータスに応じた操作が表示されます。一覧の最下部にはすべてのタスクを一括削除する All Delete も表示されます。
| 操作 | 説明 |
|---|---|
| View diff | デフォルトブランチとの差分をページャで表示 |
| Instruct | AI との会話で追加指示を作成し、再実行 |
| Create PR | コミットして push し、タスクブランチからプルリクエストを作成 |
| Merge from root | ルートブランチの HEAD をタスクブランチにマージ。コンフリクトは AI が自動解決 |
| Pull from remote | リモート origin から最新の変更を取り込み（fast-forward のみ） |
| Try merge | スカッシュマージ（コミットせずにステージング、手動レビュー用） |
| Merge & cleanup | スカッシュマージしてブランチを削除 |
| Delete | すべての変更を破棄してブランチを削除 |
| 操作 | 説明 |
|---|---|
| Requeue | Resume または Restart の位置を選択し、会話を開かずタスクを pending に戻す |
| Retry | 失敗コンテキスト付きのリトライ会話を開き、更新した指示書を確認して pending に戻す |
| Instruct | run の作業ツリーに対して AI との会話で追加指示を作成し、requeue |
| Create PR | 失敗した run の変更をコミットして push し、プルリクエストを作成 |
| Delete | 失敗したタスクレコードを削除 |
CLI/TUI の assistant と grill-me 会話では /requeue [補足] で failed または exceeded タスクを会話から決めます。補足は会話の最後のユーザー発話として対象タスクと開始位置の両方の判定に渡します。候補名との機械的な照合は行いません。AI が対象を決められない場合や判定に失敗した場合は候補タスクの一覧を表示し、人が選びます。開始位置が決まらない場合も選択可能な位置の一覧から選べます。タスク名、要約、workflow、開始位置を表示して Y/n で確認し、承認後は order.md を変えずに pending へ戻します。選択や確認を取りやめた場合は変更せず、その旨を会話に残します。再投入した結果もタスク名とともに会話へ残ります。/retry [補足] は従来どおり failed タスクを会話から決め、改訂後の order 全文を表示して タスクにつむ または 会話を続ける を選びます。タスクにつむと旧版をアーカイブして pending に戻し、会話を続けると変更せず会話へ戻ります。/retry で対象や開始位置が曖昧な場合や、どちらのコマンドでも候補がない場合は通知して終了します。どちらも対話端末が必要で、TTY がなければ選択も変更も行いません。workflow をその場で開始しません。persona 会話と Web UI ではコマンド文字列を通常メッセージとして扱います。takt resume の直接 run 向け /retry は別経路です。
| 操作 | 説明 |
|---|---|
| Delete | tasks.yaml から pending タスクを削除 |
| 操作 | 説明 |
|---|---|
| Mark as failed | running のまま残ったタスクを failed にマーク |
ワークツリークローンを持つ実行中タスクを選ぶと、そのタスクを /tell の初期対象にした通常の assistant 会話が開きます。会話中に別のタスクを確認したり、新しいタスクを相談したりできます。/tell は確定後に対象を再確認し、選択されたタスクだけへ書き込みます。完了、削除、slug 不一致、clone でない run は候補にも書き込み先にもなりません。
takt merge で起動したマージタスクや、requeue・retry 後に takt run / takt watch が実行するマージタスクも、ワークツリークローンを持つ実行中の run なら /tell の対象になります。CLI/TUI の会話、takt list から開く会話、MCP の takt_tell_run は同じ対象解決を使います。マージ run のメタデータと介入は元プロジェクトの .takt/runs/<slug>/ に保存されます。指示は子 workflow 内も含めて次の agent step で配達され、system step では消費されません。
| 操作 | 説明 |
|---|---|
| Requeue | 停止した位置から再開する形でタスクを pending に戻す |
| Delete | タスクを完全に削除 |
会話からの /requeue は exceeded タスクも対象にできます。添えた発話から、保存された実行の継続または指定ステップ（子 workflow のステップを含む）からの再実行を判定し、その操作と位置を確認してから pending に戻します。継続では保存済みの実行情報を保持し、再実行では旧 checkpoint と iteration limit 情報を除去します。指定位置が不明・利用不能で AI が決められない場合は、利用可能な開始位置を人が選びます。発話がなければ保存された停止位置を保持します。指示書の改訂や worker の開始は行いません。タスク一覧の Requeue は引き続き保存された停止位置を使います。
pr_failed ステータスのタスク（workflow は成功したが PR 作成/push に失敗）は、公開エラーを表示し、Create PR を含む完了タスクと同じ操作を提供します。workflow の結果、ローカルブランチ、コミットは保持されます。push に失敗した場合は自動 PR 作成をスキップし、ブランチ、コミット、再試行方法を表示します。
TAKT が管理するリモート push では、Git の HTTPS 認証の端末入力・askpass と Git Credential Manager の対話を無効にします。再試行前に gh auth login と gh auth setup-git、または credential helper などで認証を設定してください。独自の credential helper や SSH 認証も無人実行できる設定が必要です。
認証または表示された push エラーを解消したら、PR を作成するタスクでは takt list で対象タスクの Create PR を選択します。残っている変更をコミットして push し、同じブランチの既存 PR があれば再利用し、なければ作成します。workflow は再実行しません。再試行に成功すると completed に更新され、PR URL を保存して公開エラーを解除します。キャンセルまたは再試行失敗時は pr_failed とローカルの成果を保持します。
PR の公開後にタスク状態の保存が失敗した場合は、公開済みの PR URL と保存エラーを表示します。takt list で状態を確認し、pr_failed の場合は Create PR を再試行してください。既存 PR を再利用して状態の保存をやり直します。
PR を作成せず push だけを行うタスクでは、認証を修正してからプロジェクトのリポジトリで表示されたブランチを origin へ手動で push してください。この手動 push はタスク状態を更新しません。
完了タスクで Instruct を選択すると、TAKT は AI とのインタラクティブな会話ループを開きます。会話には次の情報がプリロードされます。
どのような追加変更が必要かを議論し、AI が指示の精緻化を支援します。準備ができたら /go を実行し、指示書が生成された後に次の操作を選択できます。
pending として再キューイングし、後で実行即座に再実行するには /accept（最新のアシスタント応答を使用）または /replay（前回の指示書を再投入）を使用します。中断してリストに戻るには /cancel を使用します。
失敗タスクの Instruct も同じ会話を使いますが、コミット済みブランチではなく run の未コミット作業ツリーを対象とします。会話には最終裁定レポートの要約（充足した要件、未解決の finding、未実証のゲート）と作業ツリー差分の概要が追加でプリロードされます。
失敗タスクで Retry を選択すると、TAKT は次の処理を行います。
Requeue も同じ workflow と開始位置の選択を使用しますが、会話を開かずタスクを pending として保存します。開始位置の選択はワークフローをツリーとして表示します。有効な Resume 位置がある場合は先頭の行が Resume failed position（失敗地点から実行状態を引き継いで再開）になり、その下に選択可能な葉として各 step が並びます。workflow_call 配下のサブワークフローは選択できない見出しとして子 step をインデント表示するため、確定できるのは常に葉の step であり、サブワークフロー自体は選べません。有効な Resume 位置がある場合は Resume 行を初期選択し、ない場合は失敗した root step に対応する選択可能な葉を初期選択します。いずれかの葉を選ぶと、その step から新しい実行を開始します。
端末の Resume 行は Resume failed position: "review" (default) のような短いラベルの直下に、経路の説明を薄い色で表示します。経路は root workflow を先頭、失敗 step を末尾とし、各呼び出しを "呼び出し step" → "呼び出し先 workflow" の組で表します。たとえば "takt-default" > "develop" → "development-core" > "review" となります。幅80列以上では説明を折り返して全経路を表示します。幅60列ではroot側を保持して説明だけを末尾から省略し、ラベルの失敗 step 名と既定印を表示します。Web UI のドロップダウンと Selected start position: … の確定ログには、ラベルと全経路の両方を残します。
Requeue 後は新しい namespace で実行されるため、台帳を引き継がず白紙で開始します。
/go の後、リトライ会話は更新された指示書を表示し、先頭かつ既定の タスクにつむ または 編集を続ける を選択できます。タスクにつむを選ぶと対象タスクの指示書を更新して pending に戻しますが、その場ではワーカーを起動しません。Retry 会話では /retry、/replay、即時実行の選択肢は利用できません。変更せずに終了する場合は /cancel を使用します。
--non-interactive）CI/CD スクリプト向けの非インタラクティブモードを使用できます。
# すべてのタスクをテキストで一覧表示
takt list --non-interactive
# すべてのタスクを JSON で一覧表示
takt list --non-interactive --format json
# 特定ブランチの差分統計を表示
takt list --non-interactive --action diff --branch takt/my-branch
# 特定ブランチをマージ
takt list --non-interactive --action merge --branch takt/my-branch
# ブランチを削除（--yes が必要）
takt list --non-interactive --action delete --branch takt/my-branch --yes
# Try merge（コミットせずにステージング）
takt list --non-interactive --action try --branch takt/my-branch
利用可能なアクションは diff、sync、try、merge、delete です。
caccia）マージ用ビルトインは Caccia を明示的に実行します。merge-review は review → caccia → wait_ci → 評価コメント、merge-review-fix と merge-review-fix-simple は review/fix → commit_and_push → caccia → wait_ci → merge_pr の順です。success と skipped は返された head の CI 待ちへ進みます。limit は未解決件数をコメントして COMPLETE で終了し、マージしません。効果の失敗は error をコメントして ABORT で終了します。push、タスク後処理、Pipeline からの暗黙の Caccia は廃止しました。merge.auto_start: true では PR 公開後にマージ用 workflow が起動し、その明示効果が Caccia を実行します。
Caccia は CodeRabbit の投稿を待ち、coderabbitai が開始した未解決スレッドだけを処理します。各反復は一時クローンで指定された workflow を実行し、判断レポートを .takt/runs/ に残します。修正を Push したら、その反復で判断したスレッドだけを Resolve し、Push したコミットへの CodeRabbit のレビューを待ちます。人が開始したスレッドは未解決のまま残します。レビューへの返信は投稿しません。成功と反復上限到達はログに記録し、設定済み通知経路にも送ります。
wait_timeout_ms は初回レビューと Push 後の各レビューの待機期限で、再依頼もこの期限に含みます。レビュー制限通知の再試行時刻が期限より前なら到来時に @coderabbitai review コメントで一度だけ依頼し、期限以降なら直ちにスキップします。制限通知を受けた後、レビューが期限までに完了しなければスキップします。制限通知を受けずに期限に達した場合は初回待機をスキップし、Push 後の待機をエラーとして記録します。system 効果は失敗を success: false と error で返します。単独の takt caccia はスキップ・エラー時に非ゼロで終了します。
効果実行の進捗、ワークフロー、終了結果、失敗は親タスクの表示モードに従います。並列実行では同じタスク名プレフィックスと色を使い、silent では画面に出力しません。workflow は効果の結果を待ってから次のステップへ進みます。
同じ機能は takt caccia <PR番号> で単独実行できます。結果と設定は CLI リファレンス と設定リファレンスを参照してください。
推奨されるエンドツーエンドのワークフローは次の通りです。
takt add – タスクを作成。.takt/tasks.yaml に pending レコードが追加され、.takt/tasks/{slug}/ に order.md が生成される。order.md を編集 – 生成されたファイルを開き、必要に応じて詳細な仕様、参考資料、補足ファイルを追加。takt run（または takt watch）– tasks.yaml の pending タスクを実行。各タスクは設定された workflow を通じて実行される。.takt/runs/{run_slug}/reports/ の実行レポートを確認。run slug は実行ごとに採番されるため、tasks.yaml の run_slug フィールドか .takt/runs/ 配下の最新ディレクトリで確認する。takt list – 結果を確認し、成功したブランチのマージ、失敗のリトライ、追加指示を行う。タスク設定で worktree を指定すると、各タスクは git clone で作成された隔離クローン内で実行され、メインの作業ディレクトリをクリーンに保ちます。
| 設定 | 説明 |
|---|---|
worktree: true |
{project}/../takt-worktrees（または worktree_dir 設定で指定した場所。親ディレクトリに書き込めない場合はプロジェクト内の .takt/worktrees にフォールバック）にクローンを自動作成 |
worktree: "/path/to/dir" |
指定パスにクローンを作成 |
branch: "feat/xxx" |
指定ブランチを使用（省略時は takt/{timestamp}-{slug} が自動生成） |
| (worktree を省略) | カレントディレクトリで実行（デフォルト） |
TAKT は git worktree の代わりに git clone --reference <メインリポジトリ> --dissociate を使用して、独立した .git ディレクトリを持つクローンを作成します（reference 元のリポジトリが shallow の場合は素の git clone にフォールバックします）。これが重要な理由は次の通りです。
.git: クローンは独自の .git ディレクトリを持ち、エージェントツールが gitdir: 参照をたどってメインリポジトリに戻ることを防ぎます。注意: YAML フィールド名は後方互換性のため
worktreeのままです。内部的にはgit worktreeではなくgit cloneを使用しています。
クローンはエフェメラルなライフサイクルに従います。
origin へのプッシュは auto_pr などを指定した場合のみ）takt list でマージまたは削除worktree 実行中、TAKT は2つのディレクトリ参照を管理します。
| ディレクトリ | 用途 |
|---|---|
cwd（クローンパス） |
エージェントの実行場所、レポートの書き込み先 |
projectCwd（プロジェクトルート） |
ログとセッションデータの保存先 |
レポートは cwd/.takt/runs/{slug}/reports/（クローン内）に書き込まれ、エージェントがメインリポジトリのパスを発見することを防ぎます。cwd !== projectCwd の場合、クロスディレクトリ汚染を避けるためセッション再開はスキップされます。
TAKT は NDJSON（改行区切り JSON、.jsonl）形式でセッションログを書き込みます。各レコードはアトミックに追加されるため、プロセスがクラッシュしても部分的なログは保存されます。
.takt/runs/{slug}/
logs/{sessionId}.jsonl # workflow 実行ごとの NDJSON セッションログ
meta.json # 実行メタデータ（タスク、workflow、開始/終了、ステータスなど）
operations/
journal.json # オペレーションジャーナル（内部実行レコード）
context/
previous_responses/
latest.md # 最新の previous response（自動継承）
observability が有効な場合、meta.json には完了時または中断時に TAKT が出力した Tempo TraceQL query を含む observability.traceDiscovery も保存されます。
| レコードタイプ | 説明 |
|---|---|
workflow_start |
タスクと workflow 名による workflow の初期化 |
step_start |
Step の実行開始 |
step_complete |
ステータス、内容、マッチしたルール情報を含む step 結果 |
workflow_complete |
Workflow の正常完了 |
workflow_abort |
Workflow の中断（理由付き） |
実行中にログをリアルタイムで監視できます。
tail -f .takt/runs/{slug}/logs/{sessionId}.jsonl