claude-code-kit 0.7.0__py3-none-any.whl

claude_kit/_payload/skills/api-and-interface-design/SKILL.md

@@ -0,0 +1,294 @@
+---
+name: api-and-interface-design
+description: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
+---
+
+# API and Interface Design
+
+## Overview
+
+Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.
+
+## When to Use
+
+- Designing new API endpoints
+- Defining module boundaries or contracts between teams
+- Creating component prop interfaces
+- Establishing database schema that informs API shape
+- Changing existing public interfaces
+
+## Core Principles
+
+### Hyrum's Law
+
+> With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.
+
+This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:
+
+- **Be intentional about what you expose.** Every observable behavior is a potential commitment.
+- **Don't leak implementation details.** If users can observe it, they will depend on it.
+- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.
+- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.
+
+### The One-Version Rule
+
+Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.
+
+### 1. Contract First
+
+Define the interface before implementing it. The contract is the spec — implementation follows.
+
+```typescript
+// Define the contract first
+interface TaskAPI {
+  // Creates a task and returns the created task with server-generated fields
+  createTask(input: CreateTaskInput): Promise<Task>;
+
+  // Returns paginated tasks matching filters
+  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;
+
+  // Returns a single task or throws NotFoundError
+  getTask(id: string): Promise<Task>;
+
+  // Partial update — only provided fields change
+  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;
+
+  // Idempotent delete — succeeds even if already deleted
+  deleteTask(id: string): Promise<void>;
+}
+```
+
+### 2. Consistent Error Semantics
+
+Pick one error strategy and use it everywhere:
+
+```typescript
+// REST: HTTP status codes + structured error body
+// Every error response follows the same shape
+interface APIError {
+  error: {
+    code: string;        // Machine-readable: "VALIDATION_ERROR"
+    message: string;     // Human-readable: "Email is required"
+    details?: unknown;   // Additional context when helpful
+  };
+}
+
+// Status code mapping
+// 400 → Client sent invalid data
+// 401 → Not authenticated
+// 403 → Authenticated but not authorized
+// 404 → Resource not found
+// 409 → Conflict (duplicate, version mismatch)
+// 422 → Validation failed (semantically invalid)
+// 500 → Server error (never expose internal details)
+```
+
+**Don't mix patterns.** If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.
+
+### 3. Validate at Boundaries
+
+Trust internal code. Validate at system edges where external input enters:
+
+```typescript
+// Validate at the API boundary
+app.post('/api/tasks', async (req, res) => {
+  const result = CreateTaskSchema.safeParse(req.body);
+  if (!result.success) {
+    return res.status(422).json({
+      error: {
+        code: 'VALIDATION_ERROR',
+        message: 'Invalid task data',
+        details: result.error.flatten(),
+      },
+    });
+  }
+
+  // After validation, internal code trusts the types
+  const task = await taskService.create(result.data);
+  return res.status(201).json(task);
+});
+```
+
+Where validation belongs:
+- API route handlers (user input)
+- Form submission handlers (user input)
+- External service response parsing (third-party data -- **always treat as untrusted**)
+- Environment variable loading (configuration)
+
+> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.
+
+Where validation does NOT belong:
+- Between internal functions that share type contracts
+- In utility functions called by already-validated code
+- On data that just came from your own database
+
+### 4. Prefer Addition Over Modification
+
+Extend interfaces without breaking existing consumers:
+
+```typescript
+// Good: Add optional fields
+interface CreateTaskInput {
+  title: string;
+  description?: string;
+  priority?: 'low' | 'medium' | 'high';  // Added later, optional
+  labels?: string[];                       // Added later, optional
+}
+
+// Bad: Change existing field types or remove fields
+interface CreateTaskInput {
+  title: string;
+  // description: string;  // Removed — breaks existing consumers
+  priority: number;         // Changed from string — breaks existing consumers
+}
+```
+
+### 5. Predictable Naming
+
+| Pattern | Convention | Example |
+|---------|-----------|---------|
+| REST endpoints | Plural nouns, no verbs | `GET /api/tasks`, `POST /api/tasks` |
+| Query params | camelCase | `?sortBy=createdAt&pageSize=20` |
+| Response fields | camelCase | `{ createdAt, updatedAt, taskId }` |
+| Boolean fields | is/has/can prefix | `isComplete`, `hasAttachments` |
+| Enum values | UPPER_SNAKE | `"IN_PROGRESS"`, `"COMPLETED"` |
+
+## REST API Patterns
+
+### Resource Design
+
+```
+GET    /api/tasks              → List tasks (with query params for filtering)
+POST   /api/tasks              → Create a task
+GET    /api/tasks/:id          → Get a single task
+PATCH  /api/tasks/:id          → Update a task (partial)
+DELETE /api/tasks/:id          → Delete a task
+
+GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
+POST   /api/tasks/:id/comments → Add a comment to a task
+```
+
+### Pagination
+
+Paginate list endpoints:
+
+```typescript
+// Request
+GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc
+
+// Response
+{
+  "data": [...],
+  "pagination": {
+    "page": 1,
+    "pageSize": 20,
+    "totalItems": 142,
+    "totalPages": 8
+  }
+}
+```
+
+### Filtering
+
+Use query parameters for filters:
+
+```
+GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01
+```
+
+### Partial Updates (PATCH)
+
+Accept partial objects — only update what's provided:
+
+```typescript
+// Only title changes, everything else preserved
+PATCH /api/tasks/123
+{ "title": "Updated title" }
+```
+
+## Type-Safe Interface Patterns
+
+### Use Discriminated Unions for Variants
+
+```typescript
+// Good: Each variant is explicit
+type TaskStatus =
+  | { type: 'pending' }
+  | { type: 'in_progress'; assignee: string; startedAt: Date }
+  | { type: 'completed'; completedAt: Date; completedBy: string }
+  | { type: 'cancelled'; reason: string; cancelledAt: Date };
+
+// Consumer gets type narrowing
+function getStatusLabel(status: TaskStatus): string {
+  switch (status.type) {
+    case 'pending': return 'Pending';
+    case 'in_progress': return `In progress (${status.assignee})`;
+    case 'completed': return `Done on ${status.completedAt}`;
+    case 'cancelled': return `Cancelled: ${status.reason}`;
+  }
+}
+```
+
+### Input/Output Separation
+
+```typescript
+// Input: what the caller provides
+interface CreateTaskInput {
+  title: string;
+  description?: string;
+}
+
+// Output: what the system returns (includes server-generated fields)
+interface Task {
+  id: string;
+  title: string;
+  description: string | null;
+  createdAt: Date;
+  updatedAt: Date;
+  createdBy: string;
+}
+```
+
+### Use Branded Types for IDs
+
+```typescript
+type TaskId = string & { readonly __brand: 'TaskId' };
+type UserId = string & { readonly __brand: 'UserId' };
+
+// Prevents accidentally passing a UserId where a TaskId is expected
+function getTask(id: TaskId): Promise<Task> { ... }
+```
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "We'll document the API later" | The types ARE the documentation. Define them first. |
+| "We don't need pagination for now" | You will the moment someone has 100+ items. Add it from the start. |
+| "PATCH is complicated, let's just use PUT" | PUT requires the full object every time. PATCH is what clients actually want. |
+| "We'll version the API when we need to" | Breaking changes without versioning break consumers. Design for extension from the start. |
+| "Nobody uses that undocumented behavior" | Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. |
+| "We can just maintain two versions" | Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. |
+| "Internal APIs don't need contracts" | Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. |
+
+## Red Flags
+
+- Endpoints that return different shapes depending on conditions
+- Inconsistent error formats across endpoints
+- Validation scattered throughout internal code instead of at boundaries
+- Breaking changes to existing fields (type changes, removals)
+- List endpoints without pagination
+- Verbs in REST URLs (`/api/createTask`, `/api/getUsers`)
+- Third-party API responses used without validation or sanitization
+
+## Verification
+
+After designing an API:
+
+- [ ] Every endpoint has typed input and output schemas
+- [ ] Error responses follow a single consistent format
+- [ ] Validation happens at system boundaries only
+- [ ] List endpoints support pagination
+- [ ] New fields are additive and optional (backward compatible)
+- [ ] Naming follows consistent conventions across all endpoints
+- [ ] API documentation or types are committed alongside the implementation

