specify

name	specify
description	Create or update the feature specification from a natural language feature description.
argument-hint	<feature description>

Templates: If you need the template files referenced below (spec-template.md, plan-template.md, etc.), they are available in the BB-Skills repository at templates/. If installed locally, check ~/.bb-skills/templates/ or the project's templates/ directory.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Outline

The text the user typed when invoking this skill is the feature description. Assume you always have it available in this conversation. Do not ask the user to repeat it unless they provided an empty command.

Given that feature description, do this:

1. Generate a concise short name (2-4 words) for the branch:

   • Analyze the feature description and extract the most meaningful keywords
   • Create a 2-4 word short name that captures the essence of the feature
   • Use action-noun format when possible (e.g., "add-user-auth", "fix-payment-bug")
   • Preserve technical terms and acronyms (OAuth2, API, JWT, etc.)
   • Keep it concise but descriptive enough to understand the feature at a glance
   • Examples:
     • "I want to add user authentication" -> "user-auth"
     • "Implement OAuth2 integration for the API" -> "oauth2-api-integration"
     • "Create a dashboard for analytics" -> "analytics-dashboard"
     • "Fix payment processing timeout bug" -> "fix-payment-timeout"

2. Check for existing branches before creating new one:

   a. First, fetch all remote branches to ensure we have the latest information:

   git fetch --all --prune
   

   b. Find the highest feature number across all sources for the short-name:

   • Remote branches: git ls-remote --heads origin | grep -E 'refs/heads/[0-9]+-<short-name>$'
   • Local branches: git branch | grep -E '^[* ]*[0-9]+-<short-name>$'
   • Specs directories: Check for directories matching specs/[0-9]+-<short-name>

   c. Determine the next available number:

   • Extract all numbers from all three sources
   • Find the highest number N
   • Use N+1 for the new branch number

   d. Create the feature branch and spec directory structure:

   • Create and checkout a new branch named N+1-<short-name>
   • Create the specs directory: specs/N+1-<short-name>/
   • Initialize the spec file at specs/N+1-<short-name>/spec.md

   IMPORTANT:

   • Check all three sources (remote branches, local branches, specs directories) to find the highest number
   • Only match branches/directories with the exact short-name pattern
   • If no existing branches/directories found with this short-name, start with number 1
   • You must only create one branch per feature

3. Collect BuildBetter context (best-effort):

   • Derive FEATURE_DIR from the spec file path.
   • If BuildBetter context collection is available, run it to gather customer evidence using the feature description.
   • The collector writes:
     • FEATURE_DIR/buildbetter-context.json
     • FEATURE_DIR/buildbetter-context.md
     • FEATURE_DIR/user-stories.md
   • Handle collector status:
     • ok: Use BuildBetter evidence directly.
     • partial: Use available evidence and preserve warnings.
     • skipped: Continue without BuildBetter data and add a note in spec assumptions.
     • error: Continue without BuildBetter data, warn explicitly, and preserve any generated artifacts.

4. Load the spec template and BuildBetter artifacts (if present) to understand required sections and evidence context.

5. Follow this execution flow:

   1. Parse user description from Input If empty: ERROR "No feature description provided"
   2. Extract key concepts from description and BuildBetter evidence Identify: actors, actions, data, constraints
      • Pull exact customer quotes from buildbetter-context.md when available
      • Pull existing stories from user-stories.md when available
      • Track each requirement/story to one or more evidence IDs (BB-EXTRACTION-*) when available
   3. For unclear aspects:
      • Make informed guesses based on context and industry standards
      • Only mark with [NEEDS CLARIFICATION: specific question] if:
        • The choice significantly impacts feature scope or user experience
        • Multiple reasonable interpretations exist with different implications
        • No reasonable default exists
      • LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total
      • Prioritize clarifications by impact: scope > security/privacy > user experience > technical details
   4. Fill User Scenarios & Testing section If no clear user flow: ERROR "Cannot determine user scenarios"
      • Prioritize evidence-backed user journeys first
   5. Generate Functional Requirements Each requirement must be testable Use reasonable defaults for unspecified details (document assumptions in Assumptions section)
   6. Define Success Criteria Create measurable, technology-agnostic outcomes Include both quantitative metrics (time, performance, volume) and qualitative measures (user satisfaction, task completion) Each criterion must be verifiable without implementation details
   7. Identify Key Entities (if data involved)
   8. Add evidence traceability annotations:
      • Each major user story includes Evidence References
      • Requirements include evidence IDs where relevant
      • If BuildBetter unavailable, explicitly mark assumptions as non-evidence-backed
   9. Return: SUCCESS (spec ready for planning)

