ai-qakit 1.0.0

package/templates/.claude/commands/devkit/backend/create-schema.md

@@ -0,0 +1,158 @@
+---
+description: Generate database schema/model definition
+argument-hint: [model-description]
+allowed-tools: Read, Grep, Write, Edit, AskUserQuestion
+---
+
+<!--
+Usage: /create-schema [model-description]
+Requires: ORM configured (Prisma/TypeORM/SQLAlchemy/etc.)
+Example: /create-schema "User model with email, name, and posts relationship"
+Example: /create-schema "Product with price, inventory, and category"
+-->
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+---
+
+**Report Protocol**: Follow ./.claude/CLAUDE.md "Sub-Agent Report Generation" protocol before spawning subagents.
+
+# Create Database Schema
+
+Generate schema/model based on description.
+
+## Input Validation
+
+### Validate Model Description ($ARGUMENTS)
+
+If $ARGUMENTS not provided:
+  Use AskUserQuestion to ask for model description:
+  - question: "What schema/model should I generate? Describe the entity, fields, and relationships."
+  - header: "Schema Description"
+  - options:
+    - I'll describe the model
+
+If $ARGUMENTS provided:
+  Proceed with schema generation for: $ARGUMENTS
+
+## ⚠️ Plan Before Executing
+
+**Always create a structured plan and get user approval before making changes.**
+
+1. Analyze the request and show schema design
+2. Display the model structure with fields and relationships
+3. Show the file content before creating
+4. Ask for confirmation before writing files
+5. Never create schemas without user approval
+
+## Important: Ask for Clarification
+
+**If anything is unclear, DO NOT GUESS. Ask the user:**
+
+- "What fields should this model have?"
+- "What's the relationship with [other model]? (one-to-one, one-to-many, many-to-many)"
+- "Should [field] be unique, indexed, or have constraints?"
+- "What's the data type for [field]? (string length, number precision)"
+- "Should this model support soft deletes?"
+- "Are there any computed/virtual fields needed?"
+
+Use AskUserQuestion tool when you need more context before proceeding.
+
+## Step 1: Reference Project Profile
+
+Read @.claude/CLAUDE.md to understand:
+- ORM (Prisma, TypeORM, Sequelize, SQLAlchemy, etc.)
+- Schema/model location
+- Field type patterns
+- Relationship patterns
+- Validation approach
+
+If `.claude/CLAUDE.md` doesn't exist, run `/init` first.
+
+## Step 2: Parse Request
+
+Analyze "$ARGUMENTS" to determine:
+- Entity/model name
+- Fields and types
+- Relationships (belongs to, has many, many-to-many)
+- Constraints (unique, required, default)
+- Indexes needed
+
+**Common relationship patterns:**
+- `User has many Posts`
+- `Post belongs to User`
+- `User has many Roles through UserRoles`
+- `Tag many-to-many with Post`
+
+## Step 3: Review Existing Models
+
+Find and analyze existing schema/models to detect:
+- Primary key pattern (uuid, cuid, auto-increment)
+- Timestamp pattern (created_at, updated_at)
+- Soft delete pattern (deleted_at)
+- Naming convention (singular/plural, camelCase/snake_case)
+- Field type usage
+- Decorator/annotation patterns
+- Validation patterns
+
+## Step 4: Map Field Types
+
+Convert requested types to ORM-specific types:
+
+| Concept | Common Types |
+|---------|--------------|
+| ID | uuid, cuid, int auto-increment |
+| String | varchar, text, string |
+| Number | int, float, decimal |
+| Boolean | boolean, tinyint |
+| Date | datetime, timestamp |
+| JSON | json, jsonb |
+| Enum | enum type |
+
+## Step 5: Generate Schema
+
+Create schema/model file following detected patterns:
+
+**Include:**
+- Proper file location
+- ID field with correct type
+- All requested fields
+- Relationships with proper decorators
+- Timestamps (if pattern exists)
+- Soft delete (if pattern exists)
+- Indexes on foreign keys
+- Validation decorators (if pattern exists)
+
+## Step 6: Show Generated Schema
+
+Display:
+1. File path
+2. Full schema/model content
+3. Database diagram (text representation):
+
+```
+┌─────────────────┐
+│ [ModelName]     │
+├─────────────────┤
+│ id: [type]      │
+│ field1: [type]  │
+│ field2: [type]  │
+│ created_at      │
+│ updated_at      │
+└─────────────────┘
+        │
+        │ 1:N
+        ▼
+┌─────────────────┐
+│ [RelatedModel]  │
+└─────────────────┘
+```
+
+## Step 7: Next Steps
+
+Provide commands:
+- Generate migration: `/create-migration [description]`
+- Apply changes: `[detected migrate command]`
+- Generate types (if applicable): `[detected generate command]`
+
+Generate schema now for: $ARGUMENTS

