We Built a Release Queue With GitHub Spec Kit and Claude Code

The publishing problem

A publishing calendar sounds simple until one piece of content depends on another. A YouTube Short that points people to an article needs to go out after that article, not before it. Then someone puts the article on hold, moves a date, or accidentally tries to mark the same item published twice.

That's exactly the kind of scheduling problem a small publisher juggles every week, so we handed it to Spec Kit and Claude Code as a bounded test project: build a small local release queue that keeps those rules straight.

The project we asked for

The brief asked for a deliberately narrow command line tool, written in Python with nothing beyond the standard library, storing its queue in a local JSON file. It manages two kinds of content, articles and YouTube Shorts, and it had to obey a short list of rules we wrote down before any generation began:

• A Short must never be scheduled before its associated article.
• The queue lists unpublished items in date order.
• A held article is visibly held, and its Short is shown as waiting on it.
• Rescheduling rechecks the article and Short relationship in either direction.
• Publishing records one publication and refuses a second attempt.
• Records survive separate runs, and bad dates or unknown IDs produce clear errors without corrupting the saved data.

This was a disposable prototype in an isolated workspace. It never touched ToolRiot production systems, and it isn't our production scheduler.

Claude Code drove Spec Kit's installed workflow through its stages: specification, plan, task breakdown, a consistency review, then implementation. The consistency review's recorded report, preserved with the trial evidence, mapped every requirement to a task and found no critical issues before any code was written. The finished project contained the workflow documents plus the program, its test suite, and a README.

Following one rule from brief to result

The most meaningful rule in this project was simple: a YouTube Short cannot be scheduled before the article it promotes. Here is how that rule stayed connected through every stage.

Our brief's acceptance criterion said:

A Short can never be scheduled before its associated article, at creation or by rescheduling either item.

The generated specification turned that into a numbered requirement, citing the criterion it came from:

- **FR-003**: The system MUST refuse to add a Short whose scheduled time is earlier than its article's scheduled time, reporting an error containing "before its article", exiting nonzero, and saving nothing. (A3)

The task list carried the requirement into concrete work: one task defined the dependency check and another required the Short creation command to run that check before saving anything, each citing the requirement by its number. The test suite then covered both moments where the rule could break, with tests named for the behavior:

test_short_before_article_refused_at_creation
test_reschedule_short_before_article_refused

Finally, we watched the rule work. When we tried to move "Spec Kit review Short" to a date before its article, the app refused:

error: cannot schedule a Short (2026-07-20 09:00) before its article (2026-07-21 09:00)

One rule, visible in the brief, the specification, the task list, the tests, and the running program. That traceability is the most convincing thing Spec Kit added.

How the finished queue behaved

We restored the archived project into a clean environment and ran the whole flow as separate commands, each one starting the program fresh: schedule the article, add its related Short, watch the invalid early date get rejected, place the article on hold, release and reschedule it, then publish it exactly once. Because every step ran as its own command, the queue proved it kept its records between runs at every stage.

The hold state is a good example of what the queue's list actually showed. With the article on hold, the recorded output was:

#2 SHORT "Spec Kit review Short" 2026-07-23 17:00 [scheduled] — waiting on held article 1
#1 ARTICLE "Spec Kit review article" 2026-07-21 09:00 [HELD]

The held article dropped out of the active order, and its Short said plainly what it was waiting for.

What the automated checks protected

The project's automated suite exercised the same rules the brief demanded. Here is what each check protected.

The suite covered scheduling, dependencies, holds, rescheduling, persistence, and duplicate protection. Every check passed in the original workspace and again after we restored the archived project in a clean environment.

Spec Kit's contribution

Spec Kit supplied the structure: the templates, scripts, and skills that produced a written specification, an implementation plan, a task breakdown, and the consistency review that connected them. Requirements got identifiers, tasks cited the requirements they implemented, and a reviewer could follow any rule backward to the brief.

Claude Code's contribution

Claude Code did the building. It interpreted the workflow documents, wrote the program and its tests, ran the permitted commands, and kept working until the tests passed. Its recorded run contains no questions back to us, which worked here because the brief was specific about behavior, storage, and errors.

Where human judgment mattered

We decided what problem was worth testing, wrote the acceptance criteria, and prepared the isolated workspace with Spec Kit installed and verified. Afterward, we reran the complete release flow and the test suite in a clean restored copy of the project.

The brief also made product decisions an agent should not quietly make on its own: local storage only, no accounts, no cloud services, no connection to real publishing platforms. A good specification gives a coding agent useful boundaries. It doesn't make the agent responsible for the product.

What this test does not prove

We didn't run the same brief through Claude Code without Spec Kit, so we can't say the workflow made the work faster, better, or cheaper than direct prompting. That comparison wasn't tested.

The scope was one coding agent, one language, and one small project. Nothing here covers team collaboration, long term maintenance, larger codebases, or changing requirements. And the prototype isn't production scheduling software: no accounts, no permissions, no integrations, no real publishing connections.

Who this workflow is for

This workflow is most useful when a project has connected requirements that need to stay consistent through planning, implementation, and testing. It also helps when someone reviewing the work needs to trace a feature back to the original request. Both applied here.

It's probably unnecessary for a quick change to one file, and it's no replacement for production engineering controls where customer data, payments, or live systems are involved.