tech-spec

Transform approved PRDs into sprint-based technical specifications and runtime bundles.

2|Updated Apr 25, 2026
One-click install
npx skills add https://github.com/iurykrieger/claude-yoke --skill tech-spec-iurykrieger
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tech-spec
Source: https://github.com/iurykrieger/claude-yoke/tree/main/skills/tech-spec
Command: npx skills add https://github.com/iurykrieger/claude-yoke --skill tech-spec-iurykrieger

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Phase 2 — Technical specification planning becomes automated: turning approved PRDs into structured sprint specs, DoDs, and per-sprint runtime bundles. The skill orchestrates a three-stage blueprint (LLM drafts the sprint index, bash scaffolds empty per-sprint files, LLM fills each sprint) and stores artifacts under .yoke/specs/ and .yoke/sprints/. It pauses at Trigger 2 until approval, ensuring a controlled, auditable transition to Phase 3.

Core Features & Use Cases

  • Drafts a sprint index from PRD to guide sprint planning and task allocation.
  • Scaffolds empty per-sprint files deterministically via Bash, seeded with frontmatter skeletons.
  • Fills sprint files with objective, DoD, tasks, functional criteria, and sensors using LLM prompts, one sprint at a time.
  • Enforces Trigger 2 approval before transitioning to Phase 3 and marks artifacts as approved.

Quick Start

Initiate the workflow by providing an approved PRD to /yoke:tech-spec to generate the sprint index, scaffold per-sprint files, and iteratively fill them.

Frequently Asked Questions about tech-spec

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I convert an approved PRD into sprint-ready technical specifications?

To convert an approved PRD into sprint-ready technical specifications, the skill drafts a sprint index using an LLM, scaffolds empty sprint files via Bash, and fills each file with objectives, tasks, and DoDs before requiring approval.

How does generating per-sprint runtime bundles from PRDs work?

Generating per-sprint runtime bundles works through a three-stage workflow: LLM drafts the sprint index, Bash deterministically scaffolds empty per-sprint files, and the LLM fills each file with strict binary acceptance criteria.

Can I use this skill to enforce an approval workflow before starting development sprints?

Yes, you can enforce an approval workflow because the skill pauses at Trigger 2, requiring explicit approval before all sprints transition to Phase 3, ensuring a controlled and auditable development handoff.

What is the best way to structure sprint tasks with strict binary acceptance criteria?

The best way to structure sprint tasks with strict binary acceptance criteria is by having the LLM populate each sprint file with functional criteria, sensors, and tasks gated by a Trigger 2 approval.

Where are technical specification and sprint artifacts stored during this process?

Technical specification and sprint artifacts are stored as markdown files under .yoke/specs/<slug>.md and .yoke/sprints/<slug>-sNN>.md, keeping all sprint planning outputs organized in your workspace.