potenlab-workflow

Generate progress.json from finalized plans

Post-completion adjustments tracked in changes.json

Execute all tasks in a phase with wave-based parallel coder agents (max 4 per wave)

Generate Vitest test files from test-plan.md into root tests/ directory

Confirm potenlab-workflow is installed and active

Creates backend-plan.md by reading dev-plan.md and translating its backend tasks into detailed schema definitions, migration SQL, RLS policies, query specifications, and connection strategies. Uses MCP Postgres to discover current database state and enforces Supabase best practices. Does NOT write code — coder agents execute from this plan. Examples: <example> Context: User has a dev-plan.md and needs backend planning. user: "Create the backend plan from the dev plan" assistant: "I'll use the backend-specialist agent to read dev-plan.md and create backend-plan.md with schema specs and RLS policies." <commentary> Since the user needs a backend plan, use the backend-specialist to produce backend-plan.md. </commentary> </example> <example> Context: User wants to plan database schema. user: "Plan the database tables from the dev plan" assistant: "I'll use the backend-specialist agent to create backend-plan.md with table definitions, indexes, and RLS policies." <commentary> Since the user needs schema planning, use the backend-specialist with MCP Postgres tools. </commentary> </example> <example> Context: User wants to review their schema design. user: "Review my database schema against best practices" assistant: "I'll use the backend-specialist agent to audit against Supabase Postgres best practices and update backend-plan.md." <commentary> The user wants best practice validation. Use the backend-specialist which has the full reference. </commentary> </example>

Creates frontend-plan.md by reading dev-plan.md and translating its frontend tasks into detailed component specifications, file paths, props, patterns, and implementation guidelines. Uses shadcn MCP to discover components and enforces Vercel React best practices. Does NOT write code — coder agents execute from this plan. Examples: <example> Context: User has a dev-plan.md and needs frontend planning. user: "Create the frontend plan from the dev plan" assistant: "I'll use the frontend-specialist agent to read dev-plan.md and create frontend-plan.md with component specs and implementation details." <commentary> Since the user needs a frontend plan, use the frontend-specialist to produce frontend-plan.md. </commentary> </example> <example> Context: User wants to plan a specific feature's frontend. user: "Plan the frontend for the auth feature" assistant: "I'll use the frontend-specialist agent to create frontend-plan.md with detailed component specs for auth." <commentary> Since the user wants frontend planning for a feature, use the frontend-specialist. </commentary> </example> <example> Context: User wants to review frontend architecture. user: "Review my frontend architecture against best practices" assistant: "I'll use the frontend-specialist agent to audit against Vercel React best practices and update frontend-plan.md." <commentary> Since the user wants best practice review, use the frontend-specialist which has the full reference. </commentary> </example>

Executes complex, multi-file tasks from dev-plan.md. Uses Opus for deep reasoning on tasks requiring cross-file coordination, architectural awareness, and intricate business logic. Handles the heavy lifting that small-coder cannot. Only writes code — does NOT update progress.json. Examples: <example> Context: User wants a full feature module implemented. user: "Build the auth feature from task 3.1" assistant: "I'll use the high-coder agent to implement this multi-file feature module." <commentary> A full feature with api/, components/, hooks/, and types/ is a complex task — use high-coder. </commentary> </example> <example> Context: User wants a page with data fetching and state management. user: "Implement the dashboard page with all its data connections" assistant: "I'll use the high-coder agent to build the dashboard with API integration and state." <commentary> A page with data fetching, multiple components, and state is complex — use high-coder. </commentary> </example> <example> Context: User wants a single utility function. user: "Add a formatDate helper" assistant: "This is a small task — I'll use the small-coder agent instead." <commentary> Single-file utility functions are NOT complex tasks — use small-coder for this. </commentary> </example>

Creates progress.json by reading dev-plan.md, frontend-plan.md, and backend-plan.md. Parses all phases and tasks into a structured JSON tracking file that coder agents use to identify pending work and dependencies. Runs AFTER all plans are finalized. Examples: <example> Context: User has finalized dev-plan.md and specialist plans. user: "Create the progress tracker from the plans" assistant: "I'll use the progress-creator agent to read all plans and generate progress.json." <commentary> Since all plans exist and the user needs progress tracking, use progress-creator to generate progress.json. </commentary> </example> <example> Context: User just finished the planning phase. user: "Generate progress.json" assistant: "I'll use the progress-creator agent to parse dev-plan.md and create progress.json with all tasks." <commentary> Since the user explicitly wants progress.json, use progress-creator. </commentary> </example> <example> Context: dev-plan.md was updated and progress.json needs to sync. user: "Sync the progress file with the updated dev plan" assistant: "I'll use the progress-creator agent to re-read dev-plan.md and regenerate progress.json." <commentary> Since dev-plan.md changed, use progress-creator to regenerate a fresh progress.json. </commentary> </example>

Generates feature tests for a Next.js + Supabase app using Vitest. Reads test-plan.md and produces .test.ts files that verify behavior via database operations and RLS policies against a running Supabase local instance. Does NOT test UI, does NOT use Playwright, does NOT create or alter tables. Examples: <example> Context: User has a test-plan.md and wants tests generated. user: "Generate tests from the test plan" assistant: "I'll use the qa-specialist agent to read test-plan.md and generate Vitest test files for each feature." <commentary> Since the user needs tests generated from a plan, use the qa-specialist to produce .test.ts files. </commentary> </example> <example> Context: User wants to test RLS policies for a specific table. user: "Write tests for the orders table RLS policies" assistant: "I'll use the qa-specialist agent to generate RLS behavior tests for the orders table using Supabase client." <commentary> RLS policy testing via database behavior is the qa-specialist's core strength. </commentary> </example> <example> Context: User wants to test a feature's CRUD operations. user: "Test the project feature end-to-end" assistant: "I'll use the qa-specialist agent to generate CRUD behavior tests against Supabase local for the project feature." <commentary> Feature behavior tests via database operations — use qa-specialist. </commentary> </example> <example> Context: User wants UI component tests. user: "Test the dashboard page rendering" assistant: "That's a UI test — I can't help with that. Use a frontend testing approach with @testing-library/react instead." <commentary> UI testing is explicitly outside qa-specialist scope. Decline and suggest alternatives. </commentary> </example>

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.

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.

Display an overview of the Potenlab plugin ecosystem. Use for "info", "ecosystem", "about potenlab".