SPECTRA

—

• speckit.spectra.brd Turn a raw business requirement — typed text or a .docx/.pdf/.md/.txt document — into a structured, specify-ready BRD written under docs/brd/, or wherever your constitution declares its Artifact root:. Reads project context, asks a few clarifying questions only when the requirement has gaps, and never invents requirements — then hands the result to the specify command. The 14-section structure is a template you can override per project at .specify/templates/overrides/brd-template.md. Arguments: the requirement as text, or a path to a requirement document. With no input it asks for one. Example (Claude)

  /speckit-spectra-brd Support agents need to merge duplicate customer tickets while preserving history

• speckit.spectra.test-strategy Decide how a project tests itself — once, at the start, alongside the constitution. It reads the repository, works out for itself whether this is greenfield or brownfield, then asks you five things it cannot measure — one question at a time, each carrying the answer it would have chosen and the evidence behind it — and writes one strategy to docs/test-strategy/TEST_STRATEGY.md, or wherever your constitution declares its Artifact root:, covering unit, integration, API contract, and end-to-end testing plus a coverage floor. Every recommendation cites a path in your project, is explicitly marked as a convention, or is marked stated and names the question you answered — never neither, and no answer ever moves a measured figure — and it will not name a tool your stack cannot run, so the end-to-end lens resolves to browser, HTTP, CLI, or none rather than reaching for a browser driver a library will never use. In brownfield it reads your source rather than your README and never proposes a floor above your current baseline: coverage figures carry their provenance, and it runs nothing unless you confirm it. It never writes your constitution — it drafts the amendment, takes your approval, records it in the document, and hands off to the constitution command. Recommends CI and coverage configuration; never applies it. A singleton, rewritten in place, with Git carrying the history. Ten sections, overridable at .specify/templates/overrides/test-strategy-template.md. Arguments: none required. Optionally a focus to weight the analysis — it never narrows the four mandatory lenses, or --non-interactive to skip the questions. Example (Claude)

  /speckit-spectra-test-strategy

• speckit.spectra.impact Find out what a proposed feature would actually touch — before anyone commits to building it. Give it one paragraph of intent and it scans the project, asks at most five questions about what the code cannot answer, and writes a numbered analysis under docs/impact-analysis/, or wherever your constitution declares its Artifact root:. Every finding carries a path:line citation and a confidence level; the impact rating comes from a defined trigger set rather than a judgement; and the output states how much of the repository it read, so a reviewer can tell “checked and found nothing” from “did not check”. It never claims there is no impact, never reproduces a secret it finds, and routes security and compliance questions to the agents that own them instead of answering them. Multi-repository systems are declared as text, a document, or a local directory read in place — it accepts no URL and makes no network request. Ten sections, overridable at .specify/templates/overrides/impact-analysis-template.md. Arguments: the feature intent as one paragraph (required), optional document paths (.md/.txt/.pdf/.docx), --non-interactive for CI, and five cap overrides for large repositories. Example (Claude)

  /speckit-spectra-impact We want to email customers who leave items in their cart for more than 24 hours

• speckit.spectra.test-plan Get the tests agreed before anyone writes them. Hand it a spec.md and it writes one test-plan.md beside it — scope with real exclusions, a risk table capped at five rows, traceable test conditions, environment and data, and an exit bar someone can make a go/no-go call from. Built for teams that work test-first: the plan is circulated and approved, then fed to the planning command so the tasks include the tests it names. Traceability runs both ways — every acceptance criterion reaches a condition or is reported as uncovered with a reason, and every condition names what it verifies using your spec’s own identifiers, so a reviewer can check coverage without reading code. It will not guess which spec you meant: no branch-name inference, no feature record, no picker — with no argument it asks and stops, because a plan built against the wrong spec is undetectably wrong to whoever signs it. Where a requirement is too vague to test it says so rather than inventing a condition. Level names come from your TEST_STRATEGY.md verbatim where you have one, a declared coverage floor is carried in and attributed, and no tool is named that your manifests cannot run. Existing coverage is read from your test source, never executed. No checkboxes anywhere, exit criteria included — it is approved, not tracked. Six sections, overridable at .specify/templates/overrides/test-plan-template.md. Arguments: the path to a spec.md, or to the feature directory containing it (required — never inferred), plus --non-interactive for CI. Example (Claude)

  /speckit-spectra-test-plan specs/021-signed-webhooks/spec.md

• speckit.spectra.defect-rca Take a defect down to its root cause, with the evidence read from your code rather than asked for. Give it a GitHub issue URL, a JIRA ticket reference, or a sentence describing what went wrong, and it reads the implicated code, the commits that touched it, the configuration and the tests before it asks you anything — then writes one advisory analysis under docs/defect-rca/, or wherever your constitution declares its Artifact root:. Every claim about the code cites a file and line; every claim that something is absent states what was searched for and where. It checks whether you have analyzed this defect before, at intake rather than after the fact — matching on implicated code, symptom, or root cause, never on title similarity — and gives each earlier preventive action a verdict of completed, not completed, or undeterminable, with a citation required for the first two. It will not call the first plausible code path a root cause: every probe names its layer on the symptom-to-systemic ladder, and a conclusion still sitting at “immediate technical cause” is reported as exactly that. Invalidated hypotheses appear in the document alongside the surviving one, because a table of nothing but confirmations is a justification rather than an analysis. It fixes nothing, writes no test, never touches your ticket, and never asks you for a credential — a missing GitHub CLI costs you a copy-paste, not the analysis. Six sections, overridable at .specify/templates/overrides/defect-rca-template.md. Arguments: the defect — a GitHub issue URL, a JIRA ticket reference, or a plain description (required — never inferred from your branch or your failing tests). Supplementary logs, configuration, and timelines can be pasted at any point. Example (Claude)

  /speckit-spectra-defect-rca https://github.com/acme/orders/issues/412