claude_kit/_payload/skills/api-integration/SKILL.md

@@ -0,0 +1,348 @@
+---
+name: api-integration
+description: Integrate APIs with proper caching, error handling, type safety, and loading states using the project's data-fetching patterns.
+argument-hint: [API endpoint or feature name]
+disable-model-invocation: true
+---
+
+Integrate API for: $ARGUMENTS.
+
+## Steps
+
+1. **Identify the API**: Determine the endpoint(s), HTTP method(s), request/response shapes, and authentication requirements for $ARGUMENTS.
+
+2. **Define types**: Create typed interfaces for request and response payloads. Co-locate types with the API client module according to the project's conventions.
+
+   ```typescript
+   // TypeScript example
+   export interface GetItemsParams {
+     page: number;
+     limit: number;
+     status?: 'open' | 'resolved' | 'escalated';
+   }
+
+   export interface ItemResponse {
+     data: Item[];
+     total: number;
+     page: number;
+   }
+   ```
+
+   ```python
+   # Python example (Pydantic)
+   from pydantic import BaseModel
+
+   class GetItemsParams(BaseModel):
+       page: int
+       limit: int
+       status: str | None = None
+
+   class ItemResponse(BaseModel):
+       data: list[Item]
+       total: int
+       page: int
+   ```
+
+3. **Create API client functions**: Place in the project's designated API layer as pure async functions. Use the project's HTTP client.
+
+   ```typescript
+   // TypeScript example
+   import { httpClient } from '@/lib/httpClient';
+   import type { GetItemsParams, ItemResponse } from './types/items';
+
+   export async function getItems(params: GetItemsParams): Promise<ItemResponse> {
+     const { data } = await httpClient.get<ItemResponse>('/items', { params });
+     return data;
+   }
+
+   export async function resolveItem(id: string, resolution: string): Promise<void> {
+     await httpClient.post(`/items/${encodeURIComponent(id)}/resolve`, { resolution });
+   }
+   ```
+
+   ```python
+   # Python example (httpx)
+   import httpx
+   from .schemas import GetItemsParams, ItemResponse
+
+   async def get_items(params: GetItemsParams) -> ItemResponse:
+       async with httpx.AsyncClient() as client:
+           response = await client.get('/items', params=params.model_dump())
+           return ItemResponse.model_validate(response.json())
+
+   async def resolve_item(id: str, resolution: str) -> None:
+       async with httpx.AsyncClient() as client:
+           await client.post(f'/items/{id}/resolve', json={'resolution': resolution})
+   ```
+
+4. **Create data-fetching hooks/functions**: Wrap API calls with the project's caching/state management layer.
+
+   ### Query Pattern (React Query example)
+   ```typescript
+   import { useQuery } from '@tanstack/react-query';
+   import { getItems } from '@/api/items';
+   import type { GetItemsParams } from '@/api/types/items';
+
+   export const itemKeys = {
+     all: ['items'] as const,
+     lists: () => [...itemKeys.all, 'list'] as const,
+     list: (params: GetItemsParams) => [...itemKeys.lists(), params] as const,
+     details: () => [...itemKeys.all, 'detail'] as const,
+     detail: (id: string) => [...itemKeys.details(), id] as const,
+   };
+
+   export function useItems(params: GetItemsParams) {
+     return useQuery({
+       queryKey: itemKeys.list(params),
+       queryFn: () => getItems(params),
+       staleTime: 5 * 60 * 1000, // 5 minutes
+       placeholderData: keepPreviousData,
+     });
+   }
+   ```
+
+   ### Mutation Pattern (React Query example)
+   ```typescript
+   import { useMutation, useQueryClient } from '@tanstack/react-query';
+   import { resolveItem } from '@/api/items';
+
+   export function useResolveItem() {
+     const queryClient = useQueryClient();
+
+     return useMutation({
+       mutationFn: ({ id, resolution }: { id: string; resolution: string }) =>
+         resolveItem(id, resolution),
+       onSuccess: () => {
+         queryClient.invalidateQueries({ queryKey: itemKeys.all });
+       },
+     });
+   }
+   ```
+
+   ### Alternative: Service Layer Pattern (backend or Vue/Angular)
+   ```python
+   # Python service layer
+   from .repository import ItemRepository
+   from .schemas import GetItemsParams, ItemResponse
+
+   class ItemService:
+       def __init__(self, repo: ItemRepository):
+           self.repo = repo
+
+       async def get_items(self, params: GetItemsParams) -> ItemResponse:
+           items = await self.repo.find_all(params)
+           total = await self.repo.count(params)
+           return ItemResponse(data=items, total=total, page=params.page)
+   ```
+
+5. **Validate responses at the boundary**: Use a validation library to ensure API responses match expected shapes.
+
+   ```typescript
+   // TypeScript with Zod
+   import { z } from 'zod';
+
+   const itemResponseSchema = z.object({
+     data: z.array(itemSchema),
+     total: z.number(),
+     page: z.number(),
+   });
+
+   export async function getItems(params: GetItemsParams) {
+     const { data } = await httpClient.get('/items', { params });
+     return itemResponseSchema.parse(data);
+   }
+   ```
+
+   ```python
+   # Python with Pydantic (validation built-in)
+   from pydantic import BaseModel, field_validator
+
+   class ItemResponse(BaseModel):
+       data: list[Item]
+       total: int
+       page: int
+
+       @field_validator('total')
+       @classmethod
+       def total_non_negative(cls, v: int) -> int:
+           if v < 0:
+               raise ValueError('total must be non-negative')
+           return v
+   ```
+
+6. **Use in components/views**: Follow the loading/empty/error state pattern.
+
+   ```tsx
+   // React example
+   function ItemList() {
+     const { data, isLoading, error } = useItems({ page: 1, limit: 20 });
+
+     if (isLoading) return <Spinner />;
+     if (error) return <EmptyState title="Failed to load items" />;
+     if (!data?.data.length) return <EmptyState title="No items found" />;
+
+     return (
+       <div className="space-y-3">
+         {data.data.map((item) => (
+           <ItemCard key={item.id} item={item} />
+         ))}
+       </div>
+     );
+   }
+   ```
+
+   ```python
+   # Python (FastAPI) example
+   from fastapi import APIRouter, Depends, HTTPException, status
+
+   @router.get('/items', response_model=ItemResponse)
+   async def list_items(
+       params: GetItemsParams = Depends(),
+       service: ItemService = Depends(),
+   ) -> ItemResponse:
+       try:
+           return await service.get_items(params)
+       except Exception as e:
+           raise HTTPException(
+               status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
+               detail='Failed to load items'
+           )
+   ```
+
+7. **Verify**: Run the project's linter, type checker, and build to confirm all checks pass.
+
+## Data-Fetching Conventions
+
+### Cache Key Factory
+Every feature should have a key factory object for consistent cache management (applies to client-side caching libraries like TanStack Query, SWR, Apollo):
+
+```typescript
+export const featureKeys = {
+  all: ['feature'] as const,
+  lists: () => [...featureKeys.all, 'list'] as const,
+  list: (params: Params) => [...featureKeys.lists(), params] as const,
+  details: () => [...featureKeys.all, 'detail'] as const,
+  detail: (id: string) => [...featureKeys.details(), id] as const,
+};
+```
+
+### Stale Time Defaults (Client-Side Caching)
+| Data Type | Stale Time | Rationale |
+|-----------|-----------|-----------|
+| Reference data (categories, roles) | 30 minutes | Rarely changes |
+| Dashboard KPIs | 5 minutes | Moderate freshness |
+| Real-time feeds (notifications, alerts) | 1 minute | Needs frequent updates |
+| User-specific (preferences) | Infinity | Only changes on mutation |
+
+### Error Handling
+- Use the data-fetching layer's built-in error state — avoid wrapping in try/catch at the component level
+- Global error handler for auth errors (401 → redirect to login)
+- Show empty/error state UI for query failures
+- Show toast/notification for mutation failures
+
+### Optimistic Updates (Client-Side)
+Use for operations where the user expects instant feedback:
+
+```typescript
+// TanStack Query example
+onMutate: async (newData) => {
+  await queryClient.cancelQueries({ queryKey });
+  const previous = queryClient.getQueryData(queryKey);
+  queryClient.setQueryData(queryKey, (old) => /* optimistic update */);
+  return { previous };
+},
+onError: (_err, _new, context) => {
+  queryClient.setQueryData(queryKey, context?.previous);
+},
+onSettled: () => {
+  queryClient.invalidateQueries({ queryKey });
+},
+```
+
+```python
+# Backend optimistic approach (return before commit)
+async def update_item(db: AsyncSession, id: str, update: ItemUpdate) -> Item:
+    item = await repo.get_by_id(db, id)
+    if not item:
+        raise HTTPException(status_code=404)
+    
+    # Apply changes
+    for field, value in update.model_dump(exclude_unset=True).items():
+        setattr(item, field, value)
+    
+    # Flush to get updated state, but don't commit yet
+    await db.flush()
+    await db.refresh(item)
+    
+    # Return optimistically (commit happens at end of request)
+    return item
+```
+
+## Directory Structure
+
+Adapt to your project's conventions. Common patterns:
+
+### Frontend (React/Vue/Angular)
+```
+src/
+  lib/
+    httpClient.ts                        # Shared HTTP client (Axios/Fetch)
+    queryKeys.ts                         # Shared query key factories (if using client-side caching)
+  providers/
+    QueryProvider.tsx                    # Data-fetching provider (TanStack Query, SWR, Apollo)
+  modules/ (or features/)
+    <feature>/
+      api/<feature>Api.ts                # Plain async API functions
+      hooks/use<Feature>Queries.ts       # Data-fetching hooks wrapping API functions
+      types/<feature>.ts                 # Request/response types
+```
+
+### Backend (Python/Node/Go/etc.)
+```
+app/
+  api/                                   # HTTP route handlers
+    v1/
+      <feature>/
+        router.py (or routes.ts)         # Route definitions
+        schemas.py (or dtos.ts)          # Request/response schemas
+        service.py (or service.ts)       # Business logic
+        repository.py (or repository.ts) # Data access
+```
+
+**Key rules:**
+- API client functions (plain async) live in the project's designated API layer
+- Data-fetching hooks/wrappers live alongside the module or in a dedicated hooks folder
+- Key factories can be co-located or centralized depending on the project's conventions
+- Validation happens at system boundaries (API responses in frontend, request payloads in backend)
+
+## Common Patterns by Stack
+
+### React + TanStack Query
+- Query hooks: `useQuery` for reads, `useMutation` for writes
+- Key factories for cache management
+- `invalidateQueries` after mutations
+- `placeholderData: keepPreviousData` for pagination
+
+### Vue + Pinia
+- API functions in composables (`useItems`)
+- Pinia store for caching if needed
+- Loading/error state in composable return
+
+### Angular + RxJS
+- API functions return Observables
+- Service layer manages HTTP calls
+- `catchError` for error handling
+- `shareReplay` for caching
+
+### Backend (FastAPI/Express/Spring Boot)
+- Repository pattern for data access
+- Service layer for business logic
+- Route handlers delegate to services
+- Typed request/response schemas
+
+## References
+
+- HTTP client: Check the project's configuration (Axios, Fetch, httpx, requests)
+- Data-fetching library: TanStack Query, SWR, Apollo (frontend), or service/repository pattern (backend)
+- Validation: Zod, Yup, io-ts (TypeScript), Pydantic (Python), Joi (Node.js)
+- Loading/error patterns: Check `code-organization.md` for the project's UI component conventions

