@codihaus/claude-skills 1.0.0 → 1.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,118 +1,101 @@
1
1
  ---
2
2
  name: dev-coding-backend
3
3
  description: Backend implementation patterns and workflows
4
- version: 1.2.0
4
+ version: 2.0.0
5
5
  ---
6
6
 
7
7
  # /dev-coding-backend - Backend Implementation
8
8
 
9
- > **Skill Awareness**: See `skills/_registry.md` for all available skills.
10
- > - **Loaded by**: `/dev-coding` when API/schema work needed
11
- > - **References**: Load tech-specific from `references/` (directus.md, prisma.md, etc.)
12
- > - **After**: Frontend uses API contract documented here
13
- > - **After**: `/dev-test` auto-runs to verify API via network requests
9
+ > **Loaded by**: `/dev-coding` when API/schema work needed
10
+ > **After**: Frontend uses API contract documented here
14
11
 
15
- Backend-specific patterns for API, schema, and data layer implementation.
12
+ Backend-specific workflow for API, schema, and data layer implementation.
16
13
 
17
- ## When Loaded
14
+ ## Knowledge Loading (CRITICAL)
18
15
 
19
- This skill is loaded by `/dev-coding` when:
20
- - Spec requires API endpoints
21
- - Spec requires schema/database changes
22
- - Spec requires backend logic
16
+ Before implementing, load relevant knowledge:
23
17
 
24
- ## Workflow
18
+ ```
19
+ 1. Read stack.md → plans/scout/stack.md
20
+ → Identify: API layer, SDK, data access method
25
21
 
26
- ### Step 1: Understand Backend Requirements
22
+ 2. Load stack knowledge based on detected tech:
23
+ | If using... | Read... | Section |
24
+ |--------------|-----------------------------------|-------------------|
25
+ | Directus | knowledge/stacks/directus/_index.md | "For /dev-coding" |
26
+ | Nuxt server | knowledge/stacks/nuxt/_index.md | "Server Routes" |
27
+ | Next.js API | knowledge/stacks/nextjs/_index.md | "API Routes" |
27
28
 
28
- From the UC spec, extract:
29
+ 3. Load domain knowledge (if applicable):
30
+ | If domain... | Read... | Section |
31
+ |--------------|-----------------------------------|-------------------|
32
+ | SaaS | knowledge/domains/saas/_index.md | Billing, Multi-tenant |
33
+ | E-commerce | knowledge/domains/ecommerce/_index.md | Orders, Payments |
29
34
 
30
- ```markdown
31
- ## Backend Requirements Checklist
35
+ 4. Use loaded knowledge for:
36
+ Correct SDK usage (not raw fetch)
37
+ → Domain-specific validation rules
38
+ → Stack-specific error handling
39
+ ```
32
40
 
33
- [ ] Schema changes needed?
34
- - New collections/tables
35
- - New fields on existing
36
- - Relations to add
41
+ ## Workflow
42
+
43
+ ### Step 1: Extract Backend Requirements
44
+
45
+ From UC spec, identify:
46
+
47
+ ```
48
+ [ ] Schema changes?
49
+ → New collections/tables
50
+ → New fields
51
+ → Relations
37
52
 
38
- [ ] API endpoints needed?
39
- - Method + Path
40
- - Request body
41
- - Response shape
42
- - Auth required?
53
+ [ ] API endpoints?
54
+ Method + Path
55
+ Request/Response shape
56
+ Auth required?
43
57
 
44
58
  [ ] Business logic?
45
- - Validation rules
46
- - Calculations
47
- - Side effects (emails, notifications)
59
+ Validation rules
60
+ Side effects (emails, webhooks)
48
61
 
49
62
  [ ] External integrations?
50
- - Third-party APIs
51
- - Webhooks
52
- - File storage
63
+ Third-party APIs
64
+ File storage
53
65
  ```
54
66
 
55
- ### Step 2: Schema First (if needed)
67
+ ### Step 2: Schema First
56
68
 
57
- **Order matters:** Schema before API
69
+ **Order:** Schema API → Logic
58
70
 
59
71
  ```
60
72
  1. Design schema based on spec
