spec

Define service specs with acceptance criteria and decision records before coding.

7|Updated Jan 26, 2026
One-click install
npx skills add https://github.com/bricerising/enterprise-software-playbook --skill spec-bricerising
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec
Source: https://github.com/bricerising/enterprise-software-playbook/tree/main/skills/spec
Command: npx skills add https://github.com/bricerising/enterprise-software-playbook --skill spec-bricerising

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Codifies contracts, decisions, ADRs, and acceptance criteria to prevent drift between planning and implementation, providing a single source of truth for multi-team collaboration.

Core Features & Use Cases

  • Spec-first artifacts cover services, API contracts (OpenAPI/protobuf/WebSocket), ADRs, task lists, and quickstarts.
  • Used before major behavior changes or cross-team work to align expectations and reduce rework.
  • Serves as the authoritative contracts surface for downstream specs, plans, and tests.

Quick Start

Draft a service spec bundle in apps/<service>/spec/ to define objectives, acceptance criteria, and decision records before coding.

Frequently Asked Questions about spec

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

FAQPage Schema
How do I prevent drift between planning and implementation using API contracts?

API contracts prevent drift by codifying spec-first artifacts like OpenAPI and protobuf definitions to serve as a single source of truth for multi-team collaboration. Defining acceptance criteria and decision records before coding ensures expectations align across teams.

What is spec-first development and when do I need decision records?

Spec-first development defines contracts, decisions, and acceptance criteria before implementation to prevent drift. You need decision records when planning major behavior changes or cross-team work to align expectations and reduce rework.

How do I structure a service spec bundle before coding?

Structure a service spec bundle in apps/<service>/spec/ to define objectives, acceptance criteria, and decision records before coding. This creates an authoritative contracts surface for downstream specs, plans, and tests.

Can I use this to define contracts for OpenAPI, protobuf, and WebSocket?

Yes, spec-first artifacts cover API contracts across OpenAPI, protobuf, and WebSocket formats. These versioned contracts serve as the authoritative surface for downstream specs, plans, and tests.

Does spec-first contract definition work for cross-team collaboration?

Spec-first contract definition works for cross-team collaboration by providing a single source of truth. Decision records, versioned contracts, and traceable requirements enforce structure and align expectations before implementation begins.

What's the best way to manage architecture decision records and acceptance criteria together?

The best way to manage ADRs and acceptance criteria together is codifying them as spec-first artifacts that serve as an authoritative contracts surface. This prevents drift between planning and implementation by maintaining traceable requirements and versioned contracts.