/specify

name: specify
description: "Create specs from project briefs with acceptance criteria and testable requirements"
usage: /attune:specify [--input FILE] [--feature NAME]

Attune Specify Command

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...

3. **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 <path>` - Input brief file (default: docs/project-brief.md)
• `--output <path>` - Output spec file (default: docs/specification.md)
• `--feature <name>` - 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

**Description**: Automatically discover and categorize technical debt from GitHub issues

**Acceptance Criteria**:
- [ ] Given a repository with issues, when scanning is triggered, then all issues with `tech-debt` label are imported
- [ ] Given imported issues, when categorizing, then each is assigned a debt type (code quality, architecture, security, performance)
- [ ] Given categorized issues, when displaying, then issues are grouped by type and priority

**Priority**: High
**Dependencies**: None
**Estimated Effort**: M

### FR-002: Debt Prioritization Framework

**Description**: Calculate priority score for each debt item based on impact and eff