61
73
  2. Create/modify collections or tables
62
74
  3. Set up relations
63
- 4. Configure permissions/roles
64
- 5. Verify schema is correct
65
- ```
66
-
67
- **Verification:**
68
- ```bash
69
- # For Directus - check collection exists
70
- curl "$DIRECTUS_URL/items/{collection}?limit=1" \
71
- -H "Authorization: Bearer $TOKEN"
72
-
73
- # For Prisma - run migration
74
- npx prisma migrate dev
75
-
76
- # For SQL - verify table
77
- psql -c "\\d {table_name}"
75
+ 4. Configure permissions
76
+ 5. Verify schema works
78
77
  ```
79
78
 
80
79
  ### Step 3: API Implementation
81
80
 
82
- **For each endpoint in spec:**
81
+ For each endpoint:
83
82
 
84
83
  ```
85
- 1. Create route/handler file
86
- 2. Implement request parsing
87
- 3. Add validation
88
- 4. Implement business logic
84
+ 1. Create route/handler
85
+ 2. Parse request
86
+ 3. Validate input
87
+ 4. Implement logic
89
88
  5. Handle errors
90
89
  6. Return response
91
90
  ```
92
91
 
93
- **Follow project patterns** (from scout):
94
- - File location (routes/, api/, controllers/)
95
- - Naming convention
96
- - Error handling pattern
97
- - Response format
98
-
99
- ### Step 4: API Patterns
92
+ **Follow project patterns** from scout (file locations, naming, error format).
100
93
 
101
- #### REST Conventions
94
+ ### Step 4: Essential Patterns
102
95
 
103
- ```
104
- GET /api/{resource} → List
105
- GET /api/{resource}/:id → Get one
106
- POST /api/{resource} → Create
107
- PUT /api/{resource}/:id → Update (full)
108
- PATCH /api/{resource}/:id → Update (partial)
109
- DELETE /api/{resource}/:id → Delete
110
- ```
111
-
112
- #### Request Validation
96
+ #### Request Validation (always do this)
113
97
 
114
98
  ```typescript
