somnus0x/agt-skill-pack/frontend-setup

Read my package.json, tsconfig, and project structure.
Tell me:
1. Framework (Next.js version? App Router or Pages?)
2. Styling (Tailwind? CSS Modules? styled-components? version?)
3. State management (Redux? Zustand? React Query? Context only?)
4. Testing (Vitest? Jest? Playwright? none?)
5. Component pattern (barrel exports? co-located files? flat?)
6. Linting/formatting (ESLint config? Prettier?)
 
Don't suggest changes. Just report what exists.

## Component Rules
 
-Components live in `src/components/` grouped by feature, not by type
-One component per file. File name = component name (PascalCase)
-Co-locate styles, tests, and types with the component:
  ```
  components/
    MarketCard/
      MarketCard.tsx
      MarketCard.test.tsx
      types.ts
  ```
-No barrel exports (index.ts re-exports) unless the folder has 5+ files
-Props interface lives in the same file, named `{ComponentName}Props`
-Default export for page components, named export for everything else

## Import Rules
 
-Absolute imports from `@/` (mapped to `src/` in tsconfig)
-Import order: react → external libs → internal modules → relative files → styles
-No circular imports. If A imports B and B imports A — extract shared types to a third file
-Prefer named imports: `import { Button } from '@/components/ui/Button'`

## Styling (Tailwind)
 
-Tailwind v4 with CSS-first config
-Use `cn()` utility for conditional classes (already in `lib/utils.ts`)
-No inline style objects. If Tailwind can't do it, add a CSS variable
-Color tokens: use semantic names (`text-primary`, `bg-surface`) not raw values
-Responsive: mobile-first. `sm:` `md:` `lg:` — no custom breakpoints

## Styling (CSS Modules)
 
-One `.module.css` per component, co-located
-Class names: camelCase in JS, kebab-case in CSS
-No global styles except in `globals.css`
-CSS variables for colors and spacing — defined in `:root`

## Data Fetching
 
-Server Components by default. Add 'use client' only when needed (state, effects, browser APIs)
-Fetch in Server Components or Route Handlers — not in client components
-Use React Server Actions for mutations
-Loading states: `loading.tsx` files, not manual isLoading booleans
-Error boundaries: `error.tsx` files at route level

## Data Fetching
 
-React Query (TanStack Query) for all server state
-Custom hooks in `hooks/` folder: `useMarkets()`, `useUser()`
-No raw fetch/axios in components — always wrap in a hook
-Loading/error states handled by React Query, not manual state

## State
 
-Server state: React Query (or Server Components if Next.js App Router)
-Client state: Zustand for global, useState for local
-No prop drilling past 2 levels — extract to context or Zustand
-Form state: react-hook-form, not manual onChange handlers

## TypeScript
 
-Strict mode. No `any` unless you add a comment explaining why
-API response types in `types/api.ts`
-Component prop types co-located with component
-Use `satisfies` over `as` for type narrowing
-Enums → union types: `type Status = 'active' | 'pending' | 'closed'`

## Testing
 
-Unit tests: Vitest + React Testing Library
-Test file lives next to component: `Button.test.tsx`
-Test behavior, not implementation. Click the button, check the result
-No snapshot tests unless explicitly asked
-E2E: Playwright for critical flows only

## Don't
 
-Don't install new dependencies without asking first
-Don't create new top-level folders
-Don't refactor existing components unless I specifically ask
-Don't add error boundaries or loading states unless I ask for them
-Don't convert between CSS approaches (don't migrate Tailwind to CSS Modules)
-Don't add comments to code you didn't write
-Don't create utility functions for one-time operations

## Before writing code
 
1.Check if a similar component already exists — don't duplicate
2.Follow the existing pattern in the nearest similar file
3.Run the dev server / type checker to verify your changes compile

Create a simple card component that displays a title and description.
Follow existing project conventions.

### Frontend setup
Before building any new component, check:
1.Does a similar component already exist? Search first
2.What pattern does the nearest existing component follow? Match it
3.Where should this file live based on project structure?
Follow the component, import, and styling rules in this file exactly.