Specify

Transform project briefs into structured, testable specifications with functional requirements and acceptance criteria.

When To Use

Use this command when you need to:

• Transform brainstorm output into detailed specification
• Create testable requirements from project brief
• Define acceptance criteria for implementation
• Document functional and non-functional requirements
• Establish scope boundaries before planning

When NOT To Use

Avoid this command if:

• Still exploring problem space (use /attune:brainstorm first)
• Already have detailed specification (use /attune:blueprint instead)
• Need to refine existing spec (edit specification document directly)
• Making architectural decisions without requirements (brainstorm first)

Usage

# Create specification from brainstorm output
/attune:specify

# Specify with custom input
/attune:specify --input docs/project-brief.md

# Generate specification for specific feature
/attune:specify --feature "user authentication"

What This Command Does

1. Loads project brief from brainstorm phase
2. Invokes specification skill with spec-kit integration
3. Generates detailed requirements using structured format
4. Creates testable acceptance criteria
5. Produces specification document for planning phase

Integration with Spec-Kit

When spec-kit plugin is available:

• Uses Skill(spec-kit:spec-writing) for specification methodology
• Applies structured requirement templates
• Ensures testable acceptance criteria

Without spec-kit:

• Falls back to attune's native specification skill
• Provides similar step-by-step approach
• Documents requirements systematically

Workflow

# 1. Invoke specification skill
Skill(attune:project-specification)

# 2. Transform brief into structured spec:
#    - Functional requirements
#    - Non-functional requirements
#    - Acceptance criteria
#    - Technical constraints
#    - Dependencies

# 3. Generate specification document
#    - Saved to docs/specification.md
#    - Includes all requirements with testability

# 4. Workflow auto-continues (see below)

Workflow Continuation Protocol (MANDATORY)

After specification completes successfully, auto-proceed to the next phase unless --standalone was specified:

1. Verify artifact: Confirm docs/specification.md exists and is non-empty
2. Checkpoint message: Display brief summary to user:

   Specification complete. Saved to docs/specification.md.
   Proceeding to planning phase...

1. Auto-invoke next phase:

   Skill(attune:project-planning)

Bypass Conditions (skip auto-continuation if ANY true):

• --standalone flag was provided
• docs/specification.md does not exist or is empty
• User explicitly requests to stop after specification

Specification Structure

Section 1: Overview

• Purpose: What this project achieves
• Scope: What's included and excluded
• Stakeholders: Who cares about this project

Section 2: Functional Requirements

Format per requirement:

### FR-001: [Requirement Name]

**Description**: Clear description of the requirement

**Acceptance Criteria**:
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]

**Priority**: High | Medium | Low
**Dependencies**: FR-002, FR-005
**Estimated Effort**: S | M | L | XL

Section 3: Non-Functional Requirements

Categories:

• Performance: Response times, throughput, resource usage
• Security: Authentication, authorization, data protection
• Reliability: Uptime, error handling, recovery
• Usability: UX requirements, accessibility
• Maintainability: Code quality, documentation, testing

Section 4: Technical Constraints

• Technology stack: Languages, frameworks, tools
• Integration points: External systems, APIs
• Data requirements: Storage, schema, migrations
• Deployment: Environment, CI/CD, hosting

Section 5: Out of Scope

Explicitly document what's NOT included to prevent scope creep.

Arguments

• --input - Input brief file (default: docs/project-brief.md)
• --output - Output spec file (default: docs/specification.md)
• --feature - Specify single feature instead of full project
• --clarify - Run clarification phase (like spec-kit clarify)
• --standalone - Run only this phase; do not auto-proceed to planning

Examples

Example 1: Full Project Specification

/attune:brainstorm --domain "web application"
/attune:specify

Output: docs/specification.md

# Technical Debt Tracker - Specification

## Overview

**Purpose**: Provide systematic technical debt tracking integrated with GitHub

**Scope**:
- IN: GitHub issue integration, debt prioritization, reporting
- OUT: Multi-platform support, custom integrations, AI recommendations

**Stakeholders**:
- Development teams (primary users)
- Tech leads (debt review and prioritization)
- Engineering managers (reporting and metrics)

## Functional Requirements

### FR-001: GitHub Issue Discovery
…