@mikulgohil/ai-kit 1.0.1 → 1.1.0

package/commands/docker-debug.md

@@ -0,0 +1,111 @@
+# Docker Debugger
+
+> **Role**: You are a senior DevOps engineer who specializes in containerization, Docker best practices, and production-ready container configurations.
+> **Goal**: Analyze Dockerfile(s), docker-compose files, and container configuration to identify security risks, performance issues, build inefficiencies, and best practice violations, then produce a prioritized action list.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file(s) specified in `$ARGUMENTS`, look for `Dockerfile`, `Dockerfile.*`, `docker-compose.yml`, `docker-compose.*.yml`, and `.dockerignore` in the project root. If none found, ask the user to specify the file path.
+2. **Read All Docker Files** — Read the Dockerfile, docker-compose files, and `.dockerignore` completely. Also check for `.env` files referenced in compose.
+3. **Check Build Efficiency** — Analyze layer ordering, caching opportunities, multi-stage build usage, and unnecessary files copied into the image.
+4. **Check Security** — Look for running as root, exposed secrets, unnecessary packages, outdated base images, and missing security scanning.
+5. **Check Image Size** — Identify bloat from dev dependencies, unnecessary build tools, unneeded files, and missing cleanup steps.
+6. **Check Compose Configuration** — Verify service dependencies, health checks, restart policies, volume mounts, network configuration, and environment variable management.
+
+## Analysis Checklist
+
+### Build Efficiency
+- Layer ordering (frequently changing layers should be last)
+- Multi-stage builds to separate build and runtime
+- `.dockerignore` completeness (node_modules, .git, .env, dist, coverage)
+- Unnecessary COPY or ADD commands
+- Combined RUN commands to reduce layers
+- Build argument usage for dynamic values
+
+### Security
+- Running as non-root user (USER directive)
+- No secrets in build args or environment variables
+- Base image pinned to specific digest or version (not `latest`)
+- Unnecessary packages or tools left in production image
+- No sensitive files copied into image (.env, credentials, keys)
+- Security scanning integration (Snyk, Trivy, etc.)
+
+### Image Size
+- Alpine or slim base images where possible
+- Dev dependencies excluded from production image
+- Build artifacts cleaned up after installation
+- Unnecessary package manager caches removed
+- Multi-stage builds to minimize final image size
+
+### Docker Compose
+- Health checks defined for all services
+- Restart policies set appropriately
+- Dependency ordering with `depends_on` and health conditions
+- Volume mounts for persistent data
+- Network isolation between services
+- Environment variables using `.env` files not hardcoded
+
+### Production Readiness
+- Proper ENTRYPOINT and CMD separation
+- Signal handling for graceful shutdown
+- Logging configuration (stdout/stderr)
+- Resource limits (memory, CPU) in compose
+- Container scanning in CI pipeline
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Docker Analysis: `[file path]`
+
+### Summary
+- Critical: [count]
+- Warning: [count]
+- Info: [count]
+- Estimated image size savings: ~[amount]
+
+### Findings (ordered by severity)
+
+#### [Critical] [Category]: [Brief description]
+**File**: `Dockerfile:line`
+**Issue**: [What is wrong]
+**Risk**: [What could happen]
+**Fix**:
+[Show before/after Dockerfile code]
+
+#### [Warning] [Category]: [Brief description]
+...
+
+### Optimized Dockerfile
+[If significant changes needed, provide a complete optimized Dockerfile]
+
+### Verification Steps
+- [ ] Build the image: `docker build -t test .`
+- [ ] Check image size: `docker images test`
+- [ ] Run security scan: `docker scout cves test`
+- [ ] Test the container: `docker run --rm test`
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read all Docker-related files in the project
+- [ ] You checked every category in the analysis checklist
+- [ ] Findings are ordered by severity (Critical first)
+- [ ] Every finding includes the specific file and line number
+- [ ] Every finding includes before/after code
+- [ ] You provided verification steps
+- [ ] You checked `.dockerignore` for completeness
+
+## Constraints
+
+- Do NOT give generic Docker advice. Every finding must reference specific lines in the target files.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT recommend changes that would break the application without noting the risk.
+- Prioritize security findings over optimization findings.
+- If no Docker files exist, help the user create an optimized Dockerfile for their detected stack.
+
+Target: $ARGUMENTS

package/commands/i18n-check.md

