spec

Convert scoped briefs and baselines into structured specification beads with test cases.

8|1|Updated Jan 21, 2024
One-click install
npx skills add https://github.com/azigler/dotfiles --skill spec-azigler
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec
Source: https://github.com/azigler/dotfiles/tree/main/agents/skills/spec
Command: npx skills add https://github.com/azigler/dotfiles --skill spec-azigler

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill turns ambiguous requirements into a structured, testable specification so design decisions are explicit and implementation can proceed safely.

Core Features & Use Cases

  • Bead-first spec writing: Produces a high-priority bead typed spec where the full specification content is stored for lifecycle management.
  • Decision-driven structure: Captures baseline, changes, formal contracts, and test cases in a consistent format that supports downstream /check, /test, and /impl workflows.
  • Open-question rigor: Forces Open Questions (OQs) to include severity and recommendations to reduce blind spots before implementation.

Quick Start

Generate a spec for the auth subsystem by running the /spec command with the scope name, so the agent outputs a ready-to-check spec bead including test cases and open questions.

Frequently Asked Questions about spec

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

FAQPage Schema
How do I write formal software requirements with test cases for engineering handoff?

Formal software requirements with test cases are generated by turning a scoped brief and baseline into a structured spec bead, capturing overview, changes, formal contracts, and verifiable acceptance criteria for safe implementation handoffs.

What is the best way to document open questions and assumptions before implementation?

Documenting open questions and assumptions requires structuring them with severity levels and actionable recommendations, forcing blind spots to be interrogated and resolved before downstream implementation workflows begin.

How do I create a specification that supports automated test and check workflows?

A specification supporting automated test and check workflows requires an acceptance-criteria checklist embedded within a typed spec bead, enabling downstream /check, /test, and /impl commands to verify formal contracts.

Can I use a structured spec for design and engineering handoffs with explicit decisions?

Structured specs are designed for design and engineering handoffs where implementation depends on explicit decisions, capturing baseline context and formal requirements to ensure verifiable acceptance criteria are met.

What should a production-ready specification include to prevent implementation blind spots?

A production-ready specification must include an overview, baseline, changes, formal requirements, test cases, and open questions with severity ratings to reduce implementation blind spots and capture interrogated assumptions.

Does spec writing work without existing baseline documentation?

Spec writing requires a scoped brief and baseline as input to produce a formal specification, meaning existing baseline documentation or context is necessary to generate the structured spec bead with accurate formal requirements.