Bencium Code Conventions
Lock agent-generated code to a consistent React, Next.js App Router, Tailwind, and backend stack style.
Overview
bencium-code-conventions is a journey-wide agent skill that enforces a fixed React/Next/Tailwind stack and naming style whenever a solo builder (or Bence-aligned project) generates or refactors code.
Install
npx skills add https://github.com/bencium/bencium-marketplace --skill bencium-code-conventionsWhat is this skill?
- Stack defaults: React, Next.js App Router, TypeScript, Tailwind CSS v3.x, shadcn UI
- Backend preference: Convex or Supabase (Postgres-compatible)—ask, avoid local Postgres
- Code style: ES modules, async/await, const arrow handlers, Zod validation, Zustand and TanStack Query
- Deployment suggestions: Netlify, Vercel, or Fly on Mac M2 without Docker/CUDA
- Directory naming: lowercase-with-dashes; functional React only, no class components
- TailwindCSS v3.x explicitly—not v4
Adoption & trust: 1.1k installs on skills.sh; 273 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your coding agent alternates between conflicting stacks, Tailwind versions, and folder layouts every session.
Who is it for?
Solo builders who want a portable personal style pack mirrored from a proven indie workflow.
Skip if: Teams with an existing divergent design system, heavy Python ML pipelines, or Docker-first infra—the skill explicitly discourages those paths.
When should I use this skill?
When writing code or setting up projects for Bence (or when adopting this convention pack).
What do I get? / Deliverables
Generated projects align to one documented convention set—App Router structure, shadcn imports, typed handlers, and approved backend hosts.
- Stack-aligned file structure
- TypeScript React modules
- Consistent import and naming patterns
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Generate auth wizard routes under components/auth-wizard with shadcn and Tailwind v3 tokens.
Choose Convex or Supabase after asking the user instead of defaulting to local Postgres.
Reject PRs that introduce var, class components, or Tailwind v4 syntax.
Apply the same const-handler and Zod patterns to hotfix branches.
How it compares
Personal convention template, not a generic linter config or framework tutorial.
Common Questions / FAQ
Who is bencium-code-conventions for?
Indie developers and small teams who want agents to follow a single Next.js + shadcn + Convex/Supabase playbook instead of improvising stack choices.
When should I use bencium-code-conventions?
At Idea when bootstrapping repo layout; during Build for every feature and refactor; at Ship during review to catch Tailwind v4 or class components; at Operate when patching production with the same naming rules.
Is bencium-code-conventions safe to install?
Check the Security Audits panel on this Prism page; the skill only steers code style and does not grant network or shell behavior by itself.
SKILL.md
READMESKILL.md - Bencium Code Conventions
# Code Conventions ## Core Technologies - **Frontend:** ReactJS, Next.js (App Router structure), TypeScript - **Styling:** TailwindCSS v3.x (never v4), Shadcn UI - **Build Tools:** Vite (when applicable) - **Backend:** Postgres compatible convex.dev or Supabase (always ask, never local postgres) - **Deployment:** Netlify or Vercel or Fly - suggest - **Environment:** Mac M2, Python3 with virtual environments, no CUDA, no Docker - **Alternative Languages:** Avoid python if you can, try using RUST ## Code Style & Structure - Use ES modules (import/export) syntax - Destructure imports when possible - Use TypeScript for all new code - Use async/await instead of Promise chains - Prefer const/let over var; use early returns - Use consts instead of functions: `const toggle = () =>`. Define types. - Use descriptive variable names with auxiliary verbs (e.g., `isLoading`, `hasError`) - Use lowercase with dashes for directory names (e.g., `components/auth-wizard`) ## Framework Conventions - **Next.js:** Use App Router (app directory) structure and page.tsx files - **React:** Functional and declarative patterns; avoid classes - **State Management:** Zustand, TanStack React Query - **Validation:** Zod for schema validation ## Component Library & Styling - **Component Library:** Prefer shadcn components from `@/components/ui` - **Styling:** Tailwind utility classes - **Layout:** Grid/flex wrappers with `gap` for spacing - **Icons:** `@phosphor-icons/react` - **Toasts:** `sonner` for notifications - Always add loading states, spinners, placeholder animations ## Quality Assurance & Testing - **TDD:** Write failing tests first, commit them, then iterate until suite passes - Never mock tests - if there's a test script, execute all until done - Always write SQL in chunks with test steps after each chunk - Typecheck after making code changes - Run tests before committing - Prefer running single tests for performance, not whole suite ## Error Handling - Implement proper error handling and user input validation - Error messages should be understood by non-technical people - Use early returns for error conditions - Test APIs via curl commands first, then implement in code ## Performance & Architecture - Minimize `'use client'`, `useEffect`, `setState`; favor RSC and Next.js SSR - Implement dynamic imports for code splitting - Optimize images: WebP format, size data, lazy loading - Favor small, simple, well-named modules ## Development Workflow **Process:** Explore → Plan → Code → Commit - Read relevant files - Think through a plan - Implement - Then commit - Never local backend, always ask (usually Supabase, Neon) - Minimal dependency, no docker ## Environment & Deployment - Add .env files for API keys; warn me to save keys in Vercel/Netlify env variables - Write code deployable to Netlify or Vercel; prepare to build locally first - Document progress in progress.md; ask for implementation plan