$npx -y skills add girijashankarj/cursor-handbook --skill create-handlerCreate a new API handler following the handler pattern. Use when the user asks to create an endpoint, handler, or route.
| 1 | # Skill: Create API Handler |
| 2 | |
| 3 | Step-by-step workflow for creating a new API handler following the {{CONFIG.patterns.handlerFlowSteps}}-step handler pattern. |
| 4 | |
| 5 | ## Scripts (Cursor skills scripts/ support) |
| 6 | |
| 7 | This skill includes a `scripts/` folder. The agent can run these scripts as part of the workflow: |
| 8 | |
| 9 | - **scripts/scaffold-handler-dirs.sh** — Creates the handler directory structure. Usage: `./scripts/scaffold-handler-dirs.sh <entity> <operation>` (e.g. `order create`). |
| 10 | |
| 11 | ## Trigger |
| 12 | When the user asks to create a new API endpoint, handler, or route. |
| 13 | |
| 14 | ## Prerequisites |
| 15 | - Project configuration loaded (`{{CONFIG.paths.handlerBasePath}}` exists) |
| 16 | - Understanding of the entity and operation |
| 17 | |
| 18 | ## Steps |
| 19 | |
| 20 | ### Step 1: Gather Requirements |
| 21 | - [ ] Identify the entity (e.g., Order, Product, User) |
| 22 | - [ ] Identify the operation (e.g., create, read, update, list, delete) |
| 23 | - [ ] Determine HTTP method and URL path |
| 24 | - [ ] Identify request parameters and body schema |
| 25 | - [ ] Identify response format |
| 26 | |
| 27 | ### Step 2: Create Directory Structure |
| 28 | ```bash |
| 29 | mkdir -p {{CONFIG.paths.handlerBasePath}}/{entity}/{operation}/logic |
| 30 | mkdir -p {{CONFIG.paths.handlerBasePath}}/{entity}/{operation}/schemas |
| 31 | ``` |
| 32 | |
| 33 | Expected structure: |
| 34 | ``` |
| 35 | {{CONFIG.paths.handlerBasePath}}/{entity}/{operation}/ |
| 36 | ├── {{CONFIG.fileNames.handlerEntry}} |
| 37 | ├── logic/ |
| 38 | │ ├── validate-request.ts |
| 39 | │ ├── validate-business.ts |
| 40 | │ ├── pre-processing.ts |
| 41 | │ ├── operation.ts |
| 42 | │ ├── post-operation.ts |
| 43 | │ └── response.ts |
| 44 | └── schemas/ |
| 45 | ├── {{CONFIG.fileNames.requestSchema}} |
| 46 | └── {{CONFIG.fileNames.responseSchema}} |
| 47 | ``` |
| 48 | |
| 49 | ### Step 3: Create Request Schema |
| 50 | - [ ] Define JSON Schema in `schemas/{{CONFIG.fileNames.requestSchema}}` |
| 51 | - [ ] Include all required and optional fields |
| 52 | - [ ] Add type validation and constraints |
| 53 | - [ ] Add description for each field |
| 54 | |
| 55 | ### Step 4: Create Response Schema |
| 56 | - [ ] Define JSON Schema in `schemas/{{CONFIG.fileNames.responseSchema}}` |
| 57 | - [ ] Follow response envelope pattern: `{ data, meta }` |
| 58 | - [ ] Include all response fields with types |
| 59 | |
| 60 | ### Step 5: Implement Logic Steps |
| 61 | For each file in `logic/`: |
| 62 | - [ ] `validate-request.ts` — Validate request against schema |
| 63 | - [ ] `validate-business.ts` — Check business rules and entity state |
| 64 | - [ ] `pre-processing.ts` — Transform and enrich data |
| 65 | - [ ] `operation.ts` — Execute core business logic |
| 66 | - [ ] `post-operation.ts` — Trigger side effects (events, notifications) |
| 67 | - [ ] `response.ts` — Format response with envelope |
| 68 | |
| 69 | ### Step 6: Create Handler Entry Point |
| 70 | - [ ] Import all logic steps |
| 71 | - [ ] Wire up the {{CONFIG.patterns.handlerFlowSteps}}-step flow |
| 72 | - [ ] Add error handling with try/catch |
| 73 | - [ ] Add structured logging with correlationId |
| 74 | - [ ] Export handler function |
| 75 | |
| 76 | ### Step 7: Register Route |
| 77 | - [ ] Add route in the appropriate router file |
| 78 | - [ ] Apply authentication middleware |
| 79 | - [ ] Apply rate limiting if needed |
| 80 | |
| 81 | ### Step 8: Add Tests |
| 82 | - [ ] Create test file: `{entity}/{operation}/__tests__/handler.test.ts` |
| 83 | - [ ] Test each logic step independently |
| 84 | - [ ] Test handler integration (success path) |
| 85 | - [ ] Test error cases (validation, business, not found) |
| 86 | - [ ] Verify {{CONFIG.testing.coverageMinimum}}% coverage |
| 87 | |
| 88 | ### Step 9: Validate |
| 89 | - [ ] Run type check: `{{CONFIG.testing.typeCheckCommand}}` |
| 90 | - [ ] Run tests for the new handler only |
| 91 | - [ ] Verify schemas match implementation |
| 92 | |
| 93 | ## Completion |
| 94 | Handler is created, tested, and type-checked. Ready for code review. |
| 95 | |
| 96 | ## If a step fails |
| 97 | |
| 98 | - **Step 2 (directory):** Ensure `{{CONFIG.paths.handlerBasePath}}` exists. Run `mkdir -p` from project root. |
| 99 | - **Step 3–4 (schemas):** If schema validation fails, check JSON Schema syntax. Use a minimal schema first. |
| 100 | - **Step 5 (logic):** If imports fail, verify paths match `{{CONFIG.paths.commonPath}}` and handler structure. |
| 101 | - **Step 8 (tests):** If tests fail, run `{{CONFIG.testing.typeCheckCommand}}` first. Fix type errors before test logic. |
| 102 | - **Step 9 (validate):** If type-check fails, fix reported errors before proceeding. Do not skip validation. |