Files written together, as when a spec is cloned or copied, are treated as one generation, so the stale banner only appears once a document is edited more than a second after the one below it.

In a side panel the node’s panel now scrolls, so the button is always reachable, and its list opens inside the panel on the side with room, showing every phase instead of being cut off at the edge.

A spec whose run recorded nothing, but which still had a status and a review comment, opened on an Overview holding only an empty run log under a tab titled Overview. It now opens on its document, and the tab says which from the first paint.

Spec Kit records which assistant a project was set up for. When that is not the assistant your AI provider setting names, SpecKit Companion now says so when it starts and offers to switch, or to keep your current one. It never switches on its own, and once you keep your choice it does not ask again for that project. A project set up for an assistant SpecKit Companion has no provider for shows nothing.

If a release was published and then retracted, every project kept being told its spec-kit commands were behind a version that no longer exists and could not be installed. The daily update check now confirms the newest version it remembers is still a published release, and drops it when it is not. A release that has only scrolled off the releases page, or a check that cannot reach GitHub, leaves the remembered version alone.

They still passed the agent with --ai, which newer Spec Kit no longer accepts, so the upgrade failed in the terminal. They now use --integration, and Upgrade Project falls back to --ai for an older Spec Kit that only knows the old flag.

It used to start Spec Kit’s own picker, so the project could end up set up for a different assistant than your AI provider setting. It now names your assistant, with the flag your Spec Kit version understands. IDE Chat on Windsurf, which current Spec Kit no longer lists, gets Spec Kit’s picker instead of a command that fails.

The configuration writer can now move a hook to another place, or up and down among the hooks at one place, as a single change. The hook keeps the text it was written with, every other line of the file stays as it was, and a move to a node or phase the step does not have is refused with nothing written. Before this a move was a removal and then an addition, so an addition that was refused left the hook gone.

They measured a step up to the next step’s start, so a spec left idle for an hour between specify and plan reported the wait as specify’s time. The step timing line now lists each step’s own duration, or says it was not measured, and a finish recorded more than once counts only the first trusted one. A step the editor started and the assistant finished through the recorder now counts as measured.

The old tab stayed open with an empty body and a header without its branch. It now reads “moved or deleted” and points you to the sidebar, which already opens the renamed spec.

A link whose target carried a quote could break out and attach its own behaviour to the page, and a link pointing at a script scheme ran when clicked. Both are now inert, and images in a spec render as images for the first time instead of as a link with a stray exclamation mark.

The tab title changed but the Overview stayed on screen, because the viewer never recorded that you had picked a document. The tab is also titled Overview while the Overview shows, instead of keeping the last document’s name.