115
- // Always validate input
116
99
  const schema = z.object({
117
100
  email: z.string().email(),
118
101
  password: z.string().min(8),
@@ -127,235 +110,117 @@ if (!result.success) {
127
110
  }
128
111
  ```
129
112
 
130
- #### Error Handling
113
+ #### Error Response Format
131
114
 
132
115
  ```typescript
133
- // Consistent error format
134
- {
135
- "error": "Error message for client",
136
- "code": "ERROR_CODE",
137
- "details": {} // Optional additional info
138
- }
116
+ // Consistent format
117
+ { "error": "Message", "code": "ERROR_CODE" }
139
118
 
140
- // HTTP status codes
141
- 200 - Success
142
- 201 - Created
143
- 400 - Bad request (validation)
144
- 401 - Unauthorized
145
- 403 - Forbidden
146
- 404 - Not found
147
- 409 - Conflict
148
- 500 - Server error
119
+ // Status codes
120
+ 200 - Success 400 - Bad request
121
+ 201 - Created 401 - Unauthorized
122
+ 403 - Forbidden
123
+ 404 - Not found
124
+ 500 - Server error
149
125
  ```
150
126
 
151
- #### Authentication Check
127
+ #### Auth Check
152
128
 
153
129
  ```typescript
154
- // Verify auth before processing
155
130
  if (!req.user) {
156
131
  return res.status(401).json({ error: 'Unauthorized' });
157
132
  }
158
-
159
- // Check permissions
160
- if (!req.user.permissions.includes('create:posts')) {
133
+ if (!hasPermission(req.user, 'create:posts')) {
161
134
  return res.status(403).json({ error: 'Forbidden' });
162
135
  }
163
136
  ```
164
137
 
165
- ### Step 5: Verification
166
-
167
- **Test each endpoint:**
138
+ ### Step 5: Verify
168
139
 
169
140
  ```bash
170
- # Test with curl
141
+ # Test endpoint
171
142
  curl -X POST http://localhost:3000/api/auth/login \
172
143
  -H "Content-Type: application/json" \
173
144
  -d '{"email":"test@test.com","password":"password123"}'
174
-
175
- # Expected: 200 with token
176
- # Or: 401 with error message
177
145
  ```
178
146
 
179
- **Verification checklist:**
147
+ Checklist:
180
148
  ```
181
149
  [ ] Endpoint responds
182
150
  [ ] Correct status codes
183
- [ ] Response matches spec
184
151
  [ ] Validation rejects bad input
185
- [ ] Auth required endpoints reject anonymous
186
- [ ] Error messages are helpful but not leaky
152
+ [ ] Auth works correctly
153
+ [ ] Response matches spec
187
154
  ```
188
155
 
189
156
  ### Step 6: Document for Frontend
190
157
 
191
- After backend complete, document what frontend needs:
192
-
193
158
  ```markdown
194
- ## API Ready for Frontend
159
+ ## API Ready
195
160
 
196
161
  ### POST /api/auth/login
197
- - **Auth**: None (public)
198
- - **Request**: `{ email: string, password: string }`
199
- - **Success (200)**: `{ token: string, user: { id, email, name } }`
200
- - **Errors**:
201
- - 400: Invalid input
202
- - 401: Invalid credentials
203
-
204
- ### GET /api/users/me
205
- - **Auth**: Bearer token required
206
- - **Request**: None
207
- - **Success (200)**: `{ id, email, name, role }`
208
- - **Errors**:
209
- - 401: No/invalid token
210
- ```
211
-
212
- ### Step 7: Hand Off to Testing
213
-
214
- After full implementation (backend + frontend), `/dev-coding` auto-triggers `/dev-test` which:
215
-
216
- ```
217
- 1. Navigate to UI (triggers API calls)
218
- 2. Capture network requests
219
- 3. Check for 4xx/5xx responses
220
- 4. Report API failures
221
- ```
222
-
223
- **What /dev-test catches for backend:**
224
- - 400 Bad Request (validation failures)
225
- - 401 Unauthorized (auth issues)
226
- - 403 Forbidden (permission issues)
227
- - 404 Not Found (wrong endpoints)
228
- - 500 Server Error (backend bugs)
229
- - CORS errors (misconfigured)
230
- - Timeout errors (slow queries)
231
-
232
- **Example test failure:**
233
- ```markdown
234
- [Network] POST /api/auth/login returned 500
235
- Response: {"error":"Internal server error"}
236
- Likely cause: Database connection or missing env var
237
- ```
238
-
239
- ## Common Patterns
240
-
241
- ### Database Query Patterns
242
-
243
- ```typescript
244
- // Pagination
245
- const page = parseInt(req.query.page) || 1;
246
- const limit = parseInt(req.query.limit) || 10;
247
- const offset = (page - 1) * limit;
248
-
249
- const items = await db.items.findMany({
250
- skip: offset,
251
- take: limit,
252
- orderBy: { createdAt: 'desc' }
253
- });
254
-
255
- // Filtering
256
- const where = {};
257
- if (req.query.status) {
258
- where.status = req.query.status;
259
- }
260
-
261
- // Include relations
262
- const post = await db.posts.findUnique({
263
- where: { id },
264
- include: { author: true, comments: true }
265
- });
266
- ```
267
-
268
- ### Transaction Pattern
269
-
270
- ```typescript
271
- // When multiple operations must succeed together
272
- await db.$transaction(async (tx) => {
273
- const user = await tx.users.create({ data: userData });
274
- await tx.profiles.create({ data: { userId: user.id } });
275
- await tx.settings.create({ data: { userId: user.id } });
276
- return user;
277
- });
278
- ```
279
-
280
- ### Soft Delete Pattern
281
-
282
- ```typescript
283
- // Don't actually delete, mark as deleted
284
- await db.posts.update({
285
- where: { id },
286
- data: {
287
- deletedAt: new Date(),
288
- status: 'deleted'
289
- }
290
- });
291
-
292
- // Query excludes deleted
293
- const posts = await db.posts.findMany({
294
- where: { deletedAt: null }
295
- });
162
+ - **Auth**: None
163
+ - **Request**: `{ email, password }`
164
+ - **Success (200)**: `{ token, user }`
165
+ - **Errors**: 400 (invalid), 401 (wrong creds)
296
166
  ```
297
167
 
298
168
  ## Security Checklist
299
169
 
300
170
  ```
301
- [ ] Input validated before use
302
- [ ] SQL/NoSQL injection prevented (use parameterized queries)
303
- [ ] Auth checked on protected routes
304
- [ ] Permissions verified for actions
305
- [ ] Sensitive data not logged
306
- [ ] Passwords hashed (never plain text)
307
- [ ] Rate limiting on auth endpoints
308
- [ ] CORS configured correctly
309
- [ ] No secrets in code (use env vars)
171
+ [ ] Input validated (Zod/Yup)
172
+ [ ] Parameterized queries (no SQL injection)
173
+ [ ] Auth on protected routes
174
+ [ ] Permissions verified
175
+ [ ] Passwords hashed
176
+ [ ] Secrets in env vars
177
+ [ ] No sensitive data in logs
310
178
  ```
311
179
 
312
- ## Debugging
313
-
314
- ### API Not Responding
180
+ ## Quick Debugging
315
181
 
316
182
  ```bash
317
- # Check if server running
183
+ # Server running?
318
184
  curl http://localhost:3000/health
319
185
 
320
- # Check logs
321
- tail -f logs/server.log
186
+ # Database connected?
187
+ npx prisma db pull # or check logs
322
188
 
323
- # Check port in use
324
- lsof -i :3000
189
+ # Token valid?
190
+ curl http://localhost:3000/api/me -H "Authorization: Bearer $TOKEN"
325
191
  ```
326
192
 
327
- ### Database Issues
193
+ ## Stack-Specific Patterns
328
194
 
329
- ```bash
330
- # Check connection
331
- npx prisma db pull # Prisma
332
- psql -c "SELECT 1" # PostgreSQL
333
-
334
- # Check migrations
335
- npx prisma migrate status
336
- ```
337
-
338
- ### Auth Issues
195
+ **Do not implement generic patterns. Load from stacks/:**
339
196
 
340
- ```bash
341
- # Test token validity
342
- curl http://localhost:3000/api/users/me \
343
- -H "Authorization: Bearer $TOKEN"
197
+ | Stack | What to load | Key patterns |
198
+ |-------|--------------|--------------|
199
+ | Directus | `stacks/directus/` | SDK queries, permissions, hooks |
200
+ | Prisma | `stacks/prisma/` (future) | ORM patterns, migrations |
201
+ | Supabase | `stacks/supabase/` (future) | RLS, auth, realtime |
344
202
 
345
- # Decode JWT (for debugging only)
346
- echo $TOKEN | cut -d. -f2 | base64 -d
203
+ **Example - if using Directus:**
204
+ ```
205
+ 1. Read knowledge/stacks/directus/_index.md
206
+ 2. Use ItemsService (not raw SQL)
207
+ 3. Follow permission patterns
208
+ 4. Use SDK for queries
347
209
  ```
348
210
 
349
- ## Tech-Specific References
211
+ ## Domain-Specific Logic
350
212
 
351
- Load additional patterns based on detected tech:
213
+ **Load from domains/ when applicable:**
352
214
 
353
- | Tech | Reference File |
354
- |------|---------------|
355
- | Directus | `references/directus.md` |
356
- | Node/Express | `references/node.md` |
357
- | Prisma | `references/prisma.md` |
358
- | PostgreSQL | `references/postgresql.md` |
359
- | Supabase | `references/supabase.md` |
215
+ | Domain | What to load | Key patterns |
216
+ |--------|--------------|--------------|
217
+ | SaaS | `domains/saas/_index.md` | Subscription states, billing |
218
+ | E-commerce | `domains/ecommerce/_index.md` | Order lifecycle, inventory |
360
219
 
361
- These files contain tech-specific patterns, gotchas, and best practices. Add them as your projects use different stacks.
220
+ **Example - SaaS billing endpoint:**
221
+ ```
222
+ 1. Read knowledge/domains/saas/_index.md
223
+ 2. Follow subscription state machine
224
+ 3. Handle trial → paid → cancelled states
225
+ 4. Validate against billing rules
226
+ ```