|
| 1 | +--- |
| 2 | +name: generate |
| 3 | +description: Generate frontend resources and fields from a natural language description |
| 4 | +--- |
| 5 | + |
| 6 | +# Generate Frontend Resources |
| 7 | + |
| 8 | +You are a software architect that designs entity schemas and scaffolds React admin panel code using CLI generators. |
| 9 | + |
| 10 | +## Input |
| 11 | + |
| 12 | +The user provides a natural language description of what they want to build (e.g., "blog with posts, categories, and comments"). |
| 13 | + |
| 14 | +## Workflow |
| 15 | + |
| 16 | +### 1. Design the entity schema |
| 17 | + |
| 18 | +Analyze the user's description and design entities with their properties. Follow these rules strictly: |
| 19 | + |
| 20 | +#### Entities |
| 21 | +- **Never generate "User" or "File" entities** — they already exist. You can reference them in relationships. |
| 22 | +- Entity names must be PascalCase and singular (e.g., `Post`, `Category`, `BlogComment`). |
| 23 | + |
| 24 | +#### Properties |
| 25 | +- **Never add "id", "createdAt", or "updatedAt"** — these are predefined for all entities. |
| 26 | +- Property names must be camelCase (e.g., `firstName`, `isActive`). |
| 27 | + |
| 28 | +#### Relationships |
| 29 | +- When the backend uses `oneToMany`, **do NOT** create the corresponding `manyToOne` on the frontend — the backend generator handles it automatically. |
| 30 | +- For **File** relations, use only `oneToOne` (`toOne`) or `manyToMany` (`toMany`). |
| 31 | + |
| 32 | +#### Property kinds (frontend only supports two) |
| 33 | +- `primitive` — basic types: `string`, `number`, `boolean`, `Date` |
| 34 | +- `reference` — relationship to another entity |
| 35 | + |
| 36 | +#### Reference types (simplified) |
| 37 | +- `toOne` — maps to backend's `oneToOne` or `manyToOne` |
| 38 | +- `toMany` — maps to backend's `oneToMany` or `manyToMany` |
| 39 | + |
| 40 | +### 2. Present the schema to the user |
| 41 | + |
| 42 | +Before running commands, show the designed schema as a table or structured list so the user can review and approve it. Include entity names, property names, kinds, types, and relationship details. |
| 43 | + |
| 44 | +### 3. Show all commands for verification |
| 45 | + |
| 46 | +Once the schema is approved, list **all** commands that will be executed — first the resource generation commands, then the field commands. Present them clearly so the user can verify every command before execution. |
| 47 | + |
| 48 | +**Always ask the user for explicit confirmation before running any commands.** |
| 49 | + |
| 50 | +### 4. Run the commands |
| 51 | + |
| 52 | +Only after the user confirms the commands, execute them in this exact order: |
| 53 | + |
| 54 | +#### Step A: Generate resources (one per entity) |
| 55 | + |
| 56 | +For each new entity (excluding User and File), run: |
| 57 | + |
| 58 | +```bash |
| 59 | +npm run generate:resource -- --name {EntityName} |
| 60 | +``` |
| 61 | + |
| 62 | +Run these sequentially, one at a time. |
| 63 | + |
| 64 | +#### Step B: Add fields (one per property) |
| 65 | + |
| 66 | +Only generate fields for properties that users can set via the admin panel (i.e., properties with `isAddToDto: true` from the backend schema). |
| 67 | + |
| 68 | +For each such property, run: |
| 69 | + |
| 70 | +```bash |
| 71 | +npm run generate:field -- --name {EntityName} --property {propertyName} --kind {kind} --type {type} --referenceType {referenceType} --propertyForSelect {propertyForSelect} --propertyInReference {propertyInReference} --isOptional {isOptional} --isShowInTable {isShowInTable} |
| 72 | +``` |
| 73 | + |
| 74 | +**Argument rules:** |
| 75 | +- `--name` (required): Entity name, PascalCase |
| 76 | +- `--property` (required): Property name, camelCase |
| 77 | +- `--kind` (required): `primitive` | `reference` |
| 78 | +- `--type` (required): For primitive: `string` | `number` | `boolean` | `Date`. For reference: the referenced entity name (e.g., `User`, `File`, `Category`) |
| 79 | +- `--referenceType`: Only for reference kind. Values: `toOne` | `toMany` |
| 80 | +- `--propertyForSelect`: Only for reference kind when type is **not** `File`. The property name used for the dropdown display (e.g., `name`, `title`, `email`). |
| 81 | +- `--propertyInReference`: Only when applicable (e.g., for inverse relationships) |
| 82 | +- `--isOptional`: `true` | `false` |
| 83 | +- `--isShowInTable`: `true` | `false` — whether to display this field in the list table |
| 84 | + |
| 85 | +**Omit arguments that don't apply** (e.g., omit `--referenceType` for primitive properties, omit `--propertyForSelect` for File references or primitive properties). |
| 86 | + |
| 87 | +Run these sequentially, one at a time. |
| 88 | + |
| 89 | +## Example |
| 90 | + |
| 91 | +User: "I need a blog with posts and categories. Posts belong to a category and can have a cover image." |
| 92 | + |
| 93 | +**Commands:** |
| 94 | +```bash |
| 95 | +npm run generate:resource -- --name Category |
| 96 | +npm run generate:resource -- --name Post |
| 97 | + |
| 98 | +npm run generate:field -- --name Category --property name --kind primitive --type string --isOptional false --isShowInTable true |
| 99 | + |
| 100 | +npm run generate:field -- --name Post --property title --kind primitive --type string --isOptional false --isShowInTable true |
| 101 | +npm run generate:field -- --name Post --property body --kind primitive --type string --isOptional false --isShowInTable false |
| 102 | +npm run generate:field -- --name Post --property category --kind reference --type Category --referenceType toOne --propertyForSelect name --isOptional false --isShowInTable true |
| 103 | +npm run generate:field -- --name Post --property coverImage --kind reference --type File --referenceType toOne --isOptional true --isShowInTable false |
| 104 | +``` |
0 commit comments