spectre

SPECTRE: A Workflow for Product Builders

SPECTRE is an Agentic Engineering workflow for Claude Code and Codex designed to help you do ONE THING more, faster, and with higher quality.

🚀 Ship Product Features

SPECTRE's workflow covers the complete software development lifecycle - from scoping a feature, finalizing user flows, writing the technical design, generating tasks, executing the tasks, code review, validating and proving the work works, cleaning up, testing, shipping, and generating durable & retrievable knowledge your Agent can find and load when relevant.

It has been tested on brand new codebases and codebases with hundreds of thousands of lines of code. Its been tested building websites, react native apps, native desktop apps, and personal software.

SPECTRE helps you get higher quality and more consistent results from your coding agent, while they work autonomously for much longer, so 10-100x'ing your typical output feels easy and more importantly, repeatable.

⚡ Quick Start

Within Claude Code

# Add marketplace and install
claude plugin marketplace add joenandez/spectre
claude plugin install spectre@spectre

Then start scoping:

/spectre:spectre-scope

Scope can finish with scope.md; run Plan later when you're ready to design implementation.

Within Codex

codex plugin marketplace add joenandez/spectre
codex plugin add spectre@spectre

Restart or open a new Codex session after install so managed custom agents can be discovered. Plugin hooks still require Codex trust review.

Then run a Spectre command such as:

$spectre:spectre-scope

🔁 How It Works

Scope records feature boundaries and can stop there. Plan turns confirmed Scope into a right-sized plan. Execute owns implementation, independent Validate, and observed Proof; Ship owns closeout.

The core workflows are /spectre:spectre-scope, /spectre:spectre-plan, /spectre:spectre-execute, and /spectre:spectre-ship.

Read the "When not to use SPECTRE" below to learn when it isn't the right tool.

How to use SPECTRE

• start with one of the focused workflow or utility skills

  • /spectre:spectre-scope defines feature boundaries and writes scope.md without starting Plan.
  • /spectre:spectre-plan turns confirmed Scope into an implementation plan.
  • /spectre:spectre-research is for high ambiguity new features and includes web research to explore what already exists and best practices. use if you have an idea but the exact scope is not clear yet.
  • /spectre:spectre-research is for highly technical explorations, focused on codebase research "how might we build …” style Qs
  • /spectre:spectre-ux I usually use after scope, but if the scope is clear from discussion its a good starting point to define user flows, components, and layout for a new feature.

• Your Agent will suggest the most relevant next step in the SPECTRE workflow automatically. For example, /spectre:spectre-ux if user flows are important, or directly to the full /spectre:spectre-plan flow to create the implementation plan.

• When context window is full or you reach a natural stopping point, run/spectre:spectre-handoff to generate a clear summary of the current work, next steps, open Qs, etc. Then start a new session (/clear) and your handoff is automatically injected into the next session. You'll see a summary when you start.

  • subsequent /spectre:spectre-handoff requests will use a subagent to combine to maintain continuity.
  • /spectre:spectre-forget when you are switching gears and want to clear the handoff context.

• SPECTRE saves canonical feature docs under .spectre/features/<feature-name>/, bug reports from /spectre:spectre-fix under .spectre/bugs/<bug-name>/, and /spectre:spectre-handoff saves branch-keyed session state under .spectre/handoffs/<branch-name>/. Keep .spectre/features/ and .spectre/bugs/ checked into git so your Agent and teammates can reference durable feature records in the future; handoffs remain local session state.

Core workflows

Scope → Plan → Execute → Ship

Spectre uses "meta skills". Meta Skills are skills that call other skills in one coordinated workflow. Your primary agent manages/orchestrates these workflows while focused subagents handle individual tasks.

Workflow	What it delivers	When to use it
/spectre:spectre-scope	Feature boundaries in scope.md	When defining what a feature should include
/spectre:spectre-plan	An aligned draft plan and Execute-preflight handoff	Before changing code
/spectre:spectre-execute	Orchestrated implementation, verification, review, and proof	When the plan is ready
/spectre:spectre-ship	Cleanup, testing, rebase, and a pull request	When the feature is ready to check in

/spectre:spectre-plan — Plan confirmed Scope at the right size

/spectre:spectre-plan classifies the work as XS, S, M, L, or XL based on its semantic shape, uncertainty, available evidence, protected boundaries, and task-graph risk.

It will:

• Consume confirmed Scope and create a plan artifact—even for XS changes.
• Add proportional research and create one right-sized aligned draft; Plan owns no review or task pipeline.
• Present a concise alignment brief and a marked Execute handoff for every size.
• Wait for your explicit approval before any code changes.
• Print the exact marked /spectre:spectre-execute command that starts preflight before any structured work exists.

/spectre:spectre-execute — Implement, verify, and prove the feature

/spectre:spectre-execute guides the primary agent through the full implementation. Run the command that /spectre:spectre-plan prints when it finishes.

It will:

