@iamnishankhan/opencode-kit-grok 1.0.0

package/kit/.opencode/skills/database-design/scripts/schema_validator.py

@@ -0,0 +1,172 @@
+#!/usr/bin/env python3
+"""
+Schema Validator - Database schema validation
+Validates Prisma schemas and checks for common issues.
+
+Usage:
+    python schema_validator.py <project_path>
+
+Checks:
+    - Prisma schema syntax
+    - Missing relations
+    - Index recommendations
+    - Naming conventions
+"""
+
+import sys
+import json
+import re
+from pathlib import Path
+from datetime import datetime
+
+# Fix Windows console encoding
+try:
+    sys.stdout.reconfigure(encoding='utf-8', errors='replace')
+except:
+    pass
+
+
+def find_schema_files(project_path: Path) -> list:
+    """Find database schema files."""
+    schemas = []
+    
+    # Prisma schema
+    prisma_files = list(project_path.glob('**/prisma/schema.prisma'))
+    schemas.extend([('prisma', f) for f in prisma_files])
+    
+    # Drizzle schema files
+    drizzle_files = list(project_path.glob('**/drizzle/*.ts'))
+    drizzle_files.extend(project_path.glob('**/schema/*.ts'))
+    for f in drizzle_files:
+        if 'schema' in f.name.lower() or 'table' in f.name.lower():
+            schemas.append(('drizzle', f))
+    
+    return schemas[:10]  # Limit
+
+
+def validate_prisma_schema(file_path: Path) -> list:
+    """Validate Prisma schema file."""
+    issues = []
+    
+    try:
+        content = file_path.read_text(encoding='utf-8', errors='ignore')
+        
+        # Find all models
+        models = re.findall(r'model\s+(\w+)\s*{([^}]+)}', content, re.DOTALL)
+        
+        for model_name, model_body in models:
+            # Check naming convention (PascalCase)
+            if not model_name[0].isupper():
+                issues.append(f"Model '{model_name}' should be PascalCase")
+            
+            # Check for id field
+            if '@id' not in model_body and 'id' not in model_body.lower():
+                issues.append(f"Model '{model_name}' might be missing @id field")
+            
+            # Check for createdAt/updatedAt
+            if 'createdAt' not in model_body and 'created_at' not in model_body:
+                issues.append(f"Model '{model_name}' missing createdAt field (recommended)")
+            
+            # Check for @relation without fields
+            relations = re.findall(r'@relation\([^)]*\)', model_body)
+            for rel in relations:
+                if 'fields:' not in rel and 'references:' not in rel:
+                    pass  # Implicit relation, ok
+            
+            # Check for @@index suggestions
+            foreign_keys = re.findall(r'(\w+Id)\s+\w+', model_body)
+            for fk in foreign_keys:
+                if f'@@index([{fk}])' not in content and f'@@index(["{fk}"])' not in content:
+                    issues.append(f"Consider adding @@index([{fk}]) for better query performance in {model_name}")
+        
+        # Check for enum definitions
+        enums = re.findall(r'enum\s+(\w+)\s*{', content)
+        for enum_name in enums:
+            if not enum_name[0].isupper():
+                issues.append(f"Enum '{enum_name}' should be PascalCase")
+        
+    except Exception as e:
+        issues.append(f"Error reading schema: {str(e)[:50]}")
+    
+    return issues
+
+
+def main():
+    project_path = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
+    
+    print(f"\n{'='*60}")
+    print(f"[SCHEMA VALIDATOR] Database Schema Validation")
+    print(f"{'='*60}")
+    print(f"Project: {project_path}")
+    print(f"Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
+    print("-"*60)
+    
+    # Find schema files
+    schemas = find_schema_files(project_path)
+    print(f"Found {len(schemas)} schema files")
+    
+    if not schemas:
+        output = {
+            "script": "schema_validator",
+            "project": str(project_path),
+            "schemas_checked": 0,
+            "issues_found": 0,
+            "passed": True,
+            "message": "No schema files found"
+        }
+        print(json.dumps(output, indent=2))
+        sys.exit(0)
+    
+    # Validate each schema
+    all_issues = []
+    
+    for schema_type, file_path in schemas:
+        print(f"\nValidating: {file_path.name} ({schema_type})")
+        
+        if schema_type == 'prisma':
+            issues = validate_prisma_schema(file_path)
+        else:
+            issues = []  # Drizzle validation could be added
+        
+        if issues:
+            all_issues.append({
+                "file": str(file_path.name),
+                "type": schema_type,
+                "issues": issues
+            })
+    
+    # Summary
+    print("\n" + "="*60)
+    print("SCHEMA ISSUES")
+    print("="*60)
+    
+    if all_issues:
+        for item in all_issues:
+            print(f"\n{item['file']} ({item['type']}):")
+            for issue in item["issues"][:5]:  # Limit per file
+                print(f"  - {issue}")
+            if len(item["issues"]) > 5:
+                print(f"  ... and {len(item['issues']) - 5} more issues")
+    else:
+        print("No schema issues found!")
+    
+    total_issues = sum(len(item["issues"]) for item in all_issues)
+    # Schema issues are warnings, not failures
+    passed = True
+    
+    output = {
+        "script": "schema_validator",
+        "project": str(project_path),
+        "schemas_checked": len(schemas),
+        "issues_found": total_issues,
+        "passed": passed,
+        "issues": all_issues
+    }
+    
+    print("\n" + json.dumps(output, indent=2))
+    
+    sys.exit(0)
+
+
+if __name__ == "__main__":
+    main()

package/kit/.opencode/skills/deployment-procedures/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: deployment-procedures
+description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
+compatibility: opencode
+metadata:
+  when_to_use: "\"When deploying to production, planning rollback strategies, or setting up CI/CD pipelines. Use with /deploy workflow.\""
+  version: "1.0.0"
+---
+# Deployment Procedures
+
+> Deployment principles and decision-making for safe production releases.
+> **Learn to THINK, not memorize scripts.**
+
+---
+
+## ⚠️ How to Use This Skill
+
+This skill teaches **deployment principles**, not bash scripts to copy.
+
+- Every deployment is unique
+- Understand the WHY behind each step
+- Adapt procedures to your platform
+
+---
+
+## 1. Platform Selection
+
+### Decision Tree
+
+```
+What are you deploying?
+│
+├── Static site / JAMstack
+│   └── Vercel, Netlify, Cloudflare Pages
+│
+├── Simple web app
+│   ├── Managed → Railway, Render, Fly.io
+│   └── Control → VPS + PM2/Docker
+│
+├── Microservices
+│   └── Container orchestration
+│
+└── Serverless
+    └── Edge functions, Lambda
+```
+
+### Each Platform Has Different Procedures
+
+| Platform | Deployment Method |
+|----------|------------------|
+| **Vercel/Netlify** | Git push, auto-deploy |
+| **Railway/Render** | Git push or CLI |
+| **VPS + PM2** | SSH + manual steps |
+| **Docker** | Image push + orchestration |
+| **Kubernetes** | kubectl apply |
+
+---
+
+## 2. Pre-Deployment Principles
+
+### The 4 Verification Categories
+
+| Category | What to Check |
+|----------|--------------|
+| **Code Quality** | Tests passing, linting clean, reviewed |
+| **Build** | Production build works, no warnings |
+| **Environment** | Env vars set, secrets current |
+| **Safety** | Backup done, rollback plan ready |
+
+### Pre-Deployment Checklist
+
+- [ ] All tests passing
+- [ ] Code reviewed and approved
+- [ ] Production build successful
+- [ ] Environment variables verified
+- [ ] Database migrations ready (if any)
+- [ ] Rollback plan documented
+- [ ] Team notified
+- [ ] Monitoring ready
+
+---
+
+## 3. Deployment Workflow Principles
+
+### The 5-Phase Process
+
+```
+1. PREPARE
+   └── Verify code, build, env vars
+
+2. BACKUP
+   └── Save current state before changing
+
+3. DEPLOY
+   └── Execute with monitoring open
+
+4. VERIFY
+   └── Health check, logs, key flows
+
+5. CONFIRM or ROLLBACK
+   └── All good? Confirm. Issues? Rollback.
+```
+
+### Phase Principles
+
+| Phase | Principle |
+|-------|-----------|
+| **Prepare** | Never deploy untested code |
+| **Backup** | Can't rollback without backup |
+| **Deploy** | Watch it happen, don't walk away |
+| **Verify** | Trust but verify |
+| **Confirm** | Have rollback trigger ready |
+
+---
+
+## 4. Post-Deployment Verification
+
+### What to Verify
+
+| Check | Why |
+|-------|-----|
+| **Health endpoint** | Service is running |
+| **Error logs** | No new errors |
+| **Key user flows** | Critical features work |
+| **Performance** | Response times acceptable |
+
+### Verification Window
+
+- **First 5 minutes**: Active monitoring
+- **15 minutes**: Confirm stable
+- **1 hour**: Final verification
+- **Next day**: Review metrics
+
+---
+
+## 5. Rollback Principles
+
+### When to Rollback
+
+| Symptom | Action |
+|---------|--------|
+| Service down | Rollback immediately |
+| Critical errors | Rollback |
+| Performance >50% degraded | Consider rollback |
+| Minor issues | Fix forward if quick |
+
+### Rollback Strategy by Platform
+
+| Platform | Rollback Method |
+|----------|----------------|
+| **Vercel/Netlify** | Redeploy previous commit |
+| **Railway/Render** | Rollback in dashboard |
+| **VPS + PM2** | Restore backup, restart |
+| **Docker** | Previous image tag |
+| **K8s** | kubectl rollout undo |
+
+### Rollback Principles
+
+1. **Speed over perfection**: Rollback first, debug later
+2. **Don't compound errors**: One rollback, not multiple changes
+3. **Communicate**: Tell team what happened
+4. **Post-mortem**: Understand why after stable
+
+---
+
+## 6. Zero-Downtime Deployment
+
+### Strategies
+
+| Strategy | How It Works |
+|----------|--------------|
+| **Rolling** | Replace instances one by one |
+| **Blue-Green** | Switch traffic between environments |
+| **Canary** | Gradual traffic shift |
+
+### Selection Principles
+
+| Scenario | Strategy |
+|----------|----------|
+| Standard release | Rolling |
+| High-risk change | Blue-green (easy rollback) |
+| Need validation | Canary (test with real traffic) |
+
+---
+
+## 7. Emergency Procedures
+
+### Service Down Priority
+
+1. **Assess**: What's the symptom?
+2. **Quick fix**: Restart if unclear
+3. **Rollback**: If restart doesn't help
+4. **Investigate**: After stable
+
+### Investigation Order
+
+| Check | Common Issues |
+|-------|--------------|
+| **Logs** | Errors, exceptions |
+| **Resources** | Disk full, memory |
+| **Network** | DNS, firewall |
+| **Dependencies** | Database, APIs |
+
+---
+
+## 8. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Deploy on Friday | Deploy early in week |
+| Rush deployment | Follow the process |
+| Skip staging | Always test first |
+| Deploy without backup | Backup before deploy |
+| Walk away after deploy | Monitor for 15+ min |
+| Multiple changes at once | One change at a time |
+
+---
+
+## 9. Decision Checklist
+
+Before deploying:
+
+- [ ] **Platform-appropriate procedure?**
+- [ ] **Backup strategy ready?**
+- [ ] **Rollback plan documented?**
+- [ ] **Monitoring configured?**
+- [ ] **Team notified?**
+- [ ] **Time to monitor after?**
+
+---
+
+## 10. Best Practices
+
+1. **Small, frequent deploys** over big releases
+2. **Feature flags** for risky changes
+3. **Automate** repetitive steps
+4. **Document** every deployment
+5. **Review** what went wrong after issues
+6. **Test rollback** before you need it
+
+---
+
+> **Remember:** Every deployment is a risk. Minimize risk through preparation, not speed.

package/kit/.opencode/skills/design-spec/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: design-spec
+description: How to author a DESIGN.md file — the machine-readable design-token + human-rationale format that must exist before any UI is built. YAML front-matter token schema (colors, typography, spacing, rounded, components), type system, token references, and canonical section order.
+compatibility: opencode
+metadata:
+  when_to_use: "\"BEFORE writing any UI code (web or mobile). Read when creating or updating a project's DESIGN.md, defining design tokens, or when a UI task needs a design source-of-truth. Pair with frontend-design ("
+  version: "1.0.0"
+---
+# DESIGN.md Specification
+
+> A DESIGN.md is the **single source of truth** for a project's visual language. Create it BEFORE building UI.
+> Two layers: machine-readable **design tokens** (YAML front matter) + human-readable **rationale** (markdown body).
+> Tokens are normative; prose gives context. Prose may use descriptive names ("Midnight Forest Green") that map to systematic token names (`primary`).
+>
+> _Format adapted from the [DESIGN.md spec](https://github.com/google-labs-code/design.md) (Google Labs, Apache-2.0). A linter/exporter exists: `npx @google/design.md`._
+>
+> 📚 **Reference library:** [collection.md](collection.md) — 70+ real-world DESIGN.md files (Airbnb, Stripe, Linear, Vercel, Apple…) to study or adapt as a starting point.
+
+---
+
+## When to produce a DESIGN.md
+
+This is a **hard gate** for UI work (see `.opencode/rules/design-rules.md`): before writing components, pages, or styles, a `DESIGN.md` must exist at the project root. If absent, create it first from the brief; if present, read it and conform.
+
+The token block converts cleanly to/from `tokens.json`, Figma variables, and Tailwind theme config — so it is the bridge between design intent and code.
+
+---
+
+## 1. File structure
+
+```
+---
+<YAML token front matter>
+---
+
+# Project Name (optional title)
+
+## Overview
+## Colors
+## Typography
+## Layout
+## Elevation & Depth
+## Shapes
+## Components
+## Do's and Don'ts
+```
+
+Front matter MUST begin and end with a line containing exactly `---`. Sections use `##` headings, appear in the order above, and may be omitted if irrelevant. Domain-specific sections may be added.
+
+---
+
+## 2. Token schema (YAML front matter)
+
+```yaml
+version: alpha            # optional
+name: Daylight Prestige
+description: ...          # optional
+colors:
+  <token-name>: "#RRGGBB"
+typography:
+  <token-name>:
+    fontFamily: Public Sans
+    fontSize: 48px
+    fontWeight: 600
+    lineHeight: 1.1
+    letterSpacing: -0.02em
+rounded:
+  <scale>: 8px
+spacing:
+  <scale>: 16px           # Dimension or unitless number
+components:
+  <component-name>:
+    backgroundColor: "{colors.primary}"
+    rounded: "{rounded.md}"
+    padding: 12px
+```
+
+`<scale>` is a named level: `xs sm md lg xl full` (any descriptive key is valid).
+
+---
+
+## 3. Type system
+
+| Type | Format | Example |
+|------|--------|---------|
+| Color | `#` + hex (sRGB) | `"#1A1C1E"` |
+| Dimension | number + unit (`px`/`em`/`rem`) | `48px`, `-0.02em` |
+| Token Reference | `{path.to.token}` | `{colors.primary}` |
+| Typography | composite object | see §4 |
+
+**Typography properties:** `fontFamily` (string), `fontSize` (Dimension), `fontWeight` (number — bare or quoted are equivalent in YAML), `lineHeight` (Dimension or unitless multiplier — unitless recommended), `letterSpacing` (Dimension), `fontFeature` (string), `fontVariation` (string).
+
+**Token references:** wrapped in `{}` pointing to another value in the tree. Most groups must reference a **primitive** (`{colors.primary-60}`), not a group. Inside `components`, references to **composite** values are allowed (`{typography.label-md}`).
+
+**Component property tokens:** `backgroundColor`, `textColor` (Color); `typography` (Typography); `rounded`, `padding`, `size`, `height`, `width` (Dimension).
+
+**Variants:** define UI states as separate entries with a related key — `button-primary`, `button-primary-hover`.
+
+---
+
+## 4. Sections (canonical order)
+
+| # | Section | Aliases | Purpose |
+|---|---------|---------|---------|
+| 1 | Overview | Brand & Style | Brand personality, audience, emotional tone. Fallback context when a token isn't defined. |
+| 2 | Colors | | Palettes; at least `primary`. Common: primary/secondary/tertiary/neutral. |
+| 3 | Typography | | 9–15 levels, each a semantic role (headline/body/label) × size. |
+| 4 | Layout | Layout & Spacing | Grid model, spacing scale, containment. |
+| 5 | Elevation & Depth | Elevation | Shadows, OR for flat designs the alternative (borders, tonal layers, contrast). |
+| 6 | Shapes | | Corner radii, edge treatment, shape language. |
+| 7 | Components | | Per-atom guidance: Buttons, Inputs, Cards, Chips, Lists, etc. |
+| 8 | Do's and Don'ts | | Guardrails during generation. |
+
+---
+
+## 5. Recommended token names (guidance, not required)
+
+- **Colors:** `primary secondary tertiary neutral surface on-surface error`
+- **Typography:** `headline-display headline-lg headline-md body-lg body-md body-sm label-lg label-md label-sm`
+- **Rounded:** `none sm md lg xl full`
+
+---
+
+## 6. Consumer behavior for unknown content
+
+The spec is extensible. When encountering content it doesn't define:
+
+| Scenario | Behavior |
+|----------|----------|
+| Unknown section heading (`## Iconography`) | Preserve; do not error |
+| Unknown color token name | Accept if value is valid |
+| Unknown typography token name | Accept as valid typography |
+| Unknown spacing value | Accept; store as string if not a valid dimension |
+| Unknown component property | Accept with warning |
+| **Duplicate section heading** (two `## Colors`) | **Error; reject the file** |
+
+---
+
+## 7. Minimal example
+
+```markdown
+---
+name: Calm Scheduler
+colors:
+  primary: "#1A1C1E"
+  tertiary: "#B8422E"
+  neutral: "#F7F5F2"
+typography:
+  h1: { fontFamily: Public Sans, fontSize: 48px, fontWeight: 600, lineHeight: 1.1 }
+  body-md: { fontFamily: Public Sans, fontSize: 16px, fontWeight: 400, lineHeight: 1.6 }
+rounded: { sm: 4px, md: 8px }
+spacing: { sm: 8px, md: 16px, lg: 32px }
+components:
+  button-primary:
+    backgroundColor: "{colors.tertiary}"
+    rounded: "{rounded.md}"
+    padding: 12px
+---
+
+# Calm Scheduler
+
+## Overview
+A calm, professional interface for a healthcare scheduling platform.
+Accessibility-first: high contrast, generous touch targets.
+
+## Colors
+- **Primary (#1A1C1E):** Deep ink for headlines and core text.
+- **Tertiary (#B8422E):** The sole driver for interaction.
+- **Neutral (#F7F5F2):** Warm limestone foundation.
+
+## Do's and Don'ts
+- Do use the tertiary color only for the single most important action per screen.
+- Don't mix rounded and sharp corners in the same view.
+- Do maintain WCAG AA contrast (4.5:1 for normal text).
+```
+
+---
+
+## Workflow
+
+1. Read the brief and infer the design direction (see `frontend-design` / `mobile-design`).
+2. **ALWAYS read [collection.md](collection.md) first** — 70+ real-world DESIGN.md files. Find the 1–2 closest in vibe/industry to the brief, open their `DESIGN.md` on GitHub, and study how they structure tokens. Adapt, never blindly copy.
+3. **Write `DESIGN.md` at the project root** — tokens first, then rationale prose.
+4. Build UI strictly against the tokens. Descriptive names in prose must map to token names.
+5. Keep DESIGN.md in sync when the visual language changes — it stays the source of truth.