Cursor Composer Complex Feature Builder

What this prompt does

This prompt drives Cursor Composer to scaffold an entire feature in one session instead of building it file-by-file. You name the [feature_name], the [framework], and describe what it does with [feature_description], then the AI generates the data model with [model_fields] and relationships, a migration with indexes and foreign keys, a controller with CRUD operations plus [custom_actions], the routes, validation logic with per-field error messages, [test_count] tests covering happy paths and edge cases and authorization, UI components matching your design system, and middleware enforcing [auth_requirement].

The structure works because it mirrors the real shape of a feature: model, migration, controller, routes, validation, tests, UI, and guards, generated in dependency order. Defining [model_fields] and relationships first means the migration, validation, and tests downstream all stay consistent with one source of truth. The prompt's key move is the @Codebase reference, which lets Composer read your existing project conventions — naming, file layout, the design system — so the generated code looks like it belongs rather than like a foreign template dropped in. That single instruction is what keeps a one-shot scaffold from feeling generic, because Composer matches the patterns it sees in your actual code instead of inventing its own.

When to use it

• You are scaffolding a complete feature and want it generated in one Composer pass
• The feature has a clear data model and a known set of [custom_actions] to implement
• You want generated code to match existing project conventions, not generic boilerplate
• You need model, migration, controller, tests, and UI created together so they stay consistent
• Authorization rules like [auth_requirement] must be baked in from the start
• You are working in a framework such as Laravel or Node where the feature layout is well established

Example output

Composer produces a multi-file changeset: a data model with [model_fields] and relationships, a migration with indexes and foreign keys, a controller exposing CRUD plus [custom_actions], the routes, field-level validation with error messages, [test_count] tests covering happy paths and authorization, UI components matching your design system, and middleware enforcing [auth_requirement]. It lands as a coherent feature you then review and refine rather than a scattered set of stubs.

Pro tips

• Write [feature_description] as a precise sentence — vague descriptions produce vague models and missing fields
• List [model_fields] exactly, including types and which are nullable, so the migration is correct on the first pass
• Always include the @Codebase reference; without it Composer drifts from your naming and folder conventions
• Set [test_count] to a realistic number and name the cases you care about, such as edge cases and authorization
• Review the migration before running it; generated indexes and foreign keys still need a careful human check
• Keep [custom_actions] to what the feature genuinely needs so Composer does not over-scaffold with dead endpoints