> ## 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.

# Add Feature

> Build new functionality and expand your app's capabilities

Feature requests pile up when the team is already stretched thin. With Blitzy, you describe the feature you need and it generates implementation code that fits your existing architecture, follows your conventions, and includes tests. Teams use Blitzy to ship features they would not have had bandwidth to build otherwise.

<Card title="Ready to add a feature?" icon="rocket" href="/templates/feature-product-development/new-feature">
  Use the **New Feature Template** to get started with a structured prompt
</Card>

<Note>
  **Jump to:** [When to Use](#when-to-use-this-approach) | [Prompt Structure](#prompt-structure) | [Key Considerations](#key-considerations) | [Common Patterns](#common-patterns) | [Troubleshooting](#troubleshooting)
</Note>

## When to Use This Approach

<Tabs>
  <Tab title="User-Facing Functionality">
    Add new pages, components, or workflows that expand what your users can do inside the product.
  </Tab>

  <Tab title="API and Service Integrations">
    Connect to third-party services or internal APIs with proper error handling, auth, and retry logic.
  </Tab>

  <Tab title="Business Logic and Workflows">
    Implement new rules, calculations, or multi-step processes that drive core product value.
  </Tab>

  <Tab title="New Modules and Components">
    Build self-contained modules within an existing system without disrupting what already works.
  </Tab>
</Tabs>

## Prompt Structure

Follow the [Golden Rules](/prompt-engineering/golden-rules) when writing your feature prompt. Focus especially on:

* **Objective Clarity** - Use clear headers for OBJECTIVE, IN SCOPE, OUT OF SCOPE, CONSTRAINTS
* **Scope Boundaries** - Label lists as "exhaustive" or "examples" to prevent scope ambiguity
* **File Organization** - Make explicit decisions about where to create new files (never give choices)
* **Architectural Patterns** - Point to code examples showing patterns to follow

## Key Considerations

<CardGroup cols={2}>
  <Card title="Scope Boundaries Matter Most" icon="crosshairs">
    Clearly define what files/components change and what remains untouched. Use absolute language ("DO NOT modify authentication") rather than suggestions.
  </Card>

  <Card title="Reference Existing Patterns" icon="code">
    Point to similar code in your codebase that demonstrates the architectural style, error handling, or integration patterns you want followed.
  </Card>

  <Card title="Integration Points Need Specificity" icon="plug">
    Identify exact files, classes, or functions where the new feature connects to existing code. Vague integration guidance leads to misaligned implementations.
  </Card>

  <Card title="Test Coverage Expectations" icon="flask">
    Specify test types (unit, integration, e2e), coverage thresholds, and critical scenarios upfront to ensure generated code includes comprehensive tests.
  </Card>
</CardGroup>

## Common Patterns

**User-facing feature with backend** - Define both frontend (UI components, state management) and backend (API endpoints, database models, business logic) in separate IN SCOPE sections. Specify integration contract (API shape, response formats).

**Third-party API integration** - Include API documentation links, authentication approach, error handling requirements, and rate limiting considerations. Specify where integration logic lives (dedicated service class vs. inline).

**Extending existing module** - Reference the module structure to extend, specify new files vs. modifications to existing files, and indicate if new database migrations or configuration changes are needed.

## Troubleshooting

<AccordionGroup>
  <Accordion title="Generated code doesn't match codebase style">
    Add the [Enforce Code Style Patterns](/templates/rules/enforce-code-style-patterns) rule to your project on the platform to extract and enforce patterns from your codebase.
  </Accordion>

  <Accordion title="Feature touches too many files">
    Scope may be too broad. Break into smaller features or add more specific CONSTRAINTS about what should NOT change.
  </Accordion>

  <Accordion title="Integration points don't connect properly">
    Add more specificity about file paths, function signatures, and data contracts at integration boundaries.
  </Accordion>

  <Accordion title="Tests are missing or inadequate">
    Add the [Require Test Coverage](/templates/rules/require-test-coverage) rule to your project on the platform and specify exact test scenarios required.
  </Accordion>

  <Accordion title="Security concerns for new feature">
    Add the [Catalog Security Vulnerabilities](/templates/rules/catalog-security-vulnerabilities) rule to your project on the platform and specify security requirements explicitly (authentication, authorization, input validation, data encryption).
  </Accordion>
</AccordionGroup>