What We're Doing vs What We Should Do

The repo deliberately keeps two things apart (speckit-extension/docs/node-model.md):

1 · Workflow steps — the pipeline in speckit-extension/workflows/speckit-companion.workflow.yml: specify → classify → route(switch) → {plan → tasks → implement} → mark-complete. Step types are command, switch, gate, shell. This is data, meant to run on spec-kit's engine (specify workflow run/resume). Caveat: the shipped VS Code path does not actually run this YAML — it has its own hardcoded 5-step list (DEFAULT_WORKFLOW/COMPANION_WORKFLOW in workflowManager.ts), and resume dispatches the installed /speckit.* commands directly. So the YAML engine path is partly aspirational.

2 · Composable command nodes — each command (e.g. speckit.companion.specify) is assembled from markdown fragments under speckit-extension/nodes/<command>/, ordered by _order.yml, with reusable parts (timing, sizing, routing, self-advance) filled into fences by assemble-nodes.py. Node kinds: investigate, author, gate, control. Big caveat: v1 is a pure refactor — the assembled body is byte-identical to the old hand-written command. "Recipes" that actually add or drop a section (the real payoff) are planned, not built.

So "add a grill-me node" means one of two concrete things: (a) add a fragment under nodes/<command>/ + its _order.yml entry (once section-level composition ships), or (b) add a before/after node hook in .specify/companion.yml — which is AI-interpreted prose, "there is no engine" yet.

No — we support a fixed registry of 8 dispatch targets, via three styles (all one-way: we send command text, never read the response back):

Six terminal CLIs — claude, gemini, copilot (ghcs), codex, qwen, opencode. IDE Chat — the host editor's built-in chat (Copilot in VS Code, Composer in Cursor, Cascade in Windsurf, Antigravity). Claude panel — the Claude Code GUI panel via URI handler. Files: src/ai-providers/ (8 provider classes + factory).

The mechanism: we assemble a prompt and hand off the /speckit.* command text; the host CLI/chat resolves it. For IDE Chat and the Claude panel we prefill but can't auto-submit (the user presses Enter), and for all of them we never read the answer back. A new tool = a new registered provider (constructor + PROVIDER_PATHS entry) — not open-ended, but the breadth is the widest in the category and it's the #1 thing the market asks rivals for.

Today: no, on both counts. The active provider is a single global machine-scoped setting (speckit.aiProvider) resolved once for the whole run — there is no per-spec, per-step, or per-node provider override. And there is no model selection anywhere — the model is whatever the underlying CLI defaults to (no model field in any setting, node frontmatter, or workflow step).

The only related knobs: workflow.yml passes one global inputs.integration uniformly to every step; VS Code custom workflows can gate a workflow to certain providers (supportedAiProviders, hides it if the active provider isn't listed) but cannot select one per step. There is a static provider capability profile (ProviderPaths: supportsHooks, autoApproveFlag, command format, …) but no canContinue/supportsSubagents flags — "continue if you can" is a prompt sentence, not a code flag.

This is the unlock. Per-node provider/model selection is the prerequisite for adversarial review, model routing (Opus for planning, Haiku for cheap steps), and cost control. It's a clean, additive build (a model/provider field on a step + resolving the right provider per dispatch).

Yes, already — two ways (both shipped, both config-level, no visual editor):

1 · VS Code custom workflows (speckit.customWorkflows setting): define your own steps[], each pointing at your own slash command (e.g. /superpowers:brainstorm), plus custom command buttons per step. Validated in workflowManager.ts (names must match ^[a-z][a-z0-9-]*$; speckit/companion reserved).

2 · .specify/companion.yml node hooks + recipes: insert a before/after node (a command, a prompt, or a user-authored node file) around any node id, or reorder a command's nodes with a recipe. Caveat: it's AI-interpreted ("there is no engine") and recipes only change order in v1, not content.

Note: the thing called src/features/workflow-editor/ is a spec-document refiner (refine a section/line of spec.md), not a visual pipeline editor. A real visual workflow/recipe editor is a future item.

Clarify today = stock spec-kit /speckit.clarify: scans an ambiguity taxonomy, asks up to 5 one-at-a-time questions (multiple-choice with a recommended option), and writes a ## Clarifications session into spec.md. Companion only wraps it with the timing/capture parts. It's a non-advancing step (records a history finish, no status change).

"Grill-me" does not exist in the repo — zero references (no Wave-3/W3·4 anything in code). It's a vault-roadmap idea, not built.

What we'd need to build grill-me (as a distinct, harder clarify): (1) a companion command that loops past 5 questions until the spec is complete ("keep going until no unknowns"); (2) each question carries a recommended default (clarify already does this — keep it); (3) it persists the Q&A + the decisions into .spec-context.json, not just spec.md (today the decisions[] field is a read-only passthrough that no capture script writes); (4) it runs as a node hook before plan. Bake in the ICE authoring checks (below) while you're there.

Today the extension does nothing about context rot — it's delegated to the underlying CLI. The prompt Companion builds is a .spec-context.json bookkeeping preamble + the slash command; it contains no fresh-context/context-window directives. Sub-agent parallelism exists only as optional prompt guidance in the implement command, host-gated ("if your host has a subagent tool… inline is the default").

The good part: the research says the winning defense is file-based state + fresh context, and our file-based trace is exactly that — the .spec-context.events.jsonl append-log is even engineered to be parallel-safe (workers append their own finish without contending). SLUMP's finding (a persistent spec file recovers 90% of lost faithfulness) is a direct endorsement of the trace.

What to add: (1) capture decisions/rationale deterministically so resume restores why, not just where; (2) ship true [P] fan-out (fresh context per task via subagent dispatch — ROADMAP step 8; the append-log foundation is ready); (3) keep the constitution/steering re-injected each step (already the model).

Adopt the mechanics, skip the rebrand. IDD/ICE is ~80% repositioning (its own author concedes "ICE is still a spec"). But three of its ideas are genuinely worth baking into our specify/clarify prompts:

(1) Separate directional constraints from binary failure conditions. Constraints ("<200ms", "99.99% uptime") stay human-readable in the spec; failure conditions (build fails, coverage <90%, secret in source, API contract change without a version bump) become the eval set the verifier runs — and the builder shouldn't see them ("can't teach a test it can't see"). This is the seed of our eval layer.

(2) The two-implementations goal test: if only one implementation can satisfy your "goal," it's a spec disguised as a goal — a cheap authoring check.

(3) Feed context progressively / code-first, don't dump one wall. We already stage via .spec-context.json; this just formalizes it.

You do not need to adopt IDSD as a methodology or rename anything. These are three prompt-level checks in clarify/specify.

Today it tracks the lifecycle spine (workflow, specName, branch, currentStep, status, history[]) + skill-authored passthroughs (decisions[], concerns[], approach, task_summaries, step_summaries, reviewComments[], last_action, livingSpecs). The by field on history is only a coarse role (extension|user|cli|ai|derive).

Missing — and each maps to a research recommendation:

• provider + model per step — which provider/model actually ran it (today: unknown; needed for the compute-allocator + governance story).
• tokens / cost per step — for the budget + auto-pause feature (Uber-budget problem).
• verification — { passed: bool, checks: [{name, status}] } — so mark-complete can gate on a real signal, not the AI's say-so.
• evals — acceptance-criteria scores over re-runs (the trend, not a pass/fail); productizes the bench behavioral-judge.
• clarifications[] / real decisions[] — captured deterministically by a grill-me/clarify command, not passthrough.
• review — the second-model verdict (approved/revise + findings) from the verifier recipe.