6. Write the specification to the spec file using the template structure, replacing placeholders with concrete details derived from the feature description and BuildBetter context while preserving section order and headings.

7. Specification Quality Validation: After writing the initial spec, validate it against quality criteria:

   a. Create Spec Quality Checklist: Generate a checklist file at FEATURE_DIR/checklists/requirements.md using the checklist template structure with these validation items:

   # Specification Quality Checklist: [FEATURE NAME]
   
   **Purpose**: Validate specification completeness and quality before proceeding to planning
   **Created**: [DATE]
   **Feature**: [Link to spec.md]
   
   ## Content Quality
   
   - [ ] No implementation details (languages, frameworks, APIs)
   - [ ] Focused on user value and business needs
   - [ ] Written for non-technical stakeholders
   - [ ] All mandatory sections completed
   
   ## Requirement Completeness
   
   - [ ] No [NEEDS CLARIFICATION] markers remain
   - [ ] Requirements are testable and unambiguous
   - [ ] Success criteria are measurable
   - [ ] Success criteria are technology-agnostic (no implementation details)
   - [ ] All acceptance scenarios are defined
   - [ ] Edge cases are identified
   - [ ] Scope is clearly bounded
   - [ ] Dependencies and assumptions identified
   
   ## Feature Readiness
   
   - [ ] All functional requirements have clear acceptance criteria
   - [ ] User scenarios cover primary flows
   - [ ] Feature meets measurable outcomes defined in Success Criteria
   - [ ] No implementation details leak into specification
   
   ## Notes
   
   - Items marked incomplete require spec updates before using the bb-clarify or bb-plan skills
   

   b. Run Validation Check: Review the spec against each checklist item:

   • For each item, determine if it passes or fails
   • Document specific issues found (quote relevant spec sections)

   c. Handle Validation Results:

8. Report completion with branch name, spec file path, BuildBetter artifact paths, checklist results, and readiness for the next phase (use the bb-clarify or bb-plan skills).

General Guidelines

Quick Guidelines

• Focus on WHAT users need and WHY.
• Avoid HOW to implement (no tech stack, APIs, code structure).
• Written for business stakeholders, not developers.
• DO NOT create any checklists that are embedded in the spec. That will be a separate command.

Section Requirements

• Mandatory sections: Must be completed for every feature
• Optional sections: Include only when relevant to the feature
• When a section doesn't apply, remove it entirely (don't leave as "N/A")

For AI Generation

When creating this spec from a user prompt:

1. Make informed guesses: Use context, industry standards, and common patterns to fill gaps
2. Document assumptions: Record reasonable defaults in the Assumptions section
3. Limit clarifications: Maximum 3 [NEEDS CLARIFICATION] markers - use only for critical decisions that:
   • Significantly impact feature scope or user experience
   • Have multiple reasonable interpretations with different implications
   • Lack any reasonable default
4. Prioritize clarifications: scope > security/privacy > user experience > technical details
5. Think like a tester: Every vague requirement should fail the "testable and unambiguous" checklist item
6. Common areas needing clarification (only if no reasonable default exists):
   • Feature scope and boundaries (include/exclude specific use cases)
   • User types and permissions (if multiple conflicting interpretations possible)
   • Security/compliance requirements (when legally/financially significant)

Examples of reasonable defaults (don't ask about these):

• Data retention: Industry-standard practices for the domain
• Performance targets: Standard web/mobile app expectations unless specified
• Error handling: User-friendly messages with appropriate fallbacks
• Authentication method: Standard session-based or OAuth2 for web apps
• Integration patterns: Use project-appropriate patterns (REST/GraphQL for web services, function calls for libraries, CLI args for tools, etc.)

Success Criteria Guidelines

Success criteria must be:

1. Measurable: Include specific metrics (time, percentage, count, rate)
2. Technology-agnostic: No mention of frameworks, languages, databases, or tools
3. User-focused: Describe outcomes from user/business perspective, not system internals
4. Verifiable: Can be tested/validated without knowing implementation details

Good examples:

• "Users can complete checkout in under 3 minutes"
• "System supports 10,000 concurrent users"
• "95% of searches return results in under 1 second"
• "Task completion rate improves by 40%"

Bad examples (implementation-focused):

• "API response time is under 200ms" (too technical, use "Users see results instantly")
• "Database can handle 1000 TPS" (implementation detail, use user-facing metric)
• "React components render efficiently" (framework-specific)
• "Redis cache hit rate above 80%" (technology-specific)