Spec Skills Case Study: From Ticket to Spec

A walkthrough of going from a vague support ticket to a shippable technical spec using Spec Skills guided questions — the actual transcript and what the output looked like.

Published on 2026-03-10 · Updated 2026-05-11 · 8 min read · Author: Spec Coding Editorial Team · Review policy: Editorial Policy

The Ticket That Kicked This Off

We had a ticket sitting in the backlog for six weeks. Flagged urgent, four sentences, and every PM who picked it up bounced off it within an hour. Here is what it actually said, pasted from Linear:

"Customers can't cancel subscriptions — need to add cancellation flow with retention offer. Support is drowning in refund requests. Legal also wants a paper trail. Let's get this shipped this sprint."

That is the entire ticket. No acceptance criteria. No definition of "cancel." No success metric. No notion of what a retention offer looked like. No mention of prorated billing, active API keys, or the other features a lapsed account still touches. We fed it into Spec Skills instead of writing the usual three-day discovery doc.

Spec Skills First Pass: The Questions Nobody Wanted to Ask

I pasted the ticket into Spec Skills and asked for a spec draft. It refused. Instead, it returned nine clarifying questions before it would draft anything. A few we had loosely thought about. Most we had been actively avoiding:

• Does "cancel" mean immediate termination of access, or end-of-billing-cycle access with no renewal?
• If end-of-cycle, do they keep write access, read-only access, or a grace period of X days?
• Is the retention offer a discount, a pause, a downgrade, or all three? Who owns the offer matrix?
• Do we issue prorated refunds on immediate cancel, and if so, who approves the refund logic — finance or product?
• What happens to active API keys, scheduled exports, and team seats when a subscription cancels?
• Is this self-service only, or does support still need a manual override path for edge cases?
• What does the "paper trail" look like for legal — signed confirmation, emailed receipt, immutable audit log, or all three?
• What is the success metric — cancel completion rate, retention-offer acceptance rate, or reduction in support tickets?
• What is the rollback plan if the flow starts producing bad refunds in production?

Reading the list out loud in standup was uncomfortable. We did not have clean answers to six of the nine. That was the point.

The Conversation Those Questions Forced

The next forty minutes was the conversation we should have had six weeks earlier. Finance vetoed immediate refunds above a dollar threshold without manual review. Product picked end-of-cycle access with a seven-day grace window. The retention offer became a single 30% discount for three months, not a matrix — we explicitly descoped the downgrade path because it touched the plans table. Legal wanted a signed confirmation plus an immutable audit row, not just an email.

Every decision had an owner before we wrote a single line of spec. That is the part the meeting-driven version always got wrong for us. We would reach rough consensus, then the spec author would quietly re-interpret it into whatever was easiest to write. This time Spec Skills had pinned each question to a specific answer slot, and we filled them in front of each other.

The Spec Structure Spec Skills Assembled

Once we fed the answers back in, Spec Skills produced a draft in eight sections — a structured document with named owners and explicit boundaries:

• Goal and non-goals — cancel flow with retention offer, end-of-cycle access. Non-goals: plan downgrades, seat reassignment, reactivation.
• User stories — three primary, one support-override, one legal-audit.
• Acceptance criteria in Given/When/Then form, grouped by surface.
• Data changes — one new cancellations table, two new columns on subscriptions, one cron job.
• API contract — two new endpoints, one modified webhook, explicit idempotency keys.
• Risk register — what breaks, who is affected, rollback path per risk.
• Rollout plan — 5% of self-serve for 72 hours, then 100%.
• Metrics — completion rate, retention-offer acceptance, refund error rate, support ticket delta.

Acceptance Criteria It Surfaced

This is where the draft stopped feeling like a doc and started feeling like a contract engineering could build against. Two of the Given/When/Then blocks from that session:

Given an active paying customer clicks "Cancel subscription"
  And they have more than 7 days remaining in their billing cycle
