Definiciones de workflow

Defines y editas tus workflows en el dashboard: abre Configuration → Workflows, donde cada workflow es una lista ordenada y con nombre de pasos, almacenada por usuario y workspace. Esa es la fuente de verdad en tiempo de ejecución.

Los archivos *.toml del directorio workflows/ (relativo a tu config.toml) son los valores por defecto. La primera vez que Takuto Core encuentra un nuevo usuario/workspace, siembra los workflows de ese workspace a partir de ellos; editar el TOML después no cambia los workflows que ya están sembrados — esos se cambian en el dashboard. Parte de tus valores por defecto desde los ejemplos incluidos en el repo de Takuto Core:

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

El resto de esta página documenta esa forma del TOML — es el formato de los archivos semilla y una referencia práctica de los mismos campos que editas en el dashboard.

Forma del archivo

Cada archivo tiene un name de nivel superior, un depends_on opcional y uno o más [[steps]]:

name = "Implement Ticket"

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

Campos de un paso

Encadenar workflows con depends_on

Una definición con depends_on = ["implement_ticket"] solo queda disponible en una tarjeta de workflow después de que el flow implement_ticket se haya completado. Así es como se cablean los seguimientos de “Merge base branch” y “Address PR comments” — corren en el mismo worktree una vez que el flow principal termina.

Placeholders de prompt

Estos son los placeholders en tiempo de ejecución de Takuto Core — llaves simples. Escríbelos literalmente en tus prompts. No tienen relación con los tokens de build de este sitio.

El linting, los tests y la apertura del PR son prompts de pasos de agente, no pasos del motor. Un paso que imprime MAESTRO_PR_URL: <url> o escribe .takuto/outcome.toml permite a Takuto Core registrar la URL del PR y mostrar la acción Address PR Comments.

Los tres workflows de ejemplo

El asistente de setup (y la carpeta de ejemplos) incluyen tres definiciones listas para usar.

1. implement_ticket.toml — la pipeline principal

Una pipeline completa de implementar → revisar → commit → lint/test → PR. Fíjate en los dos pasos Implement ticket condicionados por when: uno para el modo sin ticketing (usa {description}) y otro para el modo con ticketing (lee el ticket desde el system prompt).

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 — el bucle de revisión

Depende de implement_ticket. Usa {pr_url} para recuperar los comentarios de revisión sin resolver, corregirlos y luego reejecutar lint/tests.

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 — mantén la rama al día

Depende de implement_ticket. Hace fetch y mergea la rama base en la rama de feature, resolviendo conflictos, y luego reejecuta lint/tests.

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

Pasos de comando y run commands

Para trabajo determinista como el linting o el build, un paso de comando (commands = [...]) ejecuta comandos de shell directamente y no consume tokens de IA. Por separado, los run commands (configurados por usuario desde Configuración → Worktree Settings) aparecen como botones en las tarjetas de workflow completadas — p. ej. “Dev Server”, “Storybook” — con reenvío automático de puertos cuando un servidor arranca.

Consulta Cómo funciona para saber dónde encajan estos pasos en el ciclo de vida.