> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blitzy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Technical Specification

> Review Blitzy's living knowledge base of your codebase to verify understanding before generating code

export const WistiaVideo = ({mediaId}) => <div style={{
  position: 'relative',
  paddingTop: '56.25%',
  overflow: 'hidden',
  borderRadius: '8px'
}}>
    <iframe src={`https://fast.wistia.net/embed/iframe/${mediaId}?videoFoam=true`} title="Wistia video player" allowTransparency="true" frameBorder="0" scrolling="no" allowFullScreen style={{
  position: 'absolute',
  top: 0,
  left: 0,
  width: '100%',
  height: '100%'
}} />
  </div>;

<Note>
  **Jump to:** [Review Workflow](#review-workflow) | [Review Checklist](#review-checklist) | [Why This Matters](#why-this-matters)
</Note>

<WistiaVideo mediaId="aitg61b8oh" />

After ingestion, Blitzy produces a technical specification - a living knowledge base of your codebase that continuously updates as your code changes. It is the output of ingestion, not something you write. Your job is to spot-check it and confirm Blitzy's understanding is accurate.

## Review Workflow

The tech spec is a reference document, not something you read cover to cover. Use your domain knowledge to validate the areas you know best.

<Steps>
  <Step title="Go to what you know">
    Start with the parts of the codebase you understand deeply. Check whether Blitzy's interpretation of architecture, dependencies, or domain logic matches reality in those areas. Use the [Review Checklist](#review-checklist) to guide where to look.
  </Step>

  <Step title="Check domain-specific language">
    Verify that Blitzy correctly interprets acronyms, internal terminology, and DSL keywords used in your codebase. These are the most likely areas where interpretation may differ from your team's intended meaning.
  </Step>

  <Step title="Proceed to code generation">
    Once you've validated the areas relevant to your work, move on to writing your [generation prompt](/prompt-engineering/generation). Most specs are accurate enough to proceed after a targeted review.
  </Step>
</Steps>

<Note>
  If the tech spec has significant gaps or you want to personalize how Blitzy interprets your codebase, you can create a new Blitzy project on the same branch with an updated [ingestion prompt](/prompt-engineering/ingestion). This re-ingests your codebase and produces a new spec. This is rarely needed. Most teams proceed directly to code generation.
</Note>

## Review Checklist

Use these categories to guide your spot-check:

<AccordionGroup>
  <Accordion title="Architecture & Structure">
    * System architecture is correctly identified (monolith, microservices, hybrid)
    * Module relationships and boundaries are accurately mapped
    * Data flows between components are documented
    * Layering patterns (controllers, services, repositories) are recognized
    * Custom abstractions or unconventional layering are captured (these often require an ingestion prompt)
  </Accordion>

  <Accordion title="Dependencies & Integration Points">
    * Internal dependencies between modules are captured
    * External libraries, APIs, and services are identified
    * Single points of failure or tightly coupled components are flagged
    * Framework and library versions match your current state
    * Submodules or private registries are included (may require additional access configuration)
  </Accordion>

  <Accordion title="Domain & Business Logic">
    * Domain terminology is correctly interpreted (e.g., "instruments" in finance, "claims" in insurance)
    * Acronyms and DSL keywords match your team's definitions
    * Core business logic flows are understood
    * Domain-specific patterns and conventions are recognized
  </Accordion>

  <Accordion title="Constraints & Patterns">
    * Coding conventions and style patterns are identified
    * Security and compliance constraints are captured (HIPAA, PCI-DSS, GDPR often need explicit ingestion prompt context)
    * Testing patterns and coverage expectations are reflected
    * Build and deployment pipeline details are accurate
  </Accordion>
</AccordionGroup>

## Why This Matters

The tech spec gives your team an always-current, queryable understanding of your technology estate:

* **For developers** - Reduced time spent reverse-engineering legacy systems and maintaining stale documentation
* **For executives** - Unknown liabilities become managed exposures with auditable system lineage produced on demand
* **For the organization** - Modernization scoping based on verified system structure instead of guesswork

<CardGroup cols={2}>
  <Card title="Generation Prompts" icon="pen-to-square" href="/prompt-engineering/generation">
    Write a generation prompt that translates your development request into a clear build instruction for Blitzy
  </Card>

  <Card title="Prompt Library" icon="books" href="/templates">
    Browse ready-to-use prompt templates for common use cases
  </Card>

  <Card title="Golden Rules" icon="star" href="/prompt-engineering/golden-rules">
    Best practices for writing precise, unambiguous prompts
  </Card>

  <Card title="Agent Action Plan" icon="arrows-rotate" href="/project-lifecycle/aap-review">
    What happens after your prompt - reviewing the AAP that drives code generation
  </Card>
</CardGroup>