When they confirm cancellation and decline the retention offer
Then access remains active until the billing period end date
  And no further invoices are generated
  And a row is written to the cancellations audit table with the confirmation timestamp
  And a signed confirmation email is dispatched within 60 seconds

Given a customer accepts the retention offer
When the acceptance is confirmed
Then the subscription remains active with a 30% discount applied for the next 3 billing cycles
  And the offer_accepted_at timestamp is recorded
  And the customer cannot be offered another retention discount within 12 months

I did not write those. Spec Skills drafted them from our answers and we edited three words total. The twelve-month cooldown was its addition — legal flagged it as necessary on first read.

The Risk Register It Prompted For

The risk section was the one I did not expect to find useful and ended up being the most valuable page. For each surface touched, Spec Skills asked what breaks, what data changes, and who is affected. We ended up with a short table: webhook consumers might miss cancellation events if the new type was not allowlisted; the billing cron could double-process a subscription that cancelled and renewed in the same minute; the audit table needed row-level locking or finance would hit race conditions during month-end exports. None would have surfaced from the original ticket. One would have shipped broken.

What Spec Skills Got Right, What It Got Wrong

What it got right: it forced the awkward questions early, before anyone had written code or committed to a ship date. It refused to draft anything until the unknowns had owners. It produced Given/When/Then engineering could read without a glossary. It named risks we would have discovered in production.

What it got wrong: it suggested a retention email follow-up sequence — three emails over two weeks with win-back offers — that was not in the ticket or our answers, and presented it as core flow, not optional extension. We pushed back and removed the section. If we had not been watching, that would have quietly added lifecycle-email scope to an already-full sprint. It is a good writer, not a good PM. Guard scope.

Three Days to Four Hours

The previous version of this workflow averaged three working days — triage, discovery doc, two review cycles, finance negotiation, legal pass, sign-off. This one took four hours end to end: forty minutes of live stakeholder conversation, ninety minutes of Spec Skills drafting and me editing, the rest sign-offs. The spec landed at 1,800 words and sits as a public example at spec-coding.dev under the cancellation flow template. We shipped nine days later with zero spec-related rework tickets — a number I have not been able to write down before.

Workflow Artifact to Copy

Use this when the article becomes part of a Spec Skills run. It keeps the model output tied to a bounded source packet and gives reviewers something concrete to mark up.

Spec Skills workflow packet: Spec Skills Case Study: From Ticket to Spec

Decision to make:
- A walkthrough of going from a vague support ticket to a shippable technical spec using Spec Skills guided questions — the actual transcript and what the output looked like.

Owner check:
- Product owner:
- Engineering owner:
- QA or operations reviewer:

Scope boundary:
- In scope:
- Out of scope:
- Assumption that still needs approval:

Acceptance evidence:
- Test or fixture:
- Log, metric, or screenshot:
- Manual review step:

Tool boundary: the model may draft structure and open questions, but owner approval is still required for scope, contract behavior, and release risk.

Reviewer prompt:
- What would still be ambiguous to someone who missed the planning meeting?
- What evidence would make this safe enough to ship?

Editorial Review Note

Reviewed Apr 28, 2026. This update added a reusable artifact, checked the article against the related topic hub, and tightened the next-step links so the page works as a practical reference rather than a standalone essay.

Ticket-to-Spec Review Checklist

Use this checklist when a rough product ticket needs to become something engineering can build and QA can test. The goal is not a longer document; it is a ticket whose assumptions are visible before implementation.

Download: ticket-to-spec-field-template.md

• Quote the original ticket so reviewers can see what was inferred versus what was actually requested.
• Name goals, non-goals, owner, approval path, and unresolved decisions in separate sections.
• Convert the main behavior into Given/When/Then acceptance criteria with one failure path.
• Add a risk register for data, billing, support, API, and rollback impact before scope is approved.
• Keep any AI-suggested extension marked as an assumption until a human owner accepts it.

Evidence to Track

Track how many clarification comments remain after the first review, how many acceptance criteria map to tests, and whether implementation adds scope that was not in the approved spec. Those are better signals than word count.