Démarrage rapide

La voie canonique « essayez-le tout de suite » : installez le Takuto CLI, lancez takuto setup puis takuto start, et terminez dans le dashboard. Comptez quelques minutes.

Configuration recommandée. Quelques choix rendent l’expérience plus fluide et plus proche de la production :

Authentifiez GitHub avec une GitHub App, plutôt qu’avec un personal access token (PAT). Les PR sont alors ouvertes sous une identité de bot dédiée plutôt que sous votre compte personnel — une paternité plus propre, et un accès qui reste limité à ce que l’app autorise.

Protégez les branches que l’agent cible. Un agent autonome peut faire tout ce que son token permet : activez donc la branch protection sur main (et toute branche cible) — exigez une PR avant tout merge, exigez une revue approuvée, et interdisez les pushes directs. Couplé à une identité de bot, cela vous donne un garde-fou de revue obligatoire même en travaillant en solo.

Utilisez une base de données externe (Postgres / MySQL / MariaDB) pour que vos données vivent hors du container et puissent être sauvegardées.

Tout ce qui suit fonctionne sans cela, mais ces réglages valent la peine d’être mis en place tôt.

Vous préférez faire tourner le moteur vous-même sans le CLI ? Voir Installer Takuto Core pour la voie construisez-votre-propre-container.

1. Créer les tokens dont vous aurez besoin

Préparez-les avant de commencer — vous les ajouterez dans le dashboard (étape 6) :

Un identifiant de fournisseur d’IA — l’un de : une clé API Anthropic (ou une connexion Claude Pro/Max) pour Claude Code, une clé API OpenAI pour Codex, une clé API Cursor pour Cursor Agent — ou aucun si vous faites tourner un modèle auto-hébergé via OpenCode.
Un accès GitHub — un personal access token fine-grained limité aux dépôts sur lesquels Takuto travaillera (Contents et Pull requests : read & write ; Metadata : read ; Issues : read & write si vous interrogez GitHub Issues). Mieux encore, mettez en place une GitHub App pour que les PR proviennent d’une identité de bot à portée limitée plutôt que de votre compte personnel.
Jira (uniquement si vous interrogez Jira) — un token API Atlassian pour le compte sous lequel Takuto doit agir.

Limitez chaque token au minimum dont il a besoin — ce sont eux qui bornent ce qu’un agent autonome peut atteindre.

2. Installer le CLI

Homebrew (macOS / Linux — recommandé) :

brew install takuto-team/tap/takuto

Pour les téléchargements de binaires manuels (y compris Windows), voir la page des Releases et la référence du CLI.

3. Prérequis

Tout ce dont vous avez besoin, c’est Docker ou Podman installé — le CLI détecte automatiquement celui dont vous disposez.

Vous n’avez pas à récupérer l’image Takuto Core vous-même : takuto start la récupère au premier lancement (avec repli sur une copie en cache si vous êtes hors ligne). Elle est publiée publiquement, donc aucune authentification au registre n’est nécessaire — même si vous pouvez la pré-récupérer manuellement avec docker pull ghcr.io/takuto-team/takuto-core:latest si vous préférez.

4. Générer votre config

takuto setup

L’assistant est court : maintenant que le dashboard gère la majeure partie de la configuration, il ne vous demande que le port du dashboard et — si vous utilisez une base de données externe (Postgres / MySQL / MariaDB) — ses détails de connexion (sinon il bascule par défaut sur le SQLite intégré). Tout le reste — système de ticketing, fournisseur d’IA et modèles, polling, workflows — se configure ensuite dans le dashboard. Il génère takuto.yml ainsi qu’un dossier .takuto/ contenant config.toml, les secrets (takuto.env) et un dossier workflows/ de définitions de pipeline de départ :

takuto.yml                  # Docker Compose orchestration
.takuto/
  config.toml                # bootstrap configuration
  takuto.env                # secrets and API tokens
  workflows/                 # pipeline step definitions
    implement_ticket.toml
    merge_base.toml
    address_pr_comments.toml

Le dossier .takuto/ est créé là où vous lancez la commande — il n’a pas à être un répertoire de projet. Lancez takuto setup/takuto start depuis différents dossiers pour garder côte à côte plusieurs instances Takuto isolées : chacune avec sa propre config, son authentification, ses espaces de travail et sa base de données, sans configuration supplémentaire.

Vous pointez sur une base de données externe — surtout une qui tourne dans un container ? Réussir la chaîne de connexion est la seule partie délicate : voir Base de données externe.

5. Démarrer Takuto

takuto start

Ouvrez ensuite le dashboard dans votre navigateur — http://localhost:8080 par défaut, ou le port que vous avez choisi lors du takuto setup. takuto start récupère l’image (au premier lancement) et démarre la stack. Au premier démarrage, le dashboard vous invite à créer le compte admin initial.

6. S’authentifier et ajouter un projet

Ajoutez les tokens de l’étape 1, puis pointez Takuto sur un dépôt :

Recommandé — les tokens de l’étape 1 : saisissez votre clé de fournisseur et votre token GitHub (ANTHROPIC_API_KEY, CURSOR_API_KEY, OPENAI_API_KEY, un GH_TOKEN à portée limitée…) depuis les écrans Configuration du dashboard, ou placez-les dans .takuto/takuto.env avant le démarrage (voir Configuration).
Cliquez sur « Setup a New Project » dans le dashboard pour cloner le dépôt sur lequel vous voulez que Takuto travaille.
Si vous avez configuré Jira ou GitHub Issues, le polling démarre automatiquement et récupère les tickets « To Do ». Sinon, cliquez sur + pour coller une description et lancer un workflow manuellement.

Optionnel — takuto auth (non recommandé). takuto auth déroule des connexions OAuth interactives (GitHub + votre fournisseur d’IA) depuis le CLI. L’OAuth accorde un accès large au compte ; nous recommandons donc plutôt des clés API / tokens à portée limitée (ci-dessus). N’utilisez takuto auth que si vous avez spécifiquement besoin du flux de connexion interactif.

Ce qui se passe ensuite

Chaque workflow crée un git worktree à partir de votre branche de base, lance vos commandes d’initialisation de worktree (par ex. npm ci), puis exécute les étapes d’agent de votre définition de workflow TOML. Suivez la sortie terminal en direct sur chaque carte de workflow, et ouvrez un éditeur VS Code dans le navigateur sur n’importe quel worktree avec Open editor.

Voir Comment ça marche pour le cycle de vie complet d’un workflow, et la référence du CLI pour stop, restart et l’isolation multi-projets.

Arrêter et redémarrer

takuto stop       # arrête les services Takuto
takuto restart    # redémarre les services Takuto

Tout l’état d’authentification, les snapshots de workflow et les caches vivent dans des volumes Docker nommés : les workflows survivent donc à un redémarrage — les exécutions en pause ou en cours reprennent automatiquement.