Algorithm v0.0.1 spec

Algorithm v0.0.1 is the planning-and-execution protocol DOS enters whenever a request is anything more complex than a greeting or a two-minute task. The Concepts page "How DOS plans" is the tutorial; this page is the full specification.

Core goal

Transition from the CURRENT STATE to the IDEAL STATE using verifiable criteria — ISC, Ideal State Criteria. The target is Euphoric Surprise — a user rating of 9-10 on the work produced.

Effort tiers

Every Algorithm run is classified into one of five effort tiers during OBSERVE. The tier sets the time budget, the ISC floor, and the minimum number of distinct capabilities the run must invoke.

Minimum capabilities. The number of distinct skills or agents the run must invoke via the Skill or Task tool. Writing text that resembles a skill's output is not invocation. Selecting a capability without calling it is a critical failure — worse than not listing it, because it is dishonest.

Time check. At every phase transition the Algorithm compares elapsed time against the phase budget. Elapsed over 150% of budget triggers auto-compression — verbose tool output and intermediate reasoning get discarded while ISC status and key results are preserved.

The seven phases

Every run walks the same ordered phases. The phase header prints first at each transition, then a voice announcement, then a PRD frontmatter edit of phase: and updated:.

Phase 1: OBSERVE

Voice-announce "Entering the Observe phase.", edit PRD frontmatter updated: <timestamp>. Thinking only — no tool calls except short context recovery with Grep, Glob, Read.

Output. Reverse engineering (explicit + implicit wants, not-wants, speed expectations); effort level with an 8-word reason; atomic - [ ] ISC-N: ... checkboxes in PRD.md after the Splitting Test; a ## Context section; capability selection.

Exit criteria. ISC count gate passed; every selected capability has a concrete invocation plan.

Phase 2: THINK

Voice-announce "Entering the Think phase.", edit PRD frontmatter phase: think.

Output. Riskiest assumptions (2-12 bullets); premortem (2-12 ways the approach could fail); prerequisites check; ISC refinement with a second Splitting Test pass; a ### Risks subsection under ## Context.

Exit criteria. Every criterion survived the second Splitting Test. Premortem failure modes are covered by ISC.

Phase 3: PLAN

Voice-announce "Entering the Plan phase.", edit PRD frontmatter phase: plan. On Advanced+ effort, call EnterPlanMode.

Output. Prerequisite validation; ISC updates when planning surfaces new requirements; capability re-analysis (add or drop); on Advanced+, a ### Plan subsection with the technical approach.

Exit criteria. Plan written, prerequisites satisfied, capability list final.

Phase 4: BUILD

Voice-announce "Entering the Build phase.", edit PRD frontmatter phase: build. Invoke each selected capability via tool call — skills via Skill, agents via Task. There is no text-only alternative.

Output. Any preparation required before execution; non-obvious decisions written into the PRD's ## Decisions section.

Exit criteria. Every capability selected in OBSERVE has a corresponding Skill or Task tool call on record.

Phase 5: EXECUTE

Voice-announce "Entering the Execute phase.", edit PRD frontmatter phase: execute.

Output. The work. As each ISC is satisfied, edit the PRD: - [ ] → - [x] and bump progress: N/M. Do not wait for VERIFY.

Exit criteria. Every ISC is checked off or flagged for VERIFY.

Phase 6: VERIFY

Voice-announce "Entering the Verify phase.", edit PRD frontmatter phase: verify.

Output. For each ISC, a test that the criterion is complete; evidence written into ## Verification; a capability invocation check — every capability selected in OBSERVE must show a Skill or Task tool call in BUILD or EXECUTE. Text does not count.

Exit criteria. Every ISC verified with evidence. No phantom capabilities remain.

Phase 7: LEARN

Voice-announce "Entering the Learn phase.", edit PRD frontmatter phase: learn. After reflection, set phase: complete.

Output. Four in-session reflection questions (what to do differently, what a smarter algorithm would do, unused capabilities, a better algorithm design); a JSONL entry appended to ~/.claude/MEMORY/LEARNING/REFLECTIONS/algorithm-reflections.jsonl for Standard+ effort.

ISC decomposition

