@iamnishankhan/opencode-kit-grok 1.0.0

package/kit/.opencode/skills/simplify-code/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: simplify-code
+description: Reduce complexity of over-engineered code. Identify unnecessary abstractions, remove dead code, flatten deep nesting, and simplify logic while preserving behavior.
+compatibility: opencode
+metadata:
+  when_to_use: "\"When code is over-engineered, overly abstract, deeply nested, or more complex than needed. When user asks to 'simplify', 'clean up', 'reduce complexity', or 'make this simpler'. NOT for adding new fe"
+  version: "1.0.0"
+---
+# Simplify Code — Reduce Unnecessary Complexity
+
+> The best code is the code you don't have to write. The second best is the code anyone can read.
+
+## Core Principle
+
+```
+Complexity is a cost. Every abstraction, every indirection, every clever pattern
+adds cognitive load. Simplify ruthlessly unless complexity serves a clear purpose.
+```
+
+---
+
+## Simplification Checklist
+
+### 1. Unnecessary Abstractions
+| Smell | Simplification |
+|---|---|
+| Wrapper class that just delegates | Remove wrapper, use the inner class directly |
+| Factory that creates only one type | Replace with direct constructor |
+| Strategy pattern with one strategy | Replace with simple function |
+| Interface with one implementation | Remove interface, use the class |
+| Abstract class with one child | Merge into the child class |
+| Config object for 2 values | Use function parameters |
+
+### 2. Dead Code
+| Smell | Action |
+|---|---|
+| Unused imports | Remove |
+| Unreachable branches | Remove (check tests first) |
+| Commented-out code | Remove (it's in git history) |
+| Unused variables/functions | Remove |
+| TODO comments older than 6 months | Remove or create issue |
+| Feature flags for launched features | Remove flag, keep the code |
+
+### 3. Deep Nesting
+```javascript
+// ❌ Before: 4 levels deep
+function process(data) {
+  if (data) {
+    if (data.items) {
+      for (const item of data.items) {
+        if (item.active) {
+          doSomething(item)
+        }
+      }
+    }
+  }
+}
+
+// ✅ After: Early returns + filter
+function process(data) {
+  if (!data?.items) return
+
+  data.items
+    .filter(item => item.active)
+    .forEach(doSomething)
+}
+```
+
+### 4. Over-Parameterized Functions
+```typescript
+// ❌ Before: 8 parameters
+function createUser(name, email, age, role, dept, active, verified, avatar) { }
+
+// ✅ After: Object parameter
+function createUser(opts: CreateUserOpts) { }
+```
+
+### 5. Premature Optimization
+| Smell | Simplification |
+|---|---|
+| Custom cache for <100 items | Remove cache, measure first |
+| Memoization on cheap functions | Remove memo |
+| Lazy loading for small modules | Use direct import |
+| Complex state machine for 3 states | Use simple if/else or switch |
+
+---
+
+## Simplification Protocol
+
+### Step 1: Identify Complexity
+```
+- Count nesting levels (target: ≤3)
+- Count function parameters (target: ≤4)
+- Count lines per function (target: ≤30)
+- Count abstractions per feature (target: ≤2)
+- Check for dead code (target: 0)
+```
+
+### Step 2: Verify Understanding
+Before simplifying, ensure you understand:
+- What the code does (not what it looks like it does)
+- Why it was written this way (maybe there's a reason)
+- What tests cover it (simplification must not break tests)
+
+### Step 3: Simplify Incrementally
+```
+1. Remove dead code first (safest)
+2. Flatten nesting with early returns
+3. Inline trivial abstractions
+4. Merge related functions
+5. Simplify data structures
+```
+
+### Step 4: Verify Behavior Preserved
+```bash
+npm run test    # All existing tests still pass
+npm run build   # Still compiles
+```
+
+---
+
+## When NOT to Simplify
+
+| Situation | Why Keep Complexity |
+|---|---|
+| Performance-critical hot path | Optimization may look complex but is necessary |
+| Required by framework/library | External constraints |
+| Explicitly requested pattern | User chose this architecture |
+| Will need extension soon | Abstraction prepares for known growth |
+
+> **Ask first:** "This pattern seems over-engineered. Should I simplify it, or is there a reason for the abstraction?"

package/kit/.opencode/skills/skillify/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: skillify
+description: Auto-create new skills from repetitive workflows. When you notice yourself doing the same multi-step process repeatedly, extract it into a reusable SKILL.md that any agent can use.
+compatibility: opencode
+metadata:
+  when_to_use: "\"When the user says 'make this a skill', 'create a skill for this', 'I keep doing this same thing', or when a repetitive multi-step pattern is observed. NOT for one-off tasks.\""
+  version: "1.0.0"
+---
+# Skillify — Auto-Create Skills from Workflows
+
+> Turn repetitive patterns into reusable skills. If you've done it three times, it should be a skill.
+
+## When to Skillify
+
+✅ **Good candidates:**
+- You've seen the user ask for the same type of work 3+ times
+- A workflow involves 5+ consistent steps
+- The pattern works across different projects
+- Other agents could benefit from this knowledge
+
+❌ **Bad candidates:**
+- One-off tasks (just do them)
+- Project-specific hacks (use memory instead)
+- Already covered by existing skills (check first)
+
+---
+
+## Skill Creation Protocol
+
+### Step 1: Identify the Pattern
+```
+What triggers this workflow? (user says X, file type Y, domain Z)
+What steps are always the same?
+What parts vary between uses?
+What's the expected output?
+```
+
+### Step 2: Generate SKILL.md
+
+Use this template:
+
+```markdown
+---
+name: [kebab-case-name]
+description: [One sentence describing what this skill does]
+when_to_use: "[When the user asks X, works with Y files, or Z domain. NOT for A.]"
+allowed-tools: [Read, Write, Edit, Grep, Glob, Bash — only what's needed]
+effort: [low | medium | high]
+---
+
+# [Skill Name] — [Short Subtitle]
+
+> [One-line philosophy or principle]
+
+## Overview
+[2-3 sentences explaining what this skill enables]
+
+## When to Use
+✅ Good for: [list]
+❌ Not for: [list]
+
+## Protocol
+### Step 1: [First Action]
+[Instructions]
+
+### Step 2: [Second Action]
+[Instructions]
+
+### Step N: [Verification]
+[How to verify the skill worked correctly]
+
+## Best Practices
+[3-5 key rules]
+```
+
+### Step 3: Place the Skill
+```
+.opencode/skills/[skill-name]/SKILL.md
+```
+
+### Step 4: Verify
+- [ ] Frontmatter has all required fields (name, description, when_to_use)
+- [ ] `when_to_use` clearly defines triggers AND exclusions
+- [ ] Steps are actionable, not vague
+- [ ] Skill doesn't duplicate an existing one
+
+---
+
+## Naming Conventions
+
+| Pattern | Skill Name | Example |
+|---|---|---|
+| Action-based | `[verb]-[noun]` | `verify-changes`, `batch-operations` |
+| Domain-based | `[domain]-[aspect]` | `database-design`, `api-patterns` |
+| Tool-based | `[tool]-patterns` | `tailwind-patterns`, `prisma-expert` |
+
+**Rules:**
+- kebab-case only
+- 2-3 words maximum
+- Descriptive, not clever
+- No abbreviations unless universally known
+
+---
+
+## Quality Checklist
+
+Before finalizing a new skill:
+
+| Check | Criteria |
+|---|---|
+| **Uniqueness** | No existing skill covers this (grep `.opencode/skills/`) |
+| **Reusability** | Useful across multiple projects, not just one |
+| **Completeness** | Has overview, when to use, protocol, verification |
+| **Frontmatter** | All required fields present and accurate |
+| **Clarity** | A new agent could follow these instructions cold |

package/kit/.opencode/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: systematic-debugging
+description: 4-phase systematic debugging methodology with root cause analysis and evidence-based verification. Use when debugging complex issues.
+compatibility: opencode
+metadata:
+  when_to_use: "\"When debugging complex issues, performing root cause analysis, or using evidence-based problem solving. Use with /debug workflow.\""
+  version: "1.0.0"
+---
+# Systematic Debugging
+
+> Source: obra/superpowers
+
+## Overview
+This skill provides a structured approach to debugging that prevents random guessing and ensures problems are properly understood before solving.
+
+## 4-Phase Debugging Process
+
+### Phase 1: Reproduce
+Before fixing, reliably reproduce the issue.
+
+```markdown
+## Reproduction Steps
+1. [Exact step to reproduce]
+2. [Next step]
+3. [Expected vs actual result]
+
+## Reproduction Rate
+- [ ] Always (100%)
+- [ ] Often (50-90%)
+- [ ] Sometimes (10-50%)
+- [ ] Rare (<10%)
+```
+
+### Phase 2: Isolate
+Narrow down the source.
+
+```markdown
+## Isolation Questions
+- When did this start happening?
+- What changed recently?
+- Does it happen in all environments?
+- Can we reproduce with minimal code?
+- What's the smallest change that triggers it?
+```
+
+### Phase 3: Understand
+Find the root cause, not just symptoms.
+
+```markdown
+## Root Cause Analysis
+### The 5 Whys
+1. Why: [First observation]
+2. Why: [Deeper reason]
+3. Why: [Still deeper]
+4. Why: [Getting closer]
+5. Why: [Root cause]
+```
+
+### Phase 4: Fix & Verify
+Fix and verify it's truly fixed.
+
+```markdown
+## Fix Verification
+- [ ] Bug no longer reproduces
+- [ ] Related functionality still works
+- [ ] No new issues introduced
+- [ ] Test added to prevent regression
+```
+
+## Debugging Checklist
+
+```markdown
+## Before Starting
+- [ ] Can reproduce consistently
+- [ ] Have minimal reproduction case
+- [ ] Understand expected behavior
+
+## During Investigation
+- [ ] Check recent changes (git log)
+- [ ] Check logs for errors
+- [ ] Add logging if needed
+- [ ] Use debugger/breakpoints
+
+## After Fix
+- [ ] Root cause documented
+- [ ] Fix verified
+- [ ] Regression test added
+- [ ] Similar code checked
+```
+
+## Common Debugging Commands
+
+```bash
+# Recent changes
+git log --oneline -20
+git diff HEAD~5
+
+# Search for pattern
+grep -r "errorPattern" --include="*.ts"
+
+# Check logs
+pm2 logs app-name --err --lines 100
+```
+
+## Anti-Patterns
+
+❌ **Random changes** - "Maybe if I change this..."
+❌ **Ignoring evidence** - "That can't be the cause"
+❌ **Assuming** - "It must be X" without proof
+❌ **Not reproducing first** - Fixing blindly
+❌ **Stopping at symptoms** - Not finding root cause

package/kit/.opencode/skills/tailwind-patterns/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: tailwind-patterns
+description: Tailwind CSS v4 principles. CSS-first configuration, container queries, modern patterns, design token architecture.
+compatibility: opencode
+metadata:
+  when_to_use: "\"When using Tailwind CSS v4, implementing design tokens, container queries, or modern CSS patterns with Tailwind.\""
+  version: "1.0.0"
+---
+# Tailwind CSS Patterns (v4)
+
+> Modern utility-first CSS with CSS-native configuration.
+
+---
+
+## 1. Tailwind v4 Architecture
+
+### What Changed from v3
+
+| v3 (Legacy) | v4 (Current) |
+|-------------|--------------|
+| `tailwind.config.js` | CSS-based `@theme` directive |
+| PostCSS plugin | Oxide engine (full builds ~5x, incremental >100x) |
+| JIT mode | Native, always-on |
+| Plugin system | CSS-native features |
+| `@apply` directive | Still works, discouraged |
+
+### v4 Core Concepts
+
+| Concept | Description |
+|---------|-------------|
+| **CSS-first** | Configuration in CSS, not JavaScript |
+| **Oxide Engine** | Rust-based compiler, much faster |
+| **Native Nesting** | CSS nesting without PostCSS |
+| **CSS Variables** | All tokens exposed as `--*` vars |
+
+---
+
+## 2. CSS-Based Configuration
+
+### Theme Definition
+
+```
+@theme {
+  /* Colors - use semantic names */
+  --color-primary: oklch(0.7 0.15 250);
+  --color-surface: oklch(0.98 0 0);
+  --color-surface-dark: oklch(0.15 0 0);
+  
+  /* Spacing scale */
+  --spacing-xs: 0.25rem;
+  --spacing-sm: 0.5rem;
+  --spacing-md: 1rem;
+  --spacing-lg: 2rem;
+  
+  /* Typography */
+  --font-sans: 'Inter', system-ui, sans-serif;
+  --font-mono: 'JetBrains Mono', monospace;
+}
+```
+
+### When to Extend vs Override
+
+| Action | Use When |
+|--------|----------|
+| **Extend** | Adding new values alongside defaults |
+| **Override** | Replacing default scale entirely |
+| **Semantic tokens** | Project-specific naming (primary, surface) |
+
+---
+
+## 3. Container Queries (v4 Native)
+
+### Breakpoint vs Container
+
+| Type | Responds To |
+|------|-------------|
+| **Breakpoint** (`md:`) | Viewport width |
+| **Container** (`@container`) | Parent element width |
+
+### Container Query Usage
+
+| Pattern | Classes |
+|---------|---------|
+| Define container | `@container` on parent |
+| Container breakpoint | `@sm:`, `@md:`, `@lg:` on children |
+| Named containers | `@container/card` for specificity |
+
+### When to Use
+
+| Scenario | Use |
+|----------|-----|
+| Page-level layouts | Viewport breakpoints |
+| Component-level responsive | Container queries |
+| Reusable components | Container queries (context-independent) |
+
+---
+
+## 4. Responsive Design
+
+### Breakpoint System
+
+| Prefix | Min Width | Target |
+|--------|-----------|--------|
+| (none) | 0px | Mobile-first base |
+| `sm:` | 640px | Large phone / small tablet |
+| `md:` | 768px | Tablet |
+| `lg:` | 1024px | Laptop |
+| `xl:` | 1280px | Desktop |
+| `2xl:` | 1536px | Large desktop |
+
+### Mobile-First Principle
+
+1. Write mobile styles first (no prefix)
+2. Add larger screen overrides with prefixes
+3. Example: `w-full md:w-1/2 lg:w-1/3`
+
+---
+
+## 5. Dark Mode
+
+### Configuration Strategies
+
+| Method | Behavior | Use When |
+|--------|----------|----------|
+| `class` | `.dark` class toggles | Manual theme switcher |
+| `media` | Follows system preference | No user control |
+| `selector` | Custom selector (v4) | Complex theming |
+
+### Dark Mode Pattern
+
+| Element | Light | Dark |
+|---------|-------|------|
+| Background | `bg-white` | `dark:bg-zinc-900` |
+| Text | `text-zinc-900` | `dark:text-zinc-100` |
+| Borders | `border-zinc-200` | `dark:border-zinc-700` |
+
+---
+
+## 6. Modern Layout Patterns
+
+### Flexbox Patterns
+
+| Pattern | Classes |
+|---------|---------|
+| Center (both axes) | `flex items-center justify-center` |
+| Vertical stack | `flex flex-col gap-4` |
+| Horizontal row | `flex gap-4` |
+| Space between | `flex justify-between items-center` |
+| Wrap grid | `flex flex-wrap gap-4` |
+
+### Grid Patterns
+
+| Pattern | Classes |
+|---------|---------|
+| Auto-fit responsive | `grid grid-cols-[repeat(auto-fit,minmax(250px,1fr))]` |
+| Asymmetric (Bento) | `grid grid-cols-3 grid-rows-2` with spans |
+| Sidebar layout | `grid grid-cols-[auto_1fr]` |
+
+> **Note:** Prefer asymmetric/Bento layouts over symmetric 3-column grids.
+
+---
+
+## 7. Modern Color System
+
+### OKLCH vs RGB/HSL
+
+| Format | Advantage |
+|--------|-----------|
+| **OKLCH** | Perceptually uniform, better for design |
+| **HSL** | Intuitive hue/saturation |
+| **RGB** | Legacy compatibility |
+
+### Color Token Architecture
+
+| Layer | Example | Purpose |
+|-------|---------|---------|
+| **Primitive** | `--blue-500` | Raw color values |
+| **Semantic** | `--color-primary` | Purpose-based naming |
+| **Component** | `--button-bg` | Component-specific |
+
+---
+
+## 8. Typography System
+
+### Font Stack Pattern
+
+| Type | Recommended |
+|------|-------------|
+| Sans | `'Inter', 'SF Pro', system-ui, sans-serif` |
+| Mono | `'JetBrains Mono', 'Fira Code', monospace` |
+| Display | `'Outfit', 'Poppins', sans-serif` |
+
+### Type Scale
+
+| Class | Size | Use |
+|-------|------|-----|
+| `text-xs` | 0.75rem | Labels, captions |
+| `text-sm` | 0.875rem | Secondary text |
+| `text-base` | 1rem | Body text |
+| `text-lg` | 1.125rem | Lead text |
+| `text-xl`+ | 1.25rem+ | Headings |
+
+---
+
+## 9. Animation & Transitions
+
+### Built-in Animations
+
+| Class | Effect |
+|-------|--------|
+| `animate-spin` | Continuous rotation |
+| `animate-ping` | Attention pulse |
+| `animate-pulse` | Subtle opacity pulse |
+| `animate-bounce` | Bouncing effect |
+
+### Transition Patterns
+
+| Pattern | Classes |
+|---------|---------|
+| All properties | `transition-all duration-200` |
+| Specific | `transition-colors duration-150` |
+| With easing | `ease-out` or `ease-in-out` |
+| Hover effect | `hover:scale-105 transition-transform` |
+
+---
+
+## 10. Component Extraction
+
+### When to Extract
+
+| Signal | Action |
+|--------|--------|
+| Same class combo 3+ times | Extract component |
+| Complex state variants | Extract component |
+| Design system element | Extract + document |
+
+### Extraction Methods
+
+| Method | Use When |
+|--------|----------|
+| **React/Vue component** | Dynamic, JS needed |
+| **@apply in CSS** | Sparingly — only when a component layer isn't available |
+| **Design tokens** | Reusable values |
+
+---
+
+## 11. Anti-Patterns
+
+| Don't | Do |
+|-------|-----|
+| Arbitrary values everywhere | Use design system scale |
+| `!important` | Fix specificity properly |
+| Inline `style=` | Use utilities |
+| Duplicate long class lists | Extract component |
+| Mix v3 config with v4 | Migrate fully to CSS-first |
+| Use `@apply` heavily | Prefer components |
+
+---
+
+## 12. Performance Principles
+
+| Principle | Implementation |
+|-----------|----------------|
+| **Purge unused** | Automatic in v4 |
+| **Avoid dynamism** | No template string classes |
+| **Use Oxide** | Default in v4 (full builds ~5x, incremental >100x) |
+| **Cache builds** | CI/CD caching |
+
+---
+
+> **Remember:** Tailwind v4 is CSS-first. Embrace CSS variables, container queries, and native features. The config file is now optional.