In a monorepo, a wildcard pattern that points at each project’s specs folder used to show one empty row per project named Specs, and none of the specs inside. Each project’s specs now appear, the same way the default specs entry lists its children. Patterns that end in a wildcard, like apps/*/specs/* or openspec/changes/*, work as before. A pattern that ends in a plain name and pointed at spec folders one by one now lists their children instead: add /* to keep the old meaning.

A living spec or a spec’s delta now gets a warning on a requirement that bundles more than four rules under one heading, or takes more than 120 words to state its rule, so it can be split or cut before it becomes context for every later run.

A capability with no spec: path in the registry pointed the sidebar at capabilities/<name>/spec.md, the name from before the rename, so a spec at capabilities/<name>/<name>.spec.md showed as missing. The view now looks for the current name first and still finds the old one.

A living spec that still carried its draft banner but had no adopted requirements could never lose the DRAFT badge. The bar now offers Approve spec on any draft, and approving the whole spec always clears the banner.

Specs that name each requirement by its heading and write scenarios as #### Scenario:, which is how every living spec is written, showed no requirement count, no scenario count and no covered figure. The header and the Living Specs row now count them, and the covered figure matches the number of cards that show a test count.

A living spec’s cards were built to show a count beside the state pill, such as 3/4 tests, but the running viewer never received the numbers, so every card was blank and read as untested. A requirement whose coverage file names tests now shows how many of them exist. A requirement with none shows nothing, and a capability with no coverage file looks exactly as before.

Requirements whose tests were captured in one end-of-step write read as “No test linked”, because the names were stored as one line of text and the table only read a list. The names were in the file the whole time; every spec already on disk now renders them.

A folder holding several specs is its own group, and rows inside it drop the words they all share, so Companion Commands holds Assembly, Capture, Nodes and so on. A healthy capability has no icon, so an icon always means “look here”.

A requirement you remove and do not undo is recorded next to the spec as removed on purpose, so validation stops reporting a change that names it as missing. Remove now only refuses while a requirement in another spec still leans on the one you are removing.

The instructions sent with the command named no folder, so the agent closed the step against the previous spec and the new one stayed on Specifying. Every call now names the folder the command created.

Initialize SpecKit, Upgrade Project and Upgrade All pasted the workspace path into the terminal command, so a folder name containing shell syntax would have run it. The terminal now opens in the folder instead, the way installing the companion extension already did.

When a newer SpecKit Companion is out, the notification now offers Update first. It installs the newest version your editor’s Marketplace serves, keeps automatic updates on, and offers to reload the window. If the install fails, it opens the extension’s page instead of doing nothing.

Its two illustration panels, the spec viewer and the Overview, were placeholders that said a screenshot belonged there. They now show the viewer with a finished spec open and the Overview of a completed run.

The intro, install, getting-started, viewer, sidebar, Overview, guides and reference pages were rewritten around a picture and a short tour, cutting roughly 40 to 55 percent of the words and adding screenshots to every page that names a feature. Two duplicate guide pages are gone.

The configuration reference now lists speckit.aiProvider and the two view-visibility settings, the permission-mode flags are right for Claude in VS Code and Wibey, the providers table has a Skills row and the right display names, the custom-commands guide covers the skill hook type, and the telemetry page names the Spec Kit version sent at activation and PostHog as the destination.

Implement used to build every story inline whenever the whole pipeline ran in one session, which is every auto run. It now sends each story with five or more files to its own worker, the same as a step run on its own. Plan no longer decides for itself whether to send workers: a script prints one reader brief per code area and one writer brief per design document, and plan sends them as printed. Each worker checks in, and the doctor warns when a finished plan had briefs and nobody checked in.

With no --feature-dir, the writer follows .specify/feature.json, which still points at the previous spec until the stock command creates the new folder. It printed “not regressing” and exited 0, so a transcript read as success while the new spec was never closed. It now exits 2 and names the flag to pass.

On a simple verdict specify writes the lean plan.md and tasks.md and records both steps, but auto and the workflow’s simple route dispatched plan and tasks anyway, overwriting the lean files and spending minutes on steps the fold had finished in seconds. Both now read the verdict and go straight to implement.

Loading them never fails by design, so a skipped load looked exactly like a project with nothing to load, and the run carried on without the context every other run gets. The health check reports it as a problem.

The conventions a rules file held are already in CLAUDE.md and in the linters that enforce them, and a second copy is one that can disagree with the first. A rules file an earlier run wrote is still read.

A test named for a defect, a Fixed changelog entry, a guard with no obvious caller: each is a past bug the code alone cannot explain, and each now becomes a requirement rather than being read straight past.

Adopting a code area now tests each requirement with one question, would someone planning a change here need this, and lists what it left out as found, not proposed so you can pull any of it back. At the end of a run, a new file no spec claims no longer forces a new capability: supporting code gets no requirement, and only something a person can now do gets one.

A living spec is context every later run loads, so what folds into it is now read by someone other than its author. Before the fold, implement hands the new and changed requirements to one reviewer with a short rubric: every requirement names behaviour someone relies on, one rule per requirement, a heading someone could check, behaviour rather than how it is built, and no filler. The reviewer edits them in place, and the doctor warns when a run folded without it.

It now warns when one requirement bundles more than four rules, when it takes more than 120 words to state its rule, and when a spec drafted from the code still carries its draft banner. A spec is now too large by its length alone, past 160 lines: it no longer warns past eight requirements, since splitting bundled rules raises the count without making the spec harder to read.

When a feature added a requirement to a living spec that ends with another section, such as Uncovered, the fold put it after that section, where the requirement tools do not read it. It now goes at the end of the Requirements section.

A requirement’s tasks and tests given as one comma-separated line are stored as separate names, the same as when they are passed one flag at a time. Written as a single line, they read back as no coverage at all.

Implement used to build the whole Foundational phase itself. Each Foundational wave of four or more independent tasks now goes to up to four workers at once, and the next wave starts only when they have all returned. Smaller waves, Setup and Polish still run in the main agent. The doctor warns when a finished implement skipped those workers, and it no longer faults a small fast-path run for plan readers it never had.

Plan, tasks and implement closed by the assistant are how a Companion run works, including older specs on the turbo profile, so they are no longer reported as closed by the wrong writer.

A failed capture call from before a run’s window used to be reported as a problem for that run. It is now a note saying failures from other runs sit in the shared log.

A node’s name is where a hook attaches, so replacing the node renamed it and every hook on it was warned about and skipped — the work stopped running while the panel still drew it. Hooks now follow the swap, the same way they already followed a renamed phase.

Swapping a node for one of its alternatives sent the grouping and the order as two writes, and each is checked against the other as it stands — so whichever went first was refused for disagreeing with the half that had not moved yet. It never worked outside the tests, which sent both together. Putting a dropped node back and handing a step to your own document had the same shape and the same fix.

A hook index that was not there — a panel drawn before someone edited the file by hand — printed “there is no hook 6” and left the file at zero bytes, taking every order, phase and hook the project had written. Six writes had that shape; all of them now compute the whole file before touching it, and publish it in one move.

Selecting As shipped in the Pipeline Builder’s Workflow dropdown switched every hook in your .specify/companion.yml off, and nothing anywhere said so — the board drew the same pipeline it draws for a project that never configured anything, and there was no way back except editing the file by hand. Now the header says which of the two is running and how much of yours is parked, and the board draws your hooks where they would attach, dashed and struck through and labelled parked, so you can see what you would get back. Nothing is deleted either way: the file is left exactly as it was, and Use this project’s pipeline in the header — or This project in the same dropdown, which is new — puts it back in one click. Switching there and back is a round trip; your comments and formatting survive it.

A row read Command spe… with git at the far end of the line: the name was cut on the speckit. prefix every one of them shares, the leading word named the mechanism rather than the work, and whose hook it was came last. Hooks are now grouped by whoever registered them, each group led by that source’s mark — your own under the Companion mascot and the file they live in, an installed extension’s under via <extension>. Only spec-kit’s own git carries the GitHub mark; another publisher’s extension gets a neutral one rather than somebody else’s logo. Each row is left to name the work, so speckit.git.commit reads as commit. A block also reads top to bottom in the order it actually runs, which it did not before: an extension’s before-hooks fire ahead of anything you attached and its after-hooks behind, so the two halves swap sides between before and after. Which hooks you can edit here is unchanged, and asks first still sits on the row it belongs to.

A + sits on every phase rule and opens the lot: add a hook, add a node, rename the phase, split it, merge it into its neighbour. All of that used to be invisible until the pointer arrived, so a board full of things you could change showed nothing that could change anything, and a touch screen reached none of it. A row that cannot run here is shown greyed with the reason — “one node here, so there is nothing to split off” — because a control you never needed still teaches you it exists.

A line at the foot of the panel names the change, offers Undo where there is one, and says what it means next: a change is not in the pipeline until Build writes it. Before this, a hook attached at the bottom of a lane you had scrolled past changed nothing anybody could see, and only refusals spoke.

Two menus stood side by side with nothing to say which was which. The first is labelled Workflow and names the configuration you are on; the second is a chip reading No changes or 2 steps differ from shipped, and clicking it takes you to the first lane that does. Beside them, a chip counting the hooks opens onto what the pipeline holds — how many steps, phases and nodes, and whose hooks these are — which was a native tooltip nobody could reach from a keyboard or a touchscreen.

Move up and Move down sit on the row that says the node can move; More holds what costs something — Remove from the run (which keeps the file, so it stays on offer under Add node) and Use the shipped node. Reordering used to be drag-only, there was no way at all to stop running a node, and handing one back was a hover control that deleted your copy with no notice and no way back.

A mark down its left edge separates a node that writes a deliverable from one that only reads context or sets things up, and a node that can stop the run carries the word gate, as one that cannot be reordered carries held. The legend for the marks sits in the node’s own panel.

The bare § is a template chip, the unexplained dot is the word changed, and the green pill is a file count. Three of the marks that meant nothing without hovering now say what they are.

Add step at the end of the board gives the run a turn it did not have — a review pass after implement, an audit you launch when you want it. Name it, say where it goes and what it writes, and the panel writes a step that already runs and opens the one node there is to edit. It gets its own command, its own place in the run, and every other thing a step has: nodes you can add and replace, phases you can name, hooks you can attach.

A node that has alternatives shows Replace in the panel: draft the spec as a delta against what exists, or as a fix contract; run the quality checklist as a gate that stops and asks instead of one that records and moves on; put each feature on a branch of its own. Picking one is the same write a drag makes, so the node stays editable and one click from the shipped one.

They appear in the same picker that puts a dropped node back, each with a line saying which it is.

Merging a phase folds its nodes into its neighbour rather than dropping work, and splitting one hands its last node to the new phase, because a phase with nothing in it cannot be saved. Moving a whole phase is deliberately not offered: across every step the pipeline ships, not one such move survives the dependencies between its nodes, so the arrows that used to sit there could only ever be refused.

The order and the grouping are written together.

Click the step’s name. _frame.md — the preamble every node sits under — was the one piece of a step’s text nothing could reach, and it can be replaced like any other node.

The middle band was the one part of the pipeline you could see and not touch — the nodes were reorderable and replaceable, hooks attached anywhere, and the group they sat in belonged to the extension. Rename a phase in place in the panel, or drag a node from one phase into another; both write the whole grouping to companion.yml. A grouping that leaves a node homeless, names a phase twice, or breaks a reads: dependency is refused with the reason.

It used to be a line at the bottom of the lane, below every node.

Its instructions render beside the canvas, along with what it writes, what it needs, and whether it can be moved. “Open the file” is still there for when the editor is what you wanted.

Nodes free to move show a grip; ones held in place show a lock that names what holds them — and says the lock is only about order, since you can still rewrite the node, attach work to it, or drop it entirely. In the shipped pipeline that is two nodes out of twenty-four: everything else is free to move, including into another phase.

A workflow is a whole named configuration in .specify/companion/workflows/; switch between them from the panel’s header. Switching swaps everything at once — order, hooks, templates, routing — so a one-line fix and a client deliverable can run different pipelines from the same repository. “As it ships” is always offered as the thing to compare against.

It used to open the whole assembled command and scroll to roughly the right place, which is the text the assistant reads but not the text anyone can edit. Now it opens the node file itself — your project’s copy where you have one, otherwise the shipped source.

The new order is saved to companion.yml with everything else in the file untouched, and an order the pipeline cannot honour — a node moved across a phase boundary, or before something it reads — is refused with the reason, leaving the file as it was.

Add hook asks where it runs first, then what it is: a skill the project already has, an instruction, a shell command, or one of your own nodes. Pointing at a skill is the one to reach for — the instructions stay in the skill instead of being copied into the pipeline.

Edit in a node’s panel opens its instructions; saving is what writes your copy into .specify/companion/nodes/, so making it yours and doing the thing you came to do are one action. The node is marked yours until Use the shipped node hands it back. Rewriting how a step is written used to mean forking the extension.

When companion.yml is newer than the commands built from it, the two disagree — the file says one thing and the command your assistant is handed says another, with nothing about a run looking wrong. The panel’s header states it whenever the two are out of step, with Build a click away.

Requirements, contracts and anything else nested under a spec did nothing when clicked: the viewer stored them under their folder and the click looked them up without it, found nothing, and left whatever was already on screen. It read as though the click had opened the Specification.

Both were drawn with white text on the accent fill — about 1.5:1 against the dark theme’s mint, so ✨ Refine (2) and the comment editor’s submit all but vanished. Refine now uses the same surface treatment as the other secondary actions beside it, and Add Comment takes the ink colour the accent fill is meant to carry. Both read clearly in the light and dark viewer themes.

Pointing a section at a different shape resolved a template correctly into a file the assistant had no reason to open, because Companion’s nodes carry their shape in their own instructions. A step you reshaped now tells the assistant to follow the resolved file; a step you left alone is unchanged.

A step a project added built, got a real agent command and recorded its runs, but the viewer never drew it: the rail showed the four shipped steps and the step had no tab of its own. The rail, the sidebar, the forward button and the run’s timing now all read the pipeline the project actually runs, so the step appears where its after: puts it, its document opens from the rail, the forward button dispatches it, and it counts toward the run’s phase coverage. Nothing is written to your settings to make it visible.

Replace the whole step, on the step’s own instructions, writes a node holding everything that step currently tells the assistant — the frame and every node’s instructions, frontmatter and fences stripped — and points the step at it. It says what it costs before you pick it. Replacing what a step does used to mean rewriting each of the nodes it happens to be made of.

Every row under “What was checked” used to carry a green tick, including the ones that were only the run saying it had done something — the command beside them was text it typed, not proof anything ran. Checks the pipeline runs now show the exit code and how long they took; anything the run merely reported sits below them, quieter, and still readable. The count says how many of each.

Once a panel had been used to read any document, it answered with that document for the rest of its life: every later click on the spec name was overruled by what you had opened first. Clicking a document, step or artifact still opens what it names.

Writing a constitution leaves a summary at the top of the file listing every placeholder it filled in, and the sidebar was reading that summary as the placeholders still being there. Any project whose constitution was written by the assistant saw Configure Constitution forever.

Every document row — Research, Data Model, Requirements — opened the Overview instead, on any spec that had been run at least once. The deepest, most specific rows in the tree were the ones that did the least. Clicking the spec itself still lands where it did, and getting back to the Overview is still one click from inside the viewer.

The Specs title bar had a … menu whose only everyday entry was Collapse All, so opening the tree cost two clicks and a menu you had to read. It is a normal icon now, showing whichever action the tree’s state calls for, and the view no longer has an overflow menu of its own — the sidebar had two … buttons a few pixels apart with nothing to tell them apart. Install Companion Extension and Upgrade… moved to the Command Palette. Specs also gains the Refresh its two sibling views already had.

Create New Spec used to leave a blank filled strip between the workflow picker and the Feature Brief whenever there was nothing to say about the selected workflow. The space now closes up, and the workflow blurb still appears when there is one.

A name can be a phase and a node at the same time — the auto step ships one, orchestrate — and the board tested the two independently, so a hook that runs once got two chips and the header’s tally counted it twice. It is now drawn on the single boundary the built command actually places it at, and the count agrees with what you are looking at. Parked hooks follow the same rule.

Progress, the phase-complete notice and the check that implement has finished all count checkboxes in tasks.md, and they counted every checkbox — including the verification notes and prose checklists that sit among the tasks. The spec-kit half never counted those, so the two could disagree about whether a run was done. Both sides now require a task id (T001), which both task templates emit, and a shared set of cases holds them to it. A hand-written tasks.md whose items carry no id will read as no tasks; give them ids to have them counted.

handoff is a node in every step, so specify and plan both have one as a hook anchor. Removing the last hook under one of them deleted the first block of that name in the file — another step’s, hooks and all — and left the emptied one behind.

It travelled as a removal and an addition sent separately, so both rewrote companion.yml at the same time and whichever finished last won — and if the addition was refused the hook was simply gone. It moves in one write now, and a refusal leaves it where it was.

The Pipeline Builder could draw every hook your project runs, including the ones installed extensions registered, but adding one was a free-text box: to attach the automatic commit you had to already know it is spelled speckit.git.commit, and nothing in the panel told you. Choosing a kind now offers what this project actually has for that kind, each entry saying in plain words what it does, who registered it, and where it usually goes. The list is derived from your own registries, so an extension you install tomorrow appears without anything changing here, and a project without the git extension is offered none of its hooks. Typing a name by hand still works, beside the list rather than instead of it.

The VS Code extension updates itself from the Marketplace; the spec-kit extension it pairs with is installed per project and never does, so the two drifted with nothing to say so. Now a SpecKit commands out of date item appears in the status bar the moment the commands installed in your project are older than the ones this release expects, the install banner in Create Spec and the Activity panel names both versions with a single Update button, and a notification tells you once per version with Skip this version to silence it. Every one of them runs the same one-click specify extension add update and disappears as soon as the versions match. The comparison is local, so it works offline and never guesses when a version can’t be read. A project without the spec-kit extension keeps the existing install prompt.

The Create New Spec form spent about 230px on a single either/or and pushed the Feature Brief below the fold, so the box you came to type in was off screen. What Companion offers, whether it needs installing, and the offer to try it for one spec all moved into a banner under the picker.

A build used to take the editor to tell you it had worked. It reports in the header now — “Built 14:02 · 5 commands written”, or which commands a preview would change — with the whole log one click away and the output channel keeping it either way.

New workflow… now asks what to start from: what this project runs today, the pipeline as it ships, or one of two whole configurations Companion ships. Classic spec-kit puts the stock document shapes back — prioritized P1/P2/P3 user stories, the full Technical Context block. Brownfield is for changing a system that already exists: the spec says only what changes, the task list is attacked before it runs, and a person opens the thing before it counts as done. Picking one copies it in; everything in it is yours to change from there.

research.md, data-model.md and contracts/ were produced by a node that declared none of them, so the manifest, the builder and the verifier all had plan down for a single document. A node can now declare what it may write as well as what it always writes — the size budget is allowed to fold those away at simple, and a run that does is working, not failing.

Every hook could be added and none could be touched again; getting one wrong meant opening companion.yml. Click any hook to edit it in place, or remove it — and the anchor it was the last hook on goes with it.

The skill and node fields offer what this project actually has — 35 skills and 9 node files in this repository — rather than a blank box where a typo produces a hook that invokes nothing.

A hook another spec-kit extension registers sits in the same place and the same shape, marked ext.

The panel showed the hooks you wrote in companion.yml and nothing else — but a Companion run also fires the hooks your installed spec-kit extensions register in .specify/extensions.yml. This repository’s own panel said 9 when the answer was 21. Both are shown now, the extension ones listed under the step they fire on, marked with which extension registered them and whether they ask first.

Attaching work and naming a new workflow used editor pop-ups that covered the thing you were pointing at; both are forms in the panel now, and a refusal comes back as a line in the panel rather than a toast. Nothing about the view depends on being inside VS Code any more.

The steps are columns in run order — specify, plan, tasks, implement as shipped — instead of one tall stack sorted alphabetically. auto sits in the tail of the row under Outside the run and says what it is: the command that runs the others, not a step of its own. Narrow the panel and it folds to two columns, then one.

The workflow-editor commands (edit source, refine section, remove section, add user story, approve and continue, regenerate, navigate to phase) were left over from an editor that no longer exists — running any of them wrote a line to an output channel and nothing else. Their right-click menu entries are gone with them.

Opening a capability lands straight on its requirements, with no Overview and no tab strip; the Rules and Coverage files still open from the tree. Each requirement is a card in the same shape as a user story in the specify step, and its left edge tells you its state: the accent colour when confirmed, purple when adopted and not yet confirmed, amber when the code it describes has changed. A pill above the title names the state and says in one line what it means; the files the requirement touches, and the file an adopted one came from, sit under the title as chips. Approve and Remove sit at the card’s foot. The header counts them, the outline repeats each colour as a dot, and the bar at the bottom says whether the capability is in sync and offers Adopt an area, Validate, and Sync. A requirement names how many files it touches in one quiet link, and a capability with no spec yet opens straight to Adopt this area, which adopts the folders it already covers without asking. Validate checks only the capability you have open.

Each requirement an adoption transcribed carries an Approve control beside its badge, and the header has Approve spec for the whole file. Approving removes the marker that says a requirement is unconfirmed, and once the last one goes the draft banner goes with it; nothing is written into the spec, only taken out.

When a requirement in one living spec names the file that changed, the other specs claiming the same folder through a broad pattern stay in sync. Before, one change to a shared folder flagged every capability in it.

Inline comments on a living spec could be added but Refine did nothing, because comments are stored in the feature spec’s context file and a living spec has none. Refine now sends the comments in the open viewer straight to the AI as the same in-place edit a feature spec gets.

The panel used to disappear entirely when the Companion spec-kit extension was missing, so there was nothing to discover and nothing to click. It now stays put and shows what to do next: install the extension when it is absent, or set living specs up when it is there. Setting up asks one question — whether specs live next to the code or all under one folder — writes the registry itself, and offers to adopt a first code area. Nobody hand-writes that file any more.

The wand in the Living Specs title bar used to start adopting the moment it was clicked, with no way to say what to adopt. It now offers the directories in your project, takes a typed path for anything not on the list, and passes your answer through, so adoption works on the part you meant.

The prompt lets you tick more than one directory, or pick the whole project, and adoption brings the full proposal to one review before writing anything. For a whole-project adopt it says how many capabilities and spec files that comes to, and offers a coarser and a finer cut with the count for each, so the size of the result is a choice rather than a surprise.

Right-click a capability and pick Move Living Spec… to send it next to its code or into the central folder. Invoked from the command palette it moves every spec at once. The layout you pick at set-up is no longer a decision you are stuck with.

Adoption reads your project’s own conventions and writes down what it finds, and nothing has checked that what it wrote is true. Each of those requirements now carries an adopted from badge in the viewer naming the file it was transcribed from. The badge goes on its own the first time a real feature change updates that requirement, because building against a rule is what confirms it.

Once living specs are on and nothing is adopted yet, the panel offers to adopt a code area, rather than a row saying there is nothing here and leaving the wand icon to be discovered.

The bar at the bottom of every living spec now carries an Adopt an area button, so the moment a spec makes you want another one you can ask for it without going back to the sidebar. It asks which area, the same way the sidebar’s wand does.

The answer is stored when living specs are set up, and adoption reads it, so a project set up as central no longer gets colocated specs because a second prompt was answered differently.

It was drawing a row that said there were no living specs, and a row is enough to make the panel look occupied, so the Install and Set up buttons behind it never appeared. The panel now steps out of the way and lets them show.

It used to render exactly like a fully covered one — both showed nothing — so “we have no number for this” read as “nothing to report”. The three states now look like three states.

Every living spec used to show “In step with the code” beside Update all drifted and Check for drift, even when there was nothing to update. The drift notice and its actions now appear only once drift has been found.

A requirement says which files it describes on the line below its heading, and a markdown formatter puts a blank line there. That blank line used to erase the marker as far as the extension was concerned, so a run quietly read whole specs while reporting that it was reading only the parts it needed. Any project whose pre-commit hooks format markdown had this.

Companion now writes specs/012-offline-queue/offline-queue.spec.md instead of spec.md, so three open specs read as three features in the tab bar rather than spec.md three times. The Specs tree, the viewer, step completion, and the living-spec checks find either name, so specs written before this and specs a stock /speckit.specify writes next to them keep working unchanged.

A project with no living-specs registry — which is every project straight after specify init — was told to set enabled: true in a file that does not exist. It now offers to set living specs up instead.

A drifted capability said drift and stopped there; the action that repairs it existed only in the right-click menu, so hovering the row showed nothing. It is now a button on the row itself.

It carried an action only once drift had been found, so it was emptiest in the state you are in most of the time. It offers a drift re-check otherwise, states where the spec lives once instead of twice in two near-identical forms, and the adopted-from note no longer outweighs the spec’s own content.

Living specs answered “which rules apply to this change?” only from inside a run; sitting in a source file there was no way to ask, short of reading the registry by hand. The status bar now reads 2 living specs for whatever file is open, and clicking it lists the capabilities that claim the file with the requirements that describe it underneath, so one more click opens the spec on that requirement. Nothing appears for a file no capability claims, and the whole lookup happens inside the editor, so there is nothing to wait for.

Saving any *.spec.md now checks its shape and puts what is wrong in the Problems panel, on the line it is about: a requirement stating a rule with no scenario, a scenario with a condition and no outcome, two requirements sharing a heading, a delta pointing at a heading the target does not have. The problem clears when you fix it. Nothing is checked for a file that is not a spec, or for a project that has not turned living specs on.

A 400-line capability meant scrolling to find anything, and the outline beside the document showed only its three section headings unless you went looking for the Subsections toggle. It now lists every requirement by default, each with a dot for whether its test coverage is known and a count of the paths it claims. Click a row to jump to it.

Refresh and Sync were both circular arrows, so the instant local redraw looked identical to the button that starts an AI run and rewrites your spec files. The two that run the AI now carry a different glyph, and a drifted capability is marked by a different icon rather than the same icon in another colour.

The template chip on a step opens its document’s shape — one row per section, each offering the alternatives written for it and “As shipped”, with a line saying what each one gives you. Swap prioritized user stories for observable outcomes or numbered WHEN/THEN/SHALL requirements, put the stock spec-kit shapes back, or add a constraint block to the task list.

Claude Code registers Companion’s commands with dashes, and several of the buttons dispatched them with dots instead, which resolves to nothing at all. Every command the extension sends now carries the spelling the assistant actually registered. Cursor and Antigravity had a narrower version of the same bug, where only the first dot was converted.

Both halves worked out where the lock lives from the temporary directory their own process was given, so they agreed only when their environments did. A terminal started somewhere the editor’s environment does not reach — over SSH, from a wrapper, inside a container — would take no lock the editor could see, and a write could be lost with nothing to say it happened. Both now use one fixed place.

Two programs keep a spec’s run record: the editor, and the commands you run in a terminal. Each one used to guard only against itself, so a write from one that landed while the other was mid-update was thrown away without a word — a finished step could quietly read as unfinished again, in a file that looked perfectly fine. Both now take turns on the same lock. A writer that crashes mid-update is noticed and its turn taken over straight away, a writer that is still working is waited for rather than talked over, and nothing waits forever. Reading a spec was never blocked and still isn’t.

Every customisation the panel made — a hook, a reordered step, a swapped node, a rewritten one — was written into the extension’s own copy of the commands, and your assistant reads a separate copy the installer rendered once at install time. So Build reported five commands and changed nothing that would ever run. It refreshes those copies now, and says how many and where.

Its command was built into a file nothing could dispatch: the installer only knows the commands Companion ships, so no reinstall could ever register a step you wrote. The build now gives it a real agent command, in the same format the ones beside it use.

The update banner only ever compared against the copy bundled in the editor extension, so a project running an old spec-kit extension stayed quiet until the editor extension itself updated. It now measures against what has actually been published, and remembers it between sessions, so the warning still appears on the ordinary starts where the daily update check is skipped. What a check learns is only ever newer than what is already remembered, so a check that happens to find nothing cannot erase it.

The extension package had been carrying every video render behind the README GIFs and the landing page, which nothing in the extension ever reads. They stay out of it now, so the download and the install are the size of the extension itself.

A fresh workspace without the spec-kit extension asked five times in the first minute, and three of those asks ignored every “don’t show again” there was. Two remain: the activity-bar badge and the pinned row in the Specs tree, both ambient and neither interrupting anything. The prompt when you create a spec is answered once and then remembered, and the warning about falling back to standard SpecKit is said once per session instead of once per pipeline step.

VS Code opens a Get Started with SpecKit Companion page after install, and Help → Get Started reopens it any time. Six steps with their own buttons: open a project, read the bundled sample spec, install the Spec Kit CLI, set up the project, write your first spec, and read the Overview the run leaves behind. It appears even in a workspace with no specs and no setup, which the sidebar’s empty states never reach, and the CLI steps tick themselves off once the CLI and the project are actually detected. Two of the steps ship a clearly marked “illustration under construction” panel until the real screenshots are shot.

The one-time cleanup that turns retired and legacy settings into their current shape gave up on everything still to migrate as soon as one write was rejected — a settings file with a syntax error, for instance. Each write now stands on its own, so the rest still land, and the reason for the one that failed is written to the SpecKit Companion output.

Specify, plan, tasks and implement share one rule: check whether the thing needs to exist at all, then whether the codebase, the standard library, the platform or an existing dependency already does it, before writing anything new. The same test applies to the documents a run produces — a section nobody acts on is removed rather than filled in, a requirement is not written for what a type or a test already enforces, and a third acceptance scenario has to cover a failure the first two miss. A corner cut on purpose is named in the code and recorded as a concern, so it can be found later. Adapted from Ponytail.

Each step in the pipeline already declares what it writes, and nothing ever compared that against what ended up on disk — so a step that quietly stopped producing its document finished looking exactly like one that produced it. The report now names the missing file and the part of the step that was supposed to write it. It is a warning, not a failure: a document the size budget is allowed to fold away is not counted, and a spec built by an older or different pipeline reports no record rather than a fault.

Seven fragments ship — observable outcomes or numbered WHEN/THEN/SHALL requirements instead of prioritized user stories, the stock spec-kit shapes for projects that want them back, and three constraint blocks for the task list. A fragment you write with the same name as a shipped one replaces it.

Two ship: Classic spec-kit, which puts stock spec-kit’s document shapes back, and Brownfield, for changing a system that already exists — the spec written as a delta, the folder numbered against every branch, the task list reviewed for gaps, and a manual click-through before the work counts as done. A project starts from one and changes it from there; nothing about it is fixed afterwards.

The status report said “Decisions: (none recorded)” on every real run, even with a dozen decisions sitting in the spec’s record — it only ever recognized decisions typed in by hand, which is why the sample specs looked fine while live ones silently lost the most useful thing they had captured. Every recorded decision now appears, in the order it was made, alongside any hand-written ones. A single malformed entry is skipped on its own instead of blanking the whole section.

_order.yml takes an optional: list and a variants: map, so Companion can ship alternatives without running them: the spec as a delta for a change to something that already exists, the spec as a fix contract (defect, expected, and what must not change), a quality checklist that loops and then stops and asks, a feature branch of its own, and a manual click-through gate for the person who has to open the app. The adversarial gap review that has been in the tree since it was written is offerable now too.

Closing a task was two calls to the same script, one to record it and one to make it visible; it is now one, and the script had shipped that one-call form for months with nothing using it. Specify’s wrap-up was about eleven separate writes of the same file and is now a single one. Every step re-read the workflow definition to learn which step came next, which is a constant, so each step now names its successor outright. Companion’s own lifecycle hooks fired on Companion runs and rewrote what the step had just written; they still serve stock runs and are skipped on a Companion one. And completion was written three ways at the end of implement — the step’s own final node is the only one that writes it now. Nothing about what gets recorded changes, only how many times the run stops to record it.

workflow: shipped in .specify/companion.yml selects no configuration at all, and there was no way to write the selection back off again — once a project was on the shipped pipeline it stayed there unless someone edited the file by hand. An empty workflow name now takes the line back out. Switching to the shipped pipeline and back is an exact round trip: the file you get is the file you had, comments and blank lines included. The pipeline a panel draws also carries the hooks the shipped selection is bypassing, marked as parked, so a project’s own configuration can be shown rather than silently dropped.

rename_anchor was reached only by a phase rename, so swapping a node for one of its variants left every hook pointing at the old id — warned about at build time and skipped.

A directory of nodes under .specify/companion/nodes/<step>/ becomes a real step: it assembles into a command, and a run of it is recorded like any other. Steps are no longer a fixed five, so “review the change before it counts as done” can be a step rather than something hidden inside implement. Where it runs is one key in its own order file — after: implement puts it in the sequence, and leaving it out makes it something you launch when you want it.

build-pipeline.py turns .specify/companion.yml into the commands the assistant reads: it resolves which nodes each step runs, splices in the hooks the project declared, resolves any template it reshaped, and writes the bodies with a manifest beside them. Until now the configuration could describe a different pipeline and the shipped one ran regardless — the recipe and the hooks were resolved and then discarded. Preview first with --dry-run, which diffs against what is currently built and writes nothing. A build that cannot finish — a recipe naming a node that does not exist, one that drops a node another still needs, a configuration outside the readable subset — says which, and leaves the working pipeline exactly as it was.

commands.<step>.nodes was limited to nodes that ship, so replacing what a step does meant rewriting each of its nodes in place rather than handing the step to one document. A name that is neither shipped nor written is still refused, by name.

commands.<step>.phases replaces the shipped grouping with a list of {name, nodes}. Phases are hook anchors, so this is a real edit rather than a relabelling — and the build refuses a grouping that puts a node in two phases, names two phases the same, leaves a node without one, or orders nodes against their reads:.

A recipe that swapped two nodes in the same phase produced a byte-identical body while the build printed “reordered” — the phase grouping kept the shipped order regardless of what was asked for. The recipe’s order now decides. Because a phase is one contiguous run of the command, an order that interleaves two phases cannot be built: that is now refused by name instead of quietly rewritten to the nearest thing that fits.

Drop a file at .specify/companion/nodes/<step>/<node>.md and it replaces the shipped node of that name — the recipe could already drop, add and reorder nodes, and hooks could add text around one, but the words inside a node belonged to the extension alone, which left “we write specs differently here” with nowhere to go except a fork. A build says which nodes came from the project, and the shipped sources are never touched, so an upgrade neither overwrites your version nor quietly reverts it.

Each step’s nodes are now grouped into named phases (gather, author, check, wrap-up). A hook can attach to a whole phase instead of naming a single node, and the step is still one dispatched command, so nothing about the instruction budget changes.

The markers are HTML comments: invisible when the body renders, and the instructions are unchanged — the build proves it by stripping them and comparing to the frozen bodies.

That declaration had sat in the node files for a long time with nothing reading it.

Every step ends by handing off to the next one, and nothing expressed that — the dependency vocabulary could only say “after that particular node”, which stops being true the moment the middle is reordered. So the handoff was free to be moved anywhere, and a real project ended up running it before the node that records the step finished: planning was told to start while specify was still officially in progress. An order that moves it is now refused, and says which node would have run too late.

A suite, build or lint is captured by running it and keeping the exit code, so the Overview can show what actually happened rather than what the run says happened. Judgements that cannot be run — a manual pass, a warning you looked at and accepted — are still recorded, and are now marked as your account rather than as evidence.

A small phase costs more to hand out than to build, so only the substantial ones are, and the run says which it did which way. On a feature with small phases this halves the cost and changes nothing else; on one with large phases the parallel work still saves you minutes.

A slash in front of a dotted name is a name that resolves to nothing on an assistant that registered the dashed spelling, and worked examples throughout the shipped commands were quietly outvoting the rule that says to use the spelling your project installed. The status and resume commands were the sharp end of it: they printed a dotted name as the next thing to run, and resume dispatched it, so on Claude Code the pipeline told you to type something that resolves to nothing. Both now carry the spelling rule themselves.

Every pipeline command carried the reasoning behind its own rules: the measurements that justified them, the runs that went wrong before them, the case for why they exist. That was written for whoever maintains them, and it was shipped to every run. The rules are unchanged and none was dropped. What went is the argument for them.

Implement dispatches a worker per user story so the files each story needs are read once, in the worker, and never carried by the main run. At the end of an auto run that saving is already gone: specify, plan and tasks opened the code in the same session, so a helper would read it a second time for nothing. The rule now says which case it is in, and a run that keeps a story to itself says so in its summary. A run invoked as its own step still hands off every story, as it always did.

Where an editor or a harness starts a step and tells the command when it did so, that timestamp is what the step’s start carries. Only a start accepts one; every other boundary is still stamped as it happens.

Where your host has subagents, every user-story phase now goes to one and the checks at each join go to another; the main agent keeps setup, the foundational phase and polish, and folds each result as it returns. To make that safe the tasks step gives every file exactly one owner phase and opens each story phase with the files it owns, so two workers can never land on the same file. A host without subagents builds the phases in order exactly as before. On one measured run the main agent carried half the tokens it had the round before, for the same feature and the same passing suite.

A hook’s anchor could match the step’s own name, a phase name, and a node id, and the structure a panel draws from tested all three independently — so a hook attached to a name that means two things at once was emitted twice for something that runs once. Which boundary wins is now defined in one place, beside the splice that already implemented it, and the structure reads the same definition. A phase and a node may still share a name, which the shipped auto step does.

Specify records the areas it read and what it found there; plan re-read the same code from scratch, which was the single longest stretch of a measured run. It starts from that record now.

The GUI counted every checkbox in tasks.md while this half counted only lines carrying a task id, so a spec whose task list also held verification notes could look finished to one and unfinished to the other. Both now require the id (T001) that every task template emits, and a shared set of cases holds them to it.

extension.yml lists the commands the extension ships and is what the installer reads, so a step a project added could never appear there — its built body sat where nothing could dispatch it. The build writes that emission itself, modelled on a sibling the installer really produced rather than on a guess at seven agent formats, one of which is TOML. An area with no sibling is skipped, and an emission that already exists is never overwritten by creation.

A freshly created workflow writes its step as an empty mapping, and adding an order, a grouping or a hook to one wrote the new keys underneath that value instead of inside it. The result was a configuration the reader refused — from the panel’s own first write.

The selection was written first and only failed on the next build, so the panel said “now running ‘bugfx’” and from then on every build and every draw of the board failed on a name that pointed at nothing.

Six writes were shaped open(path, "w") and then computed what to put in it, so anything that raised — a stale hook index, a section a template does not have, an order the phases cannot express — truncated the configuration to nothing first. They compute in full and publish through a rename now, so a crash cannot leave half a file either.

The outermost anchor was a phase, so a hook meant for the whole step had to name whichever phase happened to be first, and moved when that changed.

.specify/companion/workflows/<name>.yml holds a whole configuration, and workflow: <name> in companion.yml selects it. The selected file replaces companion.yml rather than merging with it — switching is meant to swap the whole pipeline, and a merge would produce a third one nobody wrote. The reserved name shipped selects nothing at all. Nodes and fragments are shared: a node you write once is available to every workflow.

{ type: skill, ref: verify-code-review } renders as an instruction to invoke that skill at that boundary. A project that has written a skill has already written the instructions; the other hook types would have meant copying them in, and a copy forks the first time the skill is edited.

A hook declared in companion.yml is now rendered where it attaches: a command becomes a runnable block, a prompt becomes an instruction, and a node hook splices another node’s text in whole. Each lands outside the block it attaches to, so it never edits that block’s own instructions.

It used to satisfy “validate against the spec” by reading the code — so a run could write tests, never execute them, and finish looking green. Where the checks genuinely cannot be run, that is recorded as a concern rather than written up as a verification that happened.

Reaching for an ordinary YAML convenience — naming a block with an anchor and reusing it elsewhere with an alias — used to parse without complaint while everything from the anchor onward was silently discarded, so review and pull-request hooks looked configured and simply never ran. Indenting with tabs and writing a value as a multi-line block scalar failed the same invisible way. Any of these now produces the same single warning naming the line, and the shipped defaults are used — as does anything else the reader cannot read to the end of the file, so a partly-applied configuration is no longer possible. Configurations that work today are untouched: shell commands, redirects, and quoted globs all keep parsing exactly as before.

It said to point the project’s active-spec pointer at the new folder without saying what to write in it, and the calls that later look the spec up through that pointer — the ones that record whether the change is small enough to fast-track — are deliberately best-effort, so an unrecognised pointer made them skip in silence. The result was a run that looked complete while the routing decision it had just made was nowhere on record.

Name a capability and only its spec is checked; with no name it checks every living spec and active feature spec as before. An unknown name is reported as skipped, never as a clean result.

Measured across a whole project, drift is only ever read once it has piled up, and by then it is on nearly everything and tells you nothing. A capability whose spec you also wrote reports nothing, because that is the loop closing.

Drift is measured from the moment a spec was last written, so a spec nobody needed to change drifted further every week and there was no way to record that someone had read it and found it right. living-drift --accept <capability> writes down the version it was checked against. Nothing records that for you: reviewing is a claim you make.

A requirement can point at a rule under another capability, and until now nothing asked for that link to be followed, so it was written down and never read. Adoption also proposes those links while it reads an area, since that is the one moment anyone can see them.

A capability whose pattern points at the wrong place claims none of the files a change to it edits, so the run is told about no capability at all and proceeds as if nothing had been written down. Validation now reports that case.

It was the other way round, so a worker relearned from source what a requirement already stated, and the two could disagree with nothing to reconcile them.

Plan pulled it on larger changes and implement handed it to each worker, and neither could be shown to change what got built. The files are untouched; only the instructions to read them are gone, until there is a reason to put them back.

Off by default while it is measured; turn it on from the pipeline builder.

The marker is read from the first line under the heading that is not blank, rather than strictly the next line, so a formatter’s blank line no longer unmarks every requirement in a spec and sends every load back to reading the file whole.

Adoption was writing import direction, file naming and path helpers as the requirements of a capability, which is a style guide rather than a specification: someone opening a spec to learn what a screen shows found a linting policy. What the area does now goes in the spec, and the conventions go in the architecture file beside it, which only an architecture-significant plan ever reads. Both are written from one adoption run.

Adoption proposed one capability per folder, which on a nine-folder area produced ten capabilities, nine of them saying only that the folder had no rules of its own. It now reads the area, works out what someone can actually do there, and brings that list to you with a rough size for each and a coarser and finer option, before anything is written. A slice with nothing of its own is not registered at all: the capability that covers it already answers for its files.

A run that introduced behaviour no capability owned yet wrote the requirement, reported a successful fold, and dropped it without a word. The fold now names the missing capability and the command that creates it, and folding again picks it up without disturbing what already landed.

Half the commands and docs still called the central path capabilities/<name>/spec.md while living-move wrote and documented capabilities/<capability>/<name>.spec.md, so the first thing a new reader learned about central layout was a filename the tooling no longer writes. The registry’s own default has moved to the current shape too. A project written before the rename keeps working: a capability that declares no path is pointed at whichever of the two files is actually on disk.

Every requirement adoption transcribes now records the file and line it came from. Nothing has verified those requirements, and the mark says so. The first time a completed feature folds a change onto one of them, the fold removes the mark, because a run that built against a rule has confirmed it. Nobody reviews a queue and nobody presses accept. When the last mark in a spec goes, the spec’s draft banner is reported as stale so it can be removed too. This is the answer to the objection that specs written from existing code go stale: the parts nobody has checked are visible, and they clear themselves as the code is worked on.

A spec past eight requirements or a hundred and sixty lines is split; one that comes out under three requirements while siblings sit beside it is called out as a paragraph with its own file and merged back. Re-adopting an area that already has a spec now works from that spec rather than from the code, moving each requirement across untouched, and one call can name the entry it supersedes so the registry never points at a file that is gone.

Past eight requirements or a hundred and sixty lines, living-validate reports the spec as too large and names where its siblings go. Adoption splits a capability into a folder of granular specs at that point rather than writing one long one, and it now cuts a codebase where that codebase’s own rules live — by layer in a layered project — because a capability drawn around a business noun has nowhere to record a rule that sits between layers.

/speckit.companion.specify now writes <name>.spec.md — specs/012-offline-queue/offline-queue.spec.md — instead of spec.md, so a tab bar with several specs open says which is which. Every later step, the status and doctor reports, and the living-spec fold read whichever name a spec was written with, so a stock /speckit.plan run on the same project and specs written before this change keep working as they are.

A capability’s spec runs to hundreds of lines and almost every question about one is about a single requirement, so the only way to answer it was to open the file and scroll. /speckit.companion.living-show prints the slice: a capability’s requirement headings, one requirement with its scenarios, or the rules that describe a file you name. It uses the same parser a run uses, so what it prints is what a run reads. Every answer comes back cleanly, including the awkward ones — a capability that is not registered lists the ones that are, a heading that matches nothing lists the headings that exist, and a name that matches two requirements lists both rather than picking one.

Conventions about how your specs and plans should read lived in whatever people remembered to paste into chat, so they were applied unevenly and invisible to anyone reading the repository. A rules: block in living-specs.yml now carries a short list of one-line rules for the spec step and another for the plan step, and each step sees only its own. They cost no extra work in a run, and a run records the guidance it was given. A project without the block behaves exactly as before, and a block that will not parse is skipped with a warning rather than stopping the step.

A living spec is only worth keeping if what lands in it is trustworthy, and nothing checked. A requirement stating a rule with no scenario, a scenario with a WHEN and no THEN, two requirements sharing the heading that fold-back and coverage both join on, a delta marked for a capability that does not exist, a delta naming a heading the target does not have, a file marker matching nothing on disk, a code fence opened and never closed — all of it landed silently and was found weeks later by whoever next read the file. /speckit.companion.living-validate now reports every one of them with the file, the line, and a one-line fix, and never fails the shell it runs in. The fold runs the same checks before it writes, per capability, and refuses to apply a delta that would damage the record, naming what it refused on. A capability with a sound delta still lands even when a sibling is refused.

A fold that would leave a capability with no requirements at all is refused, and the refusal names the capability. A stale spec is recoverable; an emptied one has lost the thing that made it worth keeping. Retiring a capability is deliberate, so it is declared as one: retire: true on that capability in living-specs.yml. Absent reads as false, so nothing changes for a capability that never mentions it.

Starting a feature used to read every line of every capability it touched — on the largest one here, 509 lines to describe a change to a single file. A requirement can now name the files it describes, and a run reads the capability’s purpose plus the requirements about the files being changed: 73 lines instead of 509 on that same capability. Adopting a code area and syncing from your changes write those file names for you, so nothing new is yours to maintain. A requirement that names no files is read by every run, so a spec you have only partly adopted simply narrows less — it can never leave a run under-briefed.

It reads the check’s name and its outcome as separate things instead of searching the whole entry, so an unrelated note can no longer supply the verdict, and it understands negation — “no drift found” reads as clean, “not in sync” does not. It deliberately stays quiet on a bare “clean”, because nothing distinguishes a clean project from a clean note about tooling, and wrongly accusing a run of dishonesty costs more than missing one.

Previously, when one of several file moves failed (a read-only target, a removed source), the moves already made stayed in place while the registry still pointed at the old paths — the two silently disagreed with no way back. Now every applied move is undone — including the folders the failed move had already created — and the project is exactly as it was before the run.

Registering a capability rewrote both the living-specs registry and your companion configuration in place, so an interrupted write could leave either one empty or half-written — taking your other companion settings with it. Both now go through a temporary file that is flushed to disk and then renamed into place, so what is on disk is always the previous or the new state — through a crash, a kill signal, or power loss. A write that fails cleans up after itself instead of leaving a stray file next to the real one, two runs at once can no longer leave a torn half-written file behind, and a file’s permissions survive the rewrite.

Capture already took turns with other captures, but the editor writes the same run record too, and the two could not see each other — so a capture that started before an editor write finished would publish the copy it had read and quietly undo it. Both now take turns on the same lock, held for the whole of a capture’s run rather than dropped between its first write and its last. A capture that crashed is recognised as gone and its turn taken over at once, so it can never wedge a later run; one still working is waited for instead of overwritten.

A step’s completion was written only by its after-hook, and a hook is a block of text asking a runtime to dispatch a command — in a terminal session that runtime is the same assistant that just printed it, so “running the hook” and “printing the word Executing” look identical. One run sat with its next step unreachable for eight and a half minutes because of it, and that wait is now permanently part of that step’s recorded duration. Every step now closes itself as the last thing it does. The write is idempotent, so when the hook did fire nothing changes.

Recording what was verified, decided, and covered issued one command per item, each rewriting the whole context file — on one measured run that was 617KB written to carry 7KB. It is a single batched call now, in specify, plan, tasks and implement alike.

When the spec directory cannot be written to, some captures still land but the trace file recording them never gets created — and the check read the missing trace first and reported “nothing captured yet”. It now reads the unrecorded-calls marker before deciding, so the one failure that leaves no trace at all is the one it can finally name.

Running your project’s own checks was an instruction with nothing watching it, so a run could write code, tick off a task called “add a test”, and finish with nothing ever executed. The report now names an implement step that recorded no check it actually ran. A spec that never reached implement reports no record, not a problem.

The clock started partway into each step, so the extension hooks and the first slice of work sat outside the window the step later reported — on one measured run half the elapsed time belonged to no step at all. Every step now stamps its start before anything runs on its behalf.

The check waited a flat thirty minutes before calling a step stuck, so an eight-minute stall reported clean. It now judges a step against its own recorded pace: one that was logging every minute and has said nothing for eight is named.

The step-name guard was resolved before the feature directory, so the bare hook form of a start — which carries no --feature-dir — consulted only the steps that ship. A misspelling is still refused, by name.

Every capture reads the spec’s record, changes its part, and writes the whole thing back — so two arriving at once each started from the same copy, and whichever published second silently discarded the other’s work: twelve simultaneous saves left four recorded, with no warning and a perfectly valid-looking document at the end. Writers now take turns, each holding a short-lived lock across its whole read-modify-write, so every save lands. Reading is untouched — the health check and status reports never wait on a writer, and a writer never waits on them.

Its drift check reads what a run recorded to see whether an earlier claim contradicts the recomputation. An entry with nothing readable in it was stringified into a claim anyway, so a malformed record could be reported as a run asserting something it never said. Such an entry is now skipped.

Commands carry dotted names as their canonical id, but several assistants install them with dashes, and a step that told you to run a dotted name on one of those hosts named something that does not exist. Each pipeline command now checks how the commands are installed in the project before naming one.

A Gemini command wraps the same instructions in a TOML string, and writing a plain markdown body over one produced a file Gemini could not dispatch. That file is left alone now — and named, rather than passed over silently while the build reported five commands written.

Where the classifier’s verdict sends a run — fold toward implement, or run everything — was written in three places and expressible in none. It is data now, and a project can move it; the build states the routing it resolved and tells the assistant when the project changed it.

Every hook command your registries hold travels with the structure, each with its description, the extension that registered it, and the lifecycle step it usually attaches at. A command registered at several steps is carried once and names none of them, because a stock install registers the automatic commit at nine and naming the first one read would present one truth out of nine.

It wrote .specify/extensions/companion/commands/, which is the extension’s copy and which nothing dispatches; what an assistant loads is the file the installer rendered into its own directory when the extension was added. So a build was real and reached nothing. Every emission is refreshed from the freshly built body now — the agent’s own frontmatter and any provenance banner left exactly as the installer wrote them, and a pointer file with no body left alone. A command with no emission anywhere, which is what a step you added is until the installer sees it, is named rather than counted.

Both are what emitters produce, and both used to make a file “malformed” — which is why a project’s installed-extension hooks were invisible to the pipeline panel. null now reads as nothing rather than the word.

A project can replace a named section of a template — addressed by its heading, which is what a template already has — with a fragment of its own. The specimen case is a project that wants its specs written around outcomes instead of user stories, which previously existed only as a hardcoded branch nobody could ask for. The stock template is never edited in place; the resolved copy is written beside the built commands, so an upgrade cannot quietly discard the change.

The shape check only recognised a WHEN or a THEN when it was wrapped in asterisks, so - WHEN a user picks a date was reported as “this scenario has no condition” — and because that finding stops a fold, an author who did not bold the keyword silently lost the write-back their run had prepared. The emphasis is now optional in both the checker and the editor’s diagnostics. A word that merely starts with a keyword still is not one, and a scenario genuinely missing a half is still an error.

Running the derive fallback twice while a spec sat at the same step appended a second start entry to the durable record; it now records the step’s start once, matching every other writer.

The Specs view’s empty state now offers Open a live sample beside Create your first spec. It copies a small, finished-looking example spec into your workspace and opens it in the viewer, so a first run shows the actual reading surface — pipeline, phases, timing — instead of an empty tree. It is an ordinary spec after that: yours to read, edit, or delete, and clicking again reopens it rather than making a second copy.

A workspace with no specs used to show the welcome message and the Companion install prompt as two separate blocks. They are now a single welcome: one value line, both actions, and the install offer folded in when the companion extension is missing.

When your default workflow is stock SpecKit, the Companion option in Create New Spec now offers Try Companion for this spec. It applies to that one spec only; your configured default is untouched.

The bare dropdown is now a set of cards, each showing what its workflow is for — with the Companion pipeline carrying its measured result, specs 60 to 68% leaner with the same correctness — so the choice can be made without leaving the form. A workflow that needs the companion extension shows as Install to enable rather than being hidden, and custom workflows are now validated and filtered the same way here as everywhere else, so no surface offers a workflow another one hides.

Three moments were previously unmeasured or undercounted: installing the extension, opening the Specs panel, and finishing a spec — the last one only counted when you finished from the sidebar, missing both the viewer’s own action and the Companion pipeline’s final step. All three are counted now, each exactly once, and a spec created from the terminal is no longer invisible. Everything stays anonymous and both opt-out switches still stop every event; the telemetry disclosure lists each addition.

The Azure subscription behind the old analytics backend lapsed and took the pipeline with it, so every usage event had been silently discarded for months. Events now go to PostHog with the same event catalog and the same privacy contract: only enum-like values, versions, and counts, never prompt content, file paths, or spec names. Both opt-out switches keep their promise — turning off speckit.telemetry or VS Code’s global telemetry setting stops all events immediately, mid-session, no restart needed. The retired backend’s client library and its credential are removed from the shipped extension.

Turn it off and the instrumentation is gone from the commands entirely — not sitting there switched off. It takes effect on the next command dispatched, not one already running.

The doctor re-runs the drift computation itself and shows its work — which capability, which files, which commits. Each flag is labelled: real drift, a false alarm caused by the companion’s own bookkeeping writes, a false alarm caused by comparing against the wrong commit, or genuinely unknown because the baseline could not be reached. And if a run recorded that everything was in sync while a fresh computation disagrees, that contradiction is reported as a false claim rather than quietly believed.

Every capture and drift call writes one line about itself, including the ones that fail and the reason they failed — the failures that used to disappear into stderr and leave a hole in the record with no explanation. It costs no extra call, adds nothing to any command, and the file is local, size-capped, ignores itself, and is read by nothing but the doctor.

Specifying that drifts into planning, planning that turns into a task list, a task list that turns into code: each one looks fine on its own and costs you twice. The doctor names it — plan content in the spec, a task checklist in the plan, implementation code in the task list, the same task list living in two documents, source committed before implementation started, and a step before implement that ran longer than implement did.

Its tags were spec-driven-development, tracking, companion — one of them the extension’s own name, none of them mentioning living specs, drift, or the composable command model that arrived since. They are now vscode, progress, living-specs, drift, hooks. The catalog listing itself had drifted to a different set of six, so the two now come from one place.

Until now, when a spec looked wrong there was no way to tell whether the records were wrong, the display was wrong, or the assistant’s claim about what it did was wrong. The doctor recomputes rather than believing: it reports steps that started and never finished, tasks ticked off with no journal entry behind them, task finishes written in one burst at the end (so their durations mean nothing), and steps closed by the wrong author. For the familiar “the status says specified but the Plan button isn’t there” symptom, it gives one of exactly two answers — the records disagree with each other, or the records are fine and the display is at fault. It is read-only, never blocks anything, and works on specs created long before it existed. Add --chat on Claude to read back the session and explain why something failed; --json for tooling.

When marking a spec complete does not take, the doctor states which of four things happened: the write was refused and why, it reported success but never arrived, it landed and the display disagrees, or it was never attempted at all.

Closing an implement task took two separate calls; there is now a single one for the common case (parallel workers keep the split they need). The end-of-step bookkeeping volley — what was verified, what was decided, what is left over — can now go in one call instead of six. Both record exactly what they recorded before.

The Overview’s sizing line now reads “Sized simple: 6 files projected”, the verified-checks heading reads “What was checked, and what happened”, and the footer’s running and archived labels read “Step running, actions unlock when it settles” and “Archived, read-only”. Small strings, but they render for every user on every spec.

Changing what a step tells the assistant meant pressing “Make it mine” first, which copied the node into your project and opened the raw .md in the editor — frontmatter, empty fences and all. Now clicking a node opens it in the panel and you edit it there; saving is what writes your copy, so the step you had to do first and the thing you came to do are the same action. The metadata the build depends on is carried across for you, and the markers showing where shared blocks get stitched in stay in the text so they cannot be deleted by accident. The shipped node is untouched and one click away.

The error screen offered one button — open companion.yml — which is the panel handing you the file it exists to replace, at the moment you are least equipped to read it. It now offers the ways out as actions, worked out from what your configuration actually contains: take out the empty phase, give one step back its shipped grouping or order, or reset every step. Each says what it will cost before you click, narrowest first, and your hooks are never among what a recovery drops. The file is still one click away when the panel cannot help.

The whole page grew instead of the parts inside it, so reading a long node meant scrolling past all of it to reach the buttons at the bottom. The board and the node’s text scroll now; the actions stay where they are.

The up and down arrows moved a phase’s nodes with it, which breaks the order the steps depend on — across every step this ships with, not one such move was possible. They fired, the write was refused, and the panel redrew unchanged, which reads as a button that does nothing. They are gone; splitting a phase, merging it into its neighbour, renaming it, and dragging a node between phases all still work, and now say which they are.

The control for putting a node back only appeared when a step had one to put back, so in most steps there was nothing to find and nothing explaining why. It is always there now, and says the three ways a node gets into a phase when it has none to offer.

Only the hooks a project had already written were drawn, so the places work could go were invisible unless you happened to hover them. Each empty anchor is a dotted slot now, named and clickable to attach something there.

They were an unlabelled list at the foot of each step, with nothing saying what they were or why they could not be edited — a fair thing to be puzzled by. They now appear as ordinary hook chips at the point in the step where they actually fire, marked with the extension that registered them and left plainly uneditable here.

It is the node that starts the next step, so anything ordered after it runs once the step has already moved on — a real project ended up with a specify that handed off to planning before it recorded that it had finished, and nothing in the panel objected. It is now held in place in every step, with the reason on the lock, and an order that moves it is refused rather than saved.

The hook form filled its fields once when it opened, so clicking another hook left the previous one’s values on screen — while the hook it would save to had already changed underneath. Saving then wrote one hook’s contents over another’s. The form now starts fresh on each hook.

Both READMEs were rewritten for scannability: an animated tour of the Overview page leads the listing as its hero, every screenshot is captured from Storybook by a single regenerable command so the images cannot drift from the real UI, the spec-kit extension’s page gets a new text-free hero image, and cross-install banners point each half of the project at the other. The depth that used to live in the README moved into docs/.

The panel had two near-identical button styles depending on which pane you were in, and the actions came in a different order in each. They are one style now, always in the same order: the forward action, then anything else, then the destructive one, with cancelling or leaving at the far end.

Both this extension and its spec-kit companion publish their releases into one shared list, so the link — which asked GitHub for whichever release was newest — could land on the spec-kit extension’s notes instead: a different product, a different version number, and changes that had nothing to do with the update you were being offered. The link now points straight at the offered version’s own release. Which version you’re told about was always correct; only the link was wrong.

The create action worked out the home directory from the HOME environment variable, and when that variable wasn’t set — which is common on Windows — the file was written to a .claude folder relative to whatever directory the editor started in. The extension watches and reads your real home directory, so the new file simply never appeared. Home directory resolution is now the same everywhere the extension looks, writes, and watches.

On a freshly specified SpecKit Companion spec the viewer footer said “Next: Tasks” while the step strip correctly showed Plan as still pending — and clicking the button ran task generation against a spec that had never been planned. Two things were going wrong at once: the SpecKit Companion pipeline was being mistaken for a workflow you wrote yourself, which switched on a fallback that guesses progress from whatever files are on disk; and that guess then counted the specification’s own quality checklist as if planning had already produced something. The footer and the step strip now always name the same next step. Workflows you define yourself keep guessing progress from their files exactly as before.

The two watchers that keep an eye on your global Claude settings and CLAUDE.md were pointed at your home directory in a way VS Code reads as “watch everything underneath, recursively” — so every window recursively watched your entire home folder. On Linux that meant roughly 454,000 inotify watches against a 524,288 limit, which exhausted the budget and broke file watching everywhere, including source-control auto-refresh. Both watchers now look only inside ~/.claude. Measured on Linux with four windows open, total watches dropped from 456,300 to 27,116. Thanks to @amgsk for the report and the fix.

Asking a Companion run where it stood reported the stock next command — “Next: Plan the feature → /speckit.plan” instead of the Companion one — and resuming from that point dispatched the stock pipeline, quietly dropping the Companion behavior for the rest of the run. The check that picks the command family was still keyed to a per-spec field retired when the workflow choice was simplified, so nothing ever set it and the Companion commands were unreachable. It now reads the workflow the spec actually recorded. Specs written before that change still resume on Companion, and stock specs are unaffected.

The floor was pinned to >=0.9.5.dev0 to admit spec-kit’s own git-HEAD dev builds back when spec-kit’s main was still on the 0.9.5 line — that line shipped stable long ago (spec-kit’s main now builds 0.15.x), so the pin had become dead weight and the only catalog entry not using a bare floor. Floor is now >=0.9.5, matching every other catalog entry’s convention. No install behavior changes for anyone on a real release.

In the folded layout each step now sits inline with its file chips and the strip scrolls sideways instead of colliding; empty coverage is hidden rather than shown as a bare header, and spec names render acronyms correctly instead of title-casing them.

A spec driven start-to-finish in the terminal used to report “Timing coverage: 0 of 4 phases” despite the hooks recording real per-step timestamps; a coherent CLI run now derives its full per-phase timing and total elapsed.

The old install reminder only appeared for terminal-based providers, and only after you dispatched a command through the extension’s buttons — so anyone running /speckit.* by hand, or using an in-editor chat provider, never saw it. Installing the extension is a terminal command that works the same for every provider, so the prompt is now provider-agnostic and fires when you open a project that already uses spec-kit. It’s a single quiet Install notification with a Don’t show again that shares one dismissal with the in-editor nudges, respects the speckit.companion.installPrompt setting, and never blocks activation.

If you haven’t explicitly chosen a workflow, Create New Spec and per-feature resolution now pre-select SpecKit Companion whenever the companion spec-kit extension is present. An explicit speckit.defaultWorkflow setting at any scope still wins, and without the extension the default stays stock SpecKit.

If you attach your own consolidated validation run as a post-implement hook and mark it owns: validation, the tasks command’s final Polish phase now defers its “validate against Success Criteria” task to that hook instead of generating a second suite run — your suites run in exactly one place. The marker is required so that review, PR, and deploy hooks (which share the same post-implement slot) don’t accidentally suppress validation. Projects without a marked hook are unchanged: Polish still generates and owns the validation run.

When a spec was built through the pipeline and you later advanced it from the viewer footer (clicking Plan, Tasks, or Implement), it could silently switch to the stock workflow — because the run recorded the wrong workflow name. Companion specify now records that the spec runs the Companion workflow, so every later step dispatches the Companion command instead of the stock one. Specs already in flight keep whatever they recorded; new runs get the correct pin.

The write-back loop had two places where it depended on the assistant’s judgement and could silently do nothing. Before drafting, whether an area’s living specs applied was decided by eyeball — a wrong “not configured” call recorded nothing, so completion had nothing to fold. And at completion, writing zero updates was allowed (“skip the ones you merely read”), so a feature that loaded three capabilities could finish having updated none, looking exactly like a feature that correctly had nothing to update. Now which living specs apply is worked out and recorded automatically from the files you touched, and completion has to account for every one it loaded — either a real update or a one-line note saying why it was left alone (--living-spec-skip "<name>: <reason>"). A loaded capability that gets neither is called out with a loud, actionable message instead of passing silently, and the command-quality eval warns when a finished feature leaves one unaccounted. “Correctly nothing” is now a visible record, not an assumption. Still off by default and never fails your run.

The rail used to list the workflow steps under a Pipeline heading and then repeat each step’s files in separate “Plan files” / “Specification files” groups below — so a file was visually decoupled from the step it came from. Now Data Model, Living Components, and Research sit indented under Plan, Requirements sits under Specification, and so on, so “where does this file come from” is answered in place. Every file is still one click away, the Overview stays at the top, and a file whose step isn’t shown in the rail keeps a labeled fallback group so nothing goes missing.

When the Companion spec-kit extension isn’t installed, the sidebar surfaces a one-click upgrade instead of hiding it: a dot on the SpecKit activity-bar icon, a pinned Get Companion row atop the Specs tree, a dismissable Install SpecKit Companion button in the empty Specs view, and SpecKit Companion always offered in Create New Spec — picking it shows the benefits and installs in one click first, then falls back to standard SpecKit if you decline. Every nudge disappears the moment the extension is installed, with no reload, and the old buried “Not installed” badge in the Steering view is retired.

A small change run through the fast path does its planning and task work inside the specify run, so the Plan and Tasks phases have no duration of their own — but the Overview’s run timing strip showed them as Plan <1s / Tasks <1s, which looked like a bug. Those phases now carry a “folded into Specify” note and a hollow dot instead of a duration; genuinely measured phases, coverage counts, and the run’s elapsed total are unchanged.

Advancing a step fired two context updates at once, and if they overlapped, the later one could overwrite the step’s start marker — which is what made a phase’s duration occasionally read as untrusted. Updates to a single spec’s context now happen one at a time, so both always land and the start marker is never lost. Updates to different specs still run in parallel, so nothing gets slower.

You can now pick Antigravity — Google’s agentic coding agent — under Settings > speckit.aiProvider, and SpecKit commands run in its agy command-line tool inside an integrated terminal, opened interactively so you can approve edits as they happen. If agy isn’t installed yet, the extension offers its one-line install command.

Implement and Mark Complete used to sit in the rail as entries that opened nothing readable; they’re gone from the rail (the same goes for any custom workflow step that produces no document). Their actions were always in the footer, which keeps working unchanged, and while implementation runs the live task percent now shows on the Tasks tab.

The workflow picker in Create New Spec and the Continue/Resume button on active specs used to appear only after you enabled a beta toggle. That toggle and its “Beta Features” heading are gone. Both now show out of the box whenever the companion spec-kit extension is installed. Bench results showed the Companion pipeline matches stock SpecKit on correctness while producing specs 60–68% leaner, so it graduates from beta. If you’d turned the old beta setting on, nothing changes for you; the retired setting is quietly removed from your settings on upgrade.

The branch name handed to a checkpoint was always taken from the first repository in the window, so in a workspace holding more than one repository a checkpoint could stamp a commit message with a branch from a completely different project. It now uses the repository the spec actually lives in. Single-repository workspaces are unaffected.

Specs created in the terminal never fire a “spec created” signal, so five new anonymous events measure what happens inside the extension instead: opening a spec in the viewer, opening a living/capability spec, running a living-spec drift report, running a living-spec sync, and opening a steering doc. Every one is a bare event — no spec name, path, or capability name is ever attached — and spec/living-spec opens are counted once per session so re-renders don’t inflate them. All still gated on speckit.telemetry. The README’s Telemetry section adds the new signals, sample Azure queries, and a pointer to a ready-to-paste workbook (docs/telemetry-workbook.json).

A new title-bar action dispatches /speckit.companion.living-sync to your AI assistant: it groups your current working-tree changes — uncommitted and untracked files included — by capability and updates every affected living spec in one pass, leaving the spec edits uncommitted so they ship in the same commit as the code. It sits next to the existing Adopt Code Area… action and appears only when the companion spec-kit extension is installed.

Capabilities are grouped by where their specs actually live, so the view’s shape mirrors your codebase — capabilities in the same area sit together under their folder path instead of scrolling past as one long list with a grey central/colocated word on each row. The tree conveys location now, so that word is gone.

A capability, its Architecture/Coverage tiers, and orphan specs now offer Copy Name, Copy Path, Copy Relative Path, Reveal in VS Code Explorer, Reveal in File Manager, and Delete — the same set the Specs tree has. Delete removes only the spec file (with a confirmation), never the surrounding code folder.

When a capability has drifted, a new Update to Match Code action — in the sidebar right-click menu and next to the drift marker in the spec viewer’s header — asks your AI assistant to fold the changed code back into the spec. It updates rather than regenerates, so every clarification, requirement, and scenario you already wrote is preserved and only what the code changed gets revised.

Opening a finished run used to reprint the entire text of every living spec it loaded — the purpose and every requirement, in full — so the useful signal (which specs were loaded) drowned in content you can already read in the Living Specs viewer. It now shows one compact chip per capability, right under the phase timeline, and clicking a chip opens that capability in the Living Specs viewer.

If your capability registry had a typo in it, the Living Specs sidebar showed Living Specs are off and suggested you set enabled: true — advice that couldn’t help, because the file already said that and simply wasn’t parsing. The sidebar now shows Can't read living-specs.yml with the parse error in the tooltip, so you go fix the file instead of hunting for a setting.

The header for an adopted capability used to show a name and a badge and nothing else. It now shows how many requirements and scenarios the capability declares, how many of them have a mapped test, a drift marker when the code has moved on since the spec was last committed, the file patterns the capability claims, and where its spec file lives. The claimed patterns are the point: you can finally answer “why did this spec load for this change?” without opening the capability registry by hand. Coverage and drift are the same numbers the Living Specs sidebar shows — one computation feeds both, so they cannot disagree.

Its Orphans group only ever showed specs kept next to the code they describe. A spec kept centrally, under capabilities/<name>/, was invisible — so one you never registered simply didn’t appear anywhere in the view, and an empty Orphans group looked like everything was accounted for when it wasn’t. Both layouts now show up. A repository inside your repository that keeps its own registry is still treated as a separate project and stays out of the list.

The Living Specs view now reads your capabilities from living-specs.yml at the root of your project instead of from inside .specify/, so the ordinary housekeeping that re-creates that folder — a local install, a hard reset after a merge — can no longer wipe them without saying a word. Registrations you already have keep working from where they are, and move across on their own the next time you register or relocate a capability. The sidebar refreshes as soon as you edit the new file, and a repository inside your repository that keeps its own registry is still treated as a separate project.

The viewer was building the title from the folder name, so a document headed “SpecKit Extension Capture — Living Spec” appeared as “Speckit-Extension-Capture”. It now reads the document’s own heading and only falls back to the folder name when there isn’t one. Product names keep their capitalization.

A draft capability announced itself in the badge, in a banner in the body, and a third time in a tooltip that repeated the badge word for word and covered the title while it was showing. The tooltip is gone; the badge and the banner stay.

If your repo contains sample apps, fixtures, or sandboxes that carry their own capability registry, they are separate projects and their spec files no longer show up as strays in the parent repo’s sidebar.

The run overview counted the final Mark Complete step as a timing phase, but that step only marks the spec done — it has no duration to measure. So even a perfectly-captured run maxed out at “4 of 5 phases” and never showed the total elapsed time. Mark Complete is no longer counted, so a completed Companion run reads “4 of 4” and shows its Started / Elapsed / Ended summary like it should. Stock SpecKit specs are unchanged.

Each activation reports whether the companion spec-kit extension is installed, and the install banner reports when it’s shown and when its Install button is clicked (per surface — Create New Spec vs. the spec viewer). Together they answer “how many installs have the extension, and does the prompt work?” without any new personal data — the fields are booleans and fixed labels only, still gated on speckit.telemetry. The README’s Telemetry section lists the new signals and a sample query.

The README carries a full command table grouped into four families — the pipeline, the run-state commands, the living-specs commands, and the four that run themselves on a lifecycle event and should never be typed by hand, each labelled with the event that fires it. The detailed reference, which described six of the seventeen commands, now covers all of them. /speckit.companion.living-move was missing from the listing entirely and is now documented.

A new build check holds the extension’s own command list against everything downstream of it: the command files installed for each AI tool, the project’s install records, and both documents. If a command is renamed or removed and an old copy survives, or a new one never gets installed, recorded, or documented, the build fails and names the command and the exact path. Adding a command without documenting it now fails too. The AI tool directories it knows about are discovered rather than assumed, so a newly supported tool is reported instead of quietly going unchecked.

Each finished task is folded into the tracked progress the moment it lands — the checkbox flips and the count ticks up right away. Previously finishes accumulated invisibly and were folded once per wave, so a 12-task run could sit at 0, jump to 9, and jump again to done. Parallel task work is unaffected: workers still record their own finishes without touching the shared files, and the one main agent folds each result as it arrives.

The living-specs commands now carry the family: /speckit.companion.adopt → living-adopt, drift → living-drift, coverage → living-coverage, relocate → living-move. The four hook commands are now named after the lifecycle event they handle rather than the generic “capture”: capture → after-specify, capture-plan → after-plan, capture-tasks → after-tasks, capture-implement → after-implement. The hooks still auto-run, so nothing changes unless you invoked one of the four living-specs commands by hand. The other nine (specify, plan, tasks, implement, auto, classify, mark-complete, status, resume) keep their names — they mirror stock Spec Kit, and that parallel is the point.

Entries below this one predate the rename and use the names as they were at the time. Upgrading requires specify extension remove companion before reinstalling — nothing prunes emitted commands, so a plain reinstall leaves the old names live alongside the new ones (see #461).

If you code directly instead of running the Companion pipeline, keeping living specs current used to take three steps with a blind spot: run the drift report, read it, update each drifted capability by hand — and none of it could see work you hadn’t committed yet. /speckit.companion.living-sync does it in one pass: it collects your current changes (uncommitted edits, deletions, and brand-new untracked files, plus anything committed since each spec’s last update), groups them by capability, and updates every affected living spec — no hand-picking. Updates preserve what you wrote: requirements, clarifications, and scenarios the change doesn’t invalidate survive verbatim. The run ends with a report of what was synced and what was skipped (a spec that was never committed is left to /speckit.companion.living-adopt), and the spec edits are deliberately left uncommitted so they land in the same commit as the code that caused them. Off by default like the rest of living specs, and it never fails your run.

/speckit.companion.living-drift --working counts uncommitted edits, deletions, and untracked files as drift alongside committed history — the read-only preview of what a sync would touch. Without the flag the report reads committed history only, exactly as before, and the always-succeeds contract and checked/skipped counts are unchanged in both modes.

When you mark a feature complete, the assistant writes a short “what changed” note for each capability the feature loaded and actually changed, and those notes fold into each capability’s living spec. You no longer have to remember to hand-write a delta section for the record to update. A feature that changed several capabilities updates all of them, and each capability’s spec gets only its own requirements — a change to checkout never leaks into billing. The notes are written into the feature’s own spec, so they show up in the pull request and get reviewed alongside the code. Turn living specs off and nothing folds, as before.

When a completed feature added a brand-new requirement to a living spec, the fold-back could silently drop it and report “already up to date” — so the living spec never changed and you had no idea it was skipped. Now a new requirement lands in the living spec whichever way it was written up, and the fold’s summary is honest: if something couldn’t be applied, it says so instead of claiming success. A genuinely-redundant update still does nothing quietly.

Two things a small change used to drop: the one-line approach it writes into the spec never made it onto the spec’s tracked context, so the Overview’s Approach card read empty; and even in an area with living specs, whether they got recorded was left to the assistant’s judgement, which sometimes decided “not configured” and recorded nothing — so no chips appeared and finishing the feature had nothing to fold back. Now the approach is captured on every fast-tracked run, and which living specs apply is worked out and recorded automatically from the files the change touched, so it can’t be skipped by a wrong judgement call. Living specs off, or a change in an area with none, still records nothing — and none of this can slow or fail your run.

When a change is small enough to fast-track, the plan and tasks phases are folded into the spec step instead of run separately — and that fold used to leave the finished spec with “Timing coverage: 0 of N” and no living-spec context at all. Now a fast-tracked run measures every phase with a real duration, exactly like a full run, and it loads the living specs for the area it touches — so the Overview shows the living-spec chips and finishing the feature folds its changes back into those specs. Specs that were fast-tracked before this fix keep their old timing untouched; only new runs get the corrected behavior.

The plan and tasks steps used to get their “started” timestamp written after their own completion (the hook that stamped it fired last), so the timing panel rejected those spans as dishonest and a finished spec showed “Timing coverage: 1 of 4”. Every pipeline step now records its start the moment its work begins and its completion right when it ends, both with real script-stamped clocks, on every way of running the pipeline — the GUI, the skill chain, /speckit.companion.auto, the workflow engine, and the stock-named /speckit.plan · /speckit.tasks commands in a project with Companion installed. A finished spec now shows a real duration for specify, plan, tasks, and implement. Old specs recorded under the previous order are left as they are — their untrustworthy spans stay marked untrusted rather than being retroactively believed.

When you mark a feature complete and nothing gets written to the capability spec, the run now states the one reason that applied — living specs off, no capability resolved, no delta section in the feature spec, or already up to date — instead of printing all four as a single guess-for-yourself line. And if the feature loaded capability specs at the start but wrote no delta section (which the normal specify → plan → tasks flow always does), completion now names those capabilities and tells you there’s nothing to fold yet, pointing you at adding a delta section or running the drift check — so the write half of living specs can’t quietly never run.

Writing exempt: [] in living-specs.yml means “check every file, exempt nothing” — but the next command that rewrote the file dropped the empty list, and the built-in defaults (*.config.*, *.test.*, **/migrations/**) silently came back. Drift checks would quietly stop reporting files you had deliberately asked them to watch. An explicit empty list is now written back as one and keeps meaning what it says; leaving the key out still gives you the defaults.

The orphan report only looked at specs sitting next to the code they describe. A spec kept centrally, under capabilities/<name>/, was skipped entirely — so an unregistered one produced no warning and no error, and the report still came back clean. A clean report was supposed to mean everything on disk is accounted for; it only meant the colocated half was. Both layouts are now scanned, and the --all listing sees exactly the same set the orphan report does, so the two can’t disagree. This bites hardest during adoption: a capability whose match patterns span several directories has nowhere to colocate into, so the specs most likely to go missing were the ones the tool itself chose to keep centrally. A repository inside your repository that keeps its own registry is still a separate project and is still skipped, and installed dependencies under node_modules are skipped too — a spec shipped inside a package you depend on was never yours to register, and it no longer shows up as one.

Living-spec capabilities used to be stored in .specify/companion.yml, and the standard housekeeping step in a lot of projects — git restore package.json package-lock.json .specify/ after a local install, or a git reset --hard after a merge — threw the whole folder away and took every registration with it. Silently: no error, no warning, just living specs quietly not working any more, with the spec files still sitting on disk belonging to nothing. It bit hardest during first-time adoption, exactly when you have the most unsaved registrations and the least sense of what should be there.

Capabilities now live in living-specs.yml at the root of your project, where no cleanup step can reach them. Commit it alongside the specs it registers. Turning living specs on is now a matter of creating that one file:

enabled: true
capabilities:
  - name: checkout
    match: ["src/checkout/**"]

Nothing you already registered is lost. Capabilities still sitting in .specify/companion.yml keep working exactly as they do now, and the next time you register or move one, the whole set is carried across to the new file for you and you are told it happened. Your pipeline hooks and recipes stay where they are — only the capabilities move. If you would rather move them by hand, copying the old block into the new file works too; both shapes are accepted. If you end up with both files carrying capabilities, living-specs.yml is the one that counts and the old block is left untouched rather than deleted — the Living Specs view and the command output both tell you it is being ignored, so you can move anything still worth keeping before you delete it yourself.

Most CI providers clone only the most recent slice of git history. On a one-commit checkout the drift check used to print a clean all-clear having compared against nothing; with a few commits it reported drift against whatever commit happened to be the oldest one available, so the list of changed files was wrong. Both outputs looked perfectly healthy. Drift now recognizes that its baseline is out of reach, skips those capabilities with spec history unreachable (shallow clone), and tells you to fetch the full history (for example actions/checkout with fetch-depth: 0). A capability whose spec was committed inside the available slice is still checked as usual, a full clone is unaffected, and the exit code stays 0 — the check is advisory and never fails a build.

With two of nine capabilities checked, the report used to say ✓ All 2 checked capabilities in sync with the seven skips as a footnote underneath. It now says ✓ 2 of 9 capabilities in sync; 7 not checked — <reason> on one line. A run where everything was checked keeps its original wording.

The drift check reported every capability as spec.md not yet committed, which sent you looking for a file that was there all along. It now reports spec history unreadable. A repository that simply has no commits yet still reports spec.md not yet committed, which is what is actually true of it.

Folding a finished feature’s requirement changes into a living spec is meant to be repeatable — run it again and nothing should move. It wasn’t, whenever one fold both added a section and renamed or edited that same section. Add-and-rename was the damaging one: every fold appended another copy of the requirement, without limit, so five folds left five copies in a document the team treats as durable. Add-and-edit was milder but noisier — the section’s body flipped between two versions on every fold, and it made the eval harness report a repeatability failure for input that was perfectly legitimate, which teaches everyone to ignore that check. Every combination of change verbs is now repeatable, and a re-fold is a genuine no-op.

Passing --decision and --verified together recorded the decision, reported “Recorded 1 decision(s)”, dropped the verification, and exited successfully — so nothing downstream could tell that half the data had vanished. Every capture flag in a single call now takes effect, and each one is reported. --set, --concern, --expectation, --context, --coverage-req, --step-summary, --living-specs, --fold-living-spec, and --classification are all in this group. The lifecycle flags still take second place to a capture flag in the same call, but they no longer do it silently: --mark-complete --set x=y now says on stderr that the completion was skipped, instead of setting the field and exiting successfully as though the spec had shipped. Run the two as separate calls.

Right after you adopt a batch of capabilities, none of their specs are committed yet, so every one is skipped — drift needs a committed baseline to diff against. The run used to end on a green all-clear anyway, which read as a clean bill of health for a check that never ran. It now ends on 0 checked, 9 skipped (spec.md not yet committed), and the ✓ All N checked capabilities in sync. line is reserved for a run that genuinely examined at least one capability and found it clean. A partly-skipped run states both numbers. The --json output gained a checked count so a script can tell “clean” from “did not run”, and the exit code stays 0 throughout — a skip is correct behavior, not a failure.

A change block naming a requirement heading the living spec doesn’t have is skipped, but the summary still counted it, so ~3 modified printed when all three had quietly matched nothing. The counts now reflect what actually landed, and dropped changes are called out.

If your repo contains sample apps, fixtures, or sandboxes that carry their own .specify/companion.yml, they are separate projects: their spec files no longer show up as orphans in the parent repo, and they are no longer invented into capabilities of it. A nested project that has living specs turned off is left alone entirely, so opting a sandbox out finally means nothing happens to it.

Nothing you run changes — every flag behaves identically, and no command, hook, or setting needed editing. The size was the problem: it hid the fold bug above and it caused the dropped-flag bug above. Delta parsing, the living-spec fold, task syncing, and capture each have their own file now, so the next bug is findable by name.

A new command-quality eval scores a finished spec on three things a human used to judge by eyeball: did the run write too much (each of spec, plan, and tasks is measured against a size budget with a warn band and a hard fail band), did it waste time (a step whose start/finish wasn’t reliably stamped is called out as untrusted, a step far out of line with the others is flagged, and the old everything-finished-in-the-same-second task-journaling bug shape fails outright), and does each command prompt correctly (the commands that must never stop to ask — the lifecycle hooks, the living-spec reports and sync, mark-complete, status, resume, classify — are scanned for ask-the-user instructions, while the clarify step is required to ask). It runs on every pull request against two real completed specs and the shipped command sources, so a command that regresses into verbosity, burst journaling, or a wrong prompt now fails the build instead of shipping quietly.

When a spec folder sat outside the directory a command was run from — a sandbox or temp spec, a benchmark fixture, or anything driven by a script that changed directory first — the spec’s tracked branch was taken from wherever you happened to be standing rather than from the spec itself, so it recorded the wrong branch. The step-by-step lifecycle writes were affected, along with task progress, the final completed state, free-form fields, and the repair path that rebuilds a spec’s tracking from the files on disk. Normal runs were already correct and are unchanged; a spec folder that isn’t in a repository at all still falls back as before.

After the recent rename, the four automatic capture steps were still registered under their old names, and the stored command list carried eight retired names and none of their replacements. Anything reading those records — including a later clean uninstall — was working from a picture that was a release out of date. The records now match the commands that actually ship.

This is the drift the new check exists to catch, and it is worth knowing why it happened: reinstalling an extension adds to the command list it already had and never removes from it, and it will not overwrite a command file that is already there. That behavior lives in the Spec Kit CLI rather than here, so upgrading across a rename still needs specify extension remove companion before reinstalling. What changed is that a stale name is no longer invisible.

It sits at the top of the document rail as the first destination, and it only appears when the spec actually has a recorded run — a spec created outside the Companion pipeline is simply its documents, with no empty Overview to explain. A spec whose run notes are just a work log opens on its documents too.

The spec’s identity (name, status, branch, date) and its run facts (phase, tasks, traceability) now share a single header band instead of stacking as two full-width rows, and the status is stated exactly once. The facts only say what nothing else already says: no repeated status, and no phase either (a completed spec announcing “implement” tells you nothing, and a running one is already named by the badge and the spinning step). As the pane narrows they step aside — the checks and elapsed time first, then all of them in a split editor — while the title and status never yield. There’s no “Run details” link, because the Overview is an entry on the rail at every width.

Clicking Specification, Plan, or Tasks while the Overview was showing did nothing: those clicks rebuilt the whole panel, which reset the view and landed you right back on the Overview. Navigation is now a true single-page swap, so every rail entry is reachable from every other one.

Every saved comment used to plant a full-width strip in the middle of the document, complete with a delete × that never went away — five comments meant five permanent interruptions that shouted louder than the lines they were about. A comment now rests as one quiet line: a glyph, the comment truncated to a single line, and its state. Open it (click it, or press Enter when it has focus) to read it in full and act on it — Refine hands that document’s pending comments to the AI, Edit reopens the composer with the text already in it, Delete removes it. A document under review stays a document you can read.

A comment awaiting refinement reads as live; one the AI has already been asked to act on carries a check and stays on its line as a record of what was asked — quiet, and never counted in the Refine badge. Comments you already refined come back on reopen too, instead of disappearing.

A completed or archived spec’s documents used to render as an iconless list; they now carry their own status — a green check for a completed step, a blue dot for the current one, a hollow circle for the rest. A document that doesn’t exist yet says not created and offers no action that would fail.

A spec’s tooltip now reads as a short card (name, friendly status, last activity) instead of a run-on line with a raw internal status key in it, and a document’s tooltip shows its real path rather than one reconstructed from its label.

The viewer now runs the design that won the multi-provider redesign investigation: a spec with recorded activity opens on its Overview, documents live on a left rail where the highlight shows what you’re reading and separate marks show how far the run is, and the footer becomes a floating action pill led by a context line naming the next step, with workflow-provided commands under Other actions.

It used to stretch across the whole window, behind the navigation rail, even though it describes one file and its Regenerate button acts on that one file. It’s now a notice inside the reading column, and it names the document (“Plan may be stale”).

It also reads like an index again rather than a second column of prose: smaller type, long headings clipped to two lines (full text on hover), and subsections hung off a guide rule so they’re clearly children of their section instead of look-alike peers. And it only takes a column when the pane can spare one — below roughly 920px it becomes a collapsible “On this page” list above the document instead of squeezing the text you’re reading. That threshold is set for laptops: a 13” MacBook with the sidebar open keeps its outline column, while a split editor correctly falls back to the list. The ambiguous + button now says what it does (“Subsections”), and repeated entries like the five “Implementation” headings announce which section they belong to.

The viewer now ships its own tested light and dark palette (statuses, surfaces, syntax) instead of inheriting whatever the editor theme happens to define — every text/surface pair clears WCAG AA in both modes, and code blocks render on a dark surface that stays readable even in light themes. Typography follows your editor font.

The … button in the Specs toolbar used to throw a picker to the top of the window, away from the button you clicked. It now opens a normal menu right under it.

Four views, one icon language, and a toolbar you can take in at a glance. Nothing about how specs behave changed — the same commands, lifecycle, filter, sort, multi-select, and Resume rules — but the sidebar stopped looking like four features that grew separately.

Individual spec rows now start collapsed, so a project with two hundred finished specs shows you a short, readable list rather than every document of every spec. Active stays expanded, Completed and Archived stay collapsed, and Expand All still opens everything when you want it.

A spec row offers Resume (when eligible) and More Actions on hover; both that menu and the right-click menu present the same items in the same order — Set Status…, the lifecycle action, Copy Spec Name / Path, both Reveal actions — with Delete alone in its own danger group at the bottom.

The detailed illustration-style icons are gone from the tree; every functional and status concept uses VS Code’s own themed icons, so the sidebar stays legible in light, dark, and high-contrast themes. The only custom artwork left is the product mark and the official provider logos, and no status depends on color alone.

It’s built in one explicit order (Companion, your provider, Steering Docs, SpecKit Project Files, References), and the “create a rule file” actions moved out of the root and into the Project or User group they belong to — naming your provider’s real filename instead of always saying CLAUDE.md.

The filter box opens prefilled with your current query and clears when you submit it empty, so the separate clear icon is gone. Collapse/Expand All, Install Companion Extension, and Upgrade… moved into More Actions — and every one of them is still in the Command Palette.

A completed spec kept showing its Implement step as if it were still running, stuck a few percent short of done. The progress number was counting the example checkbox in the task file’s own formatting legend as an unfinished task, so it could never reach 100% — and the spinner never checked whether the spec had actually finished. Task progress now counts only real tasks, ignoring examples inside code blocks, and a finished step stops moving. Phase-completion notifications were miscounting the same way and now fire correctly.

The task id and the [P] / [US1] markers are labels about a task, so they now sit ahead of the description as small chips instead of raw brackets in the middle of the sentence. File paths and inline code inside a task quieted down too — a path is a reference, so it no longer shouts louder than the task it belongs to, and it picks up the accent only when you hover it.

A step with no output file of its own — stock Implement, or a custom workflow’s Discuss / Execute / Verify — renders in its true position in the pipeline, marked as an action and showing done/current/running state, instead of silently disappearing. Selecting one opens the document it actually runs from (Implement opens Tasks), so no rail entry is a dead click. Custom commands scoped to such a step surface in the footer while the workflow sits at that step.

The “Plan was generated before the current specification — consider regenerating” banner (and the matching warning mark on the step) kept showing on completed and archived specs, where there is no regenerating left to do. Staleness now goes quiet once a spec settles.

In a custom workflow with action steps between documents, the forward button could say one step (e.g. “Execute”) but run another (the workflow’s first action step). The button’s label and its dispatch now derive from the same next-step walk, so they can never disagree.

The redesign’s owned palette had leaked into the shared token file and repainted both editors; the palette is now scoped to the spec viewer only, and the other webviews follow your VS Code theme again.

It used to do nothing but expand the row — to see a spec you had to guess a document, open it, and then find the Overview. Now the name opens the viewer on that spec’s Overview: why it exists, what constrained it, what was verified, the decisions, and how its requirements map to tests. A spec with no recorded run has no Overview, so it opens on its first document instead. The click still expands the row, and the chevron still expands it without opening the viewer when you only want to browse.

Every file-backed row in Living Specs and Steering — including orphan living specs — offers Reveal in VS Code Explorer and Reveal in File Manager. Rows with no file behind them offer neither.

The permanent run-facts column is replaced by a one-line strip above the content (phase, tasks, traced requirements, checks, active time, PR link). The status isn’t repeated there — the header badge already carries it.

Picking Codex as your assistant and running a Companion step quietly did nothing useful — the extension piped raw text the CLI couldn’t act on, with no error to tell you. It was looking for the commands in a location spec-kit no longer writes to, and it couldn’t read a namespaced command name in the first place. Codex now runs the whole Companion pipeline like every other assistant.

The provider row’s name and its mark are now resolved together, so the host editor’s built-in chat in an unrecognized editor shows a neutral chat icon instead of a competitor’s branding. Wibey gets an intentional, documented neutral mark rather than an accidental fallback.

If you installed the extension from a release, these three commands could never work: the helpers they call were left out of the published package, so each one stopped partway and reported a missing file. Everything they need now ships with the extension. The same gap was quietly degrading /speckit.companion.specify and /speckit.companion.plan, which silently skipped loading your project’s living specs instead of reading them into context — they now pick that context up as intended.

The extension’s spec-kit version floor rejected dev builds (0.9.5.dev0 sorts below 0.9.5 under PEP 440), so anyone running spec-kit installed from GitHub — the setup the README itself recommends — was blocked with a compatibility error. The floor now admits dev builds of the same engine line.

What goes into a release used to be typed out by hand in two separate documents, and nothing verified it against what the commands actually call — which is how the three commands above shipped broken. The package is now built from a single list that is checked on every change: if a command needs something the package doesn’t carry, the build fails and says which file is missing, so a release can’t go out incomplete again.

The previous dispatch used wibey -p "$(cat "path")", which breaks when the temp-file path contains spaces (macOS stores VS Code extension storage under ~/Library/Application Support/…). Switched to interactive TUI mode: SpecKit now starts wibey in an interactive session, waits for the TUI to initialise, then sends the command as typed text — no shell expansion, no quoting issues.

Each SpecKit action was creating a fresh terminal instead of reusing an existing Wibey session. The provider now scans vscode.window.terminals for a live “SpecKit - Wibey” terminal and reuses it; a new one is created only when none is found.

Running wibey -f/-p in headless mode caused Wibey to exit once the task finished. The interactive approach keeps Wibey running after each task so the developer can continue working in the same session.

The URI-handler dispatch path (vscode.env.openExternal with a vscode:// scheme) returns true even when the target extension has no registered URI handler, silently swallowing the dispatch. This blocked the clipboard fallback (the only path that works today) from running. The URI-handler path is now disabled until genaica/wibey-vscode-extension#442 ships.

“Reveal in File Explorer” and “Reveal in Explorer View” now work from the Spec Explorer and Steering trees, not just the Specs list. Each spec row also gets a single ”…” menu that gathers status, lifecycle, copy, reveal, and delete instead of a crowded row of icons.

Auto mode used to run everything and then stop at the very end, waiting for you to click “Mark Completed.” Since an auto run is unattended by definition, it now carries the spec all the way to completed with no clicks. Manual, step-at-a-time runs are unchanged and still keep that final confirmation for you.

A custom workflow step can now say which Claude Code model and reasoning effort to use, so an easy step can run cheap and fast while a hard one gets the heavier model. Set it on the step in your settings; it applies only when Claude Code is your assistant.

A workflow can now point at folders it reads for context (for example a planning or codebase folder) as “reference” sources. Those show up under the Steering view instead of cluttering the Specs list, and they no longer get mistaken for an un-started spec with a phantom progress bar.

If a step looks like it is running but nothing has changed on disk for a while, the spec view shows a small “still running?” strip with Resume and Set status buttons. It never changes anything on its own, it just gives you a quick way to pick things back up.

The Specs tree showed “not created” next to a step whose output isn’t a fixed filename (GSD’s plan phase writes 01-01-PLAN.md), even while that document hung right beneath it. The row now reflects that the step is created, and stays expandable to its documents.

The Create Spec dialog assumed every workflow begins with specify and quietly dispatched the stock command for workflows that don’t. A workflow shaped discuss → plan → execute → verify now dispatches its own first command from the dialog.

A workflow whose only navigable step happens to be called plan (like GSD: discuss → plan → execute → verify, where discuss/execute/verify are action-only) was misread as a built-in workflow, so its progression never ran and the next-step button never appeared. Custom detection now considers every step, including action-only ones, so these workflows advance correctly.

A step that produces numbered or free-named files instead of a fixed one (GSD’s plan phase writes 01-01-PLAN.md, not plan.md) was never seen as “done,” so the forward button to the next step never appeared. When a step is marked to include related docs, Companion now counts any spec-folder document it produced as its output — the Execute step surfaces once the plan is written.

The file-driven progression now compares the files on disk against the recorded position instead of bailing whenever any history exists — so clicking the forward button once no longer freezes the workflow at its previous step.

Bring-your-own workflows wired through speckit.customWorkflows (Matt Pocock’s skills, GSD, anything that runs commands and writes markdown) never advanced in the viewer: after the first step, the button to run the next one simply never appeared, and the spec sat stuck at “specify.” The reason was that a custom workflow’s commands don’t emit the capture context the built-in pipeline relies on, so the extension couldn’t tell the run had progressed. Companion now reconstructs a custom workflow’s position from the step output files on disk — the spec it wrote, the tickets folder it filled — so the forward button lights up and dispatches the right next command, step after step, exactly like the built-in flow. Built-in and context-emitting workflows are unaffected.

Clicking a capability in the Spec Explorer used to dump you into raw markdown, lint squiggles and all. It now opens the same rendered reading experience as feature specs — minus the workflow stepper and footer, because a living spec has no phases — with the capability’s tiers (Spec, Architecture, Coverage) as tabs when they exist.

The living viewer anchored tier lookup on spec.md in the file’s directory, which only exists in the centralized layout — a colocated spec like src/lib/storage.spec.md opened to a header with an empty body. The viewer now anchors on the file that was actually clicked, so both layouts render, and two colocated capabilities sharing a folder each open their own family of tiers.

A custom workflow whose progression is reconstructed from files on disk has no real run clock, but the Phases summary was rendering the placeholder start as a literal date (“Started Dec 31, 07:00 PM · 1s active”). The wall-clock summary now appears only when a step carries an extension-stamped time; otherwise the phase names show without invented timing.

You can now pick Wibey — Walmart’s built-in AI coding assistant — as your provider, in two shapes: the wibey command line (dispatches SpecKit commands to a terminal) and the Wibey VS Code chat panel. The panel doesn’t wait on any pending Wibey feature: it tries the in-editor send command first, then a deep link, then falls back to copying the command onto your clipboard, so it works today and gets smoother as Wibey adds support.

Forcing an earlier status now genuinely rewinds the workflow position: the forward button (Implement, or Tasks when rolling back to planned) reappears, the interrupted step stops falsely showing as completed, and the aborted attempt stays visible in the spec’s history. No files to delete, recovery in two clicks.

A “Sponsor” button appears on the Marketplace listing and the extension details view, the Specs sidebar welcome screen has a “Support this project” link, and there’s a “Sponsor SpecKit Companion” command in the Command Palette. All of them open the project’s GitHub Sponsors page. Nothing changes if you’d rather not — it’s entirely optional.

Every spec in the sidebar now has a Set status… action — on the right-click menu and as a hover gear — that lets you force the spec to any lifecycle status (specifying through completed) after a "Force status to X?" confirm. The override is recorded just like any other lifecycle change and the sidebar updates immediately, so a mis-click is no longer a dead end.

The button now hides when the extension is missing, and if the command runs anyway you get the standard warning with an Install spec-kit Extension action instead of a dead dispatch.

The spec list keeps its familiar color-tinted beakers (blue in progress, yellow implemented, green done), and the Active/Completed/Archived group headers are now colorful too. Repeated leaf icons (every script, template, agent, and skill row) and the dimmed file paths on SpecKit Files rows were dropped to cut visual noise. Icons come from the open-source Fluent Emoji and Lobe Icons sets.

The Companion node also moves to the second spot in the Steering view so it’s easier to find.

Click one to open it. It appears only when the installed Companion extension actually carries templates.

Checks render as compact pills that pack like tags rather than a grid with holes, section headings read in Title Case so the hierarchy is visible again, coverage rows drop their doubled bullet markers, the tiny metadata labels are more legible on every theme, and the viewer header shows the spec name in Title Case instead of a lowercase slug.

Each capability now renders inline: its one-line purpose, its requirements as readable rows, and — for completed specs that folded changes back — the change counts (added/modified/removed). Old specs and workspaces where the content can’t be found keep the simple name list with a quiet “content unavailable” note. A new committed demo spec (specs/_03_demo-living) lets you see the card without configuring living specs.

The Approach card also shows how the pipeline sized the change. Old specs without the new data render exactly as before.

The road not taken: every decision with its WHY and the alternative it REJECTED.

Everything else moved into four keyboard-navigable tabs (Decisions, Work, Proof, Notes) with count badges; when requirements are uncovered or concerns are open, Proof opens first. Verifications render as green/amber pills, requirement chips are tinted by covered state, decisions are numbered, and the phase timeline gained duration bars for genuinely measured spans. Older specs render gracefully with only what they have.

The brief: status, honest active time, and stat chips up top; the Plan states the intent, the context the run worked from, and what was out of scope.

The view’s title bar gains an Adopt Code Area action (the brownfield wizard, handy from the empty state) and a Refresh button. Capability rows also show their health at a glance: a 3/5 covered count when a coverage file exists, and a ● drift marker (with a warning-colored icon) when code has changed since the living spec was last committed. Health is computed quietly by the extension itself and simply stays absent when it can’t be determined — the tree never errors or stalls.

The viewer’s derived timing now distinguishes measured spans from journaled ones, so elapsed-time displays can stop presenting bookkeeping as effort. Alongside this, the spec context schema now declares the new reasoning-trail fields the spec-kit extension records (the goal, out-of-scope list, decisions, verifications, and requirement coverage), so the viewer can read them.

What happened, with receipts: the phases strip shows only genuinely measured durations, and every task is journaled as it finished with the files it touched.

The helper now ships inside the editor extension itself, so it always exists. And stock runs now record the same reasoning trail the Companion pipeline does — the goal and out-of-scope fences, working context, decisions, checks, and per-requirement coverage — so the Activity panel is a real brief on stock workflows too, not just a bare timeline. Verified end-to-end by a new committed sandbox eval that replays the exact GUI-dispatched instructions against a real model in a companion-free workspace.

Proof, not self-report — captured on a plain stock spec-kit run: six checks with the exact command each ran, and every requirement mapped to the tasks and tests that satisfy it.

The banner now shows on its own merits: whenever the extension is missing and you haven’t dismissed it or turned its setting off, no matter how the workflow toggle is set. Installing the extension, dismissing the banner, and turning off its speckit.companion.installPrompt setting all still hide it exactly as before.

The README describes the maturity ladder the feature moves you along: spec-first (a spec that dies at ship), spec-anchored (a durable spec per capability that deltas fold back into, with drift detection - what living specs deliver), and spec-as-source (the machine-validated direction the drift check points at). Docs only, no behavior change.

A run used to leave behind what step you were on but not what you were trying to do, what you decided, or what you checked — all of that evaporated with the session. Each step now records its part of the reasoning trail into .spec-context.json as it finishes: the goal and the explicit out-of-scope list at specify, the approach and the decisions (with the rejected alternatives) at plan, which tasks cover each requirement at tasks, and what was verified — tests run, results, even warnings seen and dismissed — plus any friction hit, at implement. Everything is additive and repeat-safe (recording the same thing twice never duplicates it), and a skipped path (say, living specs not configured) now leaves a one-line note so an audit can tell “correctly did nothing” from “capture broke”. Resume, handoff, and review can finally answer “why is it built this way?” and “is FR-4 tested?” straight from the file.

A spec’s context file already carried its goal (intent) and its non-goals (expectations); it now also records what the run worked from — the living specs it loaded, the areas of the codebase it investigated, and the constraints it honored — written when the spec is created. Requirements also move earlier: each one is logged with its readable text the moment it’s written, not later when the task list is generated, so a spec is fully described and queryable from its very first step.

The requirement-coverage capture now carries each requirement’s one-line text alongside its id, recorded when the task list is generated — so a resume, a review, or the GUI’s coverage view can say “FR-3 — capability rows show their health” instead of a bare FR-3. Additive and repeat-safe like the rest of the trail.

You can now declare the capabilities in your codebase — checkout, auth, billing, todos — and say which files belong to each and where its long-lived spec lives, either in a central folder or right next to the code. Given a set of changed files, Companion resolves which capabilities they touch (most-specific first), and can list every capability plus any stray spec file no capability claims. It’s off by default: with no livingSpecs block in .specify/companion.yml (or enabled: false), nothing changes and every command behaves exactly as before. This first release ships the resolver and the config; later releases fold change deltas back into the living specs as you work. See the new “Living specs” section in the README.

When living specs are on, starting a feature no longer means re-describing the codebase. Companion sees which files the change touches, finds the matching capabilities, and reads their living specs into the assistant’s context before it drafts — most-specific first, so the closest capability leads and a broader one frames it. The spec step remembers which capabilities it loaded, and the plan step reuses that instead of working it out again. Still opt-in and never a blocker: with the feature off, or with a capability whose spec isn’t written yet, specify and plan behave exactly as before and never touch a living spec.

If your feature spec describes how it changes a capability — what it adds, modifies, removes, or renames, written as ## ADDED / MODIFIED / REMOVED / RENAMED Requirements sections — those changes fold into the capability’s durable living spec the moment you mark the spec complete. The feature spec was the proposal; the living spec becomes the lasting record. When several capabilities are in scope it updates only the closest one, unless a section names a different target with a <!-- capability: <name> --> marker. If a capability’s living spec doesn’t exist yet, its first folded change creates a well-formed one — a titled spec with a requirements section — so the record is born complete from its first feature rather than as a headerless fragment. It stays opt-in and safe: with living specs off there’s no fold, a feature spec with no delta section leaves the living spec untouched, and re-running completion folds nothing already there. See the new “Folding feature deltas back” section in the README.

Starting living specs on a codebase you didn’t grow this way no longer means hand-writing a spec per area. Point the new /speckit.companion.adopt command at a single code area and it reads that area’s surface, proposes capabilities for just that area, and drafts a living spec for each from what the code already exposes. Every draft wears its limits openly — the whole spec is marked [DRAFT], each requirement is tagged observed or inferred, uncertain items carry an inline [NEEDS CLARIFICATION: …], and any file it couldn’t read is listed under ## Uncovered — so a quick draft is never mistaken for a verified spec. You review and confirm, and the capability is registered into your livingSpecs block so the resolver recognizes it right away. It’s opt-in and incremental: you run it deliberately, it appends one area at a time (never a whole-repo bootstrap), re-running it for an already-adopted area is a safe no-op, and it changes no other command’s behavior. See the new “Adopting an existing code area” section in the README.

A living spec only stays honest if changes to its area flow back into it — and in practice code keeps moving while the spec sits still. The new drift command shows, for each capability, the source files that changed since its spec was last committed, and tells you how each one slipped: tracked (it went through the pipeline but was never folded back) or unspeced (it changed entirely outside the pipeline). It’s a read-only report that never fails the build — it always exits success, so a surrounding workflow or CI can decide whether to treat findings as a gate. You can exempt files you don’t want tracked (generated code, tests, migrations) with a livingSpecs.exempt glob list; sensible defaults cover the usual suspects. When every capability is in sync it prints a single all-clear line, and with living specs off it reports nothing. See the new “Spotting drift” section in the README.

A living spec can carry two more files next to its requirements: an architecture file for how the area is built, and a coverage file that maps each requirement to the test that proves it. Both were reserved before this release; now Companion uses them. When you plan a change, it pulls the area’s architecture notes into context — but only for a real, architecture-touching change, never for a small fast-path one, so trivial work stays lean. And a new /speckit.companion.coverage command reads the coverage file and tells you, per requirement, which ones have a test mapped and which are still uncovered. Like drift, it’s read-only and never fails the build — a signal you act on, not a gate. It stays opt-in: with living specs off, or a capability that ships only its requirements file, planning and coverage behave exactly as before. See the new “Coverage and architecture tiers” section in the README.

Some timestamps in a spec’s history are journaled by the assistant after the fact — they order events correctly but say nothing about how long the work took (a “94 ms plan step” was bookkeeping, not planning). Each step’s derived timing now says whether its duration was genuinely measured, so displays and analytics only show elapsed time where it’s real.

Implement can be closed from several places — as each task finishes, by an end-of-step hook, by a batch fold of parallel work, and by the final completion step — and a past run logged the same “implement finished” event four times. Those completions are now recognized as the same event regardless of who recorded it, so the activity timeline shows a single, clean completion marker. A regression test drives all four paths in one run to keep it that way.

Installing the extension now pulls down only the files it actually needs to run, instead of also carrying along docs, examples, and build-time sources. The download drops from roughly 600 KB to about 72 KB, so installs and updates are quicker. Nothing about how the extension behaves changes.

Body text is bigger and section headings stand out, so long specs are easier to scan; the top step nav is refreshed and clearly marks the step you’re on; the Activity “Phases” timeline is now a vertical timeline; and badges and callouts are calmer and higher-contrast. The viewer’s font also renders correctly now (text had been silently falling back to a system font).

It’s now a single compact line with an Install action, a Learn more link, and an ”×” to dismiss it. Dismissing hides it right away and remembers your choice everywhere, so it won’t come back in any project or after a reload. It still only appears when the extension isn’t installed.

Select the SpecKit Companion workflow and an Auto button appears next to Create Spec: describe what you need and walk away while it runs specify → plan → tasks → implement → completion on its own, with no approval pauses. Create Spec still does the normal step-by-step flow, so you choose per spec. Auto only shows for the Companion workflow (it needs the companion spec-kit extension); with stock SpecKit selected, only Create Spec appears, and the step-by-step flow always stays available.

This removes a duplicated block of text that wasted space and could occasionally cause a step to be logged twice. Plain SpecKit steps are unchanged in scope but now use a single, more reliable instruction to mark a step done and move the status forward, instead of a two-step manual edit. You won’t see a difference in the spec timeline; runs are just a bit tighter and less error-prone.

Instead of plain markdown, the viewer now lays specs out for fast reading: requirements and success criteria become labeled rows, acceptance scenarios read as clean Given/When/Then sentences, key entities and research decisions show as cards, the spec-quality checklist groups into pass/fail cards, tasks gather under their phases, and the plan’s Technical Context and Constitution Check render inline as a grid and pass/fail rows.

Recording each finished task used to rewrite the whole progress file every time, which the assistant sometimes had to retry and which quietly forced parallel work back into single file. Each finished task is now jotted down instantly to a side log and folded into the progress file in one pass after each batch, so the activity panel still keeps up while several tasks can genuinely build at the same time. Per-task timings stay just as accurate.

When a pipeline step wraps up, marking it done and bumping the spec to its next status used to take a few separate calls plus a quick re-check to be sure nothing got recorded twice or out of order. That now happens as a single, safe action: the step is recorded as finished and the spec advances to the right status together, with no stray bookkeeping. Running it again changes nothing, and a spec that’s already finished or archived is left untouched.

When a spec is marked complete, the small per-task progress log it keeps while building is cleaned up — always after everything in it has been recorded, so nothing is ever lost. Before, that log lingered, and starting the same spec folder over could fold in finishes from the previous run. Behavior during a normal run is unchanged; this is an internal tidy-up surfaced by a code review, with no setting or command change.

Instead of scattered “can run in parallel” flags, each phase of the task list is laid out as ordered waves — a wave groups tasks that touch different files and don’t depend on each other, and an explicit “wait for the wave above” line marks where the next group depends on the last. It reads clearly for a person and gives the assistant an honest dependency map to build against. Per-task notes (what each task did, which files) and the exact step-level timing are what the activity panel leans on; the per-task clock is best-effort, not a precise stopwatch.

The /speckit.companion.* pipeline produces the familiar spec-kit shape: a spec with prioritized user stories, acceptance scenarios, key entities, and edge cases; a plan with a summary, a constitution check, the concrete file layout, and the design files (research.md, data-model.md, contracts/); and a task list grouped by user story into phases. Same readable shape you already know, with the Companion extras layered on top: lifecycle timing capture, size-based right-sizing, and automatic completion.

The plan no longer restates the project’s known stack in a “Technical Context” block (your assistant already knows the codebase it’s working in), and it stops writing a quickstart file that only repeated the obvious. Plans now lead with a plain-language summary, the constitution check, and the concrete file layout — the parts that actually shape the build. A genuinely non-obvious stack choice still gets a sentence in the summary.

A task now records its own completion the instant its work is done, instead of the assistant doing a separate bookkeeping pass at the end of a phase — so the activity timeline reflects the real order and pace of the work rather than collapsing a whole phase into one moment. Checking the box in the task list is handled for you from that record, so when several tasks build at once none of them fight over the same file.

When recording that a planning or task-generation step finished, the assistant used to edit the progress file by hand, which occasionally wrote a malformed file it then had to repair. Those finish marks now go through the same safe writer everything else uses, so the file stays valid every time.

A Companion run now honors the same extension hooks a stock spec-kit run does, so the git extension (and any others you’ve installed) still fire at the start and end of each step — the branch-on-spec, the commit callouts, whatever they do. Previously those were silently skipped on the Companion pipeline. Companion’s own customization hooks run on top of them, unchanged.

When your AI assistant can work on several things at once, the Companion steps now spread the work out: it reads different parts of the codebase side by side while investigating, flags which tasks are independent enough to run together, and builds those independent tasks at the same time during implementation. Assistants that can’t do that simply run each step the usual one-at-a-time way and produce the exact same result — nothing to turn on, nothing breaks.

The new /speckit.companion.auto runs the entire pipeline end to end — from a description all the way to a finished, completed spec — without stopping for approval in between. It is the unattended sibling of the step-by-step flow and drives the very same per-step commands, so it can’t drift from what they do. There’s also a Run button in Create Spec that kicks off the same hands-off build from the editor.

Auto marks the run as unattended, and project checkpoint hooks (“Continue / Fix / Stop”) can read that signal to record the checkpoint and keep going instead of waiting for a person. Background work, reviews, and PR steps still run — only the human pause is skipped. On a plain one-shot terminal, Run falls back to the normal one-step-at-a-time flow.

You can now right-click it and choose Mark as Completed — previously the only way to confirm was the spec viewer’s footer. Implemented specs also get a distinct yellow beaker icon (vs. the green icon for confirmed-completed specs), so you can see at a glance which specs are done and which are still awaiting your sign-off.

The banner now adapts to its own width — the install button and “Learn more” link drop onto their own row below the text when space is tight, the body always wraps across the full width, and an over-long heading is trimmed with an ellipsis you can hover to read in full. At comfortable widths it looks exactly as before.

It’s now a muted gray — clearly a placeholder, still legible.

With the setting on (and the companion extension installed), Create Spec offers the SpecKit / SpecKit Companion picker and the sidebar shows the resume button; with it off, you’re on stock SpecKit only. The picker no longer appears when the companion piece isn’t installed, so you’ll never see a Companion choice that silently does nothing — and the install prompt stays reachable so you can add it. Upgrading is seamless: if you’d already turned the old resume toggle on, that choice carries over automatically and the old setting is cleaned out of your settings.

The field’s text is bumped to a comfortably readable size, and the empty field’s placeholder does the teaching — it lists what helps (what the feature is, the problem it solves, who it’s for, key requirements), shows a sample Jira link and a sample GitHub link to copy the shape of, and makes clear you can paste a reference link on its own and skip writing a description entirely. The redundant on-page “Specification” label and helper paragraph were removed from view (kept for screen readers) now that the title, subtitle, and placeholder carry the guidance.

The three former toggles — the template profile, the per-spec turbo workflow picker, and the complexity fast-path flag — are gone; the leaner output they used to enable now comes from the Companion workflow itself, and right-sizing small vs. large changes happens automatically inside that workflow with nothing to flip. Picking SpecKit Companion in a project that doesn’t have the companion spec-kit extension safely runs the standard flow instead, with a one-click install prompt. Upgrading is seamless: the default stays SpecKit, existing specs keep running the commands they started with, and any leftover values for the removed settings are cleaned out of your settings automatically.

The attachments area collapsed into a compact “Attach image” control beside the field, and the character counter stays out of the way until you near the 50,000 limit. It’s now usable without a mouse or sight: errors, “creating your spec…”, and image attach/remove are announced to screen readers; every button has a meaningful name; every control shows a visible focus ring when you tab to it; the limit is communicated beyond color and over-limit content can’t be submitted; the keyboard hint shows Cmd on macOS; and pressing Esc with typed content asks before discarding your work.

Specify now advances to “specified” on its own and the next-step (Plan) button reappears. Specs running the Companion pipeline are unaffected — they already advanced on their own.

It now resolves each spec’s own workflow (the same way the sidebar does) and falls back to the default only when none is set, so the button you see and click matches the spec in front of you.

This keeps the “still needs your Mark as Completed” state visible — which matters most for stock specs that never auto-complete — and the Completed group’s count now reflects only the specs you’ve truly confirmed. Filtering and sorting work the same on the regrouped specs; archived specs are unaffected.

The checkbox now sits next to the first line with the rest of the label hanging-indented, and it stays aligned at any font size.

It honors VS Code’s global telemetry setting too: if either switch is off, nothing is sent. It never collects prompt content, file paths, spec names, or custom workflow names — only enum-like values, booleans, versions, counts, and a random per-spec id that correlates one spec’s events without revealing which spec it is. See the Telemetry section in the README.

An optional project file (.specify/companion.yml) now lets you attach your own actions before or after any part of a Companion command — run a shell command, drop in an extra instruction, or call a reusable instruction file — and reorder which parts of a command run. If the file is absent, every command runs exactly as it ships. A worked example wires a full ship tail (review → PR → Copilot review → merge → reinstall) onto the end of a build; see examples/ship-ticket/.

Marking a spec complete used to require it to have already settled into the “implemented” state; a spec sitting at “implementing” with every task checked off would refuse to complete. It now completes correctly the moment all its tasks are done, and finishing the last task no longer bumps a closing spec back to “implementing.”

Each command is built from a short ordered list of named sections rather than one hand-written file, which is what makes the customization above possible. This is a behind-the-scenes reshape — the commands you run are byte-for-byte identical to before, proven by a parity check in CI — so nothing about how they behave changes.

The shared timing instructions baked into every stock command are now guarded so they always come from the single shared copy — if a command ever pasted its own version of them, the build catches it. Editing the timing rules remains a one-place change that flows into every command. The commands you run are byte-for-byte unchanged.

How a change is sized (small vs. large), how the pipeline routes after sizing, and how timing is recorded each used to be repeated across several command files. Each now lives in exactly one shared block that the commands reuse, so changing a rule is a one-place edit instead of hunting through three files. The installed commands stay whole and self-contained — running one in a plain terminal still gives you a complete command, and a parity check proves the reshape changed no behavior.

When you run a Companion step in an assistant that keeps working after a step finishes, it now reads the pipeline and continues into the next step on its own — pausing wherever the workflow asks you to review, and running a final “mark complete” step after implementation so the spec lands in Completed. In a plain or one-shot terminal nothing auto-advances: you drive the pipeline one step at a time, just as before, and completion stays a manual action. Stock SpecKit is unchanged and still stops at “implemented”.

There used to be two advertised shapes — a “standard” profile and a “turbo” profile. In practice there was only ever one Companion workflow: the lean one. That lean shape is now the single Companion offering. The dead “turbo” preset is gone, and “turbo”/“standard” no longer appear as profile names in the commands or docs. Stock SpecKit is untouched — it’s still the unchanged /speckit.* commands with better timing capture, available to everyone. If you ever installed the old turbo preset, it’s cleaned up automatically on upgrade.

The right-sizing fast-path — which folds a small change straight to implement instead of running the full specify → plan → tasks pipeline — is now on by default. No flag to set. Larger changes (more than 5 files or 10 tasks, or a “bigger” scope signal) still run the full pipeline and print the guardrail warning, exactly as before; nothing is ever silently fast-tracked.

The 0.5.0 minimum was written as >=0.9.5, which — under Python’s version rules — actually excludes the 0.9.5.devN pre-release builds that uv tool install --from git+… produces (the exact install path the README recommends). The result was a Compatibility Error: requires spec-kit >=0.9.5, but 0.9.5.dev0 is installed on a correctly-set-up machine. The floor is now >=0.9.5.dev0, which accepts those dev builds and every 0.9.5+ release.

A routing node right-sizes the pipeline: a small change folds plan/tasks toward implement, a normal change runs the full pipeline with both gates, and an oversized change prints a visible warning and still runs the full pipeline — it never silently skips a phase. The ≤ 5-files / ≤ 10-tasks thresholds now live inside the workflow; there’s no on/off toggle to set.

Instead of invoking specify, plan, tasks, and implement by hand, run specify workflow run speckit-companion (or point it at the workflow file directly) and spec-kit’s engine drives the entire pipeline end to end — specify → plan → tasks → implement → mark-complete — pausing at review gates before planning and before tasks. Paused at a gate? specify workflow resume <run_id> picks up from the exact step it stopped at. Every step still feeds .spec-context.json, so the VS Code GUI lights up for both run and resume.

The footer pill is gone; the step tab is now the single “AI is working” signal, and during implement it shows a spinning indicator next to the live task percentage instead of a static “Tasks 0%”. While a step is still in flight the footer no longer offers the next-step button (there’s nothing to advance yet). Reduced-motion users get a static indicator.

Enable speckit.companion.resumeBeta to show it on active specs (active / tasks-done); toggling it on or off updates visibility immediately, with no window reload. Resume now also dispatches the command family the spec has been running — a turbo spec resumes with /speckit.companion.<step>, a stock spec with /speckit.<step> — across every step it can advance.

Marking a spec completed by hand still works.

.specify/specs is now scanned by default, and a freshly-created spec clears the welcome screen and lists itself without reloading the window.

standard runs the stock commands; turbo produces a trimmed shape — a spec with no user-story section, tasks grouped by files/dependencies, and a smaller spec folder; off falls back to plain upstream spec-kit. Both command sets stay installed at all times — switching the setting is non-destructive: it only routes which one a spec uses and never deletes either, so creating a spec never fails with “Unknown command”, in any mode or after any number of switches. Each spec pins the project default the moment it’s created, so changing the setting reshapes only new specs, never one already in flight. See docs/template-profiles.md.

Opt-in beta.

the companion pipeline — directly. Label-only: the choice still pins the same turbo pipeline, the speckit.companion.templateProfile setting still lists Standard / Turbo / Off, and no settings or existing specs are migrated.

When a change projects at or under 5 files / 10 tasks (and reads as a small change), specify writes a single combined spec.md — the usual sections plus an inline Approach and Implementation Tasks list — and lands the spec at the implement step in one run. Larger changes keep the full pipeline; a change that crosses the 5-files / 10-tasks guardrail warns and runs the full pipeline rather than fast-tracking silently. Enable it with the speckit.companion.complexityFastPath setting. See docs/template-profiles.md.

No setting keys or values changed.

Turn template shaping on by selecting standard or turbo; existing projects that already pinned a profile are unaffected.

Completing any step — specify, plan, tasks, or implement — now updates the open viewer on its own within a second or two, the spinner stops, and the next action appears, with no need to switch steps. This works wherever your specs live, including the configured spec directories rather than only the legacy location.

The mode is now a non-destructive routing choice: both command sets are always present, and a project left without its stock commands by an earlier version recovers automatically on the next reload.

Every toggle except the install prompt now states that it needs the companion spec-kit extension and links to the install instructions, so a toggle that looks inert is clearly waiting on the extension. Defaults and behavior are unchanged — only the ordering and descriptions differ.

This removes the 0s ticks, the unattributed gaps between tasks, and the substep “bursts” that previously showed up in the timeline, so per-step and per-task durations read accurately. See docs/capture-and-timing.md.

When it’s missing, an Install spec-kit extension banner appears in the Create-Spec and Activity panels and an install icon appears in the Specs sidebar — clicking either runs the install in an integrated terminal, no copy-paste. Already-installed projects never see the banner.

It now points at a stable address that always serves the latest published spec-kit extension, so install and update both land the newest build and no longer drift out of date between releases.

The update check now reads your installed version reliably and the links resolve to the live listing. The check also compares only against the VS Code releases, so a spec-kit-side release no longer masquerades as a newer GUI version.

When recording implement progress, the capture now trusts the task list it’s handed — the spec whose tasks.md you pass is the spec that gets updated — instead of whichever spec the workspace currently treats as “active.” Previously, finishing one spec’s implementation while a later spec was active could write the completion into the wrong spec and flip an unrelated spec to done. If a conflicting feature directory is also passed, the capture now refuses to write rather than guessing.

The install command now points at a permanent download URL that always serves the newest release, so you’re no longer frozen on whatever version you happened to copy. Install with specify extension add companion --from https://github.com/alfredoperez/speckit-companion/releases/download/companion-latest/companion.zip --force, and to update later, re-run the exact same line — --force refreshes your installed copy in place. No version number to bump, no new URL to hunt down.

/speckit.companion.status prints the active spec’s current step, status, recorded decisions, and next action. /speckit.companion.resume continues the pipeline from the recorded step — and at the next unchecked task when mid-implementation — reporting “Pipeline complete” on terminal states. Works on stock spec-kit; no specify workflow resume subcommand required.

When enabled, /speckit.companion.specify classifies the change it just spec’d. A small change (projected ≤ 5 files / ≤ 10 tasks, no “larger” scope phrase) writes three lean files in one pass — spec.md (with an inline Approach), a plan.md pointer to it, and a real-checklist tasks.md — and folds plan and tasks into the same run, so the spec lands ready-to-implement in one pass instead of three (and the stepper/sidebar read the files as present, not “not created”; implement is the next user-triggered step). Larger changes keep the full pipeline; a change that crosses the 5-files / 10-tasks guardrail warns and runs the full pipeline rather than fast-tracking silently. Turn it on with speckit.companion.complexityFastPath: true (VS Code setting); it’s mirrored into .specify/companion.yml for the command body to read.

/speckit.companion.resume now resolves the next command from the family the spec has been running, read from its recorded profile: a turbo spec resumes with /speckit.companion.<step>, a stock spec with /speckit.<step>. This applies to every step resume can reach — plan, tasks, implement, finishing the current step, and the clarify/analyze fall-throughs — so the command shown in the terminal always matches the spec’s flow. Specs with no recorded profile keep dispatching the stock /speckit.* commands, so stock-flow specs are unchanged.

The turbo specify again produces a checklists/requirements.md quality checklist — a trimmed version without the user-story / acceptance-scenario items, graded in a single self-check pass — instead of dropping it. And plan’s side files (research.md, data-model.md, contracts/, quickstart.md) are each created only when the file genuinely helps a developer understand or build that change, rather than by fixed “if entities / if interface” rules — so research.md and quickstart.md are no longer always dropped. The four-section spec (Overview + Functional Requirements + Success Criteria + Assumptions) and the files/dependencies task shape are unchanged. See ../docs/template-profiles.md.

The after_plan, after_tasks, and after_implement hooks record each step into .spec-context.json automatically, so the VS Code GUI always reflects the real pipeline state. When a hook never ran, the state is reconstructed from the on-disk artifacts and git history.

Per-step durations and per-task cadence are stamped by the capture scripts instead of being hand-authored by the AI, so they stay reliable across the terminal, IDE chat, and the GUI. specify records a real begin→end span, each implement task records a single finish event, and durations come from the gaps between finishes — no duplicate starts, 0s ticks, or burst-stamped substeps. See ../docs/capture-and-timing.md.

A run that dumps every task’s completion in one end-of-step burst — instead of recording each task as it actually finishes — is caught and reported as a failure, where it previously passed as honest cadence. Every recorded event is checked against a fixed format, so a malformed or incomplete entry is flagged instead of silently accepted. The assistant is now instructed to journal each task the moment it completes. Records written by earlier versions keep working and rendering unchanged — nothing is rewritten on disk.

Task capture only recognized the turbo/companion bold marker (- [x] **T001**) and silently skipped the standard tasks-template’s plain markers (- [x] T001), so a standard-profile spec recorded no per-task progress and its implement step never auto-closed. Both marker formats are now detected.

Two pipeline shapes you switch between with the speckit.companion.templateProfile VS Code setting (standard | turbo | off, default off — an opt-in beta). Standard runs the stock /speckit.* commands; turbo produces a trimmed shape — a spec with no user-story section, a trimmed plan, and tasks grouped by files/dependencies (a smaller spec folder). Switching is non-destructive: both command sets stay installed and the setting only routes which one a spec dispatches, so you never lose a command set or hit “Unknown command”. Each spec pins the project default the moment it’s created, so changing the setting reshapes only new specs, never one already in flight.

(#193, #190 — thanks @JLanders96)

The Mark step complete manual override moves to the left styled as a quiet secondary action, communicating “one thing is happening, one thing is a fallback override.” Applies uniformly to specify / plan / tasks / implement. No behavior change to the override click handler; approve / inline-comment / post-completion footer modes are unchanged.

Resume dispatches /speckit.companion.resume for the spec via your configured AI provider — continuing the pipeline from the recorded step with prior decisions in scope, and at the next unchecked task when mid-implementation. The action is gated to active specs (not completed/archived) and the row updates live once the dispatched step records its state. Backed by two new Companion spec-kit commands (speckit.companion.status / speckit.companion.resume) and a status-context.py resolver that reads .spec-context.json or derives state from on-disk files when it’s missing. Resume works on the stock spec-kit version (no specify workflow resume subcommand required).

Added analyze and clarify to the substep table (single-pass — empty arrays), wired their completed status (ready-to-implement / specified) and done phrase, and guarded the substep-line renderer for empty arrays. Works in isolation: no edits to .specify/extensions.yml or user-local skill files required.

(#192, #190 — thanks @JLanders96)

The live entries carry the task id, so the hook’s --tasks-file sync dedupes against them and becomes a no-op backstop (it still journals everything when the preamble is disabled). Applies to single-step /speckit.implement and multi-step/auto lifecycle runs.

The notification offers a Reset context action that moves the broken file aside to a timestamped backup (.spec-context.json.bak-<timestamp>) and writes a fresh minimal skeleton in its place, then reloads the viewer. The original bytes are never overwritten in place (they survive in the backup); dismissing the notification leaves the broken file untouched and reopening the spec re-offers the reset. The reader now throws a typed SpecContextParseError (carrying filePath + reason) so the corrupt-file case is distinguished from a missing file without sniffing message text. JSON-syntax failures only — semantically-off-but-parseable files are still tolerated and coerced.

The spec viewer’s ensureSpecContext would then write a fresh backfillMinimalContext (raw-basename specName, empty history, status: 'draft') over the real file, destroying lifecycle history. Fixed across the stack: the readers now return null only for ENOENT and throw on parse/IO errors; writeSpecContext stat-guards the target and refuses to write when an existing file is present-but-unreadable; the spec viewer’s updateContent only calls ensureSpecContext on the first open of a panel (subsequent tab clicks are strictly read-only); saveFeatureWorkflow only emits a minimal context on ENOENT. New regression tests (specContextWipeGuard.test.ts) pin the on-disk file-unchanged invariant.

A pure resolver now maps speckit.aiProvider (and the host editor, for ide-chat) to a valid CLI agent; both dispatch sites route through it, and an unrecognized provider falls back to claude. The three upgrade commands are consolidated behind a single Upgrade… picker, and a stale speckit.workflowEditor.enabled doc reference was removed. (#190 — thanks @JLanders96)