Stack conventions for building, implementing, or extending a feature in a Next.js (App Router) + TypeScript + Prisma/PostgreSQL project (also covering BullMQ/Redis, Resend, and Docker/Playwright). Triggers when the user asks to build, implement, add, create, or extend a feature, endpoint, service, job, or email flow on such a stack. Enforces the read-first / pattern-match / test-alongside / verify-in-a-container workflow, including updates to the project's Dockerfile, compose, and stack files when the change requires it.
How this skill is triggered — by the user, by Claude, or both
Slash command
/nextjs-prisma-overlay:stack-conventionsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill is the **stack overlay** consulted by the feature-factory-core agents (and by humans) when working on a Next.js (App Router) + TypeScript + Prisma/PostgreSQL + BullMQ/Redis + Resend + Docker/Playwright project. It encodes the conventions that generalize across any repo on this stack. **Repo-specific names, commands, container names, network names, and database names are NOT hardcoded...
This skill is the stack overlay consulted by the feature-factory-core agents (and by humans) when working on a Next.js (App Router) + TypeScript + Prisma/PostgreSQL + BullMQ/Redis + Resend + Docker/Playwright project. It encodes the conventions that generalize across any repo on this stack. Repo-specific names, commands, container names, network names, and database names are NOT hardcoded here — they live in the project's own CLAUDE.md. Wherever this skill says "the project's ", read the concrete value from that repo's CLAUDE.md and docs.
Follow this loop end-to-end. Do not skip steps even when the task feels small — these conventions exist because shortcuts have caused production incidents on this stack.
Before touching code:
CLAUDE.md. It is the source of truth for the stack, architecture rules, the "Don't do" list, and the concrete container/DB/command names this skill refers to abstractly.docs/ for the area you're touching: API/service work, billing, email, background jobs, schema/queries. If an ADR covers the area, read it before contradicting it.Find 2–3 existing features that are structurally similar to what you're about to build and mirror them:
If you can't find a similar pattern, that's a signal to pause and ask — you may be building something the architecture doesn't yet support.
This is not strict TDD. Write production code and its tests together as one unit of work — typically in the same edit pass or back-to-back. Goals:
Where logic lives
Naming
Error handling
Migrations
CLAUDE.md). Never run a destructive dev/reset migration — it can drop generated/derived columns and other DB state that is not reconstructible from the schema alone.This stack ships through Docker: an image definition (Dockerfile), a local dev compose file (app + Postgres + Redis, with the project directory bind-mounted for hot reload), and a production stack/orchestration file. The exact filenames and locations are defined in this repo's CLAUDE.md.
If your change crosses the container boundary, update all relevant files together so dev and prod stay in lockstep:
.env reference) and the production stack file (prod secret reference). Never hardcode secrets; use Docker secrets or env files in prod.If the change is pure application code with no new deps / env / services, leave the Docker files alone. Don't churn them for no reason.
All verification runs inside the dockerized dev environment, not on the host. The local Docker stack (Next.js app + Postgres + Redis) is the source of truth for "does it work." Use the concrete compose file path, app service name, and commands defined in this repo's CLAUDE.md.
Bring the stack up if it isn't already, then run the project's typecheck, lint, and test commands inside the app container. For DB-touching work, also apply migrations against the containerized Postgres using the project's safe migration command (never a destructive reset).
All checks must pass. If a pre-existing failure is unrelated to your change, say so explicitly rather than glossing over it.
For UI changes, exercise the feature in a browser smoke against the running dev container (the project's Playwright/e2e harness, or a manual pass). Typecheck and tests verify code correctness, not feature correctness — a browser smoke is required before a feature is considered done.
If you touched the Dockerfile, rebuild the image before re-running checks.
Report in 1–2 sentences: what was built, which files changed (including any deploy/infra files), and confirmation that typecheck / lint / tests are green inside the container and a browser smoke passed. Nothing more.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
npx claudepluginhub kororos/cc-feature-factory --plugin nextjs-prisma-overlay