Skip to main content
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.

Ready to add a feature?

Use the New Feature Template to get started with a structured prompt
Jump to: When to Use | Prompt Structure | Key Considerations | Common Patterns | Troubleshooting

​
When to Use This Approach

Add new pages, components, or workflows that expand what your users can do inside the product.

​
Prompt Structure

Follow the 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

Scope Boundaries Matter Most

Clearly define what files/components change and what remains untouched. Use absolute language (“DO NOT modify authentication”) rather than suggestions.

Reference Existing Patterns

Point to similar code in your codebase that demonstrates the architectural style, error handling, or integration patterns you want followed.

Integration Points Need Specificity

Identify exact files, classes, or functions where the new feature connects to existing code. Vague integration guidance leads to misaligned implementations.

Test Coverage Expectations

Specify test types (unit, integration, e2e), coverage thresholds, and critical scenarios upfront to ensure generated code includes comprehensive tests.

​
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

Add the Enforce Code Style Patterns rule to your project on the platform to extract and enforce patterns from your codebase.
Scope may be too broad. Break into smaller features or add more specific CONSTRAINTS about what should NOT change.
Add more specificity about file paths, function signatures, and data contracts at integration boundaries.
Add the Require Test Coverage rule to your project on the platform and specify exact test scenarios required.
Add the Catalog Security Vulnerabilities rule to your project on the platform and specify security requirements explicitly (authentication, authorization, input validation, data encryption).