First-Class Monorepo Support
FIRE is designed from the ground up for real-world projects, including complex monorepo architectures with multiple tech stacks.
Hierarchical Standards
How It Works
Standards follow a hierarchical inheritance model:- Root standards define project-wide defaults
- Module standards override specific files when needed
- Constitution is special—always inherited, never overridden
Project Structure
Resolution Rules
1
Check Module
Does the target module have this standard file?
2
If Yes: Use Module
Use the module’s version (override)
3
If No: Inherit
Walk up to parent, use ancestor’s version
4
Exception: Constitution
Constitution is ALWAYS inherited from root, never overridden
The Constitution
The constitution contains universal policies that apply everywhere:Constitution is always inherited. If a module tries to have its own constitution.md, it’s ignored.
Why Constitution is Special
- Ensures consistent policies across all modules
- Prevents “rogue” modules with different rules
- Simplifies onboarding—one place for universal rules
- AI always knows where to find project-wide policies
Tech Stack Detection
FIRE doesn’t hardcode tech stacks—it detects them:Quick Scan (2-5 minutes)
Pattern-based detection:- Package files:
package.json,go.mod,requirements.txt,Cargo.toml - Lock files:
package-lock.json,yarn.lock,pnpm-lock.yaml - Config files:
tsconfig.json,.eslintrc,pyproject.toml - Framework markers:
next.config.js,vite.config.ts,main.go
Deep Scan (10-30 minutes)
Code analysis:- Import patterns and dependencies
- Folder structure conventions
- Test framework usage
- Build tool configuration
- Integration patterns (APIs, databases)
Generated Tech Stack
After scanning, FIRE generates atech-stack.md:
Brownfield Support
FIRE treats existing codebases as first-class citizens.Brownfield Rules
Search Before Create
Always check if similar code exists before creating new modules.
Respect Patterns
Follow existing naming, folder structures, and conventions.
Minimal Changes
Make targeted edits. Don’t rewrite files unnecessarily.
Preserve Tests
Never delete existing tests without explicit approval.
Standards Inference
For brownfield projects, FIRE infers standards from existing code:Inferred vs Prescribed
Monorepo Detection
FIRE automatically detects monorepo structures:Detection Signals
Workspace Analysis
After detection, FIRE maps the workspace:Working with Modules
Targeting a Module
When creating work items, specify the target module:- Load module-specific standards
- Respect module’s tech stack
- Follow module’s conventions
Cross-Module Work
For work spanning multiple modules:Best Practices
When to Override Standards
Override tech-stack.md
Override tech-stack.md
- Module uses different language
- Module has specific framework requirements
- Module has unique tooling needs
Override coding-standards.md
Override coding-standards.md
- Module follows different conventions (e.g., Go vs TypeScript)
- Module has special formatting rules
- Module has unique linting configuration
Never Override constitution.md
Never Override constitution.md
- Constitution is always inherited
- Project-wide policies must be consistent
- Modify root constitution for changes
Keeping Standards in Sync
- Review root standards periodically
- Update constitution when policies change
- Keep module overrides minimal
- Document why overrides exist
Module-Specific Conventions
Add context to module standards:Initialization Workflow
1
Run FIRE init
2
Monorepo Detection
FIRE detects monorepo structure and maps modules
3
Per-Module Scan
Each module analyzed for tech stack and patterns
4
Standards Generation
- Root standards created with defaults
- Module standards created with overrides
- Constitution created with universal policies
5
Review and Confirm
Review generated standards, adjust as needed