Stop Writing Prompts. Start Writing Specs.
Roelant Dieben demonstrates an end-to-end GitHub Spec Kit workflow
Roelant Dieben demonstrates GitHub Spec Kit with GitHub Copilot: store non-negotiable rules in a constitution, capture intent in a specification, move technical choices into a plan, generate ordered tasks, then implement an HTTP MCP server. The demo relies on prepared branches for most stages and shows one MCP Inspector result; it offers no prompt-first baseline, test output, or comparative quality, time, or cost evidence.
Roelant Dieben demonstrates a way to make agent instructions reviewable by a team: store rules, desired behavior, technical decisions, and tasks in versioned repository documents. Using GitHub Spec Kit with Copilot, he builds a Model Context Protocol (MCP) server that lets an agent query Microsoft Build sessions.
Key Points Covered
- Make the specification the durable artifact: Dieben contrasts instructions left in private chats with a repository specification that the team can review, retain in Git history, and extend for later features. The workflow still uses prompts; the difference is where the agreed requirements live 00:52–04:52(opens in a new tab).
- Separate rules, behavior, and implementation choices: The constitution holds cross-project or team non-negotiables; the functional spec describes what to build without technical details; the plan records stack, framework, version, deployment, and configuration decisions 01:56–02:58(opens in a new tab), 10:38–14:54(opens in a new tab).
- Inspect the generated scaffolding:
specify initconfigures the chosen agent integration and adds Markdown, scripts, and slash commands. Dieben recommends reading the.specifydirectory rather than treating the framework as magic 05:43–07:38(opens in a new tab). - Review every generated document before implementation: The team should understand and accept the constitution, specification, and plan. Dieben also warns that the plan may select a framework version that is not the desired one unless the prompt states it explicitly 02:58–03:49(opens in a new tab), 14:54–15:58(opens in a new tab).
- Generate bounded tasks, then implement: The tasks phase orders setup, prerequisites, and user stories; the implementation phase turns those tasks into code and tests. Dieben uses prepared branches for much of the demo. The result starts as an HTTP MCP server and returns a session through the MCP Inspector, a tool for exercising the server; that is a functional demonstration, not a full test or security review 09:34–10:38(opens in a new tab), 15:58–20:14(opens in a new tab).
- Adopt the workflow on one meaningful feature first: Start with a small real feature, capture what and why before how, add a few non-negotiable rules, review the artifacts, and revise the living constitution as the team learns 19:10–21:17(opens in a new tab).
Full video: https://www.youtube.com/watch?v=Orr7qadkZD8(opens in a new tab)