Add PRD to steel thread skill

[TRahulSam1997]

Why

Product PRDs describe what to build, but technical planning benefits from first identifying the thinnest end-to-end steel thread and then sequencing the remaining scope as demo-ready vertical slices. This skill creates that bridge without embedding organization-specific domain knowledge.

Parallelism must be considered while slices are formed, not added after technical tasks are generated. Capturing Dev+agent pair capacity, dependencies, safe parallel groups, and synchronization points in steel-thread.md gives Spec Kit /speckit.plan or an equivalent SDD planning step the delivery constraints needed to produce an executable design without forcing unsafe concurrency.

What changed

• adds the host-agnostic prd-to-steel-thread skill
• produces steel-thread.md with a solo steel thread, demo-ready slices, JIT infrastructure, and capacity-aware parallelism
• includes generic PRD and steel-thread templates
• adds an SDD planning/design hand-off that supports Spec Kit and other workflows
• documents the skill in the toolkit catalogue

[TRahulSam1997]

Engagement example of skill being used on a real feature that was shipped.

Running agent with skill

Running.agent.with.skill.mov

Internal agent asking human questions (guided by skill)

Ravi.asking.human.questions.guided.by.skill.mov

Internal agent asking human questions for further clarification after creating steel thread doc

Ravi.asking.human.questions.for.further.clarification.after.creating.steel.thread.doc.mov

Steel thread ready!

The next step is to run /speckit.plan on a fresh agent and feed this steel thread MD file along with the PRD to begin the build process 🔨

Usually the PRD itself is fed into /speckit.specify as that's product oriented whereas /speckit.plan is the technical implementations steps.

[bsigney]

Really like this. What makes it work for me: steel thread as Slice 0 and solo before anything fans
out, infrastructure only in the slice that exercises it, and "capacity is a ceiling, not a target" —
that last one is the opposite of how most plans get written. Flat Slice 0..N instead of lanes and
1a/1b keeps it readable too. Repo side's clean: validate passes, links stay inside the skill,
README row's there.

Just a few inconsistencies to sort out — mostly the same rules written in several places, and a
couple have already drifted apart from each other. Comments inline.

[bsigney]

This list also lives at

• references/vertical-slice-method.md 100–106
• and twice intemplates/steel-thread.md (127–132, 148–149)
  they don't match. This copy drops verbatim wording and PRD traceability; the reference keeps them.

Step 8 is what the agent actually executes, so the hand-off it writes won't carry the verbatim
rule — then check 187 ticks to say it did.

Fix: make the template's hand-off section the only copy and have this step point at it.

[bsigney]

Dependencies, pair counts and parallel groups are each stored in 2–3 places:

• the glance table,
• the slice section,
• and the parallel plan.
  "Slice 2 depends on 1" gets written as the table's Depends on column, as **Depends on:** (L75), and as Starts after: (L97).

So if I ask for a dependency change at the step 8 gate and the agent updates the slice section
but misses the other two, the doc ends up asserting two sequences at once, with nothing flagging it:

Table:           Depends on 1
Slice section:   Depends on 0
Parallel group:  Starts after 1

L124 says this document is "the confirmed delivery sequence" — so whichever copy the planner
reads first wins. Read the table and Slice 2 gets scheduled behind Slice 1, which loses the
parallelism the whole analysis was for, and nobody notices.

Suggested Fix: let the slice sections own these fields and cut the table back to number / slice / delivers.
One copy, nothing to desync. Same reason I'd drop Parallel-safe with (L77) — it's Parallel group (L79) restated per-slice.

[bsigney]

This section restates the rules block rather than checking the output. verbatim is now asserted
six times across the skill — L45, L67, L134, L187, plus reference L88 and L103.

That matters because the checklist isn't a summary, it's a second set of instructions, and it's
the last thing the agent reads. Say we later allow long task descriptions to be summarised with a
link back to the PRD: I edit L45 and L134, and L187 still says

[ ] Original PRD requirement and task descriptions are preserved verbatim.

The agent hits that last, treats it as binding, and copies verbatim anyway. The change silently
doesn't land. Recency means the copy I forgot is the copy that wins.

Fix — Make the items verify the artifact rather than re-assert rules, so they can't contradict the rules block:

• "Infrastructure appears only when first needed" (rule) → "No slice provisions infrastructure it
  doesn't exercise in its own demo gate" (checkable against the output)
• "Every later slice is traceable, demo-ready…" (rule) → "Every slice's demo gate names observable
  behaviour and how to exercise it, not that a component exists"
• drop the ones that are pure restatement (L180, L187)

And the check I'd most want is missing: every in-scope PRD requirement appears in exactly one
slice, or in Deferred/Excluded with a reason. A requirement quietly disappearing between PRD and
roadmap is the worst failure here, and no rule or gate currently catches it.

[bsigney]

minor tweak: two H1s - this section can be copied over as part of real PRD. Comment it out like in L107-108