workflow 定義

workflow はダッシュボードで定義・編集します: Configuration → Workflows を開くと、 各 workflow が名前付きの順序付きステップ一覧として、ユーザーとワークスペースごとに保存されています。 これが実行時の信頼できる情報源（source of truth）です。

workflows/ ディレクトリ（config.toml からの相対）にある *.toml ファイルは デフォルト です。Takuto Core が新しいユーザー/ワークスペースに初めて出会ったとき、その ワークスペースの workflow をそこから種付け（seed）します。その後 TOML を編集しても、すでに 種付けされた workflow は変わりません — それらはダッシュボードで変更してください。デフォルトは Takuto Core リポジトリ に同梱されたサンプルから始めましょう:

cp workflows/implement_ticket.example.toml workflows/implement_ticket.toml

このページの残りでは、その TOML の形を説明します — これは種ファイル（seed file）の形式であり、 ダッシュボードで編集するのと同じフィールドの便利なリファレンスでもあります。

ファイルの形

各ファイルはトップレベルの name、任意の depends_on、そして 1 つ以上の [[steps]] を持ちます:

name = "Implement Ticket"

[[steps]]
name = "Implement ticket"
prompt = """
Follow the instructions below:
{description}
"""
repeat = 1

ステップのフィールド

depends_on で workflow を連結する

depends_on = ["implement_ticket"] を持つ定義は、implement_ticket フローが完了した 後 に だけ workflow カード上で利用可能になります。これが「Merge base branch」や「Address PR comments」の フォローアップが結びつけられる仕組みです — メインフローが終わると、同じ worktree 内で実行されます。

プロンプトのプレースホルダー

これらは Takuto Core のランタイムプレースホルダーです — シングルブレース。 プロンプト内に そのまま書いてください。このサイトのビルドトークンとは無関係です。

lint、テスト、PR の作成は エージェントステップのプロンプト であって、エンジンのステップでは ありません。MAESTRO_PR_URL: <url> を出力するか .takuto/outcome.toml を書くステップがあれば、 Takuto Core は PR URL を記録し、Address PR Comments アクションを表に出せます。

3 つのサンプル workflow

セットアップウィザード（とサンプルフォルダー）は、すぐ使える 3 つの定義を同梱しています。

1. implement_ticket.toml — メインパイプライン

実装 → レビュー → コミット → lint/テスト → PR の完全なパイプラインです。when でゲートされた 2 つの Implement ticket ステップに注目してください: 1 つは no-ticketing モード用 （{description} を使用）、もう 1 つは ticketing モード用（チケットをシステムプロンプトから読みます）。

name = "Implement Ticket"

# Implement (no ticketing system)
[[steps]]
name = "Implement ticket"
prompt = """
Follow the instructions provided below:
{description}

BOUNDARIES: This step covers implementation only.
- Do NOT commit any changes — a dedicated "Commit changes" step follows.
- Do NOT create a PR — a dedicated "Create PR" step follows.

SCOPE CONSTRAINT: Only implement what is explicitly described above. Do not refactor
unrelated code; leave a # TODO if you spot something out of scope.
"""
when = "no_ticketing"
repeat = 1

# Implement (with ticketing system)
[[steps]]
name = "Implement ticket"
prompt = """
Follow the instructions in the system prompt.
(same boundaries and scope rules as above)
"""
when = "ticketing"
repeat = 1

# Review changes — run twice
[[steps]]
name = "Review changes"
prompt = """
Ticket context:
{ticket_context}

Review all changes on this branch relative to `{base_branch}`
(i.e. `git diff {base_branch}...HEAD`). Only address issues in code changed for this
ticket. Confirm each finding is genuine before fixing it. Do not create a PR.
"""
repeat = 2

# Commit changes
[[steps]]
name = "Commit changes"
prompt = """
Commit the work into logical, conventional commits. Never run git checkout/restore/
reset/clean/stash — only create commits. Do not create a PR.
"""
repeat = 1

# Lint and test
[[steps]]
name = "Lint and test"
prompt = """
Run the project's linter and fix all issues; run the test suite and fix failures
(never delete or skip tests); run the formatter. Commit with
`chore: fix lint warnings, format, and failing tests`. Do not create a PR.
"""
repeat = 1

# Create PR — via the create-pr skill
[[steps]]
name = "Create PR"
prompt = """
Ticket context:
{ticket_context}

The PR title must be a conventional commit message and must not contain the workflow
name, branch name, or ticket ID.
"""

[[steps.skills]]
name = "create-pr"
args = ["--no-draft"]
repeat = 1

2. address_pr_comments.toml — レビューループ

implement_ticket に依存します。{pr_url} を使って未解決のレビューコメントを取得し、修正してから lint/テストを再実行します。

name = "Address PR Comments"
depends_on = ["implement_ticket"]

[[steps]]
name = "Fix review comments"
prompt = """
Pull request URL: {pr_url}

Ticket context:
{ticket_context}

Retrieve all unresolved PR review comments. For each: make the change, verify it
locally, commit with a descriptive message, and push to the PR branch. Do not bypass
linting or tests.
"""
repeat = 1

[[steps]]
name = "Lint and test"
prompt = """
Run the linter, test suite, and formatter; fix all issues; commit with
`chore: fix lint warnings, format, and failing tests`.
"""
repeat = 1

3. merge_base.toml — ブランチを最新に保つ

implement_ticket に依存します。ベースブランチを fetch して feature ブランチにマージし、 コンフリクトを解決してから lint/テストを再実行します。

name = "Merge Base Branch"
depends_on = ["implement_ticket"]

[[steps]]
name = "Merge base branch"
prompt = """
Fetch the latest `{base_branch}` from remote and merge it into the current branch.
Resolve conflicts — prefer the current branch for feature code, the base branch for
config/dependency files unless they conflict with this ticket's work. Run lint and
tests after the merge, then commit and push.
"""
repeat = 1

コマンドステップと実行コマンド

lint やビルドのような決定論的な作業には、コマンドステップ（commands = [...]）が シェルコマンドを直接実行し、AI トークンを消費しません。これとは別に、実行コマンド （ユーザーごとに 設定 → Worktree Settings から設定）は、完了した workflow カード上に ボタンとして現れます — 例: 「Dev Server」「Storybook」 — サーバーが起動すると自動で ポートフォワーディングされます。

これらのステップがライフサイクルのどこに位置するかは 仕組み を 参照してください。