Lint, diff, and analyse product requirements from the command line
Product requirements are often trapped in documents, making them difficult to review, validate, and track over time.
RAC brings software engineering workflows to product requirements.
Write requirements in Markdown. Store them in Git. Validate them, compare versions, and analyse change over time.
Markdown
↓
Product Model
↓
Validation
↓
Diffing
↓
Portfolio Analysis
↓
AI Review (future)
Engineers have mature tooling for code:
- Linters
- Code review
- Diffs
- Static analysis
- Version control
Product requirements typically have none of these.
RAC applies the same principles to product requirements.
rac validate bond_dashboard.mdrac diff bond_dashboard_v1.md bond_dashboard_v2.mdrac stats ./featuresCreate a requirement file:
# Bond Dashboard
## Problem
Retail investors struggle to understand interest-rate exposure.
## Requirements
- [REQ-001] User can view portfolio holdings
- [REQ-002] User can view portfolio duration
- [REQ-003] User can view portfolio yield
## Success Metrics
- Monthly Active Users
- Dashboard Views
## Risks
- Inaccurate market dataValidate it:
rac validate bond_dashboard.mdOutput:
PASS
Now compare two versions:
rac diff bond_dashboard_v1.md bond_dashboard_v2.mdOutput:
Added Requirements
+ REQ-004 View projected yield forecast
Modified Requirements
~ REQ-002
Before:
User can view portfolio duration
After:
User can view and compare portfolio duration
RAC compares product changes, not just text changes.
pip install requirements-as-codeuv tool install requirements-as-codeVerify installation:
rac --helpCreate a file:
touch feature.mdAdd requirements:
# Trade Alerts
## Problem
Investors miss important market movements.
## Requirements
- [REQ-001] User can create a trade alert
- [REQ-002] User can edit a trade alert
- [REQ-003] User can delete a trade alertValidate:
rac validate feature.mdCompare versions:
rac diff old.md new.mdRAC follows a few simple principles.
Requirements should remain easy to write and review.
RAC uses Markdown as the source format.
No proprietary editors.
No custom file formats.
Requirements should work naturally inside:
- GitHub
- GitLab
- VS Code
- Cursor
- Claude Code
RAC should be useful without AI.
The foundation is:
- structure
- validation
- diffing
- analysis
AI is an enhancement, not a dependency.
Internally, RAC converts Markdown into a structured Product Model.
Markdown
↓
Parser
↓
Feature Model
↓
Validation
↓
Diffing
↓
Stats
This enables reliable analysis without relying on fragile text processing.
Every feature is represented by a single Markdown file.
Example:
# Feature Title
## Problem
Problem statement.
## Requirements
- [REQ-001] Requirement text
- [REQ-002] Requirement text
## Success Metrics
- Metric 1
## Risks
- Risk 1Required:
# Title## Problem## Requirements
Optional (recommended):
## Success Metrics## Risks
Validate a requirement file.
rac validate feature.mdChecks:
- Required sections exist
- Requirement IDs are valid
- Requirement IDs are unique
- Requirement text is not empty
Warnings:
- Missing risks
- Missing success metrics
- Duplicate requirement text
- Ambiguous wording
Compare two versions of a feature.
rac diff old.md new.mdDetects:
- Added requirements
- Removed requirements
- Modified requirements
- Added metrics
- Removed metrics
- Added risks
- Removed risks
Requirements are matched by ID.
Portfolio-level analysis. Recursively scans a directory for *.md files
(skipping dotted folders like .git), parses and validates each one, and
aggregates the totals. Files that fail validation are still counted and are
listed separately rather than skipped silently.
rac stats ./featuresExample output:
Portfolio Overview
==================
Features: 12
Requirements: 87
Metrics: 24
Risks: 18
Quality
=======
Features Missing Metrics: 2
- Trade Alerts
- Watchlists
Features Missing Risks: 3
- Trade Alerts
- Watchlists
- Onboarding
Average Requirements Per Feature: 7.3
Largest Feature: Bond Dashboard (16 requirements)
Requirements by Feature
=======================
Bond Dashboard 16
Trade Alerts 11
Watchlists 8
Onboarding 3
Invalid Features (1)
./features/draft.md — missing-title, missing-requirements
Counts span all parsed files; a feature with only warnings (e.g. no metrics) still counts as valid. Invalid files are listed at the end so they are never silently skipped.
Add --json for machine-readable output. stats exits 0 when the directory
has at least one valid feature, 1 if none are valid, and 2 if the path is
not a directory. (A --strict flag for failing on any invalid file — handy in
CI — is planned.)
AI-assisted product review.
rac review feature.mdPotential checks:
- Missing requirements
- Missing risks
- Ambiguity
- Product concerns
- Engineering concerns
RAC will use the user's configured AI provider rather than requiring hosted infrastructure.
- Markdown parser
- Product Model (AST)
- Validation
- Diffing
- CLI
- Portfolio statistics
- Quality metrics
- Repository-wide analysis
- AI review
- Provider abstraction
- Git-aware workflows
- Product intelligence
- Daily product briefs
- VS Code integration
Contributions, ideas, and feedback are welcome.
The project is intentionally focused on one goal:
Treat product requirements like code.
MIT