Simplereally

Adds a new table to Convex schema with indexes. Input: Table name, fields, and query patterns. Output: Updated schema.ts with new table definition.

Creates a new page/route in Next.js App Router with all boilerplate. Input: Route path (e.g., "/dashboard") and page purpose. Output: page.tsx, layout.tsx (if needed), loading.tsx, error.tsx.

Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.

Creates interactive React Client Components with hooks and event handlers. Input: Component name, purpose, required interactivity. Output: Client component file with proper structure and tests.

Creates pages, layouts, and server/client components in Next.js 16 App Router. Use for: new routes, RSC/RCC decisions, Server Actions, loading/error states. DO NOT use for: Convex mutations (use managing-convex), styling (use styling-ui).

Generates images using Pollinations API. Validates model constraints and dimensions. Use for: image generation logic, model selection, constraint validation. DO NOT use for: video generation (use generating-videos), UI styling (use styling-ui).

Generates videos using Pollinations API. Validates duration, audio, and interpolation capabilities. Use for: video generation logic, model selection, duration constraints. DO NOT use for: image generation (use generating-images), thumbnailing (handled automatically).

Manages Convex backend: schema, queries, mutations, and actions. Use for: database operations, server logic, real-time subscriptions. DO NOT use for: frontend components (use developing-nextjs), API routes (use Next.js actions).

Implement a feature using an implementation tournament with competing designs, judge scoring, and champion synthesis. Use when the user says "ultracode", "implementation tournament", "tournament", "design competition", or explicitly requests /implementation-tournament or a feature-building workflow with multiple competing strategies.

Run a quality gate council before shipping. Use when the user says "ultracode", "quality gate", "gate council", "ship check", "pre-ship review", "before this ships", or explicitly requests /quality-gate-council or a pre-push/pre-merge validation council.

Run a repo-wide quality offensive for <SCOPE>. Use when the user says "ultracode", "repo offensive", "quality offensive", "codebase cleanup", or explicitly requests a full-coverage quality offensive, pre-release hardening, or inherited-codebase cleanup.

Review a pull request or diff by fanning out one reviewer per changed file and adversarially verifying every issue before reporting. Use this WHENEVER the user asks to review a PR, review a diff, "look over these changes", check a branch before merge, or do a code review of more than a couple of files — even if they don't say the word "workflow". Prefer this over a single-pass review whenever the diff spans several files or the cost of missing a bug is high.

Sweep a codebase for real, reproducible bugs using diverse finder agents in a loop-until-dry, with every candidate confirmed by a multi-lens majority vote. Use this WHENEVER the user wants to "find bugs", do a bug hunt, audit a service/module for defects, hunt for a class of bug (races, null derefs, leaks, off-by-one), or shake out problems before a release — even without the word "workflow". Prefer this over reading files one-by-one whenever coverage across many files matters.

Audit every dependency in parallel — CVEs, breaking changes, maintenance health, and dead/unused packages — then rank by risk and produce an upgrade/remediation plan. Use this WHENEVER the user asks to audit dependencies, check for vulnerable/outdated packages, find unused deps, plan upgrades, or review package.json / requirements.txt / Cargo.toml / go.mod — even without the word "workflow". Prefer this over eyeballing a manifest whenever there are more than a handful of dependencies.

Root-cause a hard incident by generating competing hypotheses, gathering evidence for each in parallel, adversarially refuting them, and synthesizing the surviving root cause with a minimal fix and a verification plan. Use this WHENEVER the user is debugging a production incident, a flaky/intermittent failure, a regression, a mysterious stack trace, or asks "why is this happening / what's the root cause" — even without the word "workflow". Prefer this over a single linear debugging pass whenever the cause is non-obvious and the stakes are high.

Run a codebase-wide migration as a no-barrier pipeline where each file independently streams through transform → verify → fix in its own worktree, so a many-file change never stalls on the slowest file. Use this WHENEVER the user wants a framework swap, API deprecation cleanup, a codemod, a language-idiom migration, or any "change X to Y across the whole codebase / all these files" task — even without the word "workflow". Prefer this over editing files sequentially whenever the change spans more than ~10 files.