v7.5.2

v7.5.2

Changed

• Execute will now better parallelize and dispatch ready tasks via subagents regardless of the plan size.

v7.5.1

Fixed

• Plan now continues after its routing step instead of sometimes ending before it creates a plan.

v7.5.0

Spectre v7.5.0

Changed

• Review and high-risk execution use Claude Opus 5.5 or GPT-6 Sol. Development, testing, analysis, and research agents use Claude Sonnet 5 or GPT-6 Luna.

Fixed

• Planning more often reuses evidence from existing threads and project context before calling research agents. Larger plans still get an independent check for simpler solutions.
• After a user resolves a plan review finding or edits Scope, review moves to simplification without repeating the correctness pass.
• Codex review commands no longer wait for terminal input.

v7.4.2

v7.4.2

New

• One pull request can now carry many work records. Ship selects only the records
  that belong to the changes going out, then links each one to the pull request.
• A work record can be marked finished on its own, without waiting for a pull request.
• Both command-line tools gained work membership and work associate. The first
  reports which records belong to a set of changes; the second links those records
  to a pull request.

Changed

• Each Execute run now gets its own work record. Earlier versions treated the branch
  as the record's identity, so a second run on the same branch wrote over the first
  run's account.
• Ship freezes the exact set of outgoing changes before it looks for work records,
  so unrelated history on the same branch cannot attach itself to your pull request.
• Looking up a branch returns every work record on it, in sorted order, instead of a
  single pointer. Older combined records stay readable.
• Create PR now finds your branch's open pull request and updates it, instead of
  opening a second draft.

Fixed

• Adversarial plan review now runs in the opposite runtime. Plan review itself was
  working; Spectre was not routing the review to the opposing runtime, so the
  adversarial pass never happened.
• The retired --branch and --branch-pr-state flags now fail with a clear error
  instead of being accepted and ignored. The work-record instructions no longer tell
  agents to pass them; pull request state travels in the capture input instead.

v7.4.0

v7.4.0

Spectre v7.4 includes some major updates! Covered below

01 - updates to Spectre's codebase knowledge system - now much more automated!

02 - speed & simplicity updates to Spectre's planning workflow

03 - ux improvements to handoffs for fewer human gates and more clarity on next steps.

Read on for the details!

01 Spectre now remembers major decisions, new patterns, gotchas, and more.

Three new kinds of project memory now build up automatically as you work, so your agent can reach for those learnings the next time it plans. Knowledge Records, Work Records, and Tags.

Knowledge records

Knowledge records are durable facts about how your project works: a decision you made, a gotcha someone will hit again, a constraint, a convention, a version pin, a correction of something the agent had wrong.

Your agent writes these as they come up in normal conversation. Say "we settled on Postgres, not sharding," or "no, that only applies to the worker path," and it gets recorded. You never have to say "remember this," and your word is enough on its own — the agent does not go hunting through the repo for proof before it saves.

Work records

Work records are a durable and token efficient account of a body of work: what you asked for, what actually changed, why, what was discovered along the way, how it was verified, and what is still open.

This allows your agent to better understand past work, helpful when fixing bugs or expanding upon previous work the agent does not have in the context window.

Work records are drafted when you start Execution, updated when Execution finishes, and finalized when you run Ship. If you run multiple Execute runs prior to ship, you get a single Work Record that includes all the work.

Tags