Each ISC criterion equals one atomic verifiable thing. A criterion that can fail in two independent ways is two criteria. A PRD with 8 fat criteria is worse than one with 40 atomic criteria — fat criteria hide unverified sub-requirements.

The Splitting Test

Apply to every criterion before finalizing:

1. And / With test. "And", "with", "including", or "plus" joining two verifiable things — split.
2. Independent failure test. Can part A pass while part B fails? They are separate criteria.
3. Scope word test. "All", "every", "complete", "full" — enumerate what "all" means. "All tests pass" for 4 test files is 4 criteria.
4. Domain boundary test. UI / API / data / logic boundaries — one criterion per boundary.

Decomposition by domain

Anti-criteria

Anti-criteria use the ISC-A prefix and describe what must not happen. Verified by producing evidence the forbidden state did not occur.

ISC Count Gate

Below the floor: re-read each criterion, apply the Splitting Test, decompose, rewrite ## Criteria, recount, repeat until the floor is met.

Capability selection

Capabilities are drawn from two sources: DOS skills (the skill listing injected at session start) and Claude Code platform capabilities.

Methodology

1. Understand the task from reverse engineering.
2. Consult the skill listing for available DOS skills.
3. Consult the platform capabilities table.
4. Select across both sources. Do not limit selection to DOS skills.

Platform capabilities

/simplify is near-default for code-producing runs. /batch is considered for any task touching 3+ files. Agent Teams are considered for Extended+ effort with independent workstreams.

Anti-phantom-capability rule

Selecting a capability creates a binding commitment to invoke it. Every selected capability must appear as a Skill or Task tool call during BUILD or EXECUTE. Writing **FirstPrinciples decomposition:** without calling Skill("FirstPrinciples") is theater, not invocation.

Phantom capabilities — listed in OBSERVE, never invoked — are a critical failure, worse than never listing them. If a capability turns out not to be needed, drop it with a reason rather than leaving it unused. VERIFY's final gate checks for phantoms; a run with phantoms cannot pass VERIFY.

PRD format

The PRD is the single source of record for an Algorithm run. It lives at MEMORY/WORK/{slug}/PRD.md where slug is YYYYMMDD-HHMMSS_kebab-task-description. The AI writes every byte with Write and Edit — hooks only read it.

Frontmatter

Eight required fields plus one optional:

---
task: <same 8-word description from the entry banner>
slug: <the slug>
effort: standard
phase: observe
progress: 0/0
mode: interactive
started: <ISO-8601 timestamp>
updated: <ISO-8601 timestamp>
# optional:
iteration: 2
---

Body sections

Sections only appear when populated. The canonical field reference and continuation rules live at ~/.claude/DOS/PRDFORMAT.md.

Hook interaction

A PostToolUse hook (PRDSync.hook.ts) fires on Write / Edit of PRD.md and mirrors frontmatter plus criteria into work.json for the activity dashboard. Hooks never write to PRD.md — they only read it.

Critical rules, zero exceptions

• Mandatory output format. Every response uses ALGORITHM, NATIVE, ITERATION, or MINIMAL — no freeform output.
• No phantom capabilities. Every selected capability must be invoked via Skill or Task.
• No under-used capabilities. Use as many of the right capabilities as fit within the SLA.
• No silent stalls. Ensure background agents return results.
• PRD is your responsibility. No hook safety net — every phase transition is an explicit PRD edit.
• ISC Count Gate is mandatory. Cannot exit OBSERVE under the tier floor.
• Atomic criteria only. Every criterion passes the Splitting Test. No compound criteria; no unscoped "all" / "every".
• Context compaction at phase transitions. Extended+ effort auto-summarizes tool output at each phase boundary when it exceeds ~60% of working context — preserving ISC status, key results, next actions.

Context recovery

Mid-run context loss:

1. Read the most recent PRD from MEMORY/WORK/ by mtime — frontmatter carries phase, progress, effort, mode, task, slug, started, updated, optional iteration.
2. Re-read body sections — criteria checkboxes, decisions, verification evidence.
3. Consult ~/.claude/MEMORY/STATE/work.json for the session registry populated by the read-only PRD sync hooks.