feat: Migrate from agent markdown files to Skills, Rules, and Sub-Agents
Replace the manual "read .claude/agents/*.md" workflow with native Claude Code features for a more efficient, scalable development experience: - **Skills** (.claude/skills/): 7 auto-discovered slash commands (/requirements, /architecture, /frontend, /backend, /qa, /deploy, /help) with forked sub-agents for heavy tasks and inline execution for interactive ones - **Rules** (.claude/rules/): 4 modular rule files (general, frontend, backend, security) auto-applied based on file context - **Sub-Agents** (.claude/agents/): Lightweight configs for frontend-dev, backend-dev, and qa-engineer with model, tool, and turn limit settings - **Context Engineering**: Layered context loading, context isolation via forked skills, built-in context recovery after compaction, and "always read, never guess" rules to prevent hallucinated code references - **CLAUDE.md**: Auto-loaded project context replacing PROJECT_CONTEXT.md - **Feature tracking**: features/INDEX.md as persistent state across sessions - **Production guides**: docs/production/ for error tracking, security, performance, database optimization, and rate limiting - **Init Mode**: /requirements detects empty PRD and bootstraps full project setup (PRD + all feature specs) from a single project description Removed: 6 monolithic agent files, PROJECT_CONTEXT.md, HOW_TO_USE_AGENTS.md, TEMPLATE_CHANGELOG.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
“alexvisualmakers”
@@ -0,0 +1,25 @@
|
||||
# Backend Development Rules
|
||||
|
||||
## Database (Supabase)
|
||||
- ALWAYS enable Row Level Security on every table
|
||||
- Create RLS policies for SELECT, INSERT, UPDATE, DELETE
|
||||
- Add indexes on columns used in WHERE, ORDER BY, and JOIN clauses
|
||||
- Use foreign keys with ON DELETE CASCADE where appropriate
|
||||
- Never skip RLS - security first
|
||||
|
||||
## API Routes
|
||||
- Validate all inputs using Zod schemas before processing
|
||||
- Always check authentication: verify user session exists
|
||||
- Return meaningful error messages with appropriate HTTP status codes
|
||||
- Use `.limit()` on all list queries
|
||||
|
||||
## Query Patterns
|
||||
- Use Supabase joins instead of N+1 query loops
|
||||
- Use `unstable_cache` from Next.js for rarely-changing data
|
||||
- Always handle errors from Supabase responses
|
||||
|
||||
## Security
|
||||
- Never hardcode secrets in source code
|
||||
- Use environment variables for all credentials
|
||||
- Validate and sanitize all user input
|
||||
- Use parameterized queries (Supabase handles this)
|
||||
@@ -0,0 +1,26 @@
|
||||
# Frontend Development Rules
|
||||
|
||||
## shadcn/ui First (MANDATORY)
|
||||
- Before creating ANY UI component, check if shadcn/ui has it: `ls src/components/ui/`
|
||||
- NEVER create custom implementations of: Button, Input, Select, Checkbox, Switch, Dialog, Modal, Alert, Toast, Table, Tabs, Card, Badge, Dropdown, Popover, Tooltip, Navigation, Sidebar, Breadcrumb
|
||||
- If a shadcn component is missing, install it: `npx shadcn@latest add <name> --yes`
|
||||
- Custom components are ONLY for business-specific compositions that internally use shadcn primitives
|
||||
|
||||
## Import Pattern
|
||||
```tsx
|
||||
import { Button } from "@/components/ui/button"
|
||||
import { Card, CardHeader, CardTitle, CardContent } from "@/components/ui/card"
|
||||
```
|
||||
|
||||
## Component Standards
|
||||
- Use Tailwind CSS exclusively (no inline styles, no CSS modules)
|
||||
- All components must be responsive (mobile 375px, tablet 768px, desktop 1440px)
|
||||
- Implement loading states, error states, and empty states
|
||||
- Use semantic HTML and ARIA labels for accessibility
|
||||
- Keep components small and focused
|
||||
- Use TypeScript interfaces for all props
|
||||
|
||||
## Auth Best Practices (Supabase)
|
||||
- Use `window.location.href` for post-login redirect (not `router.push`)
|
||||
- Always verify `data.session` exists before redirecting
|
||||
- Always reset loading state in all code paths (success, error, finally)
|
||||
@@ -0,0 +1,37 @@
|
||||
# General Project Rules
|
||||
|
||||
## Feature Tracking
|
||||
- All features are tracked in `features/INDEX.md` - read it before starting any work
|
||||
- Feature specs live in `features/PROJ-X-feature-name.md`
|
||||
- Feature IDs are sequential: check INDEX.md for the next available number
|
||||
- One feature per spec file (Single Responsibility)
|
||||
- Never combine multiple independent functionalities in one spec
|
||||
|
||||
## Git Conventions
|
||||
- Commit format: `type(PROJ-X): description`
|
||||
- Types: feat, fix, refactor, test, docs, deploy, chore
|
||||
- Check existing features before creating new ones: `ls features/ | grep PROJ-`
|
||||
- Check existing components before building: `git ls-files src/components/`
|
||||
- Check existing APIs before building: `git ls-files src/app/api/`
|
||||
|
||||
## Human-in-the-Loop
|
||||
- Always ask for user approval before finalizing deliverables
|
||||
- Present options using clear choices rather than open-ended questions
|
||||
- Never proceed to the next workflow phase without user confirmation
|
||||
|
||||
## Status Updates
|
||||
- Update `features/INDEX.md` when feature status changes
|
||||
- Update the feature spec header status field
|
||||
- Valid statuses: Planned, In Progress, In Review, Deployed
|
||||
|
||||
## File Handling
|
||||
- ALWAYS read a file before modifying it - never assume contents from memory
|
||||
- After context compaction, re-read files before continuing work
|
||||
- When unsure about current project state, read `features/INDEX.md` first
|
||||
- Run `git diff` to verify what has already been changed in this session
|
||||
- Never guess at import paths, component names, or API routes - verify by reading
|
||||
|
||||
## Handoffs Between Skills
|
||||
- After completing a skill, suggest the next skill to the user
|
||||
- Format: "Next step: Run `/skillname` to [action]"
|
||||
- Handoffs are always user-initiated, never automatic
|
||||
@@ -0,0 +1,28 @@
|
||||
# Security Rules
|
||||
|
||||
## Secrets Management
|
||||
- NEVER commit secrets, API keys, or credentials to git
|
||||
- Use `.env.local` for local development (already in .gitignore)
|
||||
- Use `NEXT_PUBLIC_` prefix ONLY for values safe to expose in browser
|
||||
- Document all required env vars in `.env.local.example` with dummy values
|
||||
|
||||
## Input Validation
|
||||
- Validate ALL user input on the server side with Zod
|
||||
- Never trust client-side validation alone
|
||||
- Sanitize data before database insertion
|
||||
|
||||
## Authentication
|
||||
- Always verify authentication before processing API requests
|
||||
- Use Supabase RLS as a second line of defense
|
||||
- Implement rate limiting on authentication endpoints
|
||||
|
||||
## Security Headers
|
||||
- X-Frame-Options: DENY
|
||||
- X-Content-Type-Options: nosniff
|
||||
- Referrer-Policy: origin-when-cross-origin
|
||||
- Strict-Transport-Security with includeSubDomains
|
||||
|
||||
## Code Review Triggers
|
||||
- Any changes to RLS policies require explicit user approval
|
||||
- Any changes to authentication flow require explicit user approval
|
||||
- Any new environment variables must be documented in .env.local.example
|
||||
Reference in New Issue
Block a user