potenlab

Executes all tasks in a specific phase using wave-based parallel execution (max 4 agents per wave). Spawns small-coder and high-coder agents based on progress.json complexity. Updates progress.json after EACH wave so completed tasks immediately unblock dependents. Accepts phase number as argument (/execute-phase 3) or asks via AskUserQuestion. Triggers on: execute phase, run phase, build phase, develop phase, start phase.

Generates Vitest test files from test-plan.md using the qa-specialist agent. Reads the test plan and vitest best practices, then spawns qa-specialist agents to produce .test.ts files in the root tests/ directory for features, shared tests, and Supabase integration tests. Tests verify behavior via database operations and RLS policies — no UI testing. Triggers on: generate test, generate tests, create tests, write tests, test generation.

Orchestrates sequential project planning. First validates user intent via AskUserQuestion (MANDATORY), then spawns ui-ux-specialist to create ui-ux-plan.md, then tech-lead-specialist to create dev-plan.md from ui-ux-plan.md, then spawns frontend-specialist and backend-specialist in parallel to create their detailed plans from dev-plan.md, then spawns qa-specialist to create test-plan.md from dev-plan.md and backend-plan.md. Triggers on: plan, create plan, plan project, project plan, full plan, prd to plan.

Runs ALL Vitest tests across /features, /tests, and /supabase directories. Executes tests via npx vitest run, collects results, and generates test.result.json (replaced on every run). Uses qa-specialist to analyze failures and provide actionable feedback. Triggers on: run test all, run all tests, test all, vitest all, run tests.

Runs Vitest tests for a specific phase chosen by the user. Reads test-plan.md to identify phases, asks user which phase to run via AskUserQuestion, executes only those test files, and generates test.result.json (replaced on every run). Uses qa-specialist to analyze failures. Triggers on: run test phase, test phase, run phase test, test specific phase.

Verifies and updates tests after code changes. Detects what changed (git diff, changes.json), compares against test-plan.md, then spawns qa-specialist agents to update test-plan.md and edit/create test files in /features, /tests, /supabase. Use after /developer or manual changes to keep tests in sync. Triggers on: verify test, verify tests, sync tests, update tests, check tests, test verify.

Finalizes the planning phase by spawning progress-creator agent to read all plan files (dev-plan.md, frontend-plan.md, backend-plan.md) and generate progress.json — the structured task tracker used by coder agents. Run this AFTER /plan has completed. Triggers on: complete plan, finalize plan, create progress, generate progress, progress json.

Post-completion development skill for adjustments and changes after all phases are done. Accepts change requests from arguments (/developer fix the login button) or via AskUserQuestion. Analyzes existing code and plans, creates change tasks in docs/changes.json, spawns small-coder and high-coder agents in parallel, and tracks all results in changes.json. Triggers on: developer, dev, adjust, change, fix, tweak, modify, post-dev.

Use after plan-and-spec to build a planned change to completion. Scales to size: a small single-issue change is built directly (one story, verify, one PR); a new/large epic is walked one child story at a time (build via design, verify in a browser, open one PR per story), then reports. Triggered by plan-and-spec ONLY after the user has confirmed the FILED GitHub issue is correct; or use directly when a spec (/docs/plan) and a filed, user-approved issue already exist. Execution only — it does not plan or file issues.

You MUST use this before ANY change to the project's code or UI — building something new, OR editing, restyling, tweaking, fixing, or refactoring anything that already exists — before you touch any file. Clarifies the change through questions, writes a technical spec to /docs/plan, and ALWAYS files a GitHub issue with gh, then hands off to goal-loop to build. Skip ONLY for pure questions, explanations, or read-only code review with no change.

Use when starting any conversation - establishes how the designer-workflow plugin's skills are found and used, requiring a Skill-tool check before responding whenever a request involves building an app or any Supabase/Postgres work.

