spec-authoring

Guides authoring of spec.md files for spec-driven development work units.

Updated Jan 28, 2024
One-click install
npx skills add https://github.com/Thiago-Cruz-eng/KrockSide --skill spec-authoring-thiago-cruz-eng
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-authoring
Source: https://github.com/Thiago-Cruz-eng/KrockSide/tree/main/.agents/skills/spec-authoring
Command: npx skills add https://github.com/Thiago-Cruz-eng/KrockSide --skill spec-authoring-thiago-cruz-eng

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing a spec.md that is consistent, scoped correctly, and free of contradictions with authoritative domain documentation is hard; this Skill standardizes the structure, sections, and divergence-handling rules for every work unit. ## Core Features & Use Cases - Standardized spec structure: Defines the required sections (Overview, Domain, Scope, Domain boundary, User stories, Acceptance criteria, Dependencies, Risks) and the .agents/specs/<NNN>-<slug>/ folder convention. - Divergence handling: Establishes a three-case protocol for conflicts between authoritative documentation, code, and requirements, escalating unresolved contradictions as gaps instead of deciding silently. - Scope defense: Separates product-language Scope from technical-artifact Domain boundary, and defines rules for cross-cutting specs spanning multiple domains. - Use Case: When starting a new feature unit, ask the AI to generate a spec.md that derives acceptance criteria from the domain skill documentation, keeps the boundary limited to the delta, and records open questions as gaps. ## Quick Start Ask the AI to write the spec.md for a new work unit following the spec-authoring standard, deriving acceptance criteria from the linked domain documentation.

Frequently Asked Questions about spec-authoring

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

FAQPage Schema
How do I write a spec.md for spec-driven development?

Create a folder `.agents/specs/<NNN>-<slug>/` and write a spec.md with Overview, Domain, Scope, Domain boundary, User stories, Acceptance criteria, Cross-domain dependencies, and Risks sections. Derive acceptance criteria from the authoritative domain documentation rather than transcribing it.

What is the difference between Scope and Domain boundary in a spec?

Scope lists product capabilities in user language (what the application does and does not do). Domain boundary lists technical artifacts such as entities, endpoints, events, and modules that the unit implements versus those belonging to other domains.

What should I do when the spec contradicts the authoritative documentation?

If there is a recorded decision backing the change, describe the target behavior and record the drift in plan.md. If no decision exists, escalate the contradiction as an open gap for a human to resolve instead of choosing a side silently.

When is a spec considered cross-cutting instead of belonging to one domain?

A spec is cross-cutting when the change does not belong to a single domain, such as an ORM migration or a theme swap. It uses a Domains involved section instead of Domain, and its boundary may span modules of several domains.

Should a spec rewrite behavior that already exists in the code?

No. The spec describes the target state and restricts what it implements to the delta over existing code. Behavior that already meets the goal is acknowledged, and fully satisfied targets are escalated as open questions rather than invented scope.