Your agent will "tag" Knowledge and Work Records as they are written (e.g., #auth, #command-palette). Tags reference higher level concepts in your codebase at the feature or major capability level.

This makes it easy for you or the agent to group and link related knowledge and work records together, so when your agent searches for #cart, it can pull all the recent work records or knowledge records associate with the Cart to dive deeper into relevant work.

Search returns compact "useWhen" summaries for each record, so tag search remains token efficient and agents can dig into more detail when it sees specific records worth expanding.

How these shows up in your workflow

• Scope and Plan will search for and use knowledge records or work records before it drafts the initial scope or plan.
• Execute captures what it learns as it goes, so even long autonomous runs establish key decisions and facts that can be re-used later. Execute runs get associated with a Tag, so agents can revisit past runs if needed.
• One search covers both kinds. When you ask questions or plan work, search will surface both Knowledge and Work records that are relevant to the task, so your agents always start informed on past work, decisions, and patterns. Searching by tag shows all the records associated with that tag.
• Ordinary conversation loads nothing. Memory stays out of the way until a real question needs it, and the agent never runs the same search twice.
• Manually #tag to bring in context. You can also write #{tag} in any message and your agent treats it as a direct lookup: it pulls the records under that tag and loads only the ones that apply. It will not invent a new tag out of what you typed, and it won't load everything - only what is relevant to your question.
• /spectre:spectre-learn: You can still use /spectre:spectre-learn anytime you want to manually capture knowledge for agents to utilize in the future. Knowledge is always proactively recalled by your agents when the task at hand is relevant to it.

02 Faster, simpler, more correct plans

Agents love to over complicate work. Spectre plan now explicitly fights against that tendency of agents. The updated plan mode forces Agents not just to justify complexity, but to specifically justify why the plan can't be smaller.

Plan is now just as fast as Codex and Claude Code's native plan mode, so you never feel the need to reach for anything else.

Short by default

/spectre:spectre-plan produces the plan and puts the architecture and design decisions in front of you for approval first. The heavier adversarial plan review and task generation happens afterward during the execution workflow. Planning a medium feature takes about 5 minutes rather than about 30, which is closer to how native plan mode feels in Claude Code and Codex.

The smallest shape that delivers your scope

Before drafting anything, Plan picks the smallest solution that satisfies your scope, and it starts from what you already have: add nothing, then reuse an existing owner, then extend one boundary, then lean on a platform or dependency you already depend on, and only THEN build something new.

Anything genuinely new has to be justified by a requirement, a safety condition, or a verification need you have today. It uses Yagni but not just as prompt framing. Agents are required to justify why something new is needed and why a simpler solution couldn't achieve the same end.

Where feasibility is genuinely unknown, Plan proposes a bounded spike with a question and a stop condition. Clarity up front.

Prove it can't be smaller

Agents must justify why an L plan can't be an M, or an S plan XS. Requirements, safety, and verification stay fixed through the comparison, so a smaller shape can never win by dropping a check you need.

The simpler option wins by default. The larger one survives only when the smaller one concretely fails a requirement, a safety condition, or a verification obligation, and the failure is recorded with the evidence behind it.

A second opinion on simple, automatically

Spectre already supports adversarial review for correctness & simplification once you have an approved plan. But now, Spectre will dispatch an agent whose only job is to come up with the the smallest credible approach before any plan is drafted.

That agent writes nothing and changes nothing. It argues, and the simpler of the two candidates wins unless there is real evidence against it. It runs inside the research work already happening, so it costs you no extra waiting.

Execute finishes the job

To speed up the planning process, we moved all adversarial Plan Review into the execute workflow, which was already the longest autonomous workflow.

Correctness & Simplification adversarial reviews now enforce "scope-safe adjustments". Which means the scope you agreed upon in the planning phase is the scope -- agents work from that contract.

Execute takes an approved plan through preparation, task generation, implementation, verification, and repair without further prompting. It stops only when it needs permission or a genuinely new decision from you.

03 A smoother workflow with fewer stops

With Spectre we want the human to be in the loop at exactly the right moments, and have clarity on exactly what is being asked of them and what the options are. So we've made some improvements to the Spectre workflow.

• Standard handoff tables. Every workflow command ends with the same compact, two-column summary: what just happened, what it produced, and the exact next command. The commands are filled in, so you can copy and paste them without editing.
• One-step UX approval. Approving a UX pass also picks the next route. You choose Prototype or Plan in the same reply instead of answering twice.
• Bug fixes go straight to execution. /spectre:spectre-fix investigates, writes the report, and hands you the exact Execute command in the same reply. Bug repairs never run plan review, because the finished report already carries the requirements, the root cause, and the repair boundary. A repair large enough to need ordering is split into tasks; everything else goes straight to implementation.
• Automatic bug report detection. Execute recognizes a bug report from its path or its content, so you no longer need the --origin fix flag.
• More parallel work in Ship. Ship owns its own cleanup boundary and runs steps together that used to run one after another.

Changed

• Task generation accepts a bug report as its source, so a large repair still gets ordered tasks with test-first pairing.
• Execute keeps its full working context when it hands work to helper agents, so long runs resume correctly after an interruption.
• Resume binds saved work to the current plan, which stops an older plan from being picked up by mistake.
• Recovery handoffs for blocked and failed runs use the same structure as successful ones and include ready-to-run alternatives.

Fixed

• Route order between UX, Prototype, and Plan is correct again, and each route passes the arguments it actually needs.
• Handoff summaries no longer contain unfilled placeholders, so every suggested command runs as written.
• Execute keeps test, review, and proof results separate from the summary of what it just built.
• Workflow runs on older execute/ and ship/ folder layouts are migrated instead of failing.
• Feature folder details are kept in run summaries rather than dropped.
• Execute no longer escalates when a comparison baseline is simply unavailable.

v7.3.0

New

• Reference templates for plan review. Plan review now sends fixed reviewer instructions to each reviewer instead of rewriting them every run. Two new templates cover correctness review and simplification review. Reviews of the same plan now stay consistent between runs.
• Plan lookup by artifact. A new spectre-workflow plan match command finds a plan run from a feature root and an artifact hash.

Changed

• Plan telemetry moved out of your repository. Spectre now writes plan classification records to its own project store instead of a .spectre/telemetry folder inside your working tree. This keeps generated records out of your commits and out of merge conflicts. Existing records are copied over once on first use. Your old files are not changed or deleted.
• The design approval step now follows the decision, not the size. Medium plans asked for high-level design approval every time, even when there was nothing for you to decide. Spectre now asks only when the work involves a real choice you own, such as a product, compatibility, migration, or architecture decision. Large and extra-large plans still always ask.
• Plans stay smaller. Plan creation now requires a written reason before it adds complexity, and optional plan sections only appear when they carry real content. Empty placeholder sections are gone.
• Simplification review only removes. The simplification pass can delete, combine, reuse, or defer work. It can no longer grow a plan. It must either shrink the plan or state why no safe reduction exists.
• Feature folder names are chosen automatically. Spectre picks the feature folder name, avoids reusing an existing one, and adds a suffix when names collide. It no longer stops to ask you which folder to use.

Fixed

• Review reports now describe only what changed, instead of restating the whole plan.

v7.2.1

New

• Agents now more consistently embed inspected screenshots and playable journey recordings in visual and terminal proof reports. A validator rejects missing, incomplete, or path-only visual evidence.
• Added a repository architecture reference covering Spectre's structure and runtime model.

Changed

• Proof runs can repair broken test harnesses, drivers, fixtures, and configuration, then rerun affected journeys. Every harness change must be disclosed without influencing the product verdict.
• Execute continues plan-backed repair, verification, and proof until all requirements pass or the remaining work requires user authority.
• Fix workflows now present their hypotheses and experience evidence in the conversation and preserve them in the managed repair plan.

Fixed

• Plan routing no longer counts layout, density, breakpoint, or theme variants of one interface as separate workstreams.
• Repeated, already-shipped change patterns are less likely to be incorrectly routed through an oversized structured workflow.
• When a failure is attributed to a third-party dependency but remains unclear after a repair attempt, agents now consult current primary documentation, code, and issue sources before making another code change.

v7.2.0

New

• /spectre:fix now keeps a durable bug report. Each bug gets its own folder at .spectre/bugs/<bug-name>/, and bug-report.md records the reported problem in your words, the diagnosis, the planned repair, and a closing result of fixed, partial, or blocked. Bug work no longer lands inside a feature folder.
• Agents can read run progress with spectre-workflow run status --run-id <id> --json. This is an agent-facing command, not a user command. Execute uses it to rebuild its position after a context reset instead of re-reading the whole task graph.

Changed

• The high-level design gate is back in /spectre:plan. It used to be there, and it went away by accident when the plan router landed. The new version is more purposeful: on medium and larger work, Plan shows the approach, how the major parts interact, at most three trade-offs you are accepting, and any open questions, then stops until you approve.
• Execute treats specs/tasks.json as a fixed definition. Your approved task file is no longer edited during a run. Progress lives in local run state that the orchestrating agent keeps, and a task counts as done only when a verification check passes.
• Verification gates record short check IDs instead of collecting evidence files, so long runs stay small.
• /spectre:prune reports its cleanup summary in the conversation instead of writing a cleanup_summary.md file.

Removed

• /spectre:plan no longer writes goal-prompts.md. It hands off straight to /spectre:execute and prints the exact command for your runtime. /spectre:goal stays available as an explicit opt-in: goal mode is token intensive, and it suits a specific measurable improvement target better than brute-force execution of a plan.
• Task files no longer carry a status field, because run progress is now tracked in local runtime state by the orchestrating agent.

v7.1.1

Changed

• Refreshed the README with new Spectre artwork, current Claude Code installation commands, and a clearer Plan → Approve → Execute → Prove → Ship guide.

Fixed

• Prevented Plan from classifying a single skill that coordinates existing tools as an XL project solely because it has several stages, approval gates, supporting artifacts, or dependencies.
• Plan now respects confirmed scope assumptions, limits missing-path checks to one bounded probe, and reserves structured or high-risk routes for genuinely independent workstreams or risky implementation sequencing.

v7.1.0

New

• Added adaptive XS–XL planning that sizes work using scope shape, uncertainty, evidence, protected boundaries, and task dependencies.
• Added a compact XS path that still preserves durable scope, planning, verification, and approval.
• Added planning telemetry to record routing, reviews, approvals, reclassification, and execution outcomes.

Changed

• Repository-changing work now proceeds from Scope through the smallest sufficient planning route.
• Planning now rechecks its classification after artifacts are produced and surfaces recommendations without silently repeating work.
• Updated workflow guidance and handoffs across Scope, Plan, Fix, Execute, Goal, UX, and Prototype.

Fixed

• Made the planning route table exhaustive and deterministic.
• Ensured calibration telemetry records complete lifecycle data while remaining non-blocking if unavailable.