Build ONE app or story full-stack from an already-agreed plan — backend, UI, assets, and wiring inside an isolated sandbox branch, then run it and open a PR. Normally called by goal-loop once per child story; use directly only for a single explicit one-off build. For any fresh change request — building OR editing/restyling/fixing — use plan-and-spec FIRST, not this. Responds only in plain product language and a working app, never raw code.

Use whenever a visual or media ASSET is needed for an app or page — an image, icon, logo, illustration, hero/background, avatar, texture, video clip, sound effect, or voiceover. Higgsfield is the ONE path for generating assets: never use stock photos, emoji, placeholder boxes, hand-drawn SVGs, or another generator, and never ask the user to go find assets. AUTO-TRIGGER on asset intent: 'add an image/icon/logo/illustration', 'needs a hero', 'a background for…', 'generate a picture/video/sound', or any build step that requires visual/media content. Scope is assets ONLY — do NOT use this for code, data, schema, copywriting, or UI layout.

Wire a Supabase backend into a freshly created app the right way the first time — schema, RLS, auth, migrations, and type-safe client — driven by the Supabase MCP. Use when the /design app-creation flow (or any task) needs to give a new app a working, secure Postgres backend. Triggers: 'add a backend', 'store data', 'save submissions', 'log in', 'user accounts', 'database', Supabase, RLS, migrations, auth, edge functions. Respond to designers/PMs in plain language; do the engineering underneath.

Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.

Use when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, @supabase/ssr) in Next.js, React, SvelteKit, Astro, Remix; auth issues (login, logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS); Supabase CLI or MCP server; schema changes, migrations, security audits, Postgres extensions (pg_graphql, pg_cron, pg_vector).

Generate brand visuals via the Higgsfield MCP — logo variants, moodboard tiles, and a brand-guidelines document — once the brand intake (`brand.json` + `saas-context.json`) exists. Auto-activate after `saas-brand-intake` finishes, or when the user says "generate logo", "make moodboard", "create visuals", `/generate-visuals`, `/regen-logo`, `/regen-moodboard`. Never fall back to other image generators if Higgsfield is unavailable — stop and report.

Enforce the brand approval gate. Use this skill BEFORE any landing page work. Reads/writes `brands/<slug>/approval.json`. Auto-activate when the user says "approve", "looks good, continue", "ship it", `/approve-brand`, or attempts to start the landing page. If approval is missing, refuse to start any landing work and route back to `saas-visual-generator` if visuals also need changes.

Shared library of Higgsfield MCP prompt patterns used by `saas-visual-generator` and `saas-landing-builder`. Auto-activate when another skill is about to call `mcp__higgsfield__generate_image`, `mcp__higgsfield__generate_video`, or `mcp__higgsfield__media_upload`. Centralizes the model picks, aspect ratios, durations, negative prompts, and output paths used across the flow.

Run SaaS brand intake interviews when the user wants to validate a new product idea. Use this when there is no existing brand directory and the user mentions a SaaS idea, says "I want to validate", "let's start a new brand", "I have an idea", "validate my SaaS", or runs `/new-brand`. Collects brand basics, SaaS context, and visual direction in three question clusters, then writes `brands/<slug>/brand.json` and `saas-context.json` and hands off to `saas-visual-generator`.

Build the SaaS landing page in `sites/<slug>/` once the brand is approved. Auto-activate when `approval.json.approved === true` and the user asks for a landing page, website, marketing site, or runs `/build-landing`. Generates a Next.js + Tailwind + Framer Motion app, wires Higgsfield-generated hero motion + feature micro-animations, writes SaaS copy from `brand.json` + `saas-context.json`, and ALWAYS places a `<Waitlist />` section at the bottom.

Pick and wire the waitlist backend adapter when generating the landing page. Auto-activate when `saas-landing-builder` is scaffolding the waitlist component. Chooses between local-JSON (default), Supabase, Resend, or Loops based on env vars and user preference, then writes the matching `app/api/waitlist/route.ts` and `lib/waitlist.ts` into `sites/<slug>/`.