Protocole Thésée

VérifiéSûr

Workflow Theseus axé sur Thoughtbox pour les refactorisations préservant le comportement. À utiliser lorsque la structure change mais que le comportement doit rester fixe et que les dérives de périmètre nécessitent des limites strictes.

Spar Skills Guide Bot
DeveloppementAvancé
22/07/2026
Claude Code
#refactoring#thoughtbox#scope-control#mcp#code-mode

Recommandé pour

Synthèse automatique

Pilote un protocole de refactorisation « Theseus » via Thoughtbox (Code Mode) qui verrouille le périmètre, trace les visas et enregistre les points de contrôle et résultats côté serveur.

Points forts

  • L'état du protocole (périmètre, visas, audit, statut terminal) est détenu par Thoughtbox, pas par des fichiers locaux .theseus/
  • Le verrouillage en écriture des fichiers de test et hors périmètre à l'issue de init impose des frontières strictes au refactor
  • Seul le coordinateur appelle tb.theseus, ce qui permet de déléguer l'audit à des agents sans casser la machine d'état
  • Les opérations checkpoint/outcome produisent une trace réutilisable des succès, échecs d'audit et épuisement de périmètre

Limites

  • Dépend entièrement d'un serveur Thoughtbox MCP exposant thoughtbox_search/thoughtbox_execute et tb.theseus
  • Les scripts scripts/theseus.sh et la récupération implicite par git reset --hard ne sont plus des mécanismes de secours valides
  • Ajoute une surcharge de protocole (init, visa, checkpoint, outcome) qui ne se justifie pas pour des changements mineurs
Quand l'utiliser

À utiliser quand la structure du code doit changer alors que le comportement doit rester strictement identique et que le périmètre doit être borné.

Quand l'éviter

À éviter pour du développement de fonctionnalités ou des modifications exploratoires où le comportement est censé évoluer, ou sans serveur Thoughtbox disponible.

Analyse de sécurité

Sûr
Score qualité78/100

The skill is an instructional workflow layer around a remote protocol API. Its declared tools are read-only inspection (Read/Glob/Grep), subagent helpers, and two Thoughtbox MCP calls; there is no shell, no file mutation, no secret access, and no obfuscated payloads. It explicitly discourages relying on `git reset --hard` recovery. The only residual risk is implicit trust in the external Thoughtbox server and any hooks installed outside this file, which is a dependency concern rather than a destructive instruction.

Points d'attention
  • •Delegates all state to an external MCP service (Thoughtbox `tb.theseus`) and assumes hooks consult that service before file writes; trust in that third-party server is inherited.
  • •Mentions hooks blocking writes and a `references/theseus-gate.md` enforcement design, but no write/bash/network primitives are in the declared toolset.
Comment cette analyse est faite

Exemples

Start a behavior-preserving refactor
/theseus-protocol init scope: src/auth/session.ts, src/auth/tokens/ — description: extract token validation into its own module without changing any observable behavior
Request a scope visa
/theseus-protocol visa src/config/env.ts — the extracted validation module now imports env helpers, so the scope must expand to include it
Check status and close out
/theseus-protocol status, then record the outcome and complete with a summary of the structural yield achieved

name: theseus-protocol description: Thoughtbox-first Theseus workflow for behavior-preserving refactors. Use this when structure changes but behavior must stay fixed and scope drift needs hard boundaries. argument-hint: <init|visa|checkpoint|outcome|status|complete> [args] user-invocable: true allowed-tools: Read, Glob, Grep, Task, Agent, mcp__thoughtbox__thoughtbox_search, mcp__thoughtbox__thoughtbox_execute

Theseus Protocol

Theseus is a Thoughtbox-owned refactoring protocol.

The server-side Theseus implementation behind tb.theseus(...) owns scope, visa state, audit state, and terminal status. Claude Code hooks only ask Thoughtbox whether a write should be blocked.

Do not use .theseus/ files or scripts/theseus.sh as authoritative state. Do not rely on implicit git reset --hard recovery in the active workflow. Do not use legacy direct handles like thoughtbox_gateway or thoughtbox_theseus as the interaction surface when Code Mode is available.

API Surface

The current public Thoughtbox MCP surface is Code Mode:

  • Discovery: thoughtbox_search
  • Execution: thoughtbox_execute
  • Theseus operations: tb.theseus({ ... })

Each thoughtbox_execute call should contain at most one state-mutating Theseus operation. Read-only confirmation calls such as tb.theseus({ operation: "status" }) are safe to use for state checks.

