A concert booking service lets fans reserve seats and join a waitlist. Separate booking and notification changes must follow one release rule. Its developers need traceable agreement; an isolated label correction would need less structure.
How: work toward a solution
Specify when a released seat goes to the waitlist, plan the boundary, and link implementation tasks to that rule. Check the code against the artifacts and resolve gaps. Reuse confirmed answers.
One waitlist rule follows the specification, plan, tasks, and code review
Concert booking · illustrated requirement trace
Keep one rule through every stage
Waitlist first
Cancelled seat → next eligible fan → public offer after the agreed response period
1
spec.md
Waitlist first · Next eligible fan before public sale
Waitlist first
2
plan.md
Waitlist first · Booking and notification boundary
Waitlist first
3
tasks.md
Waitlist first · Implement and check queue-first notification
Waitlist first
4
Convergence
Waitlist first · Compare code with the agreed rule
Waitlist first
↳ Implementation gap found? Add remaining tasks and check again.
Agree on eligibility and response time. Documents and task boxes do not replace behavior checks; setup and review add work.
What: the concept
Spec Kit provides agent workflows, templates, and setup tools for specification-driven development. It also offers optional repair and idea-assessment processes. Choose by coordination and risk; size alone does not justify installation.
This example prioritizes a shared rule that affects booking and notification work. Spec Kit carries requirements through planning, tasks, implementation, and convergence. Starting without extra skills may fit adequate existing practices. Superpowers emphasizes repeatable development skills; OpenSpec records current requirements and change deltas. These tools can overlap or combine, but one artifact set should own each plan, task list, and requirement. No package guarantees assistant compliance.
02Applications
The example rule is: after a cancellation, notify the next eligible fan before offering the seat publicly. Record eligibility and timeout decisions rather than inventing them. Review the specification, technical plan, and tasks; map checks to the agreed rule. Convergence inspects implementation against those artifacts and may add remaining tasks. A small access-control change can merit this discipline even with few files.
03Implementation & cautions
In the external agent, inspect the current runtime, installed Spec Kit, project files, and official installation guide. Select the supported integration for that agent; reuse an existing installation. With installation authority, install the reviewed release and initialize the intended project scope, then inspect generated files and invocation support. Terminal setup and agent skill invocation are separate. In Codex the skills use names such as $speckit-specify; confirm the installed form. Existing-project initialization can replace conflicting managed files, so preserve local work and review the diff. Begin implementation only within approved scope. Reuse its specification, plan, and tasks for kickoff’s records rather than maintaining duplicate plans.
Already talking with external AI? Share this article link and explain why the choice fits your project and which tradeoff matters. Ask how it applies to your agreed requirements.
Discuss this idea
Comments are shared across languages. GitHub login required to post.