package/templates/.claude/commands/devkit/backend/design-graphql-api.md

@@ -0,0 +1,302 @@
+---
+description: Implement GraphQL API with schema and resolvers
+argument-hint: [schema-approach] | --schema-first | --code-first | --federation
+allowed-tools: Read, Write, Edit, Bash(git:*, ls, cat), Grep, AskUserQuestion
+---
+
+<!--
+Usage: /design-graphql-api [schema-approach]
+Example: /design-graphql-api --schema-first
+Example: /design-graphql-api --code-first
+Example: /design-graphql-api --federation
+-->
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+---
+
+**Report Protocol**: Follow ./.claude/CLAUDE.md "Sub-Agent Report Generation" protocol before spawning subagents.
+
+# Implement GraphQL API
+
+Implement comprehensive GraphQL API with modern best practices: **$ARGUMENTS**
+
+## ⚠️ Plan Before Executing
+
+**Always create a structured plan and get user approval before making changes.**
+
+1. Analyze requirements and show schema design plan
+2. Present type definitions, queries, mutations
+3. List all files that will be created
+4. Ask for confirmation before generating any code
+5. Never create GraphQL files without user approval
+
+## Important: Ask for Clarification
+
+**If anything is unclear, DO NOT GUESS. Ask the user:**
+
+- "What types/entities should the schema include?"
+- "Do you need real-time subscriptions? For what events?"
+- "What authentication/authorization rules apply?"
+- "Should I use schema-first or code-first approach?"
+- "Are there any N+1 query concerns I should optimize with DataLoader?"
+- "What query complexity limits should I enforce?"
+- "Should I set up Apollo Federation for microservices?"
+
+Use AskUserQuestion tool when you need more context before proceeding.
+
+## Current Application Context
+
+- Framework: @CLAUDE.md
+- GraphQL files: !`find . -name "*.graphql" -o -name "*resolver*" -o -name "*schema*" 2>/dev/null | grep -v node_modules | wc -l`
+- Database integration: !`ls prisma/schema.prisma 2>/dev/null || echo "Check database config"`
+- Authentication: !`grep -r "auth\|jwt\|context\|guard" src/ 2>/dev/null | wc -l` auth patterns
+
+## Step 1: Reference Project Profile
+
+Read @.claude/CLAUDE.md to understand:
+- GraphQL framework (Apollo, GraphQL Yoga, etc.)
+- Schema approach (schema-first vs code-first)
+- Authentication context setup
+- Database/ORM integration
+
+If `.claude/CLAUDE.md` doesn't exist, run `/init` first.
+
+## Step 2: Parse Schema Request
+
+Analyze "$ARGUMENTS" to determine:
+- Schema approach: `--schema-first`, `--code-first`, or `--federation`
+- Types and relationships needed
+- Query/mutation operations
+- Subscription requirements
+
+## Step 3: Design GraphQL Schema
+
+### Type Definitions
+
+```graphql
+type Resource {
+  id: ID!
+  name: String!
+  description: String
+  createdAt: DateTime!
+  updatedAt: DateTime!
+  # Relationships
+  owner: User!
+  items: [Item!]!
+}
+
+input CreateResourceInput {
+  name: String!
+  description: String
+}
+
+input UpdateResourceInput {
+  name: String
+  description: String
+}
+
+type ResourceConnection {
+  edges: [ResourceEdge!]!
+  pageInfo: PageInfo!
+  totalCount: Int!
+}
+
+type ResourceEdge {
+  node: Resource!
+  cursor: String!
+}
+```
+
+### Query Operations
+
+```graphql
+type Query {
+  # Single resource
+  resource(id: ID!): Resource
+  
+  # Paginated list with filters
+  resources(
+    first: Int
+    after: String
+    filter: ResourceFilter
+    orderBy: ResourceOrderBy
+  ): ResourceConnection!
+  
+  # Search
+  searchResources(query: String!): [Resource!]!
+}
+```
+
+### Mutation Operations
+
+```graphql
+type Mutation {
+  createResource(input: CreateResourceInput!): Resource!
+  updateResource(id: ID!, input: UpdateResourceInput!): Resource!
+  deleteResource(id: ID!): Boolean!
+  
+  # Batch operations
+  bulkDeleteResources(ids: [ID!]!): Int!
+}
+```
+
+### Subscription Operations
+
+```graphql
+type Subscription {
+  resourceCreated: Resource!
+  resourceUpdated(id: ID): Resource!
+  resourceDeleted: ID!
+}
+```
+
+## Step 4: Resolver Architecture
+
+**Query Resolvers**:
+- Field-level resolution
+- DataLoader for N+1 prevention
+- Authorization checks
+- Input validation
+
+**Mutation Resolvers**:
+- Transaction handling
+- Validation before mutation
+- Publish subscription events
+- Return updated data
+
+**Subscription Resolvers**:
+- WebSocket connection management
+- Filter subscriptions by user/resource
+- Authentication in connection context
+
+## Step 5: DataLoader Integration
+
+Implement DataLoader for efficient data fetching:
+
+```typescript
+// Batch loading pattern
+const userLoader = new DataLoader(async (userIds) => {
+  const users = await prisma.user.findMany({
+    where: { id: { in: userIds } }
+  });
+  return userIds.map(id => users.find(u => u.id === id));
+});
+```
+
+**Apply to**:
+- Related entity fetching
+- Nested object resolution
+- Avoiding N+1 queries
+
+## Step 6: Authentication & Authorization
+
+**Context Setup**:
+```typescript
+context: ({ req }) => ({
+  user: getUserFromToken(req.headers.authorization),
+  dataSources: createDataSources(),
+  loaders: createLoaders(),
+})
+```
+
+**Authorization Patterns**:
+- Directive-based: `@auth`, `@hasRole(role: ADMIN)`
+- Resolver-level checks
+- Field-level permissions
+
+## Step 7: Security & Performance
+
+**Query Complexity**:
+- Set maximum query depth
+- Calculate query cost
+- Rate limit by complexity
+
+**Validation**:
+- Input validation with custom scalars
+- Maximum pagination limits
+- Query whitelisting (production)
+
+**Caching**:
+- Response caching
+- DataLoader caching
+- CDN integration for persisted queries
+
+## Step 8: Generate GraphQL Components
+
+Create all required files following project patterns:
+
+**Schema-First Approach**:
+1. `schema.graphql` - Type definitions
+2. `resolvers/` - Query, Mutation, Subscription resolvers
+3. `dataloaders/` - DataLoader implementations
+4. `directives/` - Custom directives
+
+**Code-First Approach**:
+1. `types/` - TypeGraphQL/NestJS type classes
+2. `resolvers/` - Resolver classes with decorators
+3. `inputs/` - Input type classes
+4. `scalars/` - Custom scalar implementations
+
+## Step 9: Development Tools
+
+**Setup**:
+- GraphQL Playground/Apollo Studio
+- Introspection (dev only)
+- Schema documentation
+- Query examples
+
+## Step 10: Output
+
+Display:
+1. Complete schema definition
+2. All generated file paths and contents
+3. Resolver implementations
+4. Example queries:
+
+```graphql
+# Query example
+query GetResources($first: Int, $after: String) {
+  resources(first: $first, after: $after) {
+    edges {
+      node {
+        id
+        name
+        owner {
+          id
+          name
+        }
+      }
+      cursor
+    }
+    pageInfo {
+      hasNextPage
+      endCursor
+    }
+    totalCount
+  }
+}
+
+# Mutation example
+mutation CreateResource($input: CreateResourceInput!) {
+  createResource(input: $input) {
+    id
+    name
+    createdAt
+  }
+}
+
+# Subscription example
+subscription OnResourceCreated {
+  resourceCreated {
+    id
+    name
+    owner {
+      id
+    }
+  }
+}
+```
+
+Implement GraphQL API now for: $ARGUMENTS
+

