Jesse Liberty

I’ve been writing quite a bit about Spec Kit. Mostly because I can’t get over how effective it is when combined with Copilot. Spec Kit essentially “forces” you into Spec Driven Development best practices.

Spec‑Driven Development (SDD) flips the usual order of product work: start with a clear, testable spec that captures intent, evidence, and acceptance criteria, then drive planning and implementation from that spec. GitHub’s open-source Spec Kit is a practical toolkit for doing SDD consistently. It defines a small set of core phases you’ll use for most features and a fuller, production‑ready flow that adds project‑level setup and quality‑gate steps.

For the past six weeks I’ve been developing my demonstration program as a console application. Today I decided to give it a nice front end using Blazor (I don’t know Blazor). In the time it took to listen to Tommy (The Who, 1969) and half of The Wall (Pink Floyd, 1979) I had my first, second, and third drafts. That represents almost 30,000 lines of new code and documentation in well under 3 hours.

Yesterday I set out to add Cosmos to my demonstration project. The goal was to keep track of all queries, even after the browser is closed. My plan was to work with Spec Kit and Copilot, as described in my previous blog post. I didn’t know enough about working with Cosmos, but I was not intimidated; I had help.

The first step was to create a specification, saying what I wanted to build. (I reused the existing Constitution).

I am totally blown away by the combination of Spec Kit and Copilot. It is one thing to read about SDD and quite another to build with it.

[For more on the steps in SDD, please see what I wrote about Spec Kit previously.]

Today I fired up Spec Kit and pointed Copilot at it, instructing Copilot to create a constitution based on the existing code (my blog writing demo). A minute later I had a comprehensive document that listed all the immutable characteristics of the application. It was quite long, but here is the beginning:

tl;dr
If you’re building automated workflows that sometimes must pause for human judgment (approvals, moderation, triage), Microsoft Agent Framework provides first‑class HITL primitives: typed RequestPorts, durable suspended execution, emitted RequestInfoEvents, and automatic routing of responses back to the correct workflow executor.

This article explains the runtime mechanics (what happens when a workflow asks a human for input), the developer experience (what you write), concrete examples (C# + JSON contracts), integration patterns with Bot Framework/contact centers, failure modes, and testing strategies.

For those who are following along with the evolution of my Blog Writing application: after the last revision (allowing follow-up questions to a query) Copilot evaluated my Pull Request and sent me an email that the follow-up was not, in fact, being added to the research stage. This was because the original research was in place and so that step was skipped.

Copilot and I fixed this with the following changes: