Template
chore: initial commit (Ausgangszustand der Vorlage)
This commit is contained in:
Florian Wilde
@@ -0,0 +1,32 @@
|
||||
---
|
||||
paths:
|
||||
- "src/app/api/**"
|
||||
- "src/lib/supabase*"
|
||||
- "supabase/**"
|
||||
---
|
||||
|
||||
# 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,34 @@
|
||||
---
|
||||
paths:
|
||||
- "src/components/**"
|
||||
- "src/app/**/page.tsx"
|
||||
- "src/app/**/layout.tsx"
|
||||
- "src/hooks/**"
|
||||
---
|
||||
|
||||
# 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,75 @@
|
||||
# General Project Rules
|
||||
|
||||
## New Project Detection (MANDATORY)
|
||||
Before starting ANY work, check if the project has been initialized:
|
||||
1. Read `docs/PRD.md` - if it still contains placeholder text like "_Describe what you are building_", the project is NOT initialized
|
||||
2. Read `features/INDEX.md` - if the features table is empty, no features have been defined
|
||||
|
||||
**If the project is not initialized:**
|
||||
- Do NOT write any code or create any components
|
||||
- Do NOT skip ahead to implementation
|
||||
- Instead, tell the user: "This project hasn't been set up yet. Let's start by defining what you want to build. Run `/init` with a description of your idea (e.g. `/init I want to build a task management app`)."
|
||||
- If the user already described their idea in the current message, run `/init` automatically with their description
|
||||
|
||||
**If the project is initialized but the user requests a feature not yet in INDEX.md:**
|
||||
- Guide them to run `/write-spec` first to create the feature spec before any implementation
|
||||
|
||||
## 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 (MANDATORY - Write-Then-Verify)
|
||||
After completing work on any feature, you MUST update tracking files. Follow this exact sequence:
|
||||
|
||||
1. **Read** the feature spec (`features/PROJ-X-*.md`) and `features/INDEX.md` BEFORE editing
|
||||
2. **Write** your changes using the Edit tool — do NOT just describe what you would write
|
||||
3. **Re-read** the file AFTER editing to verify the changes are actually present
|
||||
4. **If changes are missing**, repeat step 2 — never claim updates were made without verifying
|
||||
|
||||
**What to update in the feature spec:**
|
||||
- Status field in the header (Planned → In Progress → In Review → Deployed)
|
||||
- Implementation notes: what was built, what changed, any deviations from the original spec
|
||||
- Bug fixes or design changes discovered during implementation
|
||||
|
||||
**What to update in `features/INDEX.md`:**
|
||||
- Feature status column must match the feature spec header
|
||||
- Valid statuses: Roadmap → Planned → Architected → In Progress → In Review → Approved → Deployed
|
||||
- **Roadmap**: after `/init` — feature identified, no spec file yet
|
||||
- **Planned**: after `/write-spec`
|
||||
- **Architected**: after `/architecture`
|
||||
- **In Progress**: after `/frontend` or `/backend` starts
|
||||
- **In Review**: after `/qa` starts
|
||||
- **Approved**: after `/qa` passes (no critical/high bugs)
|
||||
- **Deployed**: after `/deploy`
|
||||
|
||||
**NEVER do this:**
|
||||
- Do NOT say "I've updated the feature spec" without actually calling the Edit tool
|
||||
- Do NOT summarize changes in chat as a substitute for writing them to the file
|
||||
- Do NOT skip updates because "it's obvious" or "minor"
|
||||
|
||||
## 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,36 @@
|
||||
---
|
||||
paths:
|
||||
- "src/app/api/**"
|
||||
- ".env*"
|
||||
- "supabase/**"
|
||||
- "next.config.*"
|
||||
---
|
||||
|
||||
# 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