gps-denied-onboard/.cursor/commands/gen_feature_spec.md

Generate Feature Specification

Create a focused behavioral specification that describes what the system should do, not how it should be built.

Input parameter

building_block.md Example: 03_building_blocks/01-dashboard-export-example.md

Objective

Generate lean specifications with:

• Clear problem statement and desired outcomes
• Behavioral acceptance criteria in Gherkin format
• Essential non-functional requirements
• No implementation prescriptiveness

Process

1. Read the building_block.md
2. Analyze the codebase to understand context
3. Generate a behavioral specification using the structure below
4. DO NOT include implementation details, file structures, or technical architecture
5. Focus on behavior, user experience, and acceptance criteria
6. Save the specification into the 03_feature_specs/spec.md Example: 03_feature_specs/01-dashboard-export-example.md

Specification Structure

Header

# [Feature Name]

**Status**: Draft | **Date**: [YYYY-MM-DD] | **Feature**: [Brief Feature Description]

Problem

Clear, concise statement of the problem users are facing.

Outcome

Measurable or observable goals/benefits (use bullet points).

Scope

Included

What's in scope for this feature (bullet points).

Excluded

Explicitly what's NOT in scope (bullet points).

Acceptance Criteria

Each acceptance criterion should be:

• Numbered sequentially (AC-1, AC-2, etc.)
• Include a brief title
• Written in Gherkin format (Given/When/Then)

Example: AC-1: Export Availability Given the user is viewing the dashboard When the dashboard loads Then an "Export to Excel" button should be visible in the filter/actions area

Non-Functional Requirements

Only include essential non-functional requirements:

• Performance (if relevant)
• Compatibility (if relevant)
• Reliability (if relevant)

Use sub-sections with bullet points.

Unit tests based on Acceptance Criteria

• Acceptance criteria references
• What should be tested
• Required outcome

Integration tests based on Acceptance Criteria and/or Non-Functional requirements

• Acceptance criteria references
• Initial data and conditions
• What should be tested
• How system should behave
• List of Non-functional requiremnts to be met

Constraints

High-level constraints that guide implementation:

• Architectural patterns (if critical)
• Technical limitations
• Integration requirements
• No breaking changes (if applicable)

Risks & Mitigation

List key risks with mitigation strategies (if applicable).

Each risk should have:

• Risk: Description
• Mitigation: Approach

Output Guidelines

DO:

• Focus on behavior and user experience
• Use clear, simple language
• Keep acceptance criteria testable
• Include realistic scope boundaries
• Write from the user's perspective

DON'T:

• Include implementation details (file paths, classes, methods)
• Prescribe technical solutions or libraries
• Add architectural diagrams or code examples
• Specify exact API endpoints or data structures
• Include step-by-step implementation instructions
• Add "how to build" guidance

Example

# Dashboard Export to Excel

**Status**: Draft | **Date**: 2025-01-XX | **Feature**: Export Dashboard Data to Excel

## Problem

Users currently have no efficient way to export dashboard data for offline analysis, reporting, or sharing. Manual copy-paste is time-consuming, error-prone, and lacks context about active filters.

## Outcome
- Eliminate manual copy-paste workflows
- Enable accurate data sharing with proper context
- Measurable time savings (target: <30s vs. several minutes)
- Improved data consistency for offline analysis

## Scope
### Included
- Export filtered dashboard data to Excel
- Single-click export from dashboard view
- Respect all active filters (status, date range)
### Excluded
- CSV or PDF export options
- Scheduled or automated exports
- Email export functionality

## Acceptance Criteria
**AC-1: Export Button Visibility**
Given the user is viewing the dashboard
When the dashboard loads
Then an "Export to Excel" button should be visible in the actions area

**AC-2: Basic Export Functionality**
Given the user is viewing the dashboard with data
When the user clicks the "Export to Excel" button
Then an Excel file should download to their default location
And the filename should include a timestamp

## Non-Functional Requirements

**Performance**
- Export completes in <2 seconds for up to 1000 records
- Support up to 10,000 records per export

**Compatibility**
- Excel files openable in Microsoft Excel, Google Sheets, and LibreOffice
- Standard Excel format (.xlsx)

## Constraints
- Must respect all currently active filters
- Must follow existing hexagonal architecture patterns
- No breaking changes to existing functionality

## Risks & Mitigation
**Risk 1: Excel File Compatibility**
- *Risk*: Generated files don't open correctly in all spreadsheet applications
- *Mitigation*: Use standard Excel format, test with multiple applications

Implementation Notes

• Use descriptive but concise titles
• Keep specifications focused and scoped appropriately
• Remember: This is a behavioral spec, not an implementation plan

CRITICAL: Generate the spec file ONLY. Do NOT modify code, create files, or make any implementation changes at this stage.