agentleFS
Kastalien-ResearchKastalien-Research/thoughtbox/.agents/skills/theseus-protocol/SKILL.md

theseus-protocol

Skill64 starsChanged 4 months agoMITView on GitHub

Thoughtbox-first Theseus workflow for behavior-preserving refactors. Use this when structure changes but behavior must stay fixed and scope drift needs hard boundaries.

  • Deletes or force-pushes

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Do not use .theseus/ files or scripts/theseus.sh as authoritative state.

    line 17
  2. Very specific:

    Do not rely on implicit git reset --hard recovery in the active workflow.

    line 18
  3. Very specific:

    Do not use legacy direct handles like thoughtbox_gateway or thoughtbox_theseus as the interaction surface when Code Mode is available.

    line 19
  4. Very specific:

    If you need schema or example confirmation, call thoughtbox_search before executing.

    line 37
  5. Very specific:

    Use thoughtbox_execute and call tb.theseus({ operation: ...

    line 39
  6. Very specific:

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

    line 64
  7. Very specific:

    Before checkpoint, you may optionally run a reviewer or judge agent to produce the Cassandra-style audit.

    line 106
  8. Distinctive:

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

    line 138
  9. Distinctive:

    Test files are never modified during the refactor.

    line 158
  10. Distinctive:

    Use subagents only at explicit checkpoint phases.

    line 166

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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. Codex 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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.