Why Context-First?

AI agents start fresh with each session and reverse engineer the codebase on-demand. Buildforce inverts this by loading accumulated context first—searching your context repository before you define requirements.

The Problem with Context-On-Demand

Traditional AI-assisted development follows this pattern:

1. Start a new session - Agent has no memory of past work
2. Explain the task - "I need to add authentication..."
3. Agent explores - Reads files, searches for patterns, asks questions
4. Implement - Build the feature based on current understanding
5. Session ends - All context evaporates

The next session? Start over. Re-explain patterns. Re-discover decisions. Re-justify architectural choices.

The Context-First Approach

Buildforce inverts this by loading context before defining requirements:

1. Run /research - Search accumulated context, explore codebase, fetch current best practices
2. Context informs spec - Requirements are written knowing what already exists
3. Spec guides plan - Implementation plan references past decisions and patterns
4. Build executes - Development follows documented patterns consistently
5. Complete saves knowledge - New context files capture decisions for future work

The next session? Start with rich context. Build on past decisions. Maintain consistency automatically.

What Context-Warming Enables

Informed Specifications

When you run /research before /spec, your requirements are informed by:

• Existing architectural patterns in the codebase
• Past decisions and their rationale
• Current best practices (via web search)
• Related features and their implementations

Result: Specs that fit naturally into your existing architecture.

Consistent Implementations

Plans generated from context-aware specs automatically reference:

• Established design patterns
• Existing utility functions and helpers
• Documented conventions and style guides
• Similar feature implementations

Result: Code that feels like it was written by the same team.

Compounding Knowledge

Every completed feature enriches your context repository:

• Architectural decisions become searchable
• Design patterns get documented with examples
• Edge cases and solutions accumulate
• Team knowledge grows organically

Result: Your project gets smarter with every feature.

Context Lives in Your Repository

Context isn't stored in a cloud service or proprietary format. It lives in version-controlled YAML files alongside your code:

.buildforce/
├── context/
│   ├── _index.yaml           # Context catalog
│   ├── authentication.yaml   # Auth module context
│   ├── error-handling.yaml   # Error patterns
│   └── api-conventions.yaml  # API design decisions
└── specs/
    └── [feature-folders]/    # Feature specs and plans

Benefits:

• Version controlled - Context evolves with your codebase
• Team shared - Everyone has access to accumulated knowledge
• Searchable - /research queries across all context files
• Portable - No vendor lock-in, pure text files

Real-World Impact

Before Buildforce

• 15-20 minutes per session explaining context
• Inconsistent implementations across features
• Architectural decisions lost to Slack/Discord
• New team members struggle with unwritten rules

After Buildforce

• 2-3 minutes to run /research and load relevant context
• Consistent patterns enforced through documented context
• Decisions captured and searchable in .buildforce/context/
• New team members onboard by reading context files

Next Steps

Ready to experience context-first development? Follow the Quick Start guide to get Buildforce running in your project.