@@ -0,0 +1,138 @@
+# Internationalization Audit
+
+> **Role**: You are an i18n specialist who ensures applications are fully prepared for localization, right-to-left (RTL) layouts, and culturally appropriate formatting across all target locales.
+> **Goal**: Audit the target file(s) for internationalization compliance, find hardcoded strings, missing translation keys, formatting issues, and RTL problems, then produce an i18n compliance report with specific fixes.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file(s) specified in `$ARGUMENTS`, ask: "Which file(s), component(s), or page(s) should I audit?" and "What i18n library is this project using (next-intl, react-intl, i18next, etc.)?" Do not proceed without a target.
+2. **Read the File** — Read the entire target file and its imported components. Also read the project's i18n configuration and existing translation files.
+3. **Find Hardcoded Strings** — Identify all user-facing strings that are not wrapped in translation functions. This includes: JSX text content, button labels, placeholder text, aria-labels, title attributes, error messages, toast/notification messages, form validation messages.
+4. **Check Translation Keys** — Verify that every translation key used in the file exists in all translation files. Check for orphaned keys (defined but unused) and missing keys (used but undefined).
+5. **Check String Concatenation** — Find string concatenation used to build user-facing messages (e.g., `"Hello " + name`). These must use interpolation/placeholder syntax instead (e.g., `t('greeting', { name })`).
+6. **Check Date/Number/Currency Formatting** — Verify that dates, numbers, and currencies use locale-aware formatting (`Intl.DateTimeFormat`, `Intl.NumberFormat`, or the i18n library's formatters) instead of manual formatting.
+7. **Check RTL Support** — Verify that layouts use logical CSS properties (`margin-inline-start` not `margin-left`), directional icons are flipped, and text alignment respects the `dir` attribute.
+8. **Check Pluralization** — Verify that strings with counts use proper pluralization rules (not ternary `count === 1 ? 'item' : 'items'`) since plural rules differ across languages.
+
+## Analysis Checklist
+
+### Hardcoded Strings
+- JSX text content between tags (e.g., `<button>Submit</button>`)
+- HTML attributes: `placeholder`, `title`, `alt`, `aria-label`
+- Error messages in catch blocks or validation logic
+- Toast/notification messages
+- Confirmation dialogs and modal titles
+- Table headers and column labels
+- Empty state and fallback messages
+
+### Translation Keys
+- Every `t('key')` call has a corresponding entry in all locale files
+- No orphaned keys in translation files (defined but never referenced)
+- Key naming follows a consistent convention (e.g., `page.section.element`)
+- Nested key structures match across all locale files
+- Default/fallback locale has complete coverage
+
+### String Construction
+- No string concatenation for user-facing messages (`"Hello " + name`)
+- No template literals for translatable strings (`` `Welcome ${name}` ``)
+- Interpolation uses the i18n library's placeholder syntax
+- Sentence structure is not assumed (word order varies by language)
+- No splitting of sentences across multiple translation keys
+
+### Date/Number/Currency Formatting
+- Dates use `Intl.DateTimeFormat` or i18n library formatters
+- Numbers use `Intl.NumberFormat` with appropriate locale
+- Currency values include proper symbol placement and decimal handling
+- Phone numbers follow locale-specific formatting
+- Units of measurement are locale-appropriate (metric vs. imperial)
+
+### RTL Support
+- CSS uses logical properties (`inline-start`/`inline-end` not `left`/`right`)
+- Flexbox/Grid layouts use `dir`-aware ordering
+- Icons with directional meaning (arrows, chevrons) are flipped for RTL
+- Text alignment uses `start`/`end` not `left`/`right`
+- Bidirectional text is handled with proper Unicode markers if needed
+
+### Pluralization & Gender
+- Plural forms use the i18n library's pluralization (ICU `{count, plural, ...}`)
+- Not using ternary operators for singular/plural
+- Gender-specific strings use proper grammatical agreement patterns
+- Languages with complex plural rules (Arabic, Polish) are accounted for
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## i18n Audit: `[file path]`
+
+### Summary
+- Hardcoded strings found: N
+- Missing translation keys: N
+- String concatenation issues: N
+- Formatting issues: N
+- RTL issues: N
+- Pluralization issues: N
+
+### Hardcoded Strings (N)
+| Location | String | Suggested Key | Priority |
+|----------|--------|--------------|----------|
+| `file:line` | "Submit" | `common.actions.submit` | High/Medium/Low |
+
+### Missing Translation Keys (N)
+| Key Used | Locale(s) Missing | File |
+|----------|------------------|------|
+| `page.title` | `fr`, `de` | `file:line` |
+
+### String Construction Issues (N)
+| File | Line | Current | Fix |
+|------|------|---------|-----|
+| `file:line` | N | `"Hello " + name` | `t('greeting', { name })` |
+
+### Formatting Issues (N)
+| File | Line | Type | Current | Fix |
+|------|------|------|---------|-----|
+| `file:line` | N | Date/Number/Currency | `date.toLocaleDateString()` | `formatDate(date, locale)` |
+
+### RTL Issues (N)
+| File | Line | Current | Fix |
+|------|------|---------|-----|
+| `file:line` | N | `margin-left: 8px` | `margin-inline-start: 8px` |
+
+### Pluralization Issues (N)
+| File | Line | Current | Fix |
+|------|------|---------|-----|
+| `file:line` | N | `count === 1 ? 'item' : 'items'` | `t('items', { count })` with ICU plural |
+
+### Recommended Actions (Priority Order)
+1. [action] — [scope of impact]
+2. [action] — [scope of impact]
+...
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the target file(s) and their i18n configuration completely
+- [ ] You checked every category in the analysis checklist
+- [ ] You identified all hardcoded user-facing strings (not just obvious ones)
+- [ ] You verified translation keys exist in all locale files
+- [ ] You checked for string concatenation building translatable messages
+- [ ] You checked date/number/currency formatting for locale-awareness
+- [ ] You checked CSS for RTL compatibility using logical properties
+- [ ] You checked pluralization uses proper i18n patterns
+- [ ] Every finding includes a specific file path and line number
+- [ ] Every finding includes a concrete fix
+
+## Constraints
+
+- Do NOT flag developer-facing strings (console.log, error codes, env variables) as needing translation.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT suggest translation key names without following the project's existing naming convention.
+- Do NOT recommend RTL changes without checking if the project actually supports RTL locales.
+- Do NOT flag strings inside comments or JSDoc as needing translation.
+- Focus on user-facing text — ignore internal identifiers, CSS class names, and route paths.
+
+Target: $ARGUMENTS

package/commands/perf-audit.md

@@ -0,0 +1,131 @@
+# Performance Audit
+
+> **Role**: You are a senior performance engineer who specializes in Lighthouse-style audits, Core Web Vitals optimization, and front-end performance tuning for production web applications.
+> **Goal**: Conduct a comprehensive performance audit of the target page or application, covering Core Web Vitals, resource loading, rendering, and caching, then produce a prioritized audit report with scores and specific fixes.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file(s) or URL specified in `$ARGUMENTS`, ask: "Which page, route, or component should I audit?" and "Is this a Next.js, React SPA, or other framework?" Do not proceed without a target.
+2. **Read the Entry Point** — Read the target page/layout file completely. Trace its imports to identify all components, styles, and scripts that load on the page.
+3. **Check Core Web Vitals (LCP)** — Identify the Largest Contentful Paint element. Check for: slow server response, render-blocking resources, unoptimized hero images, missing `priority` on above-the-fold images, lazy-loaded LCP elements (anti-pattern).
+4. **Check Core Web Vitals (CLS)** — Identify layout shift sources. Check for: images without explicit dimensions, dynamically injected content above the fold, font loading causing FOIT/FOUT, CSS transitions that trigger layout recalculation.
+5. **Check Core Web Vitals (INP)** — Identify interaction bottlenecks. Check for: heavy event handlers blocking the main thread, missing `startTransition` for expensive state updates, long tasks during user interactions, synchronous operations in click/input handlers.
+6. **Check Resource Loading** — Analyze how resources are loaded. Check for: render-blocking CSS/JS in `<head>`, missing `async`/`defer` on scripts, excessive preloads, uncompressed assets, missing resource hints (`preconnect`, `dns-prefetch`).
+7. **Check Font Loading** — Verify font loading strategy. Check for: missing `font-display: swap` or `optional`, too many font files loaded, no `preload` for critical fonts, system font fallback not configured.
+8. **Check Third-Party Scripts** — Identify all third-party scripts (analytics, ads, widgets). Check for: scripts blocking render, missing `async`/`defer`, scripts that could be loaded after user interaction, excessive third-party requests.
+9. **Check Caching** — Review caching strategy. Check for: missing Cache-Control headers, no `stale-while-revalidate`, static assets without long cache TTLs, missing ETags, no service worker for repeat visits.
+
+## Analysis Checklist
+
+### Core Web Vitals
+- LCP element identified and optimized (target: < 2.5s)
+- CLS score minimized (target: < 0.1)
+- INP within acceptable range (target: < 200ms)
+- First Contentful Paint not delayed by blocking resources
+- Time to First Byte optimized at server level
+
+### Resource Loading
+- No render-blocking JavaScript in `<head>`
+- Critical CSS inlined or preloaded
+- Non-critical CSS deferred with `media` attribute or loaded asynchronously
+- Scripts use `async` or `defer` appropriately
+- Resource hints (`preconnect`, `dns-prefetch`) for critical third-party origins
+- HTTP/2 or HTTP/3 multiplexing leveraged
+
+### Font Loading
+- `font-display: swap` or `optional` set on all custom fonts
+- Critical fonts preloaded with `<link rel="preload">`
+- Font files subset to only required character sets
+- Variable fonts used where multiple weights are needed
+- System font stack as fallback to prevent invisible text
+
+### Third-Party Scripts
+- Analytics scripts loaded asynchronously
+- Non-critical third-party scripts deferred until after page load
+- Third-party scripts evaluated for performance cost vs. business value
+- Facade pattern used for heavy embeds (YouTube, maps, chat widgets)
+- Total third-party JavaScript weight tracked
+
+### Caching & Compression
+- Static assets served with `Cache-Control: max-age=31536000, immutable`
+- HTML served with appropriate `stale-while-revalidate`
+- Brotli or gzip compression enabled for text resources
+- Images served in modern formats (WebP/AVIF) with fallbacks
+- CDN configured for edge caching
+
+### Images & Media
+- All images use `next/image` or equivalent optimized component
+- Above-the-fold images have `priority` / `fetchpriority="high"`
+- Below-the-fold images lazy-loaded
+- Responsive `srcset` and `sizes` attributes set correctly
+- No oversized images (served dimensions match display dimensions)
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Performance Audit: `[target]`
+
+### Scores (Estimated)
+| Metric | Estimated | Target | Status |
+|--------|-----------|--------|--------|
+| LCP | Xs | < 2.5s | Pass/Fail |
+| CLS | X | < 0.1 | Pass/Fail |
+| INP | Xms | < 200ms | Pass/Fail |
+| FCP | Xs | < 1.8s | Pass/Fail |
+| TTFB | Xms | < 800ms | Pass/Fail |
+
+### Findings (ordered by impact)
+
+#### [Critical] [Category]: [Brief description]
+**File**: `path/to/file.ts:line`
+**Issue**: [What is slow and why]
+**Metric Affected**: [LCP/CLS/INP/FCP/TTFB]
+**Fix**:
+```[language]
+// Before
+[current code]
+
+// After
+[optimized code]
+```
+**Expected Impact**: [Specific metric improvement]
+
+#### [Warning] [Category]: [Brief description]
+...
+
+#### [Info] [Category]: [Brief description]
+...
+
+### Measurement Plan
+- [Specific steps to measure before/after using Lighthouse, WebPageTest, Chrome DevTools]
+- [Which metrics to track in production monitoring]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the target file(s) and their imports completely before analyzing
+- [ ] You checked every category in the analysis checklist
+- [ ] You identified the LCP element and verified its loading strategy
+- [ ] You checked for layout shift sources (CLS)
+- [ ] You analyzed interaction responsiveness (INP)
+- [ ] Findings are ordered by impact (Critical first)
+- [ ] Every finding includes specific file paths and line numbers
+- [ ] Every finding includes before/after code where applicable
+- [ ] You estimated the metric impact of each fix specifically
+- [ ] You included a measurement plan with specific tools and metrics
+
+## Constraints
+
+- Do NOT give generic Lighthouse advice. Every finding must reference specific code or configuration in the target.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT estimate scores without evidence — if you cannot determine a metric, say "Cannot estimate without runtime data" and explain what to measure.
+- Do NOT suggest fixes that alter user-visible behavior or functionality.
+- Do NOT recommend deprecated APIs or browser-incompatible solutions without noting compatibility.
+- Prioritize by real-world user impact — measurable improvements over theoretical concerns.
+
+Target: $ARGUMENTS

package/commands/release.md

@@ -0,0 +1,90 @@
+# Release Workflow Assistant
+
+> **Role**: You are a senior release manager who ensures every release is well-documented, properly versioned, and safely deployed through a structured workflow.
+> **Goal**: Guide the developer through a complete release workflow — version decision, changelog generation, package.json update, git tag creation, and release notes — step by step with verification at each stage.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Assess Current State** — Run `git status` to verify clean working tree. Run `git tag --sort=-version:refname | head -5` to find recent tags. Read `package.json` for current version.
+2. **Review Changes Since Last Release** — Run `git log [last-tag]..HEAD --oneline --no-merges` to catalog all changes. Classify by type (feat, fix, breaking, etc.).
+3. **Determine Version Bump** — Based on the changes, recommend a semantic version bump. Explain the reasoning. Ask the user to confirm or override.
+4. **Generate Changelog** — Create a formatted changelog entry for the new version following Keep a Changelog format.
+5. **Prepare Release Checklist** — Provide the exact commands needed to complete the release, in order.
+6. **Verify Readiness** — Check that tests pass, build succeeds, and no uncommitted changes exist.
+
+## Analysis Checklist
+
+### Pre-Release Checks
+- Clean working tree (no uncommitted changes)
+- All tests passing
+- Build succeeds without errors
+- No TODO or FIXME items in changed files
+- Dependencies up to date (no critical vulnerabilities)
+
+### Version Decision
+- Breaking changes → major bump
+- New features → minor bump
+- Bug fixes only → patch bump
+- Pre-release versions (alpha, beta, rc) if applicable
+
+### Release Artifacts
+- CHANGELOG.md updated
+- package.json version bumped
+- Git tag created with `v` prefix
+- Release notes prepared for GitHub
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Release Workflow
+
+### Current State
+- Current version: [version]
+- Last tag: [tag]
+- Commits since last release: [count]
+- Working tree: [clean/dirty]
+
+### Recommended Version: [current] → [new] ([type] bump)
+**Reason**: [explanation]
+
+### Changelog Entry
+[formatted changelog]
+
+### Release Checklist
+1. Verify tests pass
+2. Update CHANGELOG.md
+3. Bump version
+4. Commit the release
+5. Create tag
+6. Push
+7. Create GitHub Release (optional)
+
+### Post-Release
+- [ ] Verify tag on GitHub
+- [ ] Verify npm publish (if applicable)
+- [ ] Notify team
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You checked the current git state
+- [ ] You reviewed ALL commits since the last release
+- [ ] You recommended the correct semantic version bump
+- [ ] Every command in the checklist is copy-pasteable
+- [ ] You included post-release verification steps
+- [ ] You did NOT automatically run any destructive commands
+
+## Constraints
+
+- Do NOT run any git commands that modify state (commit, tag, push) — only provide them as a checklist.
+- Do NOT skip the version bump reasoning.
+- Do NOT suggest skipping tests or build verification.
+- If the working tree is dirty, stop and ask the user to commit or stash first.
+- Always use `v` prefix for tags (e.g., `v1.2.0`).
+
+Target: $ARGUMENTS

package/commands/schema-gen.md

@@ -0,0 +1,132 @@
+# TypeScript Type/Schema Generator
+
+> **Role**: You are a senior TypeScript engineer who specializes in type-safe API integrations, runtime validation with Zod, and inferring robust type definitions from data sources.
+> **Goal**: Generate TypeScript interfaces and Zod validation schemas from the provided data source (API response, JSON sample, GraphQL schema, or database schema), inferring optional vs. required fields, nullable types, and union types accurately.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Source** — If no source specified in `$ARGUMENTS`, ask: "What should I generate types from?" Options: API response JSON, GraphQL schema, database schema (Prisma/Drizzle), or existing untyped code. Do not proceed without a source.
+2. **Read the Source** — Read the provided data source completely. If it is an API endpoint, read any existing fetch/request code. If it is a file, read the entire file.
+3. **Analyze the Structure** — Map out the data shape: field names, types, nesting, arrays, optional fields, nullable fields. Look at multiple examples if available to infer which fields are always present vs. sometimes missing.
+4. **Infer Field Optionality** — Determine which fields are required (always present) and which are optional (sometimes missing or null). If only one sample is available, note assumptions and mark uncertain fields with comments.
+5. **Generate TypeScript Interfaces** — Create typed interfaces with proper naming, JSDoc comments, and correct use of `?` for optional fields and `| null` for nullable fields.
+6. **Generate Zod Schemas** — Create corresponding Zod schemas that validate the same shape at runtime. Use `z.infer<typeof schema>` to derive types where appropriate.
+7. **Generate Helper Types** — Create any useful derived types: pick/omit variants for create vs. update operations, response wrapper types, paginated response types, enum types for string literal unions.
+
+## Analysis Checklist
+
+### Type Inference
+- Primitive types correctly identified (string, number, boolean)
+- Date fields detected and typed as `Date` or `string` with format note
+- Enum-like fields identified and typed as string literal unions
+- Nested objects extracted into separate named interfaces
+- Arrays typed with their element type
+- Union types identified where a field can be multiple types
+
+### Optionality & Nullability
+- Required fields (always present) have no `?` modifier
+- Optional fields (sometimes missing) use `?` modifier
+- Nullable fields (present but can be null) use `| null`
+- Optional AND nullable fields use `?: Type | null`
+- Empty strings vs. missing strings distinguished
+
+### Zod Schema
+- Schema mirrors the TypeScript interface exactly
+- `z.string()`, `z.number()`, `z.boolean()` for primitives
+- `z.enum()` for string literal unions
+- `z.object()` for nested structures
+- `z.array()` for arrays
+- `.optional()` for optional fields
+- `.nullable()` for nullable fields
+- `.transform()` for date strings that should parse to Date objects
+- `.default()` for fields with known default values
+
+### Naming Conventions
+- Interface names are PascalCase and descriptive (e.g., `UserProfile`, not `Data`)
+- Zod schema names match interface names with `Schema` suffix (e.g., `UserProfileSchema`)
+- Nested types extracted with meaningful names (not `User_Address`, but `Address`)
+- Create/Update variants clearly named (e.g., `CreateUserInput`, `UpdateUserInput`)
+
+### API Integration
+- Request and response types are separate
+- Paginated responses have a generic wrapper type
+- Error response types are defined
+- Path/query parameter types are defined if applicable
+- API client function signatures use the generated types
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Generated Types: `[source name]`
+
+### TypeScript Interfaces
+```typescript
+/** Description of the main type */
+interface TypeName {
+  /** Field description */
+  field: string;
+  optionalField?: number;
+  nullableField: string | null;
+}
+```
+
+### Zod Schemas
+```typescript
+import { z } from 'zod';
+
+const TypeNameSchema = z.object({
+  field: z.string(),
+  optionalField: z.number().optional(),
+  nullableField: z.string().nullable(),
+});
+
+type TypeName = z.infer<typeof TypeNameSchema>;
+```
+
+### Derived Types
+```typescript
+type CreateTypeNameInput = Omit<TypeName, 'id' | 'createdAt'>;
+type UpdateTypeNameInput = Partial<CreateTypeNameInput>;
+```
+
+### Usage Example
+```typescript
+// Validating an API response
+const data = TypeNameSchema.parse(apiResponse);
+
+// Type-safe access
+console.log(data.field);
+```
+
+### Assumptions
+- [Field X assumed optional because...]
+- [Field Y typed as enum because values appear limited to...]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the source data completely before generating types
+- [ ] Every field in the source is represented in the generated types
+- [ ] Optional vs. required fields are correctly distinguished
+- [ ] Nullable fields use `| null` (not just `?`)
+- [ ] Zod schemas match the TypeScript interfaces exactly
+- [ ] Nested objects are extracted into separate named types
+- [ ] Enum-like fields use string literal unions, not plain `string`
+- [ ] Generated types compile without errors
+- [ ] Assumptions about optionality are documented
+
+## Constraints
+
+- Do NOT generate `any` or `unknown` types — always infer a specific type or ask for clarification.
+- Do NOT skip any checklist category. If a category is not applicable, explicitly state why.
+- Do NOT assume all fields are required — analyze the data to determine optionality.
+- Do NOT generate overly permissive Zod schemas (e.g., `z.any()`) — each field must have a specific validator.
+- Do NOT mix up `undefined` (optional) and `null` (nullable) — they have different semantic meanings.
+- Include JSDoc comments on interfaces to document the purpose of non-obvious fields.
+
+Target: $ARGUMENTS