claude_kit/_payload/skills/archive-sprint/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: archive-sprint
+description: Archive a completed sprint's planning docs and update the backlog status.
+argument-hint: [backlog item number]
+disable-model-invocation: true
+---
+
+Archive the completed sprint for backlog item #$ARGUMENTS.
+
+## Steps
+
+1. **Find the planning folder**: Look in `docs/planning/` for the directory corresponding to backlog item #$ARGUMENTS.
+
+2. **Verify completion**: Check that the work is actually done:
+   - Read the sprint plan and verify tasks are complete
+   - Verify the Sprint Report section is filled in (Results, Metrics, What went well/wrong, Learnings, Unresolved). If missing, tell the user to write the post-sprint report first — do not archive without it.
+   - Check if any new learnings should be added to `docs/reference/post-sprint-learnings.md`. If the sprint report has learnings not already captured there, append them.
+   - Optionally run the project's build to confirm nothing is broken
+
+3. **Move to archive**: Use `git mv` to move:
+   - The scope doc → `docs/archive/plans/{slug}-scope.md`
+   - The sprint plan → `docs/archive/sprints/{slug}-sprint.md`
+   - Any other planning docs in the folder → `docs/archive/plans/`
+
+4. **Update backlog**: Find the item in its horizon file (`docs/backlog/now.md`, `next.md`, or `later.md`) and move it to `docs/backlog/completed.md` with `Completed` status and the date. Update the item counts in `docs/backlog/README.md`.
+
+5. **Clean up**: Remove the now-empty planning directory.
+
+6. **Commit**: Stage all moved/modified files and commit with message: `backlog: complete #N — {Title}`
+
+7. **Summarize**: Tell the user what was archived and confirm the backlog was updated.