/', UserDetailView.as_view(), name='user-detail'),
+]
+```
+
+## Best Practices
+
+1. **Use class-based views for standard CRUD**
+2. **Define model methods for business logic**
+3. **Use serializers for validation**
+4. **Add proper permissions**
+5. **Use select_related/prefetch_related for queries**
+
+## Common Pitfalls
+
+### N+1 Queries
+
+```python
+# β BAD: N+1 query problem
+users = User.objects.all()
+for user in users:
+ print(user.profile.bio) # Separate query for each user
+
+# β
GOOD: Use select_related
+users = User.objects.select_related('profile').all()
+for user in users:
+ print(user.profile.bio) # Single query
+```
+
+### Missing Migrations
+
+```python
+# β BAD: Forgetting migrations
+# After changing models, forgetting to:
+python manage.py makemigrations
+python manage.py migrate
+
+# β
GOOD: Always create and run migrations
+python manage.py makemigrations
+python manage.py migrate
+```
+
+### No Validation
+
+```python
+# β BAD: Direct model creation
+user = User.objects.create(email=request.POST['email'])
+
+# β
GOOD: Use serializer for validation
+serializer = UserSerializer(data=request.data)
+if serializer.is_valid():
+ user = serializer.save()
+else:
+ return Response(serializer.errors, status=400)
+```
+
+## Advanced Patterns
+
+### Custom Managers
+
+```python
+class ActiveUserManager(models.Manager):
+ def get_queryset(self):
+ return super().get_queryset().filter(is_active=True)
+
+class User(models.Model):
+ # ...
+ objects = models.Manager()
+ active = ActiveUserManager()
+
+# Usage
+all_users = User.objects.all()
+active_users = User.active.all()
+```
+
+### Signals
+
+```python
+from django.db.models.signals import post_save
+from django.dispatch import receiver
+
+@receiver(post_save, sender=User)
+def create_user_profile(sender, instance, created, **kwargs):
+ if created:
+ Profile.objects.create(user=instance)
+```
+
+### Permissions
+
+```python
+from rest_framework import permissions
+
+class IsOwnerOrReadOnly(permissions.BasePermission):
+ def has_object_permission(self, request, view, obj):
+ if request.method in permissions.SAFE_METHODS:
+ return True
+ return obj.owner == request.user
+
+class UserViewSet(viewsets.ModelViewSet):
+ permission_classes = [IsOwnerOrReadOnly]
+ # ...
+```
+
+### Pagination
+
+```python
+from rest_framework.pagination import PageNumberPagination
+
+class StandardResultsSetPagination(PageNumberPagination):
+ page_size = 20
+ page_size_query_param = 'page_size'
+ max_page_size = 100
+
+class UserViewSet(viewsets.ModelViewSet):
+ pagination_class = StandardResultsSetPagination
+ # ...
+```
+
+## Testing
+
+```python
+from django.test import TestCase
+from rest_framework.test import APITestCase
+
+class UserModelTest(TestCase):
+ def test_create_user(self):
+ user = User.objects.create(
+ email='test@example.com',
+ name='Test User'
+ )
+ self.assertEqual(user.email, 'test@example.com')
+
+class UserAPITest(APITestCase):
+ def test_list_users(self):
+ response = self.client.get('/api/users/')
+ self.assertEqual(response.status_code, 200)
+
+ def test_create_user(self):
+ data = {'email': 'new@example.com', 'name': 'New User'}
+ response = self.client.post('/api/users/', data)
+ self.assertEqual(response.status_code, 201)
+```
+
+## Related Skills
+
+- [Python](/claudekit/skills/languages/python) - Python language
+- [PostgreSQL](/claudekit/skills/databases/postgresql) - Database
+- [pytest](/claudekit/skills/testing/pytest) - Testing
+- [OpenAPI](/claudekit/skills/api/openapi) - API documentation
diff --git a/website/src/content/docs/skills/frameworks/fastapi.md b/website/src/content/docs/skills/frameworks/fastapi.md
new file mode 100644
index 0000000..863461d
--- /dev/null
+++ b/website/src/content/docs/skills/frameworks/fastapi.md
@@ -0,0 +1,283 @@
+---
+title: FastAPI
+description: FastAPI async patterns, Pydantic validation, and OpenAPI documentation
+---
+
+The FastAPI skill provides expertise in building REST APIs with Python, async patterns, Pydantic validation, and automatic OpenAPI documentation.
+
+## When Activated
+
+- Building REST APIs with Python
+- Async web applications
+- OpenAPI/Swagger documentation needed
+- Working with FastAPI framework
+
+## Core Patterns
+
+### Route Definition
+
+```python
+from fastapi import FastAPI, HTTPException, Depends
+from pydantic import BaseModel
+
+app = FastAPI()
+
+class UserCreate(BaseModel):
+ email: str
+ name: str
+
+class UserResponse(BaseModel):
+ id: int
+ email: str
+ name: str
+
+@app.post("/users", response_model=UserResponse, status_code=201)
+async def create_user(user: UserCreate):
+ # Create user logic
+ return UserResponse(id=1, **user.model_dump())
+
+@app.get("/users/{user_id}", response_model=UserResponse)
+async def get_user(user_id: int):
+ user = await get_user_by_id(user_id)
+ if not user:
+ raise HTTPException(status_code=404, detail="User not found")
+ return user
+```
+
+### Dependency Injection
+
+```python
+from fastapi import Depends
+from sqlalchemy.ext.asyncio import AsyncSession
+
+async def get_db() -> AsyncGenerator[AsyncSession, None]:
+ async with async_session_maker() as session:
+ yield session
+
+@app.get("/users")
+async def list_users(db: AsyncSession = Depends(get_db)):
+ result = await db.execute(select(User))
+ return result.scalars().all()
+```
+
+### Router Organization
+
+```python
+from fastapi import APIRouter
+
+router = APIRouter(prefix="/users", tags=["users"])
+
+@router.get("/")
+async def list_users():
+ pass
+
+@router.post("/")
+async def create_user(user: UserCreate):
+ pass
+
+# In main.py
+app.include_router(router)
+```
+
+### Request Validation
+
+```python
+from pydantic import BaseModel, EmailStr, Field
+
+class UserCreate(BaseModel):
+ email: EmailStr
+ name: str = Field(min_length=1, max_length=100)
+ age: int = Field(ge=0, le=150)
+
+ class Config:
+ json_schema_extra = {
+ "example": {
+ "email": "user@example.com",
+ "name": "John Doe",
+ "age": 30
+ }
+ }
+```
+
+### Error Handling
+
+```python
+from fastapi import HTTPException, status
+from fastapi.responses import JSONResponse
+
+class UserNotFoundError(Exception):
+ pass
+
+@app.exception_handler(UserNotFoundError)
+async def user_not_found_handler(request, exc):
+ return JSONResponse(
+ status_code=status.HTTP_404_NOT_FOUND,
+ content={"detail": "User not found"}
+ )
+
+@app.get("/users/{user_id}")
+async def get_user(user_id: int):
+ user = await find_user(user_id)
+ if not user:
+ raise UserNotFoundError()
+ return user
+```
+
+### Background Tasks
+
+```python
+from fastapi import BackgroundTasks
+
+def send_email(email: str, message: str):
+ # Send email logic
+ pass
+
+@app.post("/users")
+async def create_user(
+ user: UserCreate,
+ background_tasks: BackgroundTasks
+):
+ new_user = await create_user_in_db(user)
+ background_tasks.add_task(send_email, user.email, "Welcome!")
+ return new_user
+```
+
+## Best Practices
+
+1. **Use Pydantic models for request/response validation**
+2. **Organize routes with APIRouter**
+3. **Use dependency injection for services**
+4. **Return proper HTTP status codes**
+5. **Add OpenAPI descriptions and examples**
+
+## Common Pitfalls
+
+### Blocking I/O in Async
+
+```python
+# β BAD: Blocking call in async function
+@app.get("/users")
+async def list_users():
+ users = blocking_db_call() # Blocks event loop
+ return users
+
+# β
GOOD: Use async libraries
+@app.get("/users")
+async def list_users(db: AsyncSession = Depends(get_db)):
+ result = await db.execute(select(User))
+ return result.scalars().all()
+```
+
+### Missing Response Models
+
+```python
+# β BAD: No response model
+@app.get("/users/{user_id}")
+async def get_user(user_id: int):
+ return await get_user_by_id(user_id)
+
+# β
GOOD: Define response model
+@app.get("/users/{user_id}", response_model=UserResponse)
+async def get_user(user_id: int):
+ return await get_user_by_id(user_id)
+```
+
+### Not Using HTTPException
+
+```python
+# β BAD: Returning error dict
+@app.get("/users/{user_id}")
+async def get_user(user_id: int):
+ user = await find_user(user_id)
+ if not user:
+ return {"error": "Not found"} # Returns 200!
+ return user
+
+# β
GOOD: Raise HTTPException
+@app.get("/users/{user_id}")
+async def get_user(user_id: int):
+ user = await find_user(user_id)
+ if not user:
+ raise HTTPException(status_code=404, detail="User not found")
+ return user
+```
+
+## Advanced Patterns
+
+### Middleware
+
+```python
+from fastapi import Request
+import time
+
+@app.middleware("http")
+async def add_process_time_header(request: Request, call_next):
+ start_time = time.time()
+ response = await call_next(request)
+ process_time = time.time() - start_time
+ response.headers["X-Process-Time"] = str(process_time)
+ return response
+```
+
+### Authentication
+
+```python
+from fastapi import Security, HTTPException
+from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
+
+security = HTTPBearer()
+
+async def get_current_user(
+ credentials: HTTPAuthorizationCredentials = Security(security)
+) -> User:
+ token = credentials.credentials
+ user = await verify_token(token)
+ if not user:
+ raise HTTPException(status_code=401, detail="Invalid token")
+ return user
+
+@app.get("/profile")
+async def get_profile(current_user: User = Depends(get_current_user)):
+ return current_user
+```
+
+### CORS
+
+```python
+from fastapi.middleware.cors import CORSMiddleware
+
+app.add_middleware(
+ CORSMiddleware,
+ allow_origins=["https://example.com"],
+ allow_credentials=True,
+ allow_methods=["*"],
+ allow_headers=["*"],
+)
+```
+
+## Testing
+
+```python
+from fastapi.testclient import TestClient
+
+client = TestClient(app)
+
+def test_create_user():
+ response = client.post(
+ "/users",
+ json={"email": "test@example.com", "name": "Test"}
+ )
+ assert response.status_code == 201
+ assert response.json()["email"] == "test@example.com"
+
+def test_get_nonexistent_user():
+ response = client.get("/users/999")
+ assert response.status_code == 404
+```
+
+## Related Skills
+
+- [Python](/claudekit/skills/languages/python) - Python language
+- [Pydantic](/claudekit/skills/languages/python) - Data validation
+- [PostgreSQL](/claudekit/skills/databases/postgresql) - Database
+- [pytest](/claudekit/skills/testing/pytest) - Testing
diff --git a/website/src/content/docs/skills/frameworks/nextjs.md b/website/src/content/docs/skills/frameworks/nextjs.md
new file mode 100644
index 0000000..6d7ab3d
--- /dev/null
+++ b/website/src/content/docs/skills/frameworks/nextjs.md
@@ -0,0 +1,404 @@
+---
+title: Next.js
+description: Next.js App Router, Server Components, and full-stack patterns
+---
+
+The Next.js skill provides expertise in Next.js with App Router, Server Components, Server Actions, and full-stack development patterns.
+
+## When Activated
+
+- React applications with SSR/SSG
+- Full-stack applications
+- App Router patterns
+- Working in `app/` directory
+
+## Core Patterns
+
+### App Router Structure
+
+```
+app/
+βββ layout.tsx # Root layout
+βββ page.tsx # Home page
+βββ loading.tsx # Loading UI
+βββ error.tsx # Error UI
+βββ api/
+β βββ users/
+β βββ route.ts # API route
+βββ users/
+ βββ page.tsx # Users page
+ βββ [id]/
+ βββ page.tsx # User detail
+```
+
+### Server Components
+
+```tsx
+// app/users/page.tsx - Server Component (default)
+async function UsersPage() {
+ const users = await db.users.findMany();
+
+ return (
+
+ {users.map(user => (
+ - {user.name}
+ ))}
+
+ );
+}
+```
+
+### Client Components
+
+```tsx
+'use client';
+
+import { useState } from 'react';
+
+export function Counter() {
+ const [count, setCount] = useState(0);
+
+ return (
+
+ );
+}
+```
+
+### API Routes
+
+```typescript
+// app/api/users/route.ts
+import { NextRequest, NextResponse } from 'next/server';
+
+export async function GET() {
+ const users = await db.users.findMany();
+ return NextResponse.json(users);
+}
+
+export async function POST(request: NextRequest) {
+ const data = await request.json();
+ const user = await db.users.create({ data });
+ return NextResponse.json(user, { status: 201 });
+}
+```
+
+### Server Actions
+
+```tsx
+// app/actions.ts
+'use server';
+
+export async function createUser(formData: FormData) {
+ const name = formData.get('name') as string;
+ await db.users.create({ data: { name } });
+ revalidatePath('/users');
+}
+
+// app/users/new/page.tsx
+import { createUser } from '@/app/actions';
+
+export default function NewUserPage() {
+ return (
+
+ );
+}
+```
+
+### Dynamic Routes
+
+```tsx
+// app/users/[id]/page.tsx
+interface PageProps {
+ params: { id: string };
+}
+
+export default async function UserPage({ params }: PageProps) {
+ const user = await db.users.findUnique({
+ where: { id: params.id }
+ });
+
+ if (!user) {
+ notFound();
+ }
+
+ return {user.name}
;
+}
+```
+
+### Layouts
+
+```tsx
+// app/layout.tsx
+export default function RootLayout({
+ children,
+}: {
+ children: React.ReactNode;
+}) {
+ return (
+
+
+
+ {children}
+
+
+
+ );
+}
+```
+
+## Best Practices
+
+1. **Use Server Components by default**
+2. **Add 'use client' only when needed**
+3. **Colocate data fetching with components**
+4. **Use loading.tsx for suspense boundaries**
+5. **Implement proper error boundaries**
+
+## Common Pitfalls
+
+### Using Hooks in Server Components
+
+```tsx
+// β BAD: Hooks in Server Component
+export default async function Page() {
+ const [state, setState] = useState(0); // Error!
+ return {state}
;
+}
+
+// β
GOOD: Mark as Client Component
+'use client';
+
+export default function Page() {
+ const [state, setState] = useState(0);
+ return {state}
;
+}
+```
+
+### Large Client Bundles
+
+```tsx
+// β BAD: Entire page as Client Component
+'use client';
+
+export default function Page() {
+ const [count, setCount] = useState(0);
+ const data = await fetchData(); // Can't use await in Client Component
+
+ return (
+
+
+
+
+ );
+}
+
+// β
GOOD: Extract interactive parts only
+export default async function Page() {
+ const data = await fetchData(); // Server Component can await
+
+ return (
+
+ {/* Server Component */}
+ {/* Small Client Component */}
+
+ );
+}
+
+// Counter.tsx
+'use client';
+export function Counter() {
+ const [count, setCount] = useState(0);
+ return ;
+}
+```
+
+### Missing Loading States
+
+```tsx
+// β BAD: No loading state
+export default async function Page() {
+ const data = await slowFetch();
+ return {data}
;
+}
+
+// β
GOOD: Add loading.tsx
+// app/page.tsx
+export default async function Page() {
+ const data = await slowFetch();
+ return {data}
;
+}
+
+// app/loading.tsx
+export default function Loading() {
+ return Loading...
;
+}
+```
+
+### Not Revalidating After Mutations
+
+```tsx
+// β BAD: No revalidation
+'use server';
+export async function createUser(data: FormData) {
+ await db.users.create({ data: getData(data) });
+ // Page still shows old data
+}
+
+// β
GOOD: Revalidate path
+'use server';
+export async function createUser(data: FormData) {
+ await db.users.create({ data: getData(data) });
+ revalidatePath('/users');
+ redirect('/users');
+}
+```
+
+## Data Fetching Patterns
+
+### Parallel Data Fetching
+
+```tsx
+export default async function Page() {
+ // Fetch in parallel
+ const [users, posts] = await Promise.all([
+ fetchUsers(),
+ fetchPosts(),
+ ]);
+
+ return (
+
+ );
+}
+```
+
+### Sequential Data Fetching
+
+```tsx
+export default async function UserPage({ params }: { params: { id: string } }) {
+ const user = await fetchUser(params.id);
+ const posts = await fetchUserPosts(user.id); // Depends on user
+
+ return (
+
+ );
+}
+```
+
+### Streaming with Suspense
+
+```tsx
+import { Suspense } from 'react';
+
+export default function Page() {
+ return (
+
+
Dashboard
+ }>
+
+
+
+
+ );
+}
+
+async function SlowComponent() {
+ const data = await slowFetch();
+ return {data}
;
+}
+```
+
+## Caching and Revalidation
+
+### Time-Based Revalidation
+
+```tsx
+// Revalidate every hour
+export const revalidate = 3600;
+
+export default async function Page() {
+ const data = await fetch('https://api.example.com/data', {
+ next: { revalidate: 3600 }
+ });
+ return {JSON.stringify(data)}
;
+}
+```
+
+### On-Demand Revalidation
+
+```tsx
+// app/actions.ts
+'use server';
+
+import { revalidatePath, revalidateTag } from 'next/cache';
+
+export async function createPost(data: FormData) {
+ await db.posts.create({ data: getData(data) });
+ revalidatePath('/posts');
+ // or
+ revalidateTag('posts');
+}
+```
+
+## Metadata
+
+```tsx
+import { Metadata } from 'next';
+
+export const metadata: Metadata = {
+ title: 'User Profile',
+ description: 'View user profile information',
+};
+
+export default function Page() {
+ return Profile
;
+}
+
+// Dynamic metadata
+export async function generateMetadata({ params }: PageProps): Promise {
+ const user = await fetchUser(params.id);
+
+ return {
+ title: `${user.name}'s Profile`,
+ description: `Profile page for ${user.name}`,
+ };
+}
+```
+
+## Integration with Other Skills
+
+### With React
+
+See [React skill](/claudekit/skills/frameworks/react) for component patterns and hooks.
+
+### With TypeScript
+
+Full TypeScript integration:
+```tsx
+import { NextRequest, NextResponse } from 'next/server';
+
+export async function GET(
+ request: NextRequest,
+ { params }: { params: { id: string } }
+): Promise {
+ const user = await fetchUser(params.id);
+ return NextResponse.json(user);
+}
+```
+
+## Related Skills
+
+- [React](/claudekit/skills/frameworks/react) - Component patterns
+- [TypeScript](/claudekit/skills/languages/typescript) - Type safety
+- [Tailwind CSS](/claudekit/skills/frontend/tailwind) - Styling
+- [PostgreSQL](/claudekit/skills/databases/postgresql) - Database
diff --git a/website/src/content/docs/skills/frameworks/react.md b/website/src/content/docs/skills/frameworks/react.md
new file mode 100644
index 0000000..b1c190f
--- /dev/null
+++ b/website/src/content/docs/skills/frameworks/react.md
@@ -0,0 +1,287 @@
+---
+title: React
+description: React component patterns, hooks, and state management
+---
+
+The React skill provides expertise in React component patterns, hooks, context, and modern React best practices.
+
+## When Activated
+
+- Building React components
+- Using React hooks
+- Component state management
+- Working with `.jsx` or `.tsx` files containing React
+
+## Core Patterns
+
+### Functional Components
+
+```tsx
+interface UserCardProps {
+ user: User;
+ onSelect?: (user: User) => void;
+}
+
+export function UserCard({ user, onSelect }: UserCardProps) {
+ return (
+ onSelect?.(user)}>
+
{user.name}
+
{user.email}
+
Loading...
;
+ if (!user) return User not found
;
+
+ return {user.name}
;
+}
+```
+
+### Context Pattern
+
+```tsx
+const UserContext = createContext(null);
+
+export function UserProvider({ children }: { children: ReactNode }) {
+ const [user, setUser] = useState(null);
+
+ return (
+
+ {children}
+
+ );
+}
+
+export function useUser() {
+ const context = useContext(UserContext);
+ if (!context) throw new Error('useUser must be within UserProvider');
+ return context;
+}
+```
+
+## Best Practices
+
+1. **Keep components small and focused**
+2. **Use TypeScript for props**
+3. **Memoize expensive computations**
+4. **Clean up effects properly**
+5. **Lift state up when needed**
+
+## Common Pitfalls
+
+### Missing Dependencies in Hooks
+
+```tsx
+// β BAD: Missing dependency
+useEffect(() => {
+ fetchData(userId);
+}, []); // userId not in dependencies
+
+// β
GOOD: All dependencies included
+useEffect(() => {
+ fetchData(userId);
+}, [userId]);
+```
+
+### State Updates on Unmounted Components
+
+```tsx
+// β BAD: No cleanup
+useEffect(() => {
+ fetchUser(id).then(setUser);
+}, [id]);
+
+// β
GOOD: Cleanup function
+useEffect(() => {
+ let cancelled = false;
+
+ fetchUser(id).then(user => {
+ if (!cancelled) setUser(user);
+ });
+
+ return () => {
+ cancelled = true;
+ };
+}, [id]);
+```
+
+### Prop Drilling
+
+```tsx
+// β BAD: Passing props through many levels
+
+
+
+
+
+
+// β
GOOD: Use context
+
+
+
+
+ {/* Gets user from context */}
+
+
+
+
+```
+
+### Not Memoizing Callbacks
+
+```tsx
+// β BAD: New function every render
+ handleUpdate(id, data)} />
+
+// β
GOOD: Memoized callback
+const handleUpdate = useCallback((data) => {
+ updateData(id, data);
+}, [id]);
+
+
+```
+
+## Component Patterns
+
+### Compound Components
+
+```tsx
+function Tabs({ children }: { children: ReactNode }) {
+ const [activeTab, setActiveTab] = useState(0);
+
+ return (
+
+ {children}
+
+ );
+}
+
+Tabs.List = function TabsList({ children }: { children: ReactNode }) {
+ return {children}
;
+};
+
+Tabs.Tab = function Tab({ index, children }: { index: number; children: ReactNode }) {
+ const { activeTab, setActiveTab } = useTabsContext();
+ return (
+
+ );
+};
+
+// Usage
+
+
+ Tab 1
+ Tab 2
+
+
+```
+
+### Render Props
+
+```tsx
+interface DataLoaderProps {
+ url: string;
+ children: (data: T | null, loading: boolean) => ReactNode;
+}
+
+function DataLoader({ url, children }: DataLoaderProps) {
+ const [data, setData] = useState(null);
+ const [loading, setLoading] = useState(true);
+
+ useEffect(() => {
+ fetch(url)
+ .then(res => res.json())
+ .then(setData)
+ .finally(() => setLoading(false));
+ }, [url]);
+
+ return <>{children(data, loading)};
+}
+
+// Usage
+ url="/api/user">
+ {(user, loading) => (
+ loading ? :
+ )}
+
+```
+
+## Integration with Frameworks
+
+### With Next.js
+
+See [Next.js skill](/claudekit/skills/frameworks/nextjs) for server components and App Router patterns.
+
+### With Testing
+
+```tsx
+import { render, screen } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+
+it('should increment count on click', async () => {
+ render();
+
+ const button = screen.getByRole('button', { name: /increment/i });
+ await userEvent.click(button);
+
+ expect(screen.getByText('Count: 1')).toBeInTheDocument();
+});
+```
+
+## Related Skills
+
+- [TypeScript](/claudekit/skills/languages/typescript) - Type safety
+- [Next.js](/claudekit/skills/frameworks/nextjs) - Full-stack React
+- [Tailwind CSS](/claudekit/skills/frontend/tailwind) - Styling
+- [vitest](/claudekit/skills/testing/vitest) - Testing
diff --git a/website/src/content/docs/skills/languages/javascript.md b/website/src/content/docs/skills/languages/javascript.md
new file mode 100644
index 0000000..ed8fd52
--- /dev/null
+++ b/website/src/content/docs/skills/languages/javascript.md
@@ -0,0 +1,170 @@
+---
+title: JavaScript
+description: Modern JavaScript (ES6+) patterns and best practices
+---
+
+The JavaScript skill provides expertise in modern JavaScript (ES6+) for Node.js and browser environments.
+
+## When Activated
+
+- Working with JavaScript files (`.js`, `.mjs`)
+- Browser scripting
+- Node.js applications without TypeScript
+
+## Core Patterns
+
+### Modern Syntax
+
+```javascript
+// Destructuring
+const { name, email } = user;
+const [first, ...rest] = items;
+
+// Spread operator
+const merged = { ...defaults, ...options };
+const combined = [...array1, ...array2];
+
+// Template literals
+const message = `Hello, ${name}!`;
+
+// Optional chaining and nullish coalescing
+const city = user?.address?.city ?? 'Unknown';
+```
+
+### Async Patterns
+
+```javascript
+// Async/await
+async function fetchData(url) {
+ const response = await fetch(url);
+ if (!response.ok) throw new Error('Fetch failed');
+ return response.json();
+}
+
+// Promise.all for parallel
+const results = await Promise.all([
+ fetchData(url1),
+ fetchData(url2),
+]);
+
+// Error handling
+try {
+ const data = await fetchData(url);
+} catch (error) {
+ console.error('Failed:', error.message);
+}
+```
+
+### Array Methods
+
+```javascript
+// Map, filter, reduce
+const names = users.map(u => u.name);
+const active = users.filter(u => u.active);
+const total = items.reduce((sum, i) => sum + i.price, 0);
+
+// Find and includes
+const user = users.find(u => u.id === id);
+const hasAdmin = users.some(u => u.role === 'admin');
+```
+
+### Classes
+
+```javascript
+class UserService {
+ #db; // Private field
+
+ constructor(database) {
+ this.#db = database;
+ }
+
+ async findById(id) {
+ return this.#db.users.find(u => u.id === id);
+ }
+}
+```
+
+## Best Practices
+
+1. **Use `const` by default, `let` when needed**
+2. **Avoid `var` - use block-scoped declarations**
+3. **Use arrow functions for callbacks**
+4. **Handle all promise rejections**
+5. **Use ESLint for consistent style**
+
+## Common Pitfalls
+
+### Implicit Type Coercion
+
+```javascript
+// β BAD: Uses ==
+if (value == null) { }
+
+// β
GOOD: Uses ===
+if (value === null || value === undefined) { }
+// Or better:
+if (value == null) { } // Only for null/undefined check
+```
+
+### Callback Hell
+
+```javascript
+// β BAD: Nested callbacks
+getData(function(a) {
+ getMoreData(a, function(b) {
+ getMoreData(b, function(c) {
+ // ...
+ });
+ });
+});
+
+// β
GOOD: Async/await
+const a = await getData();
+const b = await getMoreData(a);
+const c = await getMoreData(b);
+```
+
+### Mutating Objects
+
+```javascript
+// β BAD: Mutates original
+function addProperty(obj) {
+ obj.newProp = 'value';
+ return obj;
+}
+
+// β
GOOD: Creates new object
+function addProperty(obj) {
+ return { ...obj, newProp: 'value' };
+}
+```
+
+### Not Handling Errors
+
+```javascript
+// β BAD: Unhandled rejection
+async function loadData() {
+ const data = await fetch(url);
+ return data.json();
+}
+
+// β
GOOD: Handle errors
+async function loadData() {
+ try {
+ const response = await fetch(url);
+ if (!response.ok) {
+ throw new Error(`HTTP ${response.status}`);
+ }
+ return response.json();
+ } catch (error) {
+ console.error('Load failed:', error);
+ throw error;
+ }
+}
+```
+
+## Related Skills
+
+- [TypeScript](/claudekit/skills/languages/typescript) - Typed JavaScript
+- [React](/claudekit/skills/frameworks/react) - UI components
+- [Next.js](/claudekit/skills/frameworks/nextjs) - Full-stack framework
diff --git a/website/src/content/docs/skills/languages/python.md b/website/src/content/docs/skills/languages/python.md
new file mode 100644
index 0000000..1c9d0ed
--- /dev/null
+++ b/website/src/content/docs/skills/languages/python.md
@@ -0,0 +1,185 @@
+---
+title: Python
+description: Modern Python development with type hints, async, and best practices
+---
+
+The Python skill provides expertise in modern Python development including type hints, async patterns, dataclasses, and Pythonic idioms.
+
+## When Activated
+
+- Working with Python files (`.py`)
+- Writing Python scripts or applications
+- Using Python frameworks (Django, FastAPI, Flask)
+- Data processing and automation
+
+## Core Patterns
+
+### Type Hints
+
+```python
+from typing import Optional, List, Dict, Union
+from collections.abc import Callable
+
+def process_items(
+ items: List[str],
+ callback: Callable[[str], None],
+ config: Optional[Dict[str, Any]] = None
+) -> List[str]:
+ """Process items with optional callback."""
+ return [callback(item) for item in items]
+```
+
+### Async/Await
+
+```python
+import asyncio
+from typing import List
+
+async def fetch_data(url: str) -> dict:
+ async with aiohttp.ClientSession() as session:
+ async with session.get(url) as response:
+ return await response.json()
+
+async def fetch_all(urls: List[str]) -> List[dict]:
+ return await asyncio.gather(*[fetch_data(url) for url in urls])
+```
+
+### Context Managers
+
+```python
+from contextlib import contextmanager
+
+@contextmanager
+def managed_resource():
+ resource = acquire_resource()
+ try:
+ yield resource
+ finally:
+ release_resource(resource)
+
+# Usage
+with managed_resource() as r:
+ r.do_something()
+```
+
+### Dataclasses
+
+```python
+from dataclasses import dataclass, field
+from datetime import datetime
+
+@dataclass
+class User:
+ id: int
+ email: str
+ name: str
+ created_at: datetime = field(default_factory=datetime.now)
+
+ def __post_init__(self):
+ self.email = self.email.lower()
+```
+
+### Pydantic Models
+
+```python
+from pydantic import BaseModel, EmailStr, Field
+
+class UserCreate(BaseModel):
+ email: EmailStr
+ name: str = Field(min_length=1, max_length=100)
+ password: str = Field(min_length=8)
+
+ class Config:
+ str_strip_whitespace = True
+```
+
+## Best Practices
+
+1. **Use type hints for all public functions**
+2. **Use dataclasses or Pydantic for data models**
+3. **Prefer context managers for resource management**
+4. **Use async for I/O-bound operations**
+5. **Follow PEP 8 style guidelines**
+
+## Common Pitfalls
+
+### Mutable Default Arguments
+
+```python
+# β BAD: Mutable default
+def add_item(item, items=[]):
+ items.append(item)
+ return items
+
+# β
GOOD: Use None and initialize
+def add_item(item, items=None):
+ if items is None:
+ items = []
+ items.append(item)
+ return items
+```
+
+### Not Closing Resources
+
+```python
+# β BAD: Manual resource management
+file = open('data.txt')
+data = file.read()
+file.close()
+
+# β
GOOD: Use with statement
+with open('data.txt') as file:
+ data = file.read()
+```
+
+### Blocking in Async
+
+```python
+# β BAD: Blocking call in async function
+async def process():
+ result = expensive_cpu_work() # Blocks event loop
+ return result
+
+# β
GOOD: Run in thread pool
+async def process():
+ loop = asyncio.get_event_loop()
+ result = await loop.run_in_executor(None, expensive_cpu_work)
+ return result
+```
+
+### Catching Bare Exceptions
+
+```python
+# β BAD: Catching everything
+try:
+ risky_operation()
+except:
+ handle_error()
+
+# β
GOOD: Specific exceptions
+try:
+ risky_operation()
+except (ValueError, TypeError) as e:
+ handle_error(e)
+```
+
+## Integration with Frameworks
+
+### With FastAPI
+
+See [FastAPI skill](/claudekit/skills/frameworks/fastapi) for API development patterns.
+
+### With Django
+
+See [Django skill](/claudekit/skills/frameworks/django) for web application patterns.
+
+### With pytest
+
+See pytest skill for testing patterns.
+
+## Related Skills
+
+- [FastAPI](/claudekit/skills/frameworks/fastapi) - REST API development
+- [Django](/claudekit/skills/frameworks/django) - Web applications
+- [pytest](/claudekit/skills/testing/pytest) - Testing framework
+- [PostgreSQL](/claudekit/skills/databases/postgresql) - Database integration
diff --git a/website/src/content/docs/skills/languages/typescript.md b/website/src/content/docs/skills/languages/typescript.md
new file mode 100644
index 0000000..5eebad3
--- /dev/null
+++ b/website/src/content/docs/skills/languages/typescript.md
@@ -0,0 +1,214 @@
+---
+title: TypeScript
+description: TypeScript development with strict typing and modern patterns
+---
+
+The TypeScript skill provides expertise in strict typing, advanced type utilities, and modern TypeScript patterns.
+
+## When Activated
+
+- Working with TypeScript files (`.ts`, `.tsx`)
+- Building typed JavaScript applications
+- React/Next.js development
+- Node.js backend development
+
+## Core Patterns
+
+### Type Definitions
+
+```typescript
+// Interfaces for objects
+interface User {
+ id: string;
+ email: string;
+ name: string;
+ createdAt: Date;
+}
+
+// Types for unions and utilities
+type Status = 'pending' | 'active' | 'inactive';
+type UserWithStatus = User & { status: Status };
+
+// Generic types
+type ApiResponse = {
+ data: T;
+ error?: string;
+ status: number;
+};
+```
+
+### Utility Types
+
+```typescript
+// Partial - all properties optional
+type UserUpdate = Partial;
+
+// Pick - select properties
+type UserPreview = Pick;
+
+// Omit - exclude properties
+type UserWithoutId = Omit;
+
+// Record - dictionary type
+type UserMap = Record;
+```
+
+### Async Patterns
+
+```typescript
+async function fetchUser(id: string): Promise {
+ const response = await fetch(`/api/users/${id}`);
+ if (!response.ok) {
+ throw new Error(`Failed to fetch user: ${response.status}`);
+ }
+ return response.json();
+}
+
+// Error handling
+async function safeOperation(
+ operation: () => Promise
+): Promise<[T, null] | [null, Error]> {
+ try {
+ const result = await operation();
+ return [result, null];
+ } catch (error) {
+ return [null, error as Error];
+ }
+}
+```
+
+### Class Patterns
+
+```typescript
+class UserService {
+ constructor(private readonly db: Database) {}
+
+ async findById(id: string): Promise {
+ return this.db.users.findUnique({ where: { id } });
+ }
+
+ async create(data: UserCreate): Promise {
+ return this.db.users.create({ data });
+ }
+}
+```
+
+### Zod Validation
+
+```typescript
+import { z } from 'zod';
+
+const UserSchema = z.object({
+ email: z.string().email(),
+ name: z.string().min(1).max(100),
+ password: z.string().min(8),
+});
+
+type UserInput = z.infer;
+
+function validateUser(data: unknown): UserInput {
+ return UserSchema.parse(data);
+}
+```
+
+## Best Practices
+
+1. **Enable strict mode in tsconfig.json**
+2. **Avoid `any` - use `unknown` and type guards**
+3. **Use interfaces for object shapes, types for unions**
+4. **Prefer `const` assertions for literal types**
+5. **Use discriminated unions for state**
+
+## Common Pitfalls
+
+### Using `any`
+
+```typescript
+// β BAD: Defeats type safety
+function process(data: any) {
+ return data.value;
+}
+
+// β
GOOD: Use unknown and type guards
+function process(data: unknown) {
+ if (typeof data === 'object' && data !== null && 'value' in data) {
+ return (data as { value: string }).value;
+ }
+ throw new Error('Invalid data');
+}
+```
+
+### Not Handling Null/Undefined
+
+```typescript
+// β BAD: Assumes user exists
+function getUserName(id: string): string {
+ const user = findUser(id);
+ return user.name; // Might crash
+}
+
+// β
GOOD: Handle null case
+function getUserName(id: string): string | null {
+ const user = findUser(id);
+ return user?.name ?? null;
+}
+```
+
+### Type Assertions Over Guards
+
+```typescript
+// β BAD: Unsafe type assertion
+const user = data as User;
+
+// β
GOOD: Type guard
+function isUser(data: unknown): data is User {
+ return (
+ typeof data === 'object' &&
+ data !== null &&
+ 'id' in data &&
+ 'email' in data
+ );
+}
+
+if (isUser(data)) {
+ // data is safely typed as User here
+}
+```
+
+### Ignoring Errors
+
+```typescript
+// β BAD: Unhandled rejection
+async function loadData() {
+ const data = await fetchData();
+ return data;
+}
+
+// β
GOOD: Handle errors
+async function loadData() {
+ try {
+ const data = await fetchData();
+ return data;
+ } catch (error) {
+ console.error('Failed to load data:', error);
+ throw error;
+ }
+}
+```
+
+## Integration with Frameworks
+
+### With React
+
+See [React skill](/claudekit/skills/frameworks/react) for component patterns.
+
+### With Next.js
+
+See [Next.js skill](/claudekit/skills/frameworks/nextjs) for full-stack patterns.
+
+## Related Skills
+
+- [JavaScript](/claudekit/skills/languages/javascript) - Parent language
+- [React](/claudekit/skills/frameworks/react) - UI components
+- [Next.js](/claudekit/skills/frameworks/nextjs) - Full-stack framework
+- [vitest](/claudekit/skills/testing/vitest) - Testing framework
diff --git a/website/src/content/docs/skills/methodology/brainstorming.md b/website/src/content/docs/skills/methodology/brainstorming.md
new file mode 100644
index 0000000..ff9380f
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/brainstorming.md
@@ -0,0 +1,378 @@
+---
+title: Brainstorming
+description: Interactive design refinement through collaborative dialogue
+---
+
+The Brainstorming skill transforms rough ideas into fully-formed designs through structured questioning and incremental validation.
+
+## Overview
+
+Brainstorming is an interactive design methodology that uses sequential questioning to clarify requirements, explore alternatives, and validate design decisions before implementation begins.
+
+**Core Principle**: One question at a time produces better designs than dumping everything at once.
+
+## When to Use
+
+Use brainstorming for:
+
+- Designing new features with unclear requirements
+- Exploring architecture decisions
+- Refining user requirements
+- Breaking down complex problems
+- When multiple valid approaches exist
+
+## When NOT to Use
+
+Skip brainstorming for:
+
+- Clear "mechanical" processes with known implementation
+- Simple bug fixes with obvious solutions
+- Tasks with explicit requirements already defined
+
+## The Three-Phase Process
+
+### Phase 1: Understanding
+
+**Goal**: Clarify requirements through sequential questioning.
+
+**Rules**:
+- Ask only ONE question per message
+- Break complex topics into multiple questions
+- Prefer multiple-choice over open-ended questions
+- Wait for user response before next question
+
+**Example**:
+
+```
+β BAD: "What authentication method do you want, and should we support SSO,
+ and what about password requirements?"
+
+β
GOOD: "Which authentication method should we use?
+ a) Username/password only
+ b) OAuth (Google, GitHub)
+ c) Both options"
+```
+
+### Phase 2: Exploration
+
+**Goal**: Present alternatives with clear trade-offs.
+
+**Process**:
+1. Present 2-3 different approaches
+2. Lead with the recommended option
+3. Explain trade-offs for each
+4. Let user choose direction
+
+**Format**:
+
+```markdown
+## Approach 1: JWT-Based Auth (Recommended)
+Stateless tokens stored in HTTP-only cookies.
+
+- **Pros**: Scalable, no server-side session storage, works across services
+- **Cons**: Cannot revoke tokens before expiry, larger cookie size
+
+## Approach 2: Session-Based Auth
+Server-side sessions with session IDs.
+
+- **Pros**: Easy revocation, smaller cookie size, familiar pattern
+- **Cons**: Requires session store (Redis), harder to scale horizontally
+
+Which approach aligns better with your goals?
+```
+
+### Phase 3: Design Presentation
+
+**Goal**: Present validated design in digestible chunks.
+
+**Rules**:
+- Break design into 200-300 word sections
+- Validate incrementally after each section
+- Be flexible - allow clarification or changes
+
+**Sections to Cover**:
+1. Architecture overview
+2. Component breakdown
+3. Data flow
+4. Error handling
+5. Testing considerations
+
+## Core Principles
+
+### YAGNI Ruthlessly
+
+Remove unnecessary features aggressively:
+
+- Question every "nice to have"
+- Start with minimal viable design
+- Add complexity only when justified
+- "We might need this later" = remove it
+
+**Example**:
+
+```
+User: "Let's add user roles, permissions, and audit logging"
+
+Brainstorming: "Do you need all of those now, or can we start with
+ basic roles and add permissions/audit later when
+ you have real requirements?"
+```
+
+### One Question at a Time
+
+Sequential questioning produces better results:
+
+- Gives user time to think deeply
+- Prevents overwhelming with choices
+- Creates natural conversation flow
+- Allows follow-up on unclear points
+
+### Multiple-Choice Preference
+
+When possible, provide structured options:
+
+```
+Instead of: "How should we handle errors?"
+
+Ask: "How should we handle validation errors?
+ a) Return 400 with error details in JSON
+ b) Return 422 with field-specific errors
+ c) Return 400 with generic error message"
+```
+
+Benefits:
+- Reduces cognitive load
+- Surfaces your understanding
+- Makes decisions concrete
+- Still allow "Other" option
+
+## Output Format
+
+After design validation, document to timestamped markdown:
+
+```markdown
+# Design: User Email Verification
+Date: 2025-01-29
+
+## Summary
+Add email verification to registration flow. Users receive verification
+email on signup, click link to verify, and are marked as verified in database.
+
+## Architecture
+- Verification token: JWT with 24-hour expiry
+- Storage: Add `verified` boolean to User table
+- Email: SendGrid API for delivery
+
+## Components
+### UserService
+- `createUser()`: Create user, send verification email
+- `verifyEmail()`: Validate token, mark user verified
+
+### EmailService
+- `sendVerificationEmail()`: Generate token, send email
+
+## Data Flow
+1. User registers β User created with verified=false
+2. System generates JWT token with user email
+3. Email sent with verification link
+4. User clicks link β Token validated
+5. User marked verified=true
+
+## Error Handling
+- Expired token: Return error, offer resend
+- Invalid token: Return 400 error
+- Already verified: Return success (idempotent)
+
+## Testing Strategy
+- Unit: Token generation, validation logic
+- Integration: Full registration β verification flow
+- Manual: Test email delivery in staging
+
+## Open Questions
+- Should unverified users have limited access? (Deferred to v2)
+```
+
+## Activation
+
+### Via Command
+
+```bash
+/brainstorm "user authentication system"
+/brainstorm --interactive "payment processing"
+```
+
+### Via Mode
+
+```bash
+/mode brainstorm
+# Now in brainstorming mode for the session
+```
+
+### Implicit Activation
+
+Brainstorming activates automatically when:
+- `/feature` command encounters unclear requirements
+- Design discussion is needed before planning
+- Multiple approaches are possible
+
+## Integration with Other Skills
+
+### Flows to Writing Plans
+
+After brainstorming completes:
+
+```bash
+# 1. Brainstorm the design
+/brainstorm "email verification"
+
+# 2. Convert design to implementation plan
+/plan designs/email-verification.md
+```
+
+### Combines with Sequential Thinking
+
+For complex decisions:
+
+```bash
+# Use sequential thinking during brainstorming
+/brainstorm --use-skill=sequential-thinking "database architecture"
+```
+
+## Examples
+
+### Example 1: Authentication Design
+
+```
+User: I need authentication
+
+Claude: What type of users will authenticate?
+ a) End users (customers)
+ b) Administrators only
+ c) Both end users and admins
+
+User: Both
+
+Claude: Should end users and admins use the same auth system?
+ a) Yes, same system with role differentiation
+ b) No, separate systems (admin has higher security)
+
+User: Same system
+
+Claude: Which authentication method?
+ a) Email/password
+ b) OAuth (Google, GitHub, etc.)
+ c) Both options
+
+User: Both
+
+Claude: [Presents 2-3 architecture approaches with trade-offs]
+```
+
+### Example 2: API Design
+
+```
+User: Design a REST API for products
+
+Claude: What operations do you need?
+ a) Read-only (GET products, search)
+ b) Full CRUD (create, read, update, delete)
+ c) Read + Create only
+
+User: Full CRUD
+
+Claude: Who can create/update/delete products?
+ a) Anyone (public API)
+ b) Authenticated users
+ c) Admins only
+
+User: Admins only
+
+Claude: [Presents API design with endpoints and auth requirements]
+```
+
+## Best Practices
+
+### Ask Better Questions
+
+```
+β "What do you want?"
+β
"Should new users start with limited access or full access?"
+
+β "How should this work?"
+β
"When a user clicks 'delete', should we:
+ a) Delete immediately
+ b) Soft delete (mark as deleted)
+ c) Require confirmation first"
+```
+
+### Validate Incrementally
+
+```
+After presenting architecture:
+"Does this architecture make sense so far, or should I clarify anything?"
+
+After data flow:
+"Is this the flow you envisioned, or should we adjust?"
+```
+
+### Push Back on Complexity
+
+```
+User: "Let's add caching, rate limiting, and API versioning"
+
+Claude: "Those are all valuable features. Which one solves your
+ immediate problem? We can add the others later when needed."
+```
+
+## Common Patterns
+
+### The "Why" Question
+
+Always understand motivation:
+
+```
+User: "Add pagination to the API"
+Claude: "What problem does pagination solve for you?
+ a) Performance (large datasets)
+ b) UX (easier navigation)
+ c) Both"
+```
+
+### The Scope Question
+
+Define boundaries early:
+
+```
+User: "Build a notification system"
+Claude: "What types of notifications?
+ a) Email only
+ b) Email + SMS
+ c) Email + SMS + Push"
+```
+
+### The Constraint Question
+
+Identify limitations:
+
+```
+User: "Design file upload"
+Claude: "What's the maximum file size you need to support?
+ a) < 10 MB (standard)
+ b) 10-100 MB (medium)
+ c) > 100 MB (large, needs chunking)"
+```
+
+## Next Steps
+
+After brainstorming:
+
+1. **Save the design**: Commit design doc to version control
+2. **Create plan**: Use [Writing Plans](/claudekit/skills/methodology/writing-plans) skill
+3. **Implement**: Use [Executing Plans](/claudekit/skills/methodology/executing-plans) skill
+4. **Review**: Use [Code Review](/claudekit/skills/methodology/code-review) skill
+
+## Related Skills
+
+- [Writing Plans](/claudekit/skills/methodology/writing-plans) - Convert designs to tasks
+- [Sequential Thinking](/claudekit/skills/methodology/sequential-thinking) - Deep analysis
+- [Executing Plans](/claudekit/skills/methodology/executing-plans) - Implement designs
diff --git a/website/src/content/docs/skills/methodology/code-review.md b/website/src/content/docs/skills/methodology/code-review.md
new file mode 100644
index 0000000..7f93122
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/code-review.md
@@ -0,0 +1,455 @@
+---
+title: Code Review
+description: Request and receive code reviews effectively
+---
+
+The Code Review skill covers both requesting reviews with clear context and processing feedback systematically.
+
+## Overview
+
+Effective code review involves clear communication when requesting reviews and systematic processing of feedback. This skill combines both requesting and receiving reviews into a cohesive workflow.
+
+## Requesting Code Reviews
+
+### When to Request
+
+- After completing a task (before proceeding to next)
+- After implementing a feature
+- Before merging to main branch
+- When unsure about implementation approach
+- After fixing critical bugs
+
+### Review Request Components
+
+#### 1. Scope Definition
+
+Clearly state what should be reviewed:
+
+```markdown
+## Review Scope
+
+**Files changed**:
+- src/services/user-service.ts (modified)
+- src/services/user-service.test.ts (added)
+- src/types/user.ts (modified)
+
+**Lines changed**: ~150 additions, ~20 deletions
+
+**Not in scope** (don't review):
+- package.json changes (unrelated dependency update)
+- Generated files in dist/
+```
+
+#### 2. Context
+
+Explain why these changes were made:
+
+```markdown
+## Context
+
+**Task**: Implement user email verification
+
+**Requirements**:
+- Users must verify email before accessing features
+- Verification link expires after 24 hours
+- Users can request new verification email
+
+**Design decisions**:
+- Used JWT for verification token (stateless)
+- Stored verification status in existing User table
+```
+
+#### 3. Areas of Concern
+
+Highlight where you want focused attention:
+
+```markdown
+## Areas of Concern
+
+1. **Security**: Is the token generation secure enough?
+2. **Error handling**: Are all edge cases covered?
+3. **Performance**: Will the verification lookup be efficient?
+```
+
+#### 4. Test Coverage
+
+Show what's tested:
+
+```markdown
+## Test Coverage
+
+- Unit tests: 8 new tests in user-service.test.ts
+- Integration: Manual testing of full flow
+- Edge cases: Expired token, invalid token, already verified
+
+**Not tested** (known gaps):
+- Load testing with many concurrent verifications
+```
+
+### Review Request Template
+
+```markdown
+## Code Review Request
+
+### Summary
+Implemented email verification for new user registrations.
+
+### Files Changed
+- `src/services/user-service.ts` - Added verification methods
+- `src/services/user-service.test.ts` - Added 8 unit tests
+- `src/types/user.ts` - Added verified field
+
+### Context
+Users now receive a verification email on signup. They must click
+the link within 24 hours to verify their account.
+
+### Implementation Notes
+- JWT tokens for stateless verification
+- Tokens expire after 24 hours
+- Idempotent verification (safe to verify twice)
+
+### Areas for Focus
+1. Token security (generation and validation)
+2. Edge case handling
+3. Test coverage completeness
+
+### Testing
+- [x] Unit tests added/updated
+- [x] Integration tests pass
+- [ ] E2E tests (not applicable)
+
+### Checklist
+- [x] Code follows project conventions
+- [x] No security vulnerabilities introduced
+- [x] Documentation updated if needed
+```
+
+## Receiving Code Reviews
+
+### Feedback Categories
+
+#### Critical Issues
+
+**Definition**: Must fix before proceeding.
+
+Examples:
+- SQL injection vulnerability
+- Unhandled null pointer
+- Data corruption possibility
+- Authentication bypass
+
+**Response**: Fix immediately. Do not proceed until resolved.
+
+#### Important Issues
+
+**Definition**: Should fix before proceeding.
+
+Examples:
+- Missing error handling
+- Inefficient algorithm
+- Poor naming
+- Missing tests for edge cases
+
+**Response**: Fix before merging. May defer to follow-up if blocking.
+
+#### Minor Issues
+
+**Definition**: Can fix later.
+
+Examples:
+- Variable naming suggestions
+- Comment improvements
+- Minor refactoring opportunities
+- Documentation polish
+
+**Response**: Note for later. Can merge without addressing.
+
+### Processing Workflow
+
+#### Step 1: Categorize All Feedback
+
+```markdown
+## Review Feedback
+
+### Critical (Must Fix)
+1. Line 45: SQL query vulnerable to injection
+2. Line 89: User data exposed in logs
+
+### Important (Should Fix)
+1. Line 23: Missing null check
+2. Line 67: Test doesn't cover error path
+
+### Minor (Can Defer)
+1. Line 12: Consider renaming 'x' to 'count'
+2. Line 34: Could extract to helper function
+```
+
+#### Step 2: Fix Critical Issues First
+
+```markdown
+Addressing critical issue 1:
+- File: src/db/queries.ts:45
+- Issue: SQL injection vulnerability
+- Fix: Use parameterized query
+- Verification: Tested with malicious input
+```
+
+#### Step 3: Fix Important Issues
+
+```markdown
+Addressing important issue 1:
+- File: src/services/user.ts:23
+- Issue: Missing null check
+- Fix: Added guard clause
+- Verification: Test added for null case
+```
+
+#### Step 4: Note Minor Issues
+
+```markdown
+Deferred for follow-up:
+- Line 12: Variable rename (tracked in TODO)
+- Line 34: Extract helper (low priority)
+```
+
+#### Step 5: Request Re-Review
+
+After fixes applied:
+
+```markdown
+## Re-Review Request
+
+### Fixed Issues
+- [x] SQL injection (line 45) - Now uses parameterized query
+- [x] Data exposure (line 89) - Removed user data from logs
+- [x] Null check (line 23) - Added guard clause
+- [x] Test coverage (line 67) - Added error path test
+
+### Deferred (Minor)
+- Variable rename (line 12) - Will address in cleanup PR
+
+### Changes Since Last Review
+- 4 files modified
+- 2 tests added
+- All previous feedback addressed
+```
+
+## Review Types
+
+### Quick Review
+
+For small, low-risk changes:
+
+```markdown
+## Quick Review: Fix typo in error message
+
+**File**: src/errors.ts
+**Change**: Fixed "recieved" β "received" in error message
+**Risk**: None
+```
+
+### Standard Review
+
+For typical feature work:
+
+```markdown
+## Review: Add user preferences
+
+**Files**: 3 files, ~200 lines
+**Context**: Users can now save display preferences
+**Focus**: Data validation, storage approach
+```
+
+### Critical Review
+
+For high-risk changes:
+
+```markdown
+## CRITICAL REVIEW: Authentication refactor
+
+**Files**: 12 files, ~800 lines
+**Risk**: HIGH - Authentication system changes
+**Required reviewers**: Security team
+**Focus**: Token handling, session management, encryption
+```
+
+## Handling Disagreements
+
+### When You Disagree
+
+1. Don't dismiss immediately
+2. Consider the reviewer's perspective
+3. Explain your reasoning
+4. Provide evidence (code, tests, docs)
+5. Be open to being wrong
+6. Escalate if needed (tech lead, team discussion)
+
+### Disagreement Response Template
+
+```markdown
+## Re: Token expiration approach
+
+I considered this feedback carefully. Here's my perspective:
+
+**Reviewer's concern**: Token should expire after 1 hour
+**My reasoning**: 24 hours allows users to verify later
+**Evidence**: User research shows 40% verify after 6+ hours
+**Proposed resolution**: Keep 24 hours, add configurable option
+```
+
+## Common Feedback Types
+
+### Security Issues
+
+Always fix immediately:
+
+```typescript
+// Before (vulnerable)
+const query = `SELECT * FROM users WHERE id = '${userId}'`;
+
+// After (secure)
+const query = 'SELECT * FROM users WHERE id = $1';
+const result = await db.query(query, [userId]);
+```
+
+### Error Handling
+
+Add comprehensive handling:
+
+```typescript
+// Before
+const user = await getUser(id);
+return user.name;
+
+// After
+const user = await getUser(id);
+if (!user) {
+ throw new NotFoundError(`User ${id} not found`);
+}
+return user.name;
+```
+
+### Test Coverage
+
+Add missing tests:
+
+```typescript
+// Before: Only happy path tested
+it('should return user', async () => {
+ const user = await getUser('valid-id');
+ expect(user).toBeDefined();
+});
+
+// After: Edge cases covered
+it('should return user', async () => { /* ... */ });
+it('should throw NotFoundError for missing user', async () => { /* ... */ });
+it('should throw ValidationError for invalid id', async () => { /* ... */ });
+```
+
+## Re-Review Checklist
+
+Before requesting re-review:
+
+- [ ] All Critical issues fixed
+- [ ] All Important issues fixed (or explicitly deferred with reason)
+- [ ] Minor issues noted for follow-up
+- [ ] Tests added/updated for fixes
+- [ ] Full test suite passes
+- [ ] Changes summarized for reviewer
+
+## Iteration Limits
+
+If review requires 3+ cycles:
+
+1. STOP
+2. Schedule discussion with reviewer
+3. Identify root cause of misalignment
+4. May need design discussion
+5. Don't keep iterating endlessly
+
+## Activation
+
+### Requesting Reviews
+
+```bash
+/review src/services/user-service.ts
+/review --persona=security src/auth/
+/ship --review "implement email verification"
+```
+
+### After Executing Plans
+
+Automatic code review between tasks when using [Executing Plans](/claudekit/skills/methodology/executing-plans).
+
+## Integration with Other Skills
+
+### With Executing Plans
+
+[Executing Plans](/claudekit/skills/methodology/executing-plans) includes automatic code review:
+- Review after each task
+- Categorize issues (Critical/Important/Minor)
+- Fix before proceeding
+
+### With TDD
+
+Code reviews check:
+- Tests exist for new code
+- Tests follow TDD pattern (written first)
+- Tests cover edge cases
+
+### With Verification
+
+Reviews verify:
+- Claims are backed by evidence
+- Tests actually pass
+- No unverified assertions
+
+## Best Practices
+
+### Keep Reviews Focused
+
+```
+β
"Review the user verification feature (3 files)"
+β "Review my last week of work"
+```
+
+### Provide Runnable Context
+
+```markdown
+## To test locally
+1. git checkout feature/email-verification
+2. npm install
+3. npm test -- --grep "email verification"
+```
+
+### Be Specific About Concerns
+
+```
+β
"I'm unsure about the error handling in lines 45-60"
+β "Let me know if anything looks wrong"
+```
+
+### Respond to All Feedback
+
+```markdown
+β
Issue 1: Fixed
+β
Issue 2: Fixed
+β
Issue 3: Disagree, here's why (with evidence)
+β
Issue 4: Deferred to follow-up PR #123
+```
+
+## Next Steps
+
+After review approval:
+
+1. **Merge code**: If all issues resolved
+2. **Follow-up tasks**: Create tickets for deferred issues
+3. **Documentation**: Update if needed
+4. **Deployment**: Use [deploy command](/claudekit/commands/deploy)
+
+## Related Skills
+
+- [Executing Plans](/claudekit/skills/methodology/executing-plans) - Automated reviews
+- [TDD](/claudekit/skills/methodology/tdd) - Test coverage checks
+- [Verification](/claudekit/skills/methodology/verification) - Evidence-based claims
+- [Security (OWASP)](/claudekit/skills/security/owasp) - Security review focus
diff --git a/website/src/content/docs/skills/methodology/executing-plans.md b/website/src/content/docs/skills/methodology/executing-plans.md
new file mode 100644
index 0000000..404f18a
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/executing-plans.md
@@ -0,0 +1,472 @@
+---
+title: Executing Plans
+description: Subagent-driven plan execution with quality gates
+---
+
+The Executing Plans skill automates implementation of detailed plans using fresh agents per task and mandatory code review between tasks.
+
+## Overview
+
+Executing Plans bridges planning and delivery through systematic, quality-gated execution. Each task runs in isolation with independent review, preventing context pollution and ensuring consistent quality.
+
+**Core Pattern**: Fresh subagent per task + review between tasks = high quality, fast iteration
+
+## When to Use
+
+- Executing plans created with [Writing Plans](/claudekit/skills/methodology/writing-plans) skill
+- Staying in current session with independent tasks
+- Wanting quality gates without human delays
+- Systematic implementation with verification
+
+## When NOT to Use
+
+- Plan needs review first (use brainstorming)
+- Tasks are tightly coupled and need shared context
+- Plan requires revision during execution
+
+## The Workflow
+
+### Step 1: Load Plan
+
+```markdown
+1. Read the plan file
+2. Verify plan is complete and approved
+3. Create task tracking with all tasks
+4. Set first task to in_progress
+```
+
+### Step 2: Execute Task
+
+For each task:
+
+```markdown
+1. Dispatch fresh subagent with task details
+2. Subagent implements following TDD cycle:
+ - Write failing test
+ - Verify test fails
+ - Implement minimally
+ - Verify test passes
+ - Commit
+3. Subagent returns completion summary
+```
+
+### Step 3: Code Review
+
+After each task:
+
+```markdown
+1. Dispatch code-reviewer subagent
+2. Review scope: only changes from current task
+3. Reviewer returns findings:
+ - Critical: Must fix before proceeding
+ - Important: Should fix before proceeding
+ - Minor: Can fix later
+```
+
+### Step 4: Handle Review Findings
+
+```markdown
+IF Critical or Important issues found:
+ 1. Dispatch fix subagent for each issue
+ 2. Re-request code review
+ 3. Repeat until no Critical/Important issues
+
+IF only Minor issues:
+ 1. Note for later cleanup
+ 2. Proceed to next task
+```
+
+### Step 5: Mark Complete
+
+```markdown
+1. Update task tracking - mark task completed
+2. Move to next task
+3. Repeat from Step 2
+```
+
+### Step 6: Final Review
+
+After all tasks complete:
+
+```markdown
+1. Dispatch comprehensive code review
+2. Review entire implementation against plan
+3. Verify all success criteria met
+4. Run full test suite
+5. Use finishing-development-branch skill
+```
+
+## Critical Rules
+
+### Never Skip Code Reviews
+
+Every task must be reviewed before proceeding. No exceptions.
+
+**Why**: Catches issues when they're easiest to fix.
+
+### Never Proceed with Critical Issues
+
+Critical issues must be fixed immediately:
+
+```
+implement β review β fix critical β re-review β proceed
+```
+
+**Not**:
+```
+implement β review β note issue β proceed anyway
+```
+
+### Never Run Parallel Implementation
+
+Tasks run sequentially:
+
+```
+β WRONG: Run Task 1, 2, 3 simultaneously
+β
RIGHT: Run Task 1 β Review β Task 2 β Review β Task 3 β Review
+```
+
+**Why**: Each task may depend on previous tasks being correct.
+
+### Always Read Plan Before Implementing
+
+```
+β WRONG: Start coding based on memory of plan
+β
RIGHT: Read plan file, extract task details, then implement
+```
+
+## Subagent Communication
+
+### Implementation Subagent Prompt
+
+```markdown
+## Task: Add verified flag to User model
+
+**Context**: Executing plan for Email Verification feature
+
+**Files to modify**:
+- Modify: src/models/user.ts
+- Test: src/models/user.test.ts
+
+**Steps**:
+1. Write failing test for verified flag
+2. Verify test fails (run npm test)
+3. Add verified field to User model
+4. Verify test passes
+5. Commit changes
+
+**Requirements**:
+- Follow TDD: test first, then implement
+- Commit after completion
+- Return summary of what was done
+
+**Output expected**:
+- Files modified: [list]
+- Tests added: [count]
+- Commit hash: [hash]
+- Any issues encountered: [none or details]
+```
+
+### Code Review Subagent Prompt
+
+```markdown
+## Code Review Request
+
+**Scope**: Changes from Task 3: Add login endpoint
+
+**Files changed**:
+- src/routes/auth.ts
+- src/routes/auth.test.ts
+- src/middleware/auth.ts
+
+**Review against**:
+- Plan requirements for this task
+- Code quality standards
+- Security best practices
+- Test coverage requirements
+
+**Return**:
+- Critical issues (must fix before continuing)
+- Important issues (should fix before continuing)
+- Minor issues (can defer)
+- Approval status (approved / needs fixes)
+```
+
+## Task Tracking
+
+Track status throughout execution:
+
+```markdown
+| Task | Status | Reviewed |
+|------|--------|----------|
+| Task 1: Create model | completed | β |
+| Task 2: Add validation | completed | β |
+| Task 3: Create endpoint | in_progress | - |
+| Task 4: Add tests | pending | - |
+| Task 5: Documentation | pending | - |
+```
+
+Status values:
+- `pending` - Not started
+- `in_progress` - Currently being implemented
+- `completed` - Done and reviewed
+
+## Error Handling
+
+### Task Fails
+
+```markdown
+1. Capture error details
+2. Attempt fix (max 2 retries)
+3. If still failing, pause execution
+4. Report to user with:
+ - Which task failed
+ - Error details
+ - Suggested resolution
+5. Wait for user decision
+```
+
+### Review Finds Major Issues
+
+```markdown
+1. List all Critical/Important issues
+2. Dispatch fix subagent for each
+3. Re-run code review
+4. If issues persist after 2 cycles:
+ - Pause execution
+ - Report to user
+ - May need plan revision
+```
+
+## Activation
+
+### Via Command
+
+```bash
+/execute-plan plans/feature-x.md
+/execute-plan plans/feature-x.md --parallel-reviews # Review multiple tasks
+```
+
+### From Writing Plans
+
+```bash
+/plan "add email verification"
+# Plan created at plans/email-verification.md
+
+"Would you like to execute this plan now?"
+> Yes
+
+# Begins execution automatically
+```
+
+## Example Execution
+
+```markdown
+## Plan Execution: Email Verification
+
+### Status: In Progress (Task 3 of 8)
+
+---
+
+### Task 1: Add verified flag β
+**Implementation**: Completed in 3 minutes
+- Added `verified: boolean` field to User model
+- Test: user.test.ts (1 new test)
+- Commit: a1b2c3d
+
+**Code Review**: Approved
+- No issues found
+- Test coverage: 100%
+
+---
+
+### Task 2: Create verification token β
+**Implementation**: Completed in 4 minutes
+- Added token generation utility
+- Test: token.test.ts (3 new tests)
+- Commit: e4f5g6h
+
+**Code Review**: 1 Important issue found
+- Issue: Token expiry not validated
+- Fix: Added expiry check
+- Re-review: Approved
+
+---
+
+### Task 3: Send verification email β³
+**Status**: Implementation in progress...
+```
+
+## Completion Checklist
+
+Before declaring plan execution complete:
+
+- [ ] All tasks marked completed
+- [ ] All code reviews passed
+- [ ] Full test suite passes
+- [ ] No Critical issues outstanding
+- [ ] No Important issues outstanding
+- [ ] Final comprehensive review done
+- [ ] Ready for branch cleanup/merge
+
+## Integration with Other Skills
+
+### From Writing Plans
+
+```bash
+# 1. Create plan
+/plan "feature X"
+
+# 2. Execute plan
+/execute-plan plans/feature-x.md
+```
+
+### With TDD
+
+Every task implementation follows [TDD](/claudekit/skills/methodology/tdd):
+1. Write failing test
+2. Verify it fails
+3. Implement minimally
+4. Verify it passes
+
+### With Code Review
+
+Automatic [code review](/claudekit/skills/methodology/code-review) after each task:
+- Categorizes issues (Critical/Important/Minor)
+- Enforces fixes before proceeding
+- Maintains code quality
+
+### With Verification
+
+Uses [verification before completion](/claudekit/skills/methodology/verification):
+- Never claims completion without proof
+- Runs tests to verify
+- Checks actual output
+
+## Best Practices
+
+### Review Scope
+
+Keep review focused on current task:
+
+```
+β
"Review changes in src/auth.ts from Task 5"
+β "Review the entire codebase"
+```
+
+### Fresh Agents
+
+Each task gets a clean slate:
+
+```
+Task 1 Agent: Focuses only on Task 1
+Task 2 Agent: No memory of Task 1 details
+Task 3 Agent: No memory of Task 1 or 2
+```
+
+**Benefit**: No context pollution, clearer focus.
+
+### Incremental Quality
+
+Fix issues immediately:
+
+```
+Task β Review β Issues Found β Fix β Re-review β Pass β Next Task
+```
+
+**Not**:
+```
+Task 1 β Issues noted
+Task 2 β More issues noted
+Task 3 β Try to fix all issues (context lost)
+```
+
+## Common Patterns
+
+### Standard Task
+
+```markdown
+1. Load task from plan
+2. Dispatch implementation agent
+3. Agent implements with TDD
+4. Agent commits
+5. Dispatch review agent
+6. If approved β next task
+7. If issues β fix β re-review
+```
+
+### Error Recovery
+
+```markdown
+1. Task fails
+2. Capture error
+3. Attempt automatic fix
+4. If fix works β review β proceed
+5. If fix fails β pause β report to user
+```
+
+### Quality Gate
+
+```markdown
+After each task:
+1. Code review categorizes issues
+2. Critical β Must fix (block)
+3. Important β Should fix (block)
+4. Minor β Note for later (allow)
+```
+
+## Troubleshooting
+
+### Task Keeps Failing
+
+```markdown
+Problem: Task 5 fails 3 times
+
+Actions:
+1. STOP execution
+2. Review task requirements
+3. Check if plan needs adjustment
+4. May need to revise approach
+5. Consult user before continuing
+```
+
+### Review Never Passes
+
+```markdown
+Problem: Task 2 reviewed 3 times, still has issues
+
+Actions:
+1. PAUSE execution
+2. Review the review feedback
+3. May indicate plan gap
+4. May need design discussion
+5. Don't iterate endlessly
+```
+
+### Tests Pass Individually, Fail Together
+
+```markdown
+Problem: Each task's tests pass, but full suite fails
+
+Actions:
+1. Identify test interdependencies
+2. Fix test isolation
+3. May need test setup/teardown improvements
+4. Run full suite after each task (not just new tests)
+```
+
+## Next Steps
+
+After plan execution completes:
+
+1. **Final verification**: Run full test suite
+2. **Cleanup**: Address Minor issues noted during reviews
+3. **Documentation**: Update docs if needed
+4. **Branch finishing**: Use finishing-development-branch skill
+
+## Related Skills
+
+- [Writing Plans](/claudekit/skills/methodology/writing-plans) - Create plans to execute
+- [TDD](/claudekit/skills/methodology/tdd) - Test-first implementation
+- [Code Review](/claudekit/skills/methodology/code-review) - Quality gates
+- [Verification](/claudekit/skills/methodology/verification) - Prove completion
diff --git a/website/src/content/docs/skills/methodology/sequential-thinking.md b/website/src/content/docs/skills/methodology/sequential-thinking.md
new file mode 100644
index 0000000..a22e12a
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/sequential-thinking.md
@@ -0,0 +1,391 @@
+---
+title: Sequential Thinking
+description: Step-by-step reasoning with evidence and confidence tracking
+---
+
+The Sequential Thinking skill provides a structured methodology for complex problem analysis using explicit evidence collection and confidence tracking.
+
+## Overview
+
+Sequential Thinking breaks down complex problems into systematic steps with documented evidence, hypotheses, and confidence scores. This approach creates an audit trail of decision-making and prevents jumping to conclusions.
+
+**Use for**: Complex debugging, architecture decisions, security analysis, performance investigation
+
+## When to Use
+
+- Complex debugging
+- Architecture decisions
+- Security analysis
+- Performance investigation
+- Any problem with multiple possible causes
+- When decisions need documentation
+
+## The Sequential Process
+
+### Step 1: Define the Question
+
+Clearly state what you're investigating:
+
+```markdown
+## Question
+What is causing the authentication timeout for users with special characters in passwords?
+```
+
+### Step 2: Gather Evidence
+
+Collect all relevant information systematically:
+
+```markdown
+## Evidence Collection
+
+### Evidence 1: Error Logs
+- Source: `logs/auth-service.log`
+- Finding: Timeout occurs at password encoding step
+- Confidence: High (direct observation)
+
+### Evidence 2: Code Review
+- Source: `src/auth/password.ts:42`
+- Finding: URL encoding applied to password
+- Confidence: High (code inspection)
+
+### Evidence 3: Test Results
+- Source: Manual testing
+- Finding: Works with alphanumeric, fails with `@#$`
+- Confidence: High (reproducible)
+```
+
+### Step 3: Form Hypotheses
+
+Generate possible explanations:
+
+```markdown
+## Hypotheses
+
+### Hypothesis A: URL Encoding Issue
+- Evidence supporting: E1, E2, E3
+- Evidence against: None
+- Probability: 80%
+
+### Hypothesis B: Character Set Mismatch
+- Evidence supporting: E3
+- Evidence against: E2 (UTF-8 used)
+- Probability: 15%
+
+### Hypothesis C: Database Encoding
+- Evidence supporting: None directly
+- Evidence against: E1 (fails before DB)
+- Probability: 5%
+```
+
+### Step 4: Test Hypotheses
+
+Verify the most likely explanation:
+
+```markdown
+## Testing
+
+### Test for Hypothesis A
+Action: Remove URL encoding, use base64 instead
+Result: Password `test@123` now works
+Conclusion: Hypothesis A confirmed
+```
+
+### Step 5: Document Conclusion
+
+State the final answer with confidence:
+
+```markdown
+## Conclusion
+
+**Root Cause**: URL encoding in password.ts:42 mangles special characters
+
+**Confidence**: 9/10
+
+**Evidence Chain**:
+1. Timeout at encoding step (logs)
+2. URL encoding in code (review)
+3. Special char passwords fail (testing)
+4. Removing encoding fixes issue (verification)
+
+**Fix**: Replace URL encoding with base64 at line 42
+```
+
+## Output Template
+
+```markdown
+# Sequential Analysis: [Problem Description]
+
+## Question
+[Clear statement of what we're investigating]
+
+## Evidence
+
+### Evidence 1: [Title]
+- Source: [where found]
+- Finding: [what it shows]
+- Confidence: [High/Medium/Low]
+
+### Evidence 2: [Title]
+...
+
+## Hypotheses
+
+### Hypothesis A: [Name]
+- Supporting evidence: [list]
+- Contradicting evidence: [list]
+- Probability: [X%]
+
+### Hypothesis B: [Name]
+...
+
+## Testing
+
+### Test 1: [What tested]
+- Action: [what was done]
+- Expected: [what should happen if hypothesis true]
+- Actual: [what happened]
+- Result: [confirms/refutes hypothesis]
+
+## Conclusion
+
+**Answer**: [clear statement]
+**Confidence**: [X/10]
+**Key Evidence**: [most important findings]
+**Recommended Action**: [what to do next]
+```
+
+## Confidence Scoring
+
+| Score | Meaning | Evidence Required |
+|-------|---------|-------------------|
+| 9-10 | Certain | Multiple independent confirmations |
+| 7-8 | High | Strong evidence, tested hypothesis |
+| 5-6 | Medium | Good evidence, some uncertainty |
+| 3-4 | Low | Limited evidence, multiple possibilities |
+| 1-2 | Guess | Insufficient evidence |
+
+## Anti-Patterns
+
+### Jumping to Conclusions
+
+```
+β "The bug is probably in the database"
+β
"Let me gather evidence before hypothesizing"
+```
+
+### Confirmation Bias
+
+```
+β Only looking for evidence supporting first guess
+β
Actively seeking contradicting evidence
+```
+
+### Skipping Documentation
+
+```
+β Fixing without recording reasoning
+β
Document even simple analysis for future reference
+```
+
+## Activation
+
+### Via Mode
+
+```bash
+/mode deep-research
+# Enables sequential thinking for session
+```
+
+### Via Command
+
+```bash
+/research --sequential "authentication timeout"
+/debug --sequential "performance degradation"
+```
+
+### Explicit Request
+
+```
+"Use sequential thinking to analyze why the cache is returning stale data"
+```
+
+## Example Analysis
+
+```markdown
+# Sequential Analysis: API Response Time Degradation
+
+## Question
+Why did API response times increase from 100ms to 3000ms after deployment?
+
+## Evidence
+
+### Evidence 1: Deployment Timing
+- Source: Deployment logs
+- Finding: Degradation started 5 minutes after deploy at 2:34 PM
+- Confidence: High (exact timing match)
+
+### Evidence 2: Database Query Logs
+- Source: PostgreSQL slow query log
+- Finding: No new slow queries, same query times as before
+- Confidence: High (database not the cause)
+
+### Evidence 3: Code Changes
+- Source: git diff deploy-123
+- Finding: Added Redis caching to user lookup
+- Confidence: High (code inspection)
+
+### Evidence 4: Redis Metrics
+- Source: Redis monitoring
+- Finding: Redis responding in < 1ms per request
+- Confidence: High (Redis not slow)
+
+### Evidence 5: Network Latency
+- Source: Application metrics
+- Finding: 2900ms spent waiting for external API
+- Confidence: High (measured directly)
+
+### Evidence 6: Code Review of Caching Logic
+- Source: src/services/user.ts:45-60
+- Finding: Cache miss triggers external API call
+- Confidence: High (code inspection)
+
+### Evidence 7: Cache Hit Rate
+- Source: Application metrics
+- Finding: Cache hit rate: 5% (95% miss rate)
+- Confidence: High (measured)
+
+## Hypotheses
+
+### Hypothesis A: Cache Not Working Properly
+- Supporting: E3 (caching added), E7 (low hit rate)
+- Contradicting: E4 (Redis is fast)
+- Probability: 60%
+- Details: Cache might not be storing data correctly
+
+### Hypothesis B: External API Became Slow
+- Supporting: E5 (external API latency)
+- Contradicting: E1 (timing matches deploy, not external change)
+- Probability: 20%
+
+### Hypothesis C: Cache Key Mismatch
+- Supporting: E3 (new code), E7 (low hit rate), E6 (cache logic)
+- Contradicting: None
+- Probability: 90% (after code review)
+- Details: New code might generate different cache keys than lookup
+
+## Testing
+
+### Test 1: Verify Cache Storage
+- Action: Log cache keys on write and read
+- Expected: Keys should match
+- Actual: Write key: `user:123`, Read key: `user:{"id":"123"}`
+- Result: CONFIRMED - Key mismatch found
+
+### Test 2: Fix Cache Key Format
+- Action: Standardize cache key format in both write and read
+- Expected: Hit rate should increase dramatically
+- Actual: Hit rate increased to 95%, response time back to 100ms
+- Result: CONFIRMED - This was the root cause
+
+## Conclusion
+
+**Root Cause**: Cache key format mismatch between write and read operations
+
+**Confidence**: 10/10 (tested and verified)
+
+**Evidence Chain**:
+1. Timing matches deployment (E1)
+2. Caching logic was added (E3)
+3. Cache hit rate extremely low (E7)
+4. Cache keys don't match between read/write (Test 1)
+5. Fixing keys resolves issue (Test 2)
+
+**Fix Applied**: Standardized cache key format in user.ts:45-60
+
+**Recommended Follow-up**:
+1. Add unit tests for cache key generation
+2. Add monitoring for cache hit rate
+3. Review other services for similar issues
+```
+
+## Integration with Other Skills
+
+### With Systematic Debugging
+
+Sequential Thinking provides the framework, [Systematic Debugging](/claudekit/skills/methodology/systematic-debugging) provides the debugging-specific workflow.
+
+### With TDD
+
+After identifying root cause:
+1. Write test that reproduces issue (TDD red)
+2. Fix based on conclusion (TDD green)
+3. Verify test passes (TDD verify)
+
+### With Verification
+
+All conclusions must be verified with [evidence-based completion](/claudekit/skills/methodology/verification).
+
+## Best Practices
+
+### Number Your Evidence
+
+Makes it easy to reference: "E1 and E3 support Hypothesis A"
+
+### Update Probabilities
+
+As you gather evidence, adjust hypothesis probabilities
+
+### Document Contradictions
+
+Evidence against a hypothesis is as valuable as evidence for it
+
+### Test Highest Probability First
+
+Focus effort on most likely causes
+
+## Common Use Cases
+
+### Security Analysis
+
+```markdown
+Question: Is this authentication bypass a real vulnerability?
+Evidence: Code review, test results, security logs
+Hypotheses: Multiple attack vectors
+Testing: Actual exploit attempts
+Conclusion: Confirmed vulnerability with 9/10 confidence
+```
+
+### Performance Investigation
+
+```markdown
+Question: What's causing 95th percentile latency spike?
+Evidence: Metrics, logs, profiling data
+Hypotheses: Database, network, algorithm
+Testing: Controlled experiments
+Conclusion: Database connection pool exhaustion
+```
+
+### Architecture Decision
+
+```markdown
+Question: Should we use microservices or monolith?
+Evidence: Team size, requirements, constraints
+Hypotheses: Different architectural patterns
+Testing: Prototype both approaches
+Conclusion: Monolith recommended with 8/10 confidence
+```
+
+## Next Steps
+
+After completing sequential analysis:
+
+1. **Implement fix** based on conclusion
+2. **Add regression test** to prevent recurrence
+3. **Document learning** for future reference
+4. **Review similar code** for related issues
+
+## Related Skills
+
+- [Systematic Debugging](/claudekit/skills/methodology/systematic-debugging) - Debugging methodology
+- [Verification](/claudekit/skills/methodology/verification) - Evidence-based completion
+- [Root Cause Tracing](/claudekit/skills/methodology/root-cause-tracing) - Deep investigation
diff --git a/website/src/content/docs/skills/methodology/systematic-debugging.md b/website/src/content/docs/skills/methodology/systematic-debugging.md
new file mode 100644
index 0000000..f5740d6
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/systematic-debugging.md
@@ -0,0 +1,336 @@
+---
+title: Systematic Debugging
+description: Four-phase debugging methodology for finding root causes
+---
+
+The Systematic Debugging skill uses a structured four-phase process centered on finding root causes before implementing fixes.
+
+**Foundational Principle**: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+
+## Overview
+
+Systematic debugging prevents "whack-a-mole" bug fixing by requiring thorough investigation before any code changes. This approach saves time by fixing the actual problem, not symptoms.
+
+## When to Use
+
+- Bug reports with unclear cause
+- Errors appearing in production
+- Tests failing unexpectedly
+- Intermittent/flaky issues
+- Complex multi-component failures
+
+## The Four Phases
+
+### Phase 1: Root Cause Investigation
+
+**Goal**: Understand what's happening before attempting to fix.
+
+**Steps**:
+
+1. **Read error messages carefully**
+ - What is the exact error message?
+ - What is the stack trace?
+ - What line numbers are mentioned?
+ - What values are shown?
+
+2. **Reproduce consistently**
+ - Can you trigger the bug reliably?
+ - What exact steps reproduce it?
+ - What environment is required?
+ - Document the reproduction steps
+
+3. **Track recent changes**
+ - What changed recently?
+ - `git log --oneline -20`
+ - When did it last work?
+ - What was deployed?
+
+4. **Gather evidence**
+ - Collect logs
+ - Check monitoring/metrics
+ - Review related code
+ - Note any patterns
+
+5. **Add instrumentation** (for multi-component systems)
+ ```typescript
+ // Add diagnostic logging at each boundary
+ console.error('[DEBUG] Input received:', JSON.stringify(input));
+ console.error('[DEBUG] After validation:', JSON.stringify(validated));
+ console.error('[DEBUG] Before database call:', JSON.stringify(query));
+ console.error('[DEBUG] Database result:', JSON.stringify(result));
+ ```
+
+### Phase 2: Pattern Analysis
+
+**Goal**: Find comparable working code to identify differences.
+
+**Steps**:
+
+1. **Find working code**
+ - Is there similar functionality that works?
+ - What did this code look like before?
+ - Are there reference implementations?
+
+2. **Study reference thoroughly**
+ - How does the working version handle this case?
+ - What dependencies does it use?
+ - What assumptions does it make?
+
+3. **Identify differences**
+ - What's different between working and broken?
+ - Configuration differences?
+ - Data differences?
+ - Environment differences?
+
+4. **Understand dependencies**
+ - What does this code depend on?
+ - What depends on this code?
+ - Are dependencies behaving correctly?
+
+### Phase 3: Hypothesis and Testing
+
+**Goal**: Form and test a specific theory about the cause.
+
+**Steps**:
+
+1. **Form specific hypothesis**
+ ```markdown
+ Write it down explicitly:
+ "The bug occurs because [X] causes [Y] when [Z]"
+
+ Example:
+ "The bug occurs because the cache returns stale data
+ when the user's session expires during an active request"
+ ```
+
+2. **Test with minimal changes**
+ - Change ONE variable at a time
+ - Don't combine multiple fixes
+ - Verify results after each change
+
+3. **Validate hypothesis**
+ - Does the fix address the hypothesis?
+ - Can you explain WHY it works?
+ - Does it make the bug impossible, not just unlikely?
+
+### Phase 4: Implementation
+
+**Goal**: Fix properly with verification.
+
+**Steps**:
+
+1. **Write failing test first**
+ ```typescript
+ it('should handle expired session during request', () => {
+ // Reproduce the bug scenario
+ const session = createExpiredSession();
+ const result = processRequest(session);
+
+ // This should fail before the fix
+ expect(result.error).toBe('SESSION_EXPIRED');
+ });
+ ```
+
+2. **Implement single targeted fix**
+ ```typescript
+ // Fix addresses root cause, not symptom
+ function processRequest(session: Session) {
+ if (session.isExpired()) {
+ return { error: 'SESSION_EXPIRED' };
+ }
+ // ... rest of logic
+ }
+ ```
+
+3. **Verify fix works**
+ ```bash
+ npm test -- --grep "expired session"
+ # Should pass
+ ```
+
+4. **Verify no regressions**
+ ```bash
+ npm test
+ # All tests should pass
+ ```
+
+## The Three-Fix Rule
+
+**If three or more fixes fail consecutively, STOP.**
+
+This signals an architectural problem, not a simple bug:
+
+```markdown
+Fix attempt 1: Failed
+Fix attempt 2: Failed
+Fix attempt 3: Failed
+
+STOP: This is not a bug - this is a design problem.
+
+Action: Discuss with user/team before proceeding
+- Explain what's been tried
+- Explain why it's not working
+- Propose architectural changes
+```
+
+## Key Principles
+
+### Never Skip Error Details
+
+```
+β BAD: "There's an error somewhere"
+β
GOOD: "TypeError: Cannot read property 'id' of undefined
+ at UserService.getUser (user-service.ts:42)"
+```
+
+### Reproduce Before Investigating
+
+```
+β BAD: "I think I know what's wrong" (starts coding)
+β
GOOD: "Let me reproduce this first" (writes repro steps)
+```
+
+### Trace Backward to Origin
+
+```
+β BAD: Fix where error appears
+β
GOOD: Trace data backward to find where it became invalid
+```
+
+### One Change Per Test
+
+```
+β BAD: "I changed A, B, and C - now it works!"
+ (Which one fixed it? Are the others safe?)
+
+β
GOOD: "I changed A - still broken.
+ I reverted A and changed B - now it works.
+ B was the fix."
+```
+
+## Debugging Checklist
+
+Before attempting any fix:
+
+- [ ] Error message fully read and understood
+- [ ] Bug reproduced consistently
+- [ ] Recent changes reviewed
+- [ ] Evidence gathered (logs, traces)
+- [ ] Hypothesis written down
+- [ ] Similar working code identified
+- [ ] Root cause identified (not just symptom)
+
+Before declaring fixed:
+
+- [ ] Failing test written
+- [ ] Fix implemented
+- [ ] Test passes
+- [ ] No regressions (full test suite passes)
+- [ ] Fix explained (can articulate why it works)
+
+## Activation
+
+```bash
+/fix "timeout error in auth service"
+/debug --systematic "flaky test"
+/feature --debug-mode "fix login bug"
+```
+
+## Integration with Other Skills
+
+### With TDD
+
+1. Reproduce bug with failing test (TDD red)
+2. Investigate root cause (Debugging)
+3. Fix root cause (TDD green)
+4. Verify test passes (TDD verify)
+
+### With Sequential Thinking
+
+For complex bugs, combine with [sequential thinking](/claudekit/skills/methodology/sequential-thinking):
+- Document evidence systematically
+- Form hypotheses with confidence scores
+- Test hypotheses methodically
+
+### With Verification
+
+Always verify fix with [verification before completion](/claudekit/skills/methodology/verification):
+- Run test before fix (must fail)
+- Run test after fix (must pass)
+- Run full suite (must pass)
+
+## Example Debugging Session
+
+```markdown
+## Bug: Users logged out randomly
+
+### Phase 1: Investigation
+- Error: "Session not found" in production logs
+- Reproduces: Yes, after 30-45 minutes of inactivity
+- Recent changes: Session timeout increased to 1 hour (commit abc123)
+- Evidence: Session exists in Redis, but app can't find it
+
+### Phase 2: Pattern Analysis
+- Working code: Login endpoint creates sessions correctly
+- Difference: Session keys use different format after timeout change
+- Key format before: `sess:user-id`
+- Key format after: `session:user-id`
+
+### Phase 3: Hypothesis
+"The timeout change introduced a key format mismatch. Old sessions use
+ 'sess:' prefix, new code looks for 'session:' prefix."
+
+Test: Check Redis for both key formats
+Result: Confirmed - old keys exist with 'sess:' prefix
+
+### Phase 4: Implementation
+1. Test: Verify session lookup handles both formats
+2. Fix: Update lookup to check both prefixes
+3. Verify: Test passes, no more random logouts
+4. Full suite: All tests pass
+
+## Root Cause
+Key prefix changed in commit abc123 without migration of existing sessions.
+
+## Fix
+Check both 'sess:' and 'session:' prefixes during lookup until old sessions expire.
+```
+
+## Common Pitfalls
+
+### Fixing Symptoms
+
+```
+β "Error happens at line 42, I'll add a try-catch"
+β
"Why does line 42 error? What's the invalid data?"
+```
+
+### Shotgun Debugging
+
+```
+β "Let me try changing A, B, C, D and see what happens"
+β
"I hypothesize A is the cause. Let me test only A."
+```
+
+### Assuming vs. Verifying
+
+```
+β "The cache is probably stale"
+β
"Let me check the cache: console.log(cache.get(key))"
+```
+
+## Next Steps
+
+After successful debugging:
+
+1. **Add regression test**: Ensure bug can't return
+2. **Document root cause**: Help future debugging
+3. **Review related code**: Are there similar issues?
+4. **Update monitoring**: Catch this class of bug earlier
+
+## Related Skills
+
+- [TDD](/claudekit/skills/methodology/tdd) - Write failing test first
+- [Sequential Thinking](/claudekit/skills/methodology/sequential-thinking) - Evidence-based analysis
+- [Verification](/claudekit/skills/methodology/verification) - Prove the fix works
+- [Root Cause Tracing](/claudekit/skills/methodology/root-cause-tracing) - Deep investigation
diff --git a/website/src/content/docs/skills/methodology/tdd.md b/website/src/content/docs/skills/methodology/tdd.md
new file mode 100644
index 0000000..883fb71
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/tdd.md
@@ -0,0 +1,436 @@
+---
+title: Test-Driven Development (TDD)
+description: Strict test-first development methodology
+---
+
+The TDD skill enforces test-driven development with the fundamental rule: "If you didn't watch the test fail, you don't know if it tests the right thing."
+
+## Overview
+
+Test-Driven Development is a methodology where tests are written before production code. This ensures code is designed to be testable and that tests actually verify the intended behavior.
+
+**Non-Negotiable Rule**: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+
+## When to Use
+
+- New feature development
+- Bug fixes (write test that reproduces bug first)
+- Refactoring (ensure tests exist before changing)
+- Any behavior change
+
+## When NOT to Use
+
+Requires explicit approval:
+- Throwaway prototypes
+- Generated/scaffolded code
+- Pure configuration changes
+
+## The Red-Green-Refactor Cycle
+
+### 1. RED: Write Failing Test
+
+Write a minimal test demonstrating the desired behavior:
+
+```typescript
+describe('calculateTotal', () => {
+ it('should sum item prices', () => {
+ const items = [{ price: 10 }, { price: 20 }];
+ expect(calculateTotal(items)).toBe(30);
+ });
+});
+```
+
+### 2. VERIFY RED: Confirm Test Fails
+
+Run the test and confirm it fails **for the right reason**:
+
+```bash
+npm test -- --grep "sum item prices"
+# Expected: FAIL
+# Reason: calculateTotal is not defined
+```
+
+**Critical**: The failure should be because the feature doesn't exist, not because of typos or syntax errors.
+
+### 3. GREEN: Write Minimal Code
+
+Write the simplest code that makes the test pass:
+
+```typescript
+function calculateTotal(items: Item[]): number {
+ return items.reduce((sum, item) => sum + item.price, 0);
+}
+```
+
+**Don't over-engineer**. If the test passes with simple code, stop.
+
+### 4. VERIFY GREEN: Confirm Test Passes
+
+```bash
+npm test -- --grep "sum item prices"
+# Expected: PASS
+```
+
+### 5. REFACTOR: Clean Up
+
+With green tests, refactor safely:
+- Extract functions
+- Rename variables
+- Remove duplication
+- Run tests after each change
+
+## The Rule
+
+**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST**
+
+This is not a guideline. It's a rule.
+
+### What If I Already Wrote Code?
+
+Delete it. Completely.
+
+```
+β WRONG: "I'll keep this code as reference while writing tests"
+β
RIGHT: Delete the code, write test, rewrite implementation
+```
+
+### Why So Strict?
+
+- Code written before tests wasn't driven by tests
+- Keeping it as reference leads to rationalization
+- Tests written after code often just verify what was written
+- True TDD produces different (usually better) designs
+
+## Test Quality Standards
+
+### One Behavior Per Test
+
+```typescript
+// β BAD: Multiple behaviors
+it('should validate and save user', () => {
+ expect(validateUser(user)).toBe(true);
+ expect(saveUser(user)).toBe(1);
+});
+
+// β
GOOD: Single behavior
+it('should validate user email format', () => {
+ expect(validateUser({ email: 'test@example.com' })).toBe(true);
+});
+
+it('should save valid user', () => {
+ const user = createValidUser();
+ expect(saveUser(user)).toBe(1);
+});
+```
+
+### Clear Naming
+
+Test names should describe the behavior:
+
+```typescript
+// β BAD
+it('test1', () => {});
+it('calculateTotal', () => {});
+
+// β
GOOD
+it('should return 0 for empty cart', () => {});
+it('should apply discount when coupon is valid', () => {});
+```
+
+### Real Code Over Mocks
+
+Use real implementations when possible:
+
+```typescript
+// β
PREFER: Real database (test container)
+const db = await startTestDatabase();
+const result = await userRepo.save(user);
+
+// β οΈ AVOID: Excessive mocking
+const mockDb = { save: jest.fn().mockResolvedValue(1) };
+```
+
+### Test Observable Behavior
+
+Test what the code does, not how it does it:
+
+```typescript
+// β BAD: Testing implementation
+it('should call helper function', () => {
+ calculateTotal(items);
+ expect(helperFn).toHaveBeenCalled();
+});
+
+// β
GOOD: Testing behavior
+it('should return correct total', () => {
+ expect(calculateTotal(items)).toBe(30);
+});
+```
+
+## Edge Cases to Test
+
+Always include tests for:
+
+- Empty inputs
+- Null/undefined values
+- Boundary conditions
+- Error scenarios
+- Large inputs
+- Invalid inputs
+
+```typescript
+describe('calculateTotal', () => {
+ it('should return 0 for empty array', () => {
+ expect(calculateTotal([])).toBe(0);
+ });
+
+ it('should handle null items array', () => {
+ expect(() => calculateTotal(null)).toThrow();
+ });
+
+ it('should handle negative prices', () => {
+ const items = [{ price: -10 }, { price: 20 }];
+ expect(calculateTotal(items)).toBe(10);
+ });
+});
+```
+
+## Common Rationalizations
+
+### "I'll write tests after"
+
+**Rejected**. Tests written after code verify what was written, not what should happen.
+
+### "Manual testing is enough"
+
+**Rejected**. Ad-hoc testing is not systematic, misses edge cases, and doesn't prevent regressions.
+
+### "This code is too simple to test"
+
+**Rejected**. Simple code breaks too. A test takes seconds and provides permanent verification.
+
+### "I don't have time"
+
+**Rejected**. TDD is faster in the medium term. Debugging time saved far exceeds test-writing time.
+
+### "I already wrote it, might as well keep it"
+
+**Rejected**. Sunk cost fallacy. Delete and rewrite properly.
+
+## TDD Workflow Example
+
+### Bug Fix with TDD
+
+```typescript
+// 1. RED: Write test that reproduces bug
+it('should handle expired session gracefully', () => {
+ const session = createExpiredSession();
+ const result = processRequest(session);
+ expect(result.error).toBe('SESSION_EXPIRED');
+});
+
+// 2. VERIFY RED: Confirm test fails
+// npm test β FAIL (current code crashes or returns wrong error)
+
+// 3. GREEN: Fix the bug
+function processRequest(session: Session) {
+ if (session.isExpired()) {
+ return { error: 'SESSION_EXPIRED' };
+ }
+ // ... rest of logic
+}
+
+// 4. VERIFY GREEN: Confirm test passes
+// npm test β PASS
+
+// 5. Commit with test
+// git commit -m "fix: handle expired session gracefully"
+```
+
+### New Feature with TDD
+
+```typescript
+// 1. RED: Write test for feature
+it('should calculate discount for premium users', () => {
+ const user = { type: 'premium' };
+ const price = 100;
+ expect(calculatePrice(user, price)).toBe(90); // 10% off
+});
+
+// 2. VERIFY RED
+// npm test β FAIL (calculatePrice doesn't consider user type)
+
+// 3. GREEN: Implement feature
+function calculatePrice(user: User, price: number): number {
+ if (user.type === 'premium') {
+ return price * 0.9;
+ }
+ return price;
+}
+
+// 4. VERIFY GREEN
+// npm test β PASS
+
+// 5. REFACTOR: Extract discount logic
+function getDiscount(user: User): number {
+ return user.type === 'premium' ? 0.1 : 0;
+}
+
+function calculatePrice(user: User, price: number): number {
+ const discount = getDiscount(user);
+ return price * (1 - discount);
+}
+
+// 6. VERIFY still GREEN
+// npm test β PASS
+```
+
+## Activation
+
+### Via Command
+
+```bash
+/tdd "add user authentication"
+/feature --methodology=tdd "payment processing"
+```
+
+### Automatic in Plans
+
+When using [Writing Plans](/claudekit/skills/methodology/writing-plans), every task follows TDD automatically.
+
+### During Execution
+
+[Executing Plans](/claudekit/skills/methodology/executing-plans) enforces TDD for each task.
+
+## Integration with Other Skills
+
+### With Writing Plans
+
+Plans include TDD steps for every task:
+
+```markdown
+1. Write failing test
+2. Verify test fails
+3. Implement minimally
+4. Verify test passes
+5. Commit
+```
+
+### With Verification
+
+[Verification](/claudekit/skills/methodology/verification) ensures:
+- Tests actually fail before implementation
+- Tests pass after implementation
+- Full suite remains green
+
+### With Testing Anti-Patterns
+
+[Testing Anti-Patterns](/claudekit/skills/methodology/testing-anti-patterns) prevents:
+- Testing mocks instead of real code
+- Incomplete mocks
+- Over-mocking
+- Afterthought tests
+
+## Benefits
+
+### TDD Catches Bugs Early
+
+- Writing test first forces you to think about edge cases
+- Seeing test fail proves it can catch failures
+- Green bar confirms the fix works
+- Test prevents regression forever
+
+### TDD Improves Design
+
+- Forces consideration of interfaces before implementation
+- Encourages small, focused functions
+- Makes dependencies explicit
+- Results in more testable code
+
+### TDD Saves Time
+
+Prevents this cycle:
+1. Write code
+2. Manual test (miss edge case)
+3. Ship
+4. Bug reported
+5. Debug
+6. Fix
+7. Ship again
+
+With TDD:
+1. Write test
+2. See it fail
+3. Implement
+4. See it pass
+5. Ship confidently
+
+## Best Practices
+
+### Keep Tests Fast
+
+```typescript
+// β
Fast tests
+it('should validate email format', () => {
+ expect(validateEmail('test@example.com')).toBe(true);
+});
+
+// β οΈ Slow tests (when avoidable)
+it('should validate email', async () => {
+ await db.connect();
+ await db.query('SELECT ...');
+ // Use test doubles for unit tests
+});
+```
+
+### Test Behavior, Not Implementation
+
+```typescript
+// β BAD: Brittle implementation test
+it('should call emailService.send', () => {
+ registerUser(data);
+ expect(emailService.send).toHaveBeenCalled();
+});
+
+// β
GOOD: Behavior test
+it('should send welcome email to new user', async () => {
+ await registerUser({ email: 'test@example.com' });
+ const emails = await getTestEmails();
+ expect(emails).toContainEqual(
+ expect.objectContaining({
+ to: 'test@example.com',
+ subject: 'Welcome'
+ })
+ );
+});
+```
+
+### Arrange-Act-Assert Pattern
+
+```typescript
+it('should calculate total with tax', () => {
+ // Arrange
+ const items = [{ price: 100 }];
+ const taxRate = 0.1;
+
+ // Act
+ const total = calculateTotalWithTax(items, taxRate);
+
+ // Assert
+ expect(total).toBe(110);
+});
+```
+
+## Next Steps
+
+- Use with [Writing Plans](/claudekit/skills/methodology/writing-plans) for structured TDD
+- Combine with [Code Review](/claudekit/skills/methodology/code-review) for quality
+- Avoid [Testing Anti-Patterns](/claudekit/skills/methodology/testing-anti-patterns)
+- Enforce with [Verification](/claudekit/skills/methodology/verification)
+
+## Related Skills
+
+- [Writing Plans](/claudekit/skills/methodology/writing-plans) - Plans include TDD steps
+- [Executing Plans](/claudekit/skills/methodology/executing-plans) - Enforces TDD per task
+- [Testing Anti-Patterns](/claudekit/skills/methodology/testing-anti-patterns) - Avoid mistakes
+- [Verification](/claudekit/skills/methodology/verification) - Prove tests work
diff --git a/website/src/content/docs/skills/methodology/testing-anti-patterns.md b/website/src/content/docs/skills/methodology/testing-anti-patterns.md
new file mode 100644
index 0000000..5b4d169
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/testing-anti-patterns.md
@@ -0,0 +1,376 @@
+---
+title: Testing Anti-Patterns
+description: Common testing mistakes that create false confidence
+---
+
+The Testing Anti-Patterns skill helps recognize and avoid common testing mistakes that make tests pass while failing to verify actual behavior.
+
+## Overview
+
+Tests can provide false confidence when they verify mocks instead of real behavior, pollute production code, or are written as afterthoughts. This skill identifies these patterns and provides solutions.
+
+## When to Use
+
+- Writing new tests
+- Reviewing test code
+- Debugging flaky or unreliable tests
+- When tests pass but bugs still ship
+
+## The Five Anti-Patterns
+
+### 1. Testing Mock Behavior Instead of Real Code
+
+**The Problem**: Tests verify mocks work, not that actual code works.
+
+```typescript
+// β BAD: Testing the mock
+it('should call the database', () => {
+ const mockDb = { save: jest.fn().mockResolvedValue({ id: 1 }) };
+ const service = new UserService(mockDb);
+
+ await service.createUser({ name: 'Test' });
+
+ expect(mockDb.save).toHaveBeenCalled(); // Only proves mock was called
+});
+```
+
+**The Solution**: Test actual behavior with real (or realistic) dependencies.
+
+```typescript
+// β
GOOD: Testing real behavior
+it('should persist user to database', async () => {
+ const db = await createTestDatabase();
+ const service = new UserService(db);
+
+ const result = await service.createUser({ name: 'Test' });
+
+ const saved = await db.findById(result.id);
+ expect(saved.name).toBe('Test'); // Proves data was actually saved
+});
+```
+
+**Key Principle**: Test what the code does, not what the mocks do.
+
+### 2. Polluting Production with Test-Only Methods
+
+**The Problem**: Adding methods to production code solely for test cleanup or access.
+
+```typescript
+// β BAD: Production class with test-only method
+class ConnectionPool {
+ private connections: Connection[] = [];
+
+ // This method exists only for tests
+ destroy(): void { // DON'T DO THIS
+ this.connections.forEach(c => c.close());
+ this.connections = [];
+ }
+}
+```
+
+**The Solution**: Handle cleanup in test utilities, not production code.
+
+```typescript
+// β
GOOD: Test utility handles cleanup
+// test-utils/connection-pool.ts
+export async function withTestPool(fn: (pool: ConnectionPool) => Promise) {
+ const pool = new ConnectionPool();
+ try {
+ await fn(pool);
+ } finally {
+ // Cleanup handled by test infrastructure
+ await closeAllConnections(pool);
+ }
+}
+```
+
+**Key Principle**: Production code should never know it's being tested.
+
+### 3. Mocking Without Understanding Dependencies
+
+**The Problem**: Over-mocking to "be safe" removes behavior the test actually depends on.
+
+```typescript
+// β BAD: Mocking everything blindly
+it('should process order', () => {
+ jest.mock('./inventory'); // What does this mock?
+ jest.mock('./payment'); // Did we need to mock this?
+ jest.mock('./shipping'); // This might break the test logic
+
+ const result = processOrder(order);
+ expect(result.status).toBe('complete');
+});
+```
+
+**The Solution**: Understand what each dependency does before mocking it.
+
+```typescript
+// β
GOOD: Selective, understood mocking
+it('should process order when payment succeeds', () => {
+ // Only mock external service (payment gateway)
+ // Keep inventory and shipping real for integration test
+ const paymentGateway = createMockPaymentGateway({
+ chargeResult: { success: true, transactionId: 'txn-123' }
+ });
+
+ const result = processOrder(order, { paymentGateway });
+
+ expect(result.status).toBe('complete');
+ expect(result.transactionId).toBe('txn-123');
+});
+```
+
+**Key Principle**: Mock at boundaries, not internally.
+
+### 4. Creating Incomplete Mocks
+
+**The Problem**: Partial mocks that only include known fields, hiding structural assumptions.
+
+```typescript
+// β BAD: Incomplete mock
+const mockApiResponse = {
+ data: { users: [] }
+ // Missing: status, headers, pagination, errors
+};
+
+it('should handle API response', () => {
+ fetchMock.mockResolvedValue(mockApiResponse);
+ const result = await getUsers();
+ expect(result).toEqual([]);
+});
+// Test passes, but production fails when accessing response.pagination
+```
+
+**The Solution**: Create complete mocks that match real API responses.
+
+```typescript
+// β
GOOD: Complete mock matching real response structure
+const mockApiResponse = {
+ status: 200,
+ headers: { 'content-type': 'application/json' },
+ data: {
+ users: [],
+ pagination: { page: 1, total: 0, hasMore: false },
+ errors: null
+ }
+};
+
+it('should handle empty API response', () => {
+ fetchMock.mockResolvedValue(mockApiResponse);
+ const result = await getUsers();
+ expect(result.users).toEqual([]);
+ expect(result.hasMore).toBe(false);
+});
+```
+
+**Key Principle**: Mocks should be indistinguishable from real responses.
+
+### 5. Writing Tests as Afterthoughts
+
+**The Problem**: Treating testing as optional follow-up work rather than integral to development.
+
+```typescript
+// β BAD: Tests written after code, just verifying what exists
+it('should do what the function does', () => {
+ // This test was written by looking at the implementation
+ // It tests the current behavior, not the intended behavior
+ const result = processData(input);
+ expect(result).toMatchSnapshot(); // "Whatever it does is correct"
+});
+```
+
+**The Solution**: Use TDD - tests define requirements before implementation.
+
+```typescript
+// β
GOOD: Test written first, defines requirement
+it('should filter inactive users from report', () => {
+ const users = [
+ { id: 1, name: 'Alice', active: true },
+ { id: 2, name: 'Bob', active: false }
+ ];
+
+ const report = generateReport(users);
+
+ expect(report.users).toHaveLength(1);
+ expect(report.users[0].name).toBe('Alice');
+});
+// Now implement generateReport to make this pass
+```
+
+**Key Principle**: TDD prevents all these anti-patterns naturally.
+
+## Recognition Guide
+
+| Symptom | Likely Anti-Pattern |
+|---------|---------------------|
+| Tests pass but bugs ship | #1 Testing mocks |
+| `destroy()` or `reset()` in production | #2 Test pollution |
+| "I mocked that to be safe" | #3 Blind mocking |
+| TypeError in production, not tests | #4 Incomplete mocks |
+| Tests feel like documentation | #5 Afterthought tests |
+
+## Prevention Checklist
+
+Before committing tests, verify:
+
+- [ ] Tests use real dependencies where possible
+- [ ] Mocks are for external boundaries only
+- [ ] No production code exists solely for tests
+- [ ] Mock structures match real API responses
+- [ ] Tests were written before implementation (TDD)
+- [ ] Tests verify behavior, not implementation details
+
+## Core Principle
+
+**"Mocks are tools to isolate, not things to test."**
+
+Mocks help you:
+- Isolate unit under test
+- Control external dependencies
+- Speed up slow operations (network, disk)
+
+Mocks should never:
+- Be the thing you're verifying
+- Hide bugs in dependencies
+- Create false confidence
+
+## Good Mocking Practices
+
+### Mock External Services Only
+
+```typescript
+// β
GOOD: Mock external API
+const mockStripeApi = {
+ charges: {
+ create: jest.fn().mockResolvedValue({ id: 'ch_123' })
+ }
+};
+
+// β
GOOD: Keep business logic real
+const paymentService = new PaymentService(mockStripeApi);
+const result = await paymentService.processPayment(order);
+```
+
+### Use Test Containers for Databases
+
+```typescript
+// β
BETTER: Use real database (in Docker)
+import { PostgreSqlContainer } from 'testcontainers';
+
+let container: PostgreSqlContainer;
+let db: Database;
+
+beforeAll(async () => {
+ container = await new PostgreSqlContainer().start();
+ db = await createDatabase(container.getConnectionString());
+});
+
+it('should save user', async () => {
+ const user = await db.users.create({ name: 'Test' });
+ expect(user.id).toBeDefined();
+});
+```
+
+### Create Mock Factories
+
+```typescript
+// β
GOOD: Centralized, complete mocks
+function createMockUser(overrides: Partial = {}): User {
+ return {
+ id: '123',
+ email: 'test@example.com',
+ name: 'Test User',
+ role: 'user',
+ active: true,
+ createdAt: new Date(),
+ ...overrides
+ };
+}
+
+// Tests use complete, consistent mocks
+it('should greet admin', () => {
+ const admin = createMockUser({ role: 'admin' });
+ expect(greet(admin)).toBe('Hello Admin!');
+});
+```
+
+## Integration with Other Skills
+
+### With TDD
+
+[TDD](/claudekit/skills/methodology/tdd) naturally prevents anti-patterns:
+- Tests written first define real requirements
+- Can't test mocks when no mocks exist yet
+- Forces thinking about actual behavior
+
+### With Verification
+
+[Verification](/claudekit/skills/methodology/verification) ensures:
+- Tests actually run (not just mocked)
+- Tests verify real behavior
+- Evidence of actual execution
+
+### With Code Review
+
+[Code Review](/claudekit/skills/methodology/code-review) should catch:
+- Over-mocking in tests
+- Test pollution in production
+- Incomplete mock structures
+
+## Examples of Good Tests
+
+### Integration Test (Preferred)
+
+```typescript
+it('should create user and send welcome email', async () => {
+ const db = await createTestDatabase();
+ const emailService = new TestEmailService();
+ const userService = new UserService(db, emailService);
+
+ const user = await userService.create({
+ email: 'new@example.com',
+ name: 'New User'
+ });
+
+ // Verify database persistence
+ const saved = await db.users.findById(user.id);
+ expect(saved.email).toBe('new@example.com');
+
+ // Verify email sent
+ const emails = emailService.getSentEmails();
+ expect(emails).toHaveLength(1);
+ expect(emails[0].to).toBe('new@example.com');
+});
+```
+
+### Unit Test with Minimal Mocking
+
+```typescript
+it('should calculate total with tax', () => {
+ const items = [
+ { price: 100, taxable: true },
+ { price: 50, taxable: false }
+ ];
+
+ const total = calculateTotal(items, 0.1); // 10% tax
+
+ expect(total).toBe(160); // 100 + 10 (tax) + 50
+});
+```
+
+## Next Steps
+
+To improve test quality:
+
+1. **Review existing tests** for these anti-patterns
+2. **Use TDD** for new features
+3. **Prefer integration tests** over heavily mocked unit tests
+4. **Mock only at boundaries** (external APIs, file system)
+5. **Create complete mocks** matching real structures
+
+## Related Skills
+
+- [TDD](/claudekit/skills/methodology/tdd) - Prevents afterthought tests
+- [Verification](/claudekit/skills/methodology/verification) - Ensures tests run
+- [Code Review](/claudekit/skills/methodology/code-review) - Catches anti-patterns
+- [Systematic Debugging](/claudekit/skills/methodology/systematic-debugging) - Investigates test failures
diff --git a/website/src/content/docs/skills/methodology/verification.md b/website/src/content/docs/skills/methodology/verification.md
new file mode 100644
index 0000000..8cb2ec2
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/verification.md
@@ -0,0 +1,394 @@
+---
+title: Verification Before Completion
+description: Mandatory verification before claiming task completion
+---
+
+The Verification Before Completion skill enforces evidence-based completion rather than assumption-based claims.
+
+**Core Rule**: Never claim completion without proof
+
+## Overview
+
+This skill prevents premature completion claims by requiring actual verification for every assertion. Tests must run, builds must complete, and evidence must exist before declaring success.
+
+## When to Use
+
+- Before claiming tests pass
+- Before claiming build succeeds
+- Before claiming bug is fixed
+- Before marking any task complete
+- Before declaring success to user
+
+## The 5-Step Verification Process
+
+### Step 1: IDENTIFY
+
+Determine the command that proves your assertion:
+
+```markdown
+Claim: "Tests pass"
+Verification command: npm test
+
+Claim: "Build succeeds"
+Verification command: npm run build
+
+Claim: "Linting passes"
+Verification command: npm run lint
+```
+
+### Step 2: EXECUTE
+
+Run the command fully and freshly:
+
+```bash
+# Don't rely on cached results
+# Don't assume previous run is still valid
+npm test
+```
+
+### Step 3: READ
+
+Read the complete output and exit codes:
+
+```bash
+# Check output carefully
+# Don't skim - read every line
+# Note exit code (0 = success)
+```
+
+### Step 4: VERIFY
+
+Confirm the output matches your claim:
+
+```markdown
+Claim: "All tests pass"
+Output shows: "42 passing, 0 failing"
+Verification: β Claim is accurate
+```
+
+### Step 5: CLAIM
+
+Only now make the claim, with evidence:
+
+```markdown
+β All tests pass (42 passing, verified at 2025-01-29 14:30)
+```
+
+## Required Validations by Category
+
+### Testing
+
+```bash
+# Run test command
+npm test
+
+# Verify in output:
+# - Zero failures
+# - Expected test count
+# - No skipped tests (unless intentional)
+```
+
+**Not valid**: "Tests should pass" without running them
+
+### Linting
+
+```bash
+# Run linter completely
+npm run lint
+
+# Verify in output:
+# - Zero errors
+# - Zero warnings (or acceptable known warnings)
+```
+
+**Not valid**: Using lint as proxy for build success
+
+### Building
+
+```bash
+# Run build command
+npm run build
+
+# Verify:
+# - Exit code 0
+# - Build artifacts created
+# - No errors in output
+```
+
+**Not valid**: Assuming lint passing means build passes
+
+### Bug Fixes
+
+```bash
+# Step 1: Reproduce original bug
+npm test -- --grep "failing test"
+# Should fail
+
+# Step 2: Apply fix
+
+# Step 3: Verify fix works
+npm test -- --grep "failing test"
+# Should pass
+```
+
+**Not valid**: Claiming fix works without reproducing original failure
+
+### Regression Tests
+
+Complete red-green cycle required:
+
+```bash
+# 1. Write test, run it
+npm test # Should PASS with new test
+
+# 2. Revert the fix
+git stash
+
+# 3. Run test again
+npm test # Should FAIL (proves test catches the bug)
+
+# 4. Restore fix
+git stash pop
+
+# 5. Run test again
+npm test # Should PASS
+```
+
+## Forbidden Language
+
+Never use these phrases without verification:
+
+| Forbidden | Why |
+|-----------|-----|
+| "should work" | Implies uncertainty |
+| "probably fixed" | Not verified |
+| "seems to pass" | Didn't read output |
+| "I think it's done" | Guessing |
+| "Great!" (before checking) | Premature celebration |
+| "Done!" (before verification) | Unverified claim |
+
+### Replace With
+
+| Instead Say | After |
+|-------------|-------|
+| "Tests pass" | Running tests, seeing 0 failures |
+| "Build succeeds" | Running build, exit code 0 |
+| "Bug is fixed" | Reproducing bug, verifying fix |
+
+## Anti-Patterns
+
+### Partial Verification
+
+```
+β BAD: "I ran one test and it passed"
+β
GOOD: "Full test suite passes (42/42)"
+```
+
+### Relying on Prior Runs
+
+```
+β BAD: "Tests passed earlier"
+β
GOOD: "Tests pass now (just ran)"
+```
+
+### Skipping Verification
+
+```
+β BAD: "This is a small change, no need to verify"
+β
GOOD: "Small change, but verified: tests pass, lint clean"
+```
+
+### Trusting Without Checking
+
+```
+β BAD: "Agent said it's fixed, so it's fixed"
+β
GOOD: "Agent said it's fixed, I verified by running tests"
+```
+
+## Verification Checklist Template
+
+Use before claiming completion:
+
+```markdown
+## Task: Add Email Verification
+
+### Verification Steps
+- [ ] Tests run: `npm test`
+ - Result: 45 passing, 0 failing
+- [ ] Lint passes: `npm run lint`
+ - Result: No errors, no warnings
+- [ ] Build succeeds: `npm run build`
+ - Result: Exit code 0, dist/ created
+- [ ] Requirements met:
+ - [ ] Users receive verification email (tested manually)
+ - [ ] Token expires after 24 hours (unit test added)
+ - [ ] Invalid tokens rejected (unit test added)
+
+### Evidence
+```
+Test output:
+PASS src/services/email.test.ts
+PASS src/services/user.test.ts
+Test Suites: 2 passed, 2 total
+Tests: 45 passed, 45 total
+```
+
+### Conclusion
+β Task complete, all verifications passed
+```
+
+## Integration with Other Skills
+
+### With TDD
+
+[TDD](/claudekit/skills/methodology/tdd) naturally includes verification:
+1. Write test - verify it fails (red)
+2. Implement - verify it passes (green)
+3. Refactor - verify it still passes
+
+### With Systematic Debugging
+
+[Debugging](/claudekit/skills/methodology/systematic-debugging) requires verification:
+1. Reproduce bug - verify it fails
+2. Fix bug - verify it passes
+3. Check regressions - verify full suite passes
+
+### With Executing Plans
+
+[Plan execution](/claudekit/skills/methodology/executing-plans) includes verification gates:
+- After each task - verify tests pass
+- After code review - verify issues fixed
+- Before completion - verify all requirements met
+
+## Example Verification
+
+### Before Claiming "Tests Pass"
+
+```bash
+$ npm test
+
+> project@1.0.0 test
+> vitest run
+
+ β src/models/user.test.ts (12 tests)
+ β src/services/auth.test.ts (18 tests)
+ β src/api/users.test.ts (15 tests)
+
+Test Files 3 passed (3)
+ Tests 45 passed (45)
+ Start at 14:23:10
+ Duration 2.34s
+```
+
+**Now you can claim**: "All tests pass (45/45, verified at 14:23)"
+
+### Before Claiming "Build Succeeds"
+
+```bash
+$ npm run build
+
+> project@1.0.0 build
+> tsc && vite build
+
+vite v4.3.9 building for production...
+β 145 modules transformed.
+dist/index.html 0.42 kB
+dist/assets/index-a1b2c3d4.js 87.23 kB β gzip: 28.42 kB
+
+β built in 3.45s
+
+$ echo $?
+0
+```
+
+**Now you can claim**: "Build succeeds (exit code 0, dist/ created)"
+
+### Before Claiming "Bug Fixed"
+
+```bash
+# 1. Verify bug exists
+$ npm test -- --grep "login with expired session"
+FAIL src/auth.test.ts
+ β login with expired session (45ms)
+ Expected error, got success
+
+# 2. Apply fix
+
+# 3. Verify fix works
+$ npm test -- --grep "login with expired session"
+PASS src/auth.test.ts
+ β login with expired session (12ms)
+
+# 4. Verify no regressions
+$ npm test
+Test Files 3 passed (3)
+ Tests 45 passed (45)
+```
+
+**Now you can claim**: "Bug fixed, all tests pass including regression test"
+
+## Activation
+
+This skill is always active, but particularly enforced:
+
+- During [Executing Plans](/claudekit/skills/methodology/executing-plans)
+- After [TDD](/claudekit/skills/methodology/tdd) implementation
+- Before [Code Review](/claudekit/skills/methodology/code-review)
+- In quality-critical contexts
+
+## Best Practices
+
+### Verify Immediately
+
+Don't wait to verify - do it right after implementation:
+
+```
+Implement β Verify β Claim
+NOT: Implement β Claim β Verify later
+```
+
+### Include Output in Claims
+
+```
+β
"Tests pass (45/45)"
+β
"Build succeeds (exit 0, 87KB bundle)"
+β
"Lint clean (0 errors, 0 warnings)"
+```
+
+### Re-verify After Changes
+
+```
+After changing code:
+1. Re-run tests (don't trust old results)
+2. Verify they still pass
+3. Update verification timestamp
+```
+
+### Document Failed Attempts
+
+```markdown
+## Verification Attempts
+
+Attempt 1: FAILED (test 12 failing)
+- Fixed null check in user.ts:45
+- Re-verified
+
+Attempt 2: PASSED (45/45 tests)
+- Verification complete
+```
+
+## Next Steps
+
+After successful verification:
+
+1. **Document the evidence**: Keep verification output
+2. **Commit with confidence**: You know it works
+3. **Report completion**: With evidence attached
+4. **Move to next task**: Previous task is proven complete
+
+## Related Skills
+
+- [TDD](/claudekit/skills/methodology/tdd) - Includes verification in cycle
+- [Systematic Debugging](/claudekit/skills/methodology/systematic-debugging) - Verify fixes work
+- [Executing Plans](/claudekit/skills/methodology/executing-plans) - Verification gates
+- [Code Review](/claudekit/skills/methodology/code-review) - Verify review feedback addressed
diff --git a/website/src/content/docs/skills/methodology/writing-plans.md b/website/src/content/docs/skills/methodology/writing-plans.md
new file mode 100644
index 0000000..6a2ce0e
--- /dev/null
+++ b/website/src/content/docs/skills/methodology/writing-plans.md
@@ -0,0 +1,478 @@
+---
+title: Writing Plans
+description: Generate detailed implementation plans with bite-sized tasks
+---
+
+The Writing Plans skill creates comprehensive, step-by-step implementation plans that bridge design and execution with 2-5 minute tasks.
+
+## Overview
+
+Writing Plans transforms completed designs into executable roadmaps. Each task includes exact file paths, complete code samples, and expected outcomes - enabling anyone to implement the plan successfully.
+
+**Core Principle**: Tasks so small and clear that implementation becomes mechanical.
+
+## When to Use
+
+- After brainstorming/design is complete
+- Before starting implementation
+- When handing off work to another developer
+- For complex features requiring structured approach
+
+## Plan Structure
+
+### Header Section
+
+```markdown
+# Plan: Add Email Verification
+
+**Required Skill**: executing-plans
+
+## Goal
+Add email verification to user registration flow.
+
+## Architecture Overview
+Send verification email on registration, validate token on click,
+mark user as verified in database.
+
+## Tech Stack
+- Node.js, TypeScript
+- PostgreSQL
+- SendGrid for email
+```
+
+### Task Format
+
+Each task follows this structure:
+
+```markdown
+## Task 1: Add verified flag to User model
+
+**Files**:
+- Modify: `src/models/user.ts`
+- Create: `src/migrations/add-verified-flag.ts`
+- Test: `src/models/user.test.ts`
+
+**Steps**:
+
+1. Write failing test
+ ```typescript
+ describe('User model', () => {
+ it('should have verified flag defaulting to false', () => {
+ const user = new User({ email: 'test@example.com' });
+ expect(user.verified).toBe(false);
+ });
+ });
+ ```
+
+2. Verify test fails
+ ```bash
+ npm test -- --grep "verified flag"
+ # Expected: 1 failing (verified is undefined)
+ ```
+
+3. Add verified field to User model
+ ```typescript
+ // src/models/user.ts
+ export class User {
+ email: string;
+ verified: boolean = false; // Add this line
+ // ...
+ }
+ ```
+
+4. Verify test passes
+ ```bash
+ npm test -- --grep "verified flag"
+ # Expected: 1 passing
+ ```
+
+5. Commit
+ ```bash
+ git add src/models/user.ts src/models/user.test.ts
+ git commit -m "feat(user): add verified flag with false default"
+ ```
+```
+
+## Task Granularity
+
+### The 2-5 Minute Rule
+
+Each task should take 2-5 minutes of focused work:
+
+- Write one test
+- Implement one function
+- Add one validation
+- Create one component
+
+### Why So Small?
+
+- Easier to verify correctness
+- Natural commit points
+- Reduces context switching
+- Enables parallel work
+- Clearer progress tracking
+
+### Bad vs Good Breakdown
+
+```
+β BAD: "Implement user authentication"
+ (Too large - could take hours)
+
+β
GOOD:
+ - Task 1: Create User model with email field (3 min)
+ - Task 2: Add password hashing to User model (4 min)
+ - Task 3: Create login endpoint (5 min)
+ - Task 4: Add JWT token generation (4 min)
+ - Task 5: Create auth middleware (5 min)
+ - Task 6: Add token refresh endpoint (4 min)
+```
+
+## Core Requirements
+
+### Exact File Paths Always
+
+Never use vague references:
+
+```
+β BAD: "Update the user service"
+β
GOOD: "Modify `src/services/user-service.ts`"
+```
+
+### Complete Code Samples
+
+Include exact code, not descriptions:
+
+```
+β BAD: "Add a function that validates email"
+
+β
GOOD:
+```typescript
+export function validateEmail(email: string): boolean {
+ const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+ return emailRegex.test(email);
+}
+```
+```
+
+### Expected Output Specifications
+
+Always specify expected command results:
+
+```bash
+npm test
+# Expected output:
+# PASS src/services/user.test.ts
+# User validation
+# β validates correct email format (3ms)
+# β rejects invalid email format (1ms)
+# 2 passing
+```
+
+## Guiding Principles
+
+### DRY (Don't Repeat Yourself)
+
+- Identify patterns before implementation
+- Plan for reusable components
+- Note shared utilities needed
+
+### YAGNI (You Aren't Gonna Need It)
+
+- Only plan what's required now
+- Remove speculative features
+- Add complexity when justified
+
+### TDD (Test-Driven Development)
+
+Every task follows the cycle:
+1. Write failing test
+2. Verify it fails
+3. Implement minimally
+4. Verify it passes
+5. Refactor if needed
+6. Commit
+
+### Frequent Commits
+
+- Commit after each task
+- Clear, descriptive messages
+- Atomic changes only
+
+## Activation
+
+### Via Command
+
+```bash
+/plan "add email verification"
+/plan --detailed "user authentication" # Extra detailed (30+ tasks)
+/plan designs/feature-x.md # Plan from design doc
+```
+
+### Automatic from Brainstorming
+
+```bash
+/brainstorm "payment processing"
+# After design completes...
+"Would you like me to create an implementation plan?"
+```
+
+## Example Plan
+
+```markdown
+# Plan: Add Password Reset
+
+**Required Skill**: executing-plans
+
+## Goal
+Allow users to reset forgotten passwords via email link.
+
+## Architecture Overview
+User requests reset, receives email with token link, submits new password,
+password updated if token valid.
+
+## Tech Stack
+- TypeScript, Express
+- PostgreSQL
+- SendGrid
+
+---
+
+## Task 1: Add resetToken field to User model
+
+**Files**:
+- Modify: `src/models/user.ts`
+- Test: `src/models/user.test.ts`
+
+**Steps**:
+
+1. Write test for reset token
+ ```typescript
+ it('should store password reset token', () => {
+ const user = new User({ email: 'test@example.com' });
+ user.resetToken = 'abc123';
+ user.resetTokenExpiry = new Date(Date.now() + 3600000);
+ expect(user.resetToken).toBe('abc123');
+ });
+ ```
+
+2. Verify test fails
+ ```bash
+ npm test -- --grep "reset token"
+ # Expected: 1 failing
+ ```
+
+3. Add fields to User model
+ ```typescript
+ export class User {
+ email: string;
+ passwordHash: string;
+ resetToken?: string;
+ resetTokenExpiry?: Date;
+ }
+ ```
+
+4. Verify test passes
+ ```bash
+ npm test
+ # Expected: All passing
+ ```
+
+5. Commit
+ ```bash
+ git add .
+ git commit -m "feat(user): add reset token fields"
+ ```
+
+## Task 2: Create password reset request endpoint
+
+**Files**:
+- Create: `src/routes/auth.ts` (if not exists)
+- Modify: `src/routes/auth.ts`
+- Test: `src/routes/auth.test.ts`
+
+**Steps**:
+
+1. Write test for POST /auth/reset-request
+ ```typescript
+ it('should generate reset token for valid email', async () => {
+ await createUser({ email: 'test@example.com' });
+
+ const res = await request(app)
+ .post('/auth/reset-request')
+ .send({ email: 'test@example.com' });
+
+ expect(res.status).toBe(200);
+ expect(res.body.message).toContain('sent');
+ });
+ ```
+
+2. Verify test fails
+ ```bash
+ npm test -- --grep "reset-request"
+ # Expected: 404 (route doesn't exist)
+ ```
+
+3. Implement endpoint
+ ```typescript
+ router.post('/reset-request', async (req, res) => {
+ const { email } = req.body;
+ const user = await User.findByEmail(email);
+
+ if (!user) {
+ return res.status(200).json({ message: 'Reset email sent' });
+ }
+
+ user.resetToken = crypto.randomBytes(32).toString('hex');
+ user.resetTokenExpiry = new Date(Date.now() + 3600000);
+ await user.save();
+
+ await sendResetEmail(user.email, user.resetToken);
+
+ res.json({ message: 'Reset email sent' });
+ });
+ ```
+
+4. Verify test passes
+ ```bash
+ npm test -- --grep "reset-request"
+ # Expected: 1 passing
+ ```
+
+5. Commit
+ ```bash
+ git add .
+ git commit -m "feat(auth): add password reset request endpoint"
+ ```
+
+## Task 3: ... (continue for remaining tasks)
+```
+
+## Execution Handoff
+
+After plan is complete, offer implementation pathways:
+
+### Option 1: Subagent-Driven (Current Session)
+
+```
+Use the executing-plans skill for automated execution with:
+- Fresh agent per task
+- Code review between tasks
+- Quality gates
+```
+
+### Option 2: Manual Execution
+
+```
+Developer executes in current or separate session:
+- Read plan file
+- Follow tasks sequentially
+- Commit after each task
+```
+
+## Integration with Other Skills
+
+### From Brainstorming
+
+```bash
+/brainstorm "feature X"
+# β Design created
+/plan designs/feature-x.md
+# β Plan created
+```
+
+### To Executing Plans
+
+```bash
+/plan "feature Y"
+# β Plan created in plans/feature-y.md
+/execute-plan plans/feature-y.md
+# β Automated execution begins
+```
+
+### With TDD
+
+Every task in the plan follows TDD:
+1. Write failing test
+2. Verify failure
+3. Implement
+4. Verify success
+5. Commit
+
+See [TDD skill](/claudekit/skills/methodology/tdd) for details.
+
+## Best Practices
+
+### Start with File List
+
+Before writing tasks, list all files:
+
+```markdown
+## Files Involved
+- `src/models/user.ts` - Add fields
+- `src/services/user-service.ts` - Add methods
+- `src/routes/auth.ts` - Add endpoints
+- `src/utils/email.ts` - Email helpers
+- Tests for each of above
+```
+
+### Group Related Tasks
+
+```markdown
+## Phase 1: Database Layer (Tasks 1-3)
+## Phase 2: Business Logic (Tasks 4-6)
+## Phase 3: API Layer (Tasks 7-9)
+## Phase 4: Integration (Tasks 10-12)
+```
+
+### Include Verification Steps
+
+Every task must verify:
+- Test fails before implementation
+- Test passes after implementation
+- Full suite still passes
+
+## Common Pitfalls
+
+### Tasks Too Large
+
+```
+β "Implement authentication system" (hours)
+β
"Add password field to User model" (3 minutes)
+```
+
+### Missing Expected Output
+
+```
+β "Run npm test"
+β
"Run npm test (expect: 42 passing, 0 failing)"
+```
+
+### Vague File References
+
+```
+β "Update the service"
+β
"Modify src/services/user-service.ts line 45"
+```
+
+### No TDD Cycle
+
+```
+β "Add the feature and test it"
+β
"1. Write failing test, 2. Verify fails, 3. Implement, 4. Verify passes"
+```
+
+## Next Steps
+
+After creating a plan:
+
+1. **Review the plan**: Ensure it's complete and detailed
+2. **Execute manually**: Follow tasks yourself, or
+3. **Execute with agent**: Use [Executing Plans](/claudekit/skills/methodology/executing-plans)
+4. **Review code**: Use [Code Review](/claudekit/skills/methodology/code-review)
+
+## Related Skills
+
+- [Brainstorming](/claudekit/skills/methodology/brainstorming) - Design before planning
+- [Executing Plans](/claudekit/skills/methodology/executing-plans) - Automated execution
+- [TDD](/claudekit/skills/methodology/tdd) - Test-driven development
+- [Code Review](/claudekit/skills/methodology/code-review) - Quality gates
diff --git a/website/src/content/docs/skills/overview.md b/website/src/content/docs/skills/overview.md
new file mode 100644
index 0000000..5cfea72
--- /dev/null
+++ b/website/src/content/docs/skills/overview.md
@@ -0,0 +1,273 @@
+---
+title: Skills Overview
+description: Comprehensive guide to all Claude Kit skills organized by category
+---
+
+Claude Kit includes a rich library of skills that provide deep expertise in methodologies, languages, frameworks, and tools. Skills are automatically activated when relevant to your task, or can be explicitly invoked.
+
+## What Are Skills?
+
+Skills are knowledge modules that enhance Claude's capabilities in specific domains. Each skill contains:
+
+- **Best practices** for the technology or methodology
+- **Common patterns** and code examples
+- **Anti-patterns** to avoid
+- **Activation conditions** - when the skill is used
+- **Integration points** with other skills
+
+## Skill Categories
+
+### Methodology Skills
+
+Development methodologies and workflows for high-quality software delivery.
+
+| Skill | Purpose | Key Feature |
+|-------|---------|-------------|
+| [Brainstorming](/claudekit/skills/methodology/brainstorming) | Interactive design refinement | One question at a time |
+| [Writing Plans](/claudekit/skills/methodology/writing-plans) | Detailed implementation plans | 2-5 minute tasks |
+| [Executing Plans](/claudekit/skills/methodology/executing-plans) | Automated plan execution | Fresh agents per task |
+| [Test-Driven Development](/claudekit/skills/methodology/tdd) | TDD workflow | Red-green-refactor cycle |
+| [Systematic Debugging](/claudekit/skills/methodology/systematic-debugging) | Root-cause debugging | Four-phase process |
+| [Code Review](/claudekit/skills/methodology/code-review) | Request & receive reviews | Categorized feedback |
+| [Sequential Thinking](/claudekit/skills/methodology/sequential-thinking) | Complex problem analysis | Evidence-based reasoning |
+| [Verification Before Completion](/claudekit/skills/methodology/verification) | Mandatory verification | Never claim without proof |
+| [Testing Anti-Patterns](/claudekit/skills/methodology/testing-anti-patterns) | Avoid common test mistakes | Mock behavior detection |
+
+### Language Skills
+
+Modern programming language expertise with best practices.
+
+| Skill | Purpose | Key Features |
+|-------|---------|--------------|
+| [Python](/claudekit/skills/languages/python) | Python development | Type hints, async, dataclasses |
+| [TypeScript](/claudekit/skills/languages/typescript) | TypeScript development | Strict typing, utility types |
+| [JavaScript](/claudekit/skills/languages/javascript) | Modern JavaScript | ES6+, async patterns |
+
+### Framework Skills
+
+Full-stack framework knowledge and patterns.
+
+| Skill | Purpose | Key Features |
+|-------|---------|--------------|
+| [React](/claudekit/skills/frameworks/react) | React components | Hooks, context, patterns |
+| [Next.js](/claudekit/skills/frameworks/nextjs) | Next.js App Router | Server components, actions |
+| [FastAPI](/claudekit/skills/frameworks/fastapi) | FastAPI REST APIs | Pydantic, async, OpenAPI |
+| [Django](/claudekit/skills/frameworks/django) | Django web apps | ORM, views, REST framework |
+
+### Database Skills
+
+Database design and query optimization.
+
+- **PostgreSQL** - Relational database expertise
+- **MongoDB** - Document database patterns
+
+### Testing Skills
+
+Test frameworks and testing methodologies.
+
+- **pytest** - Python testing with fixtures
+- **vitest** - Fast Vite-based testing
+
+### DevOps Skills
+
+Deployment and infrastructure automation.
+
+- **Docker** - Container best practices
+- **GitHub Actions** - CI/CD workflows
+
+### Frontend Skills
+
+Modern frontend development tools.
+
+- **Tailwind CSS** - Utility-first CSS
+- **shadcn/ui** - React component library
+
+### Security Skills
+
+Security best practices and vulnerability prevention.
+
+- **OWASP** - Web security standards
+
+### API Skills
+
+API design and documentation.
+
+- **OpenAPI** - REST API specification
+
+### Optimization Skills
+
+Performance and cost optimization.
+
+- **Token Efficient** - Reduce API costs
+
+## How Skills Are Activated
+
+### Automatic Activation
+
+Skills activate automatically based on context:
+
+```typescript
+// Working with a .ts file automatically activates:
+// - TypeScript skill
+// - JavaScript skill (parent)
+
+// Using React components activates:
+// - React skill
+// - TypeScript skill
+// - JavaScript skill
+```
+
+### Explicit Activation
+
+Reference skills directly in commands:
+
+```bash
+# Use specific methodology
+/plan --methodology=tdd "add user authentication"
+
+# Activate debugging skill
+/fix --use-skill=systematic-debugging "timeout error"
+
+# Enable sequential thinking
+/research --sequential "performance bottleneck"
+```
+
+### Mode-Based Activation
+
+Certain modes activate related skills:
+
+```bash
+# Deep research mode enables:
+/mode deep-research
+# - Sequential thinking
+# - Root cause tracing
+# - Evidence collection
+
+# Implementation mode enables:
+/mode implementation
+# - TDD
+# - Verification before completion
+# - Testing anti-patterns awareness
+```
+
+## Combining Skills
+
+Skills work together synergistically:
+
+### Planning to Execution
+
+1. **Brainstorming** - Design the solution
+2. **Writing Plans** - Break into tasks
+3. **Executing Plans** - Automated implementation
+4. **Code Review** - Quality gates
+
+### Bug Fixing
+
+1. **Systematic Debugging** - Find root cause
+2. **Sequential Thinking** - Analyze evidence
+3. **TDD** - Write regression test
+4. **Verification** - Confirm fix works
+
+### Feature Development
+
+1. **Brainstorming** - Explore approaches
+2. **Writing Plans** - Detailed tasks
+3. **TDD** - Test-first implementation
+4. **Code Review** - Review and iterate
+5. **Verification** - Confirm completion
+
+## Customizing Skills
+
+Skills can be customized in your `.claude/CLAUDE.md`:
+
+```markdown
+## Skill Overrides
+
+### TDD Strictness
+- Level: Strict (no code without tests)
+- Red-Green-Refactor: Always required
+
+### Code Review
+- Required reviewers: 1 minimum
+- Security review: Required for auth changes
+- Performance review: Required for queries
+
+### Brainstorming
+- Style: Interactive (one question at a time)
+- YAGNI: Ruthless (remove all "might need")
+```
+
+## Creating Custom Skills
+
+Add project-specific skills:
+
+```bash
+.claude/skills/
+βββ custom/
+β βββ company-api-patterns/
+β β βββ SKILL.md
+β βββ deployment-checklist/
+β βββ SKILL.md
+```
+
+See [Custom Skills Guide](/claudekit/guides/custom-skills) for details.
+
+## Skill Reference
+
+For detailed documentation on each skill:
+
+- **Methodology**: See individual skill pages linked above
+- **Languages**: Python, TypeScript, JavaScript skill pages
+- **Frameworks**: React, Next.js, FastAPI, Django pages
+- **Other Categories**: Browse `/skills/` directory
+
+## Best Practices
+
+### Let Skills Guide You
+
+Trust the methodologies:
+
+```bash
+# Instead of:
+"Just write some code for X"
+
+# Use:
+"/brainstorm X" β design first
+"/plan X" β break into tasks
+"/execute-plan" β implement systematically
+```
+
+### Combine Complementary Skills
+
+Use skills together:
+
+```bash
+# TDD + Systematic Debugging
+1. Write failing test (TDD)
+2. Investigate why it fails (Debugging)
+3. Fix root cause (Debugging)
+4. Verify test passes (Verification)
+
+# Brainstorming + Sequential Thinking
+1. Explore options (Brainstorming)
+2. Analyze each deeply (Sequential Thinking)
+3. Choose with evidence (Sequential Thinking)
+```
+
+### Respect Skill Constraints
+
+Skills enforce quality standards:
+
+- **TDD**: No production code without failing test first
+- **Verification**: Never claim completion without proof
+- **Code Review**: All critical issues must be fixed
+- **Systematic Debugging**: Three-fix rule stops runaway debugging
+
+These aren't suggestions - they're requirements.
+
+## Next Steps
+
+- Explore [Methodology Skills](/claudekit/skills/methodology/brainstorming)
+- Learn [Language Skills](/claudekit/skills/languages/python)
+- Check [Framework Skills](/claudekit/skills/frameworks/react)
+- Try [Custom Skills](/claudekit/guides/custom-skills)
diff --git a/website/src/styles/custom.css b/website/src/styles/custom.css
new file mode 100644
index 0000000..a08ff5a
--- /dev/null
+++ b/website/src/styles/custom.css
@@ -0,0 +1,180 @@
+/* Ocean Theme - Custom Starlight Styles */
+
+/* Color Palette:
+ Primary: Deep Navy #0f172a
+ Accent: Cyan #06b6d4
+ Secondary: Slate #64748b
+ Background: #020617
+*/
+
+:root {
+ /* Light mode overrides */
+ --sl-color-accent-low: #e0f2fe;
+ --sl-color-accent: #0891b2;
+ --sl-color-accent-high: #164e63;
+ --sl-color-white: #0f172a;
+ --sl-color-gray-1: #1e293b;
+ --sl-color-gray-2: #334155;
+ --sl-color-gray-3: #475569;
+ --sl-color-gray-4: #64748b;
+ --sl-color-gray-5: #94a3b8;
+ --sl-color-gray-6: #cbd5e1;
+ --sl-color-black: #f8fafc;
+
+ /* Text colors */
+ --sl-color-text: #0f172a;
+ --sl-color-text-accent: #0891b2;
+}
+
+:root[data-theme='dark'] {
+ /* Dark mode - Ocean theme */
+ --sl-color-accent-low: #164e63;
+ --sl-color-accent: #06b6d4;
+ --sl-color-accent-high: #67e8f9;
+ --sl-color-white: #f8fafc;
+ --sl-color-gray-1: #e2e8f0;
+ --sl-color-gray-2: #cbd5e1;
+ --sl-color-gray-3: #94a3b8;
+ --sl-color-gray-4: #64748b;
+ --sl-color-gray-5: #475569;
+ --sl-color-gray-6: #1e293b;
+ --sl-color-black: #020617;
+
+ /* Text colors */
+ --sl-color-text: #f8fafc;
+ --sl-color-text-accent: #22d3ee;
+
+ /* Background */
+ --sl-color-bg: #020617;
+ --sl-color-bg-nav: #0f172a;
+ --sl-color-bg-sidebar: #0f172a;
+ --sl-color-hairline-light: #1e293b;
+ --sl-color-hairline: #334155;
+}
+
+/* Custom styling for hero section */
+.hero {
+ background: linear-gradient(135deg, #020617 0%, #0f172a 50%, #164e63 100%);
+}
+
+/* Code blocks */
+:root[data-theme='dark'] .expressive-code {
+ --ec-codeBg: #0f172a;
+ --ec-codeFg: #e2e8f0;
+ --ec-codeSelBg: #1e293b;
+ --ec-codeBrdCol: #1e293b;
+}
+
+/* Sidebar active state */
+:root[data-theme='dark'] [data-current='true'] {
+ background: linear-gradient(90deg, transparent, #164e6320);
+ border-left: 2px solid var(--sl-color-accent);
+}
+
+/* Links */
+a:not([class]) {
+ color: var(--sl-color-text-accent);
+}
+
+a:not([class]):hover {
+ color: var(--sl-color-accent-high);
+}
+
+/* Buttons */
+.sl-link-button {
+ transition: all 0.2s ease;
+}
+
+.sl-link-button:hover {
+ transform: translateY(-1px);
+ box-shadow: 0 4px 12px rgba(6, 182, 212, 0.3);
+}
+
+/* Cards in docs */
+.card {
+ background: var(--sl-color-bg-nav);
+ border: 1px solid var(--sl-color-hairline);
+ border-radius: 0.5rem;
+ padding: 1.5rem;
+ transition: border-color 0.2s ease;
+}
+
+.card:hover {
+ border-color: var(--sl-color-accent);
+}
+
+/* Landing page specific */
+.landing-hero-gradient {
+ background: radial-gradient(ellipse at top, #164e63 0%, #020617 70%);
+}
+
+/* Feature cards */
+.feature-card {
+ background: linear-gradient(180deg, #0f172a 0%, #020617 100%);
+ border: 1px solid #1e293b;
+ border-radius: 0.75rem;
+ padding: 2rem;
+ transition: all 0.3s ease;
+}
+
+.feature-card:hover {
+ border-color: #06b6d4;
+ transform: translateY(-4px);
+ box-shadow: 0 20px 40px -12px rgba(6, 182, 212, 0.15);
+}
+
+/* Stats section */
+.stat-number {
+ font-size: 3rem;
+ font-weight: 700;
+ background: linear-gradient(135deg, #06b6d4 0%, #22d3ee 100%);
+ -webkit-background-clip: text;
+ -webkit-text-fill-color: transparent;
+ background-clip: text;
+}
+
+/* Code snippet styling */
+.code-snippet {
+ background: #0f172a;
+ border: 1px solid #1e293b;
+ border-radius: 0.5rem;
+ font-family: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, monospace;
+}
+
+/* Badge styling */
+.badge {
+ display: inline-flex;
+ align-items: center;
+ padding: 0.25rem 0.75rem;
+ border-radius: 9999px;
+ font-size: 0.75rem;
+ font-weight: 500;
+ background: #164e63;
+ color: #67e8f9;
+}
+
+.badge-free {
+ background: #065f46;
+ color: #6ee7b7;
+}
+
+/* Terminal animation */
+@keyframes blink {
+ 0%, 50% { opacity: 1; }
+ 51%, 100% { opacity: 0; }
+}
+
+.cursor-blink {
+ animation: blink 1s infinite;
+}
+
+/* Responsive adjustments */
+@media (max-width: 768px) {
+ .stat-number {
+ font-size: 2rem;
+ }
+
+ .feature-card {
+ padding: 1.5rem;
+ }
+}
diff --git a/website/src/styles/global.css b/website/src/styles/global.css
new file mode 100644
index 0000000..a461c50
--- /dev/null
+++ b/website/src/styles/global.css
@@ -0,0 +1 @@
+@import "tailwindcss";
\ No newline at end of file
diff --git a/website/tsconfig.json b/website/tsconfig.json
new file mode 100644
index 0000000..8bf91d3
--- /dev/null
+++ b/website/tsconfig.json
@@ -0,0 +1,5 @@
+{
+ "extends": "astro/tsconfigs/strict",
+ "include": [".astro/types.d.ts", "**/*"],
+ "exclude": ["dist"]
+}