Définitions de workflow

Vous définissez et éditez vos workflows dans le dashboard : ouvrez Configuration → Workflows, où chaque workflow est une liste d’étapes nommée et ordonnée, stockée par utilisateur et par workspace. C’est la source de vérité à l’exécution.

Les fichiers *.toml du répertoire workflows/ (relatif à votre config.toml) sont les valeurs par défaut. La première fois que Takuto Core rencontre un nouvel utilisateur/workspace, il amorce les workflows de ce workspace à partir d’eux ; éditer le TOML par la suite ne change pas les workflows déjà amorcés — modifiez ceux-là dans le dashboard. Partez de vos valeurs par défaut à partir des exemples fournis dans le dépôt Takuto Core :

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

Le reste de cette page documente cette forme TOML — c’est le format des fichiers d’amorçage, et une référence pratique pour les mêmes champs que vous éditez dans le dashboard.

Structure d’un fichier

Chaque fichier a un name de premier niveau, un depends_on optionnel, et une ou plusieurs [[steps]] :

name = "Implement Ticket"

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

Champs d’une étape

Enchaîner les workflows avec depends_on

Une définition avec depends_on = ["implement_ticket"] ne devient disponible sur une carte de workflow qu’après la fin du flow implement_ticket. C’est ainsi que sont câblés les suivis « Merge base branch » et « Address PR comments » — ils tournent dans le même worktree une fois le flow principal terminé.

Placeholders de prompt

Ce sont les placeholders runtime de Takuto Core — accolades simples. Écrivez-les littéralement dans vos prompts. Ils n’ont aucun rapport avec les build tokens de ce site.

Le linting, les tests et l’ouverture de la PR sont des prompts d’étapes d’agent, pas des étapes du moteur. Une étape qui affiche MAESTRO_PR_URL: <url> ou qui écrit .takuto/outcome.toml permet à Takuto Core d’enregistrer l’URL de la PR et de faire apparaître l’action Address PR Comments.

Les trois workflows d’exemple

L’assistant de configuration (et le dossier d’exemples) fournit trois définitions prêtes à l’emploi.

1. implement_ticket.toml — le pipeline principal

Un pipeline complet implémenter → relire → committer → lint/test → PR. Notez les deux étapes Implement ticket conditionnées par when : une pour le mode sans ticketing (utilise {description}) et une pour le mode ticketing (lit le ticket depuis le system prompt).

name = "Implement Ticket"

# Implémentation (sans système de ticketing)
[[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

# Implémentation (avec système de ticketing)
[[steps]]
name = "Implement ticket"
prompt = """
Follow the instructions in the system prompt.
(same boundaries and scope rules as above)
"""
when = "ticketing"
repeat = 1

# Revue des changements — lancée deux fois
[[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 des changements
[[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 et 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

# Création de la PR — via le skill create-pr
[[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 — la boucle de revue

Dépend de implement_ticket. Utilise {pr_url} pour récupérer les commentaires de revue non résolus, les corriger, puis relancer 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 — garder la branche à jour

Dépend de implement_ticket. Récupère et fusionne la branche de base dans la branche de fonctionnalité, résout les conflits, puis relance 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

Étapes de commande et commandes de run

Pour le travail déterministe comme le linting ou le build, une étape de commande (commands = [...]) exécute des commandes shell directement et ne consomme aucun token IA. Séparément, les commandes de run (configurées par utilisateur depuis Configuration → Worktree Settings) apparaissent comme des boutons sur les cartes de workflow terminées — par ex. « Dev Server », « Storybook » — avec un transfert de port automatique au démarrage d’un serveur.

Voir Comment ça marche pour situer ces étapes dans le cycle de vie.