• For an aligned Plan draft, run the existing scope-safe review, assess safe parallelism, then create and read the normal execute.md/tasks.json pair.
• Give each @spectre:dev subagent in Claude Code—or @spectre_dev in Codex—only the context required for its task.
• Run affected verification after every execution wave.
• Add intermediate reviews when the plan records compounding risk.
• Run one opposite-runtime adversarial code review, followed by one consolidated repair pass.
• Finish with Execute’s independent Validate pass and observed public-interface Proof. Validation findings must be addressed or reported as blocked before PASS.
• Capture screenshots or video for visual work, evaluate the evidence and logs, and produce a reviewable proof.html.

/spectre:spectre-ship — Clean up and open the pull request

Run /spectre:spectre-ship when the feature is ready to check in.

It loads its cleanup, risk-based testing, sweep, and rebase references, then runs /spectre:spectre-create_pr to open the pull request.

🛑 When NOT to use SPECTRE

Plan scales work from XS through XL. Use a specialist entry instead in these scenarios:

• XXS changes - copy, layout iteration, styling, etc. These are the one case where the back/forth is by design.
• Read-only diagnosis or review, release operations, and execution of an already-approved artifact do not need a new Plan cycle.
• Use /spectre:spectre-prototype for throwaway interaction exploration; repository changes that result from it still return through Plan.
• For bugs, use /spectre:spectre-fix; diagnosis remains load-bearing, and any code-changing repair leaves a durable bug report under .spectre/bugs/<bug-name>/bug-report.md and waits for approval.
• Massive multi-phase features. SPECTRE is designed for a relatively 'standard' sized feature. If you are building a huge product, and the work needs to be broken up into multiple-phases, typically what I'll do is run one /spectre:spectre-plan for the complete scope, then work with the agent to break it up into logical phases - saving that doc as phases.md. Then I'll run another /spectre:spectre-plan for the phase I'm building.

Scenarios where SPECTRE is particularly useful

• Building brand new products. Starting with /spectre:spectre-research is a great starting point, including web research, identifying existing related products, and creating a high quality kick off document you can then take into /spectre:spectre-plan.
• Highly ambiguous, highly technical features or questions. /spectre:spectre-research is excellent for this because it includes usage of the @spectre:web-research subagent in Claude Code or @spectre_web_research in Codex, which searches the web exhaustively on the topic. The final report is sometimes good enough to jump straight into execution, and is almost always extremely clarifying.
• Building internal developer tools, skills, workflows, personal software. Basically, if you have an idea, and you want to get clear on the scope, the process is generic enough to work for anything you want the agent to build.

🎯 Core SPECTRE Principles

• Great Inputs → Great Outputs
• Ambiguity is Death
• One Workflow, Every Feature, Any Size, Any Codebase
• Obvious > Clever

👻 SPECTRE Purpose

SPECTRE exists because I wanted a consistent, repeatable workflow to get high quality results from Agents.

The more time I spent automating and improving SPECTRE, the faster I could go, the higher quality the results, the less time I spent validating that a feature works at all. My time is now spent 90% on scope/ux planning, big thorny complex problems, dogfooding, and building the machine that builds the machine.

SPECTRE's core premise is actually very simple.

💀 AMBIGUITY IS DEATH.

When the scope, ux, and plan are ambiguous, you must rely on the LLM to fill in the blanks. And while sometimes you can get lucky - especially for smaller features - for any real technology or product work, ambiguity is how you end up with spaghetti code, conflicts, and AI slop.

Ambiguity is not just about scope. Its also about plans that don't get adversarially reviewed. Code that agents write that doesn't get checked. Agents finishing work without validating that it actually works.

You can get lucky, but in my experience Ambiguity leads to bad products.

Providing the right amount of context and specificity can be a lot of work. Just think about the most detailed spec or technical design you’ve ever written. Takes days and sometimes weeks.

BUT --- you can use LLMs to make it EASY to provide that specificity. And that is exactly what SPECTRE does.

✅ Workflows = Easy Button

Prompt based workflows that generate canonical docs that you and your Agents are aligned on are how you get the best, highest quality, and most consistent results from AI Coding Agents.

They provide the necessary context, detail, and structure for the agent to ask the right questions, investigate the right details, and generate the right requirements, plans, tasks, code, tests, and more.

They force adversarial reviews, check code quality, teach the agent how to verify that the code works, find and clean up mistakes and dead code from dead ends, and more importantly --- they create time & space for you to focus on the most important things.

That the product does exactly what you expected it to do, performantly, securely, and tastefully.

The better your prompt based workflows, the lower the ambiguity, the more AI can take on, the longer AI can work autonomously, the more easily you can multi-task, and suddenly you are 100x'ing your output.

📄 Canonical Docs

As a former PM I've lived the value of Canonical Docs (shout out Naomi Gleit). The reasons they work for Humans are the same reasons they work with AI Agents (see 💀 Ambiguity is Death)