Features
The things this extension deals in. Each page explains what the thing is and how to write one — what a reference table cannot tell you, because the reasoning is the part that does not survive being compressed into a list of keys.
| Workspaces | where “here” is. Folder, workspace and profile scopes, and what changes when you open a .code-workspace. |
| Spec-driven development | a process whose tasks are AI-drafted documents and human decisions. The styles that ship, their exact prompts, and writing your own. |
| Workflows | pipelines you declare and the engine runs. Writing a new one. |
| Tasks | the one-liners you run all day, in tasks.yml — each runnable on its own. |
| Plugins | the last, smallest thing that executes. Every task bottoms out in one. The four that ship, and writing your own in plain JavaScript. |
package.json |
your existing npm scripts, listed beside everything else. |
If you already know what you are looking for, the cheat sheets have the keys, values and defaults with none of the explanation.
If you have not run anything yet, start with Getting started — these pages assume you have.
The one distinction worth having up front
The engine knows nothing about spec-driven development.
The runner walks a graph of tasks: resolve the args, run the task, record what happened, stop at the gates. SDD is a layer above that — a folder of prompts, a config file, and a purpose-built panel — expressed entirely in terms the engine already had.
That is not an implementation detail you can ignore. It is the reason a style is a YAML file you can replace, rather than a feature you have to wait for someone to build. Every phase of every process is a stage with a prompt and a gate, and nothing in the engine knows what “requirements” means.