FIRE Flow Overview

Fast Intent-Run Engineering - Ship in hours with adaptive checkpoints

What is FIRE?

FIRE (Fast Intent-Run Engineering) is an Adaptive Spec-Driven Development flow with first-class Monorepo and Brownfield support. It kills the ceremony and right-sizes the rigor—because fixing a UI bug isn’t the same as refactoring your payment gateway.

Key Differentiators

Dynamic Execution

No pre-planned execution. Builder scans remaining work items and recommends what to run next based on dependencies and current state.

Adaptive Checkpoints

0-2 checkpoints per work item based on complexity. Autopilot for simple tasks, Validate for critical changes.

First-Class Brownfield

Auto-detects existing patterns, respects conventions, and extends rather than rewrites your codebase.

Monorepo Support

Hierarchical standards with module-specific overrides. One project, multiple tech stacks.

Walkthrough Generation

Every change documented automatically. Review what AI did without digging through code.

Change-Friendly

Requirements changed? Just update your specs. No execution plans to re-create—next run adapts automatically.

FIRE vs AI-DLC (specs.md)

FIRE and specs.md’s AI-DLC flow share intent-driven philosophy but are distinct flows. FIRE prioritizes adaptive execution; our AI-DLC implementation prioritizes comprehensive traceability.

Aspect	FIRE	specs.md AI-DLC
Philosophy	Intent-driven, AI proposes, human validates	Same
Hierarchy	Intent → Work Item → Run	Intent → Unit → Story → Bolt → Stages
Execution Planning	Dynamic—Builder recommends next run	Pre-planned—Bolts created before execution
Requirement Changes	Just update specs, next run adapts	May require re-planning bolts
Checkpoints	Adaptive (based on complexity + config)	Comprehensive (fixed per bolt type)
Agents	3 (Orchestrator, Planner, Builder)	4 (Master, Inception, Construction, Operations)
Artifacts	Adaptive (design docs when needed)	Comprehensive (per bolt type)
Phases	Plan → Execute (continuous)	Inception → Construction → Operations (sequential)
Design Approach	Adaptive based on complexity	DDD or Simple bolt types
Optimized For	Teams who hate friction	Teams needing full traceability

Dynamic vs Pre-Planned Execution

This is a fundamental difference in how the two flows handle execution:

FIRE (Dynamic): When you invoke the Builder agent, it scans all remaining intents and work items, analyzes their dependencies, and recommends which work items can run together next. You approve or adjust, then it executes. No execution plans are created ahead of time.

AI-DLC (Pre-Planned): During the Inception phase, you create “bolts”—pre-defined execution plans that bundle stories together with specific stages. Bolts are planned before construction begins.

When to Use FIRE

You hate unnecessary friction

FIRE is built for collectives—tight-knit teams and solo devs who want to ship without bureaucracy getting in the way.

You're working in a brownfield codebase

FIRE analyzes your existing structure. It respects the patterns you already have and extends rather than rewrites.

You have a monorepo

Hierarchical standards support different tech stacks per module while sharing common policies.

You want adaptive rigor

Simple tasks burn through fast. Complex changes get the attention they deserve. FIRE right-sizes the ceremony.

Your project doesn't always need DDD

If your project doesn’t need complex domain modeling, FIRE won’t force it. Design docs appear when complexity warrants them.

When to Consider specs.md AI-DLC Instead

Core Concepts

Intent

A high-level objective that delivers user value. Captured through guided conversation, not lengthy specs.

intent:
  id: auth-system
  title: User Authentication System
  status: in_progress
  priority: high

Work Item

A discrete, executable unit of work derived from an Intent. Each work item completes in a single Run.

work_item:
  id: create-user-schema
  title: Create user database schema
  complexity: low
  mode: autopilot  # 0 checkpoints

Work Complexity: Is this a simple tweak or a systemic change?
Your Autonomy Config: How much oversight do you want?

These combine to dynamically choose when to ask and when to burn through:

Mode	Checkpoints	Use For
Autopilot	0	Bug fixes, minor updates, well-defined changes
Confirm	1 (plan)	Standard features, moderate complexity
Validate	2 (design + plan)	Security, payments, core architecture

You configure your autonomy preference during project initialization:

Execution Modes

Learn how Autopilot, Confirm, and Validate modes work with detailed flow diagrams

Project Structure

project/
├── .specsmd/
│   └── fire/                    # FIRE flow definition
│       └── agents/              # Agent definitions
│
└── .specs-fire/                 # Project artifacts
    ├── state.yaml               # Central state tracking
    ├── standards/               # Project standards
    │   ├── constitution.md      # Universal policies (always inherited)
    │   ├── tech-stack.md        # Technology choices
    │   ├── coding-standards.md  # Code conventions
    │   └── folder-structure.md  # Directory layout
    ├── intents/                 # Intent documentation
    │   └── {intent-id}/
    │       ├── brief.md
    │       └── work-items/
    ├── runs/                    # Run logs
    └── walkthroughs/            # Generated documentation

Get Started

Install specs.md

npx specsmd@latest install

Select FIRE during init

Choose “FIRE” when prompted for flow selection

Capture your first intent

/specsmd-fire-planner

Describe what you want to build

Execute work items

/specsmd-fire-builder

AI executes with appropriate checkpoints

Quick Start Guide

Step-by-step guide to shipping your first feature with FIRE