Runtime Contract

  1. Protocol entry is explicit-only in v1.
  2. If you need schema or example confirmation, call thoughtbox_search before executing.
  3. Use thoughtbox_execute and call tb.theseus({ operation: ... }) for every protocol transition.
  4. Hooks consult Thoughtbox before mutating file operations.
  5. Hooks do not spawn agents or mutate protocol state.
  6. Helper agents may audit or gather evidence, but only the coordinator calls tb.theseus.

Commands

init

Required inputs:

  • Declared scope
  • Optional refactor description

Call:

async () => {
  return await tb.theseus({
    operation: "init",
    scope: ["src/module-a.ts", "src/module-b/"],
    description: "<refactor goal>",
  });
}

After init, test files are write-locked and out-of-scope writes require a visa.

visa

Required inputs:

  • Out-of-scope file path
  • Justification

Call:

async () => {
  return await tb.theseus({
    operation: "visa",
    filePath: "src/dependency.ts",
    justification: "<why the scope must expand>",
    antiPatternAcknowledged: true,
  });
}

This is the only supported way to expand scope in the active workflow.

checkpoint

Required inputs:

  • Diff hash or equivalent checkpoint identity
  • Atomic narrative
  • Cassandra verdict

Call:

async () => {
  return await tb.theseus({
    operation: "checkpoint",
    diffHash: "<diff hash>",
    commitMessage: "<atomic narrative>",
    approved: true,
    feedback: "<optional audit rationale>",
  });
}

Before checkpoint, you may optionally run a reviewer or judge agent to produce the Cassandra-style audit. That agent returns only a verdict and rationale. The coordinator records the outcome with tb.theseus.

outcome

Required inputs:

  • Whether validation passed
  • Optional details

Call:

async () => {
  return await tb.theseus({
    operation: "outcome",
    testsPassed: false,
    details: "<what failed>",
  });
}

The protocol records whether the refactor remains in a valid state. Recovery requirements are described by protocol state, not hidden local git resets.

status

Call:

async () => {
  return await tb.theseus({
    operation: "status",
  });
}

Use the returned state as the only source of truth for scope, visas, and audit history.

complete

Call:

async () => {
  return await tb.theseus({
    operation: "complete",
    terminalState: "complete",
    summary: "<what structural yield was achieved>",
  });
}

Completion should yield protocol closure plus reusable knowledge about successes, audit failures, or scope exhaustion.

Invariants

  1. Scope is explicit and server-owned.
  2. Test files are never modified during the refactor.
  3. Out-of-scope writes require a visa.
  4. Checkpoints are explicit and auditable.
  5. Audit evidence may come from helper agents, but state transitions belong to the coordinator.
  6. Knowledge capture includes failures, not just successful refactors.

Subagent Use

Use subagents only at explicit checkpoint phases.

Good uses:

  • Cassandra-style audit before checkpoint
  • Independent diff review for premature abstraction
  • Focused evidence gathering around a requested visa

Bad uses:

  • Hook-triggered subagents
  • Letting a helper agent call tb.theseus
  • Treating git rollback behavior as the protocol itself

References

  • Public MCP surface: thoughtbox_search, thoughtbox_execute
  • Theseus SDK call: tb.theseus({ operation: ... })
  • Durable context and thought trace: Thoughtbox session, thought, and knowledge operations through Code Mode
  • Protocol implementation: src/protocol/theseus-tool.ts
  • Enforcement design reference: references/theseus-gate.md

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/theseus-protocol-mrwaka1x/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/theseus-protocol-mrwaka1x' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/theseus-protocol-mrwaka1x/download' --output '.skill-downloads/theseus-protocol-mrwaka1x/SKILL.md.part' && mv '.skill-downloads/theseus-protocol-mrwaka1x/SKILL.md.part' '.skill-downloads/theseus-protocol-mrwaka1x/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Outils déclarés par l’auteur (à vérifier dans votre agent) : Read, Glob, Grep, Task, Agent, mcp__thoughtbox__thoughtbox_search, mcp__thoughtbox__thoughtbox_execute

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/theseus-protocol-mrwaka1x/SKILL.md' && test -s '.skill-downloads/theseus-protocol-mrwaka1x/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/theseus-protocol' && cp -R '.skill-downloads/theseus-protocol-mrwaka1x' '.claude/skills/theseus-protocol'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/theseus-protocol-mrwaka1x'

openskills read 'theseus-protocol-mrwaka1x'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/theseus-protocol-mrwaka1x/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires