---
name: sot-reasoning
description: Use the external State-of-Thought controller for complex, multi-step reasoning, research, architecture, debugging, planning, or decisions where evidence selection, uncertainty, contradictions, and a deliberate stop condition matter.
---

# State-of-Thought Reasoning

Use this skill when a task benefits from an explicit reasoning state rather than an unstructured long context.

## Core rule

Never write private chain-of-thought, hidden reasoning, or verbatim internal deliberation into the SoT tools. Record only concise decision-relevant summaries, evidence, confidence, contradictions, and progress.

## Workflow

1. Call `sot_start` before substantial reasoning.
2. Add important facts, observations, source excerpts, test results, and constraints with `sot_add_evidence`.
3. Before a major reasoning step, call `sot_context` with the immediate subproblem. Prefer the evidence returned by the controller instead of replaying the whole history.
4. After a meaningful state transition, call `sot_checkpoint` with:
   - a short summary of what changed,
   - current progress from 0 to 1,
   - current confidence from 0 to 1,
   - evidence ids that materially support the checkpoint,
   - concise contradictions or unresolved tensions.
5. Read the returned state vector and recommendation.
6. If the controller says `revisit`, inspect contradictory or high-value evidence before continuing.
7. If it says `continue`, make the next bounded reasoning step and checkpoint again.
8. If it says `stop`, produce the answer unless the user has explicitly required more work.
9. Call `sot_finish` with the final outcome summary.

## State interpretation

The controller maintains four explicit dimensions:

- `progress`: estimated completion toward the task objective.
- `consistency`: compatibility of the current trajectory with recorded evidence.
- `uncertainty`: residual uncertainty after confidence and contradiction pressure.
- `change`: magnitude of the latest state transition.

A healthy terminal trajectory normally has high progress, high consistency, low uncertainty, and low state change across more than one checkpoint.

## Evidence discipline

- Treat user-provided facts as evidence, not as automatically verified truth when external verification matters.
- Keep separate evidence items for independent claims.
- Give stronger evidence a higher `weight`.
- Mark outdated, disproven, or superseded evidence as inactive with `sot_update_evidence` rather than silently forgetting it.
- Use tags such as `requirement`, `test`, `source`, `constraint`, `risk`, or domain-specific terms.

## Provider notes

### Claude

Claude may use its own adaptive thinking internally. Do not try to copy that internal reasoning into this plugin. Use SoT checkpoints as an external control and memory layer around the host reasoning process.

### Astra / Codex

Astra may use persisted reasoning inside the Responses API or Codex runtime. Keep that provider-owned state separate. The SoT plugin is the explicit task state: evidence, progress, contradiction pressure, uncertainty, and stop policy.

## Failure modes to avoid

- Do not checkpoint every sentence. Checkpoint state changes.
- Do not use confidence as a substitute for evidence.
- Do not force a stop merely because token usage is high.
- Do not keep stale evidence active after it is disproven.
- Do not expose hidden chain-of-thought in checkpoint summaries.