package/templates/.claude/commands/devkit/backend/design-rest-api.md

@@ -0,0 +1,192 @@
+---
+description: Design RESTful API architecture with endpoints and auth
+argument-hint: [api-version] | --v1 | --v2 | --openapi
+allowed-tools: Read, Write, Edit, Bash(git:*, ls, cat), Grep, AskUserQuestion
+---
+
+<!--
+Usage: /design-rest-api [api-version]
+Example: /design-rest-api v1
+Example: /design-rest-api --v2
+Example: /design-rest-api --openapi
+-->
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+---
+
+**Report Protocol**: Follow ./.claude/CLAUDE.md "Sub-Agent Report Generation" protocol before spawning subagents.
+
+# Design REST API
+
+Design comprehensive RESTful API architecture: **$ARGUMENTS**
+
+## ⚠️ Plan Before Executing
+
+**Always create a structured plan and get user approval before making changes.**
+
+1. Analyze requirements and show API design plan
+2. Present endpoint specifications with methods/paths
+3. List all files that will be created
+4. Ask for confirmation before generating any code
+5. Never create API files without user approval
+
+## Important: Ask for Clarification
+
+**If anything is unclear, DO NOT GUESS. Ask the user:**
+
+- "What resources/entities should this API expose?"
+- "What authentication method should I use? (JWT, OAuth, API Keys)"
+- "What authorization rules apply? (roles, permissions, ownership)"
+- "Should I include rate limiting? What limits?"
+- "What versioning strategy do you prefer? (URL, header, content-type)"
+- "Are there any specific business rules for this API?"
+- "Should I generate OpenAPI/Swagger documentation?"
+
+Use AskUserQuestion tool when you need more context before proceeding.
+
+## Current Application Context
+
+- Framework: @CLAUDE.md
+- Existing routes: !`grep -r "route\|@Get\|@Post\|@Controller\|@RestController" src/ 2>/dev/null | wc -l` routes found
+- Authentication: !`grep -r "auth\|jwt\|session\|passport" src/ 2>/dev/null | wc -l` auth components
+- Documentation: !`ls swagger.yaml swagger.json openapi.yaml openapi.json 2>/dev/null || echo "No OpenAPI spec found"`
+
+## Step 1: Reference Project Profile
+
+Read @.claude/CLAUDE.md to understand:
+- Framework and conventions
+- Existing API patterns
+- Authentication approach
+- Validation patterns
+
+If `.claude/CLAUDE.md` doesn't exist, run `/init` first.
+
+## Step 2: Parse API Request
+
+Analyze "$ARGUMENTS" to determine:
+- API version (v1, v2, etc.)
+- Resource name and relationships
+- Required endpoints
+- Special requirements (OpenAPI generation, etc.)
+
+## Step 3: Design Resource Endpoints
+
+**REST Conventions**:
+
+| Action | Method | Endpoint | Status Codes | Description |
+|--------|--------|----------|--------------|-------------|
+| List | GET | /api/v1/{resources} | 200 | Get paginated list |
+| Get | GET | /api/v1/{resources}/:id | 200, 404 | Get single resource |
+| Create | POST | /api/v1/{resources} | 201, 400 | Create new resource |
+| Update | PUT | /api/v1/{resources}/:id | 200, 400, 404 | Full update |
+| Patch | PATCH | /api/v1/{resources}/:id | 200, 400, 404 | Partial update |
+| Delete | DELETE | /api/v1/{resources}/:id | 204, 404 | Delete resource |
+
+**Nested Resources**:
+- GET /api/v1/{parent}/:parentId/{children}
+- POST /api/v1/{parent}/:parentId/{children}
+
+## Step 4: Request/Response Design
+
+**Request Validation**:
+- Path parameters: ID validation, UUID format
+- Query parameters: Pagination (page, limit), filtering, sorting
+- Request body: DTO validation with decorators/schemas
+
+**Response Format**:
+```json
+{
+  "data": { ... },
+  "meta": {
+    "page": 1,
+    "limit": 20,
+    "total": 100,
+    "totalPages": 5
+  }
+}
+```
+
+**Error Response**:
+```json
+{
+  "statusCode": 400,
+  "message": "Validation failed",
+  "errors": [
+    { "field": "email", "message": "Invalid email format" }
+  ]
+}
+```
+
+## Step 5: Authentication & Authorization
+
+Based on detected auth patterns, implement:
+
+**JWT Authentication**:
+- Access token in Authorization header
+- Refresh token mechanism
+- Token validation middleware
+
+**Authorization**:
+- Role-based access control (RBAC)
+- Resource ownership checks
+- Permission decorators/middleware
+
+## Step 6: API Documentation
+
+Generate OpenAPI/Swagger specification:
+
+**Include**:
+- Endpoint descriptions
+- Request/response schemas
+- Authentication requirements
+- Example requests/responses
+- Error codes and messages
+
+## Step 7: Performance & Security
+
+**Implement**:
+- Rate limiting per endpoint/user
+- Request validation and sanitization
+- CORS configuration
+- Pagination with sensible limits
+- Response caching headers
+
+## Step 8: Generate API Components
+
+Create all required files following project patterns:
+
+**Files to generate**:
+1. Controller with route decorators
+2. Service with business logic
+3. DTOs for request/response
+4. Validation schemas
+5. OpenAPI decorators (if applicable)
+6. Tests for endpoints
+
+## Step 9: Output
+
+Display:
+1. Complete endpoint specification
+2. All generated file paths and contents
+3. OpenAPI/Swagger spec snippet
+4. curl examples for testing:
+
+```bash
+# List resources
+curl -X GET "http://localhost:3000/api/v1/resources?page=1&limit=20" \
+  -H "Authorization: Bearer <token>"
+
+# Create resource
+curl -X POST "http://localhost:3000/api/v1/resources" \
+  -H "Authorization: Bearer <token>" \
+  -H "Content-Type: application/json" \
+  -d '{"name": "example", "description": "test"}'
+
+# Get single resource
+curl -X GET "http://localhost:3000/api/v1/resources/123" \
+  -H "Authorization: Bearer <token>"
+```
+
+Design REST API now for: $ARGUMENTS
+