Originally published on LinkedIn on November 9, 2025.
Hari Krishnan’s article examines OpenSpec as a Spec-Driven Development (SDD) tool, highlighting its distinctive approach of maintaining a single “source of truth” specification.
Key Concepts
OpenSpec’s Workflow Structure
The tool manages three types of specifications:
- Change Specifications (Delta Specs) marking sections as “ADDED,” “MODIFIED,” or “REMOVED”
- A living “Source of Truth” spec representing current system state
- Archived Specifications preserving historical delta specs
Problems Solved
I identify critical limitations with competing tools like Spec-Kit and Kiro:
- Fragmented Understanding - “Feature-level specs are often fragmented across subfolders” making systemic comprehension difficult
- Spec Evolution Confusion - Unclear mechanisms for how specifications evolve over time
- Unintended Interactions - “Every new feature added risks unintentionally affecting existing behaviour, since there is no unified view”
Alignment Levels
The article references Birgitta Boeckeler’s framework of three alignment categories:
- Spec-First - Specs guide initial exploration but diverge from implementation
- Spec-Anchored - Continuous validation against unified specifications remains possible
- Spec-As-Source - Not discussed in detail
OpenSpec enables Spec-Anchored validation through its single source-of-truth model.
Observed Advantages
- Faster iteration cycles maintaining developer focus
- Natural brownfield project support
- Reduced context switching during development