• speckit.spectra.kb-vault Get the knowledge your team already has into the repository, where people and coding agents can both read it. Attach the documents — a PDF of architecture decisions inherited from a previous team, a Word file describing the engineering workflow, a deck of UX/UI standards, a diagram exported as an image — or just describe what you know. It absorbs all of it, works out what kind of document each source is, learns how your project already keeps documentation, and shows you a table before it writes anything: category, description, destination, create or update. Then it stops and waits. An ambiguous answer writes nothing; any change re-presents the whole table. It updates what you already have rather than duplicating it — matching on subject and category, never on title similarity — editing the existing file in place, keeping its name and the hand-written sections your source never mentions. Where a supplied document is a kind Spectra already produces — an ADR, a BRD, an impact analysis, a test strategy, a defect RCA — it adopts that agent’s folder, numbering and template, so it joins the existing set instead of starting a second one beside it. Everything else takes its own category folder under docs/, or wherever your constitution declares its Artifact root:, with an index maintained beside it. It never invents and never mines your codebase: every sentence traces to something you supplied, a template section with no source says so, a file it cannot read is named rather than guessed at, and “document the architecture” with nothing attached gets you a request for material. Originals stay outside the repository; you get Markdown. And it never commits — when the files are written it tells you they are uncommitted and hands the review back. Six sections, overridable at .specify/templates/overrides/kb-document-template.md, or per category at .specify/templates/overrides/<category>-template.md. Arguments: optional — steering for the attached documents, or knowledge dictated directly when you have nothing to attach. Documents are supplied as session attachments or readable paths. With neither, it asks for material and stops. Example (Claude)

  /speckit-spectra-kb-vault these are our UX standards and the old architecture decisions

• speckit.spectra.adr Create a context-aware Architecture Decision Record grounded in your codebase, prior ADRs, and constitution — it asks a few clarifying questions, then writes the ADR under docs/adr/ (or your declared Artifact root:). Its section structure is a template you can override per project at .specify/templates/overrides/adr-template.md. Use it when making a significant architecture or technology choice. Arguments: a short description of the decision. If omitted, you'll be asked for one before drafting. Example (Claude)

  /speckit-spectra-adr We should standardize on PostgreSQL for all primary data stores

• speckit.spectra.domain-analyzer Scan the existing codebase, docs, and ADRs to infer the project's domain, then write an opt-in proposal of candidate guardrails for SME review and handoff to the constitution. It never edits the constitution or source — you choose what to adopt. Arguments: none required — runs on the whole project (ideal for brownfield). Optionally pass a domain hint to steer it. Example (Claude)

  /speckit-spectra-domain-analyzer this is a banking system

• speckit.spectra.create-pr Open a correctly-targeted GitHub PR for the branch you're on — optionally linked to an issue, with the body built from an overridable pr-template. Offers to commit and push uncommitted work, asks once with everything on the table before creating anything, and returns the PR URL. Also offered automatically after implement. Arguments: none opens a ready-for-review PR (default); --issue <url-or-number> links an issue (you're asked once if omitted); --draft opens a draft; --base <branch> sets the base branch. Example (Claude)

  /speckit-spectra-create-pr --issue 42

• speckit.spectra.review-pr Review a GitHub pull request against the spec, ADRs, and constitution it carries — reading them at the PR's own revision, and the constitution in force on the base branch — plus the linked issue as optional extra context, which becomes the traceability baseline when there is no spec. Surfaces what a diff-only review cannot: a task marked complete but missing from the change, scope no requirement authorized, a pattern an ADR forbids. Every finding cites a file, a line, and its source, and lands on the line it is about, with an applicable suggestion where the fix is mechanical. Only blockers and majors are proposed — minors, nits and questions are listed by number but left out, so a one-word yes publishes just what should block the merge and takes the verdict that follows from it. all takes everything, any selection of your own still works, and an empty answer posts nothing. You see the exact review first, then one atomic review is published under your own credentials. The body's shape is a template you can override per project. Arguments: none offers the current branch's PR then lists open PRs to pick from; <url> or <number> reviews that PR; --issue <url-or-number> supplies the linked issue; --since <revision> re-reviews only the delta since a revision you reviewed before. Example (Claude)

  /speckit-spectra-review-pr https://github.com/acme/api/pull/142

• speckit.spectra.flaky-test-detector Find the tests that pass and fail on the same code — by reading your test source, with no CI integration, no results store, and no waiting for run history. Reports each candidate with a confidence rating and a specific fix, then stops. On your go-ahead it writes a task list to .specify/memory/flaky-test-analysis.md that you prune; on a second go-ahead it fixes what's left, ticking each item off on disk as it lands, so an interrupted session resumes exactly where it stopped. It never runs anything — not your suite, not a build, not even to check a fix worked — and a fix must remove the cause: deleting assertions, skipping tests, and adding retries are forbidden as remedies. Edits stay in test code, nothing is committed, and your constitution decides which fixes are allowed. Arguments: none analyzes the whole working tree; a path or suite name narrows the run — and before a narrowed run replaces a broader plan, it names the pending items that would be dropped. Example (Claude)

  /speckit-spectra-flaky-test-detector