@jhm1909/ag-kit 0.1.0

package/.agent/skills/game-development/vr-ar/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: vr-ar
+description: VR/AR development principles. Comfort, interaction, performance requirements.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# VR/AR Development
+
+> Immersive experience principles.
+
+---
+
+## 1. Platform Selection
+
+### VR Platforms
+
+| Platform | Use Case |
+|----------|----------|
+| **Quest** | Standalone, wireless |
+| **PCVR** | High fidelity |
+| **PSVR** | Console market |
+| **WebXR** | Browser-based |
+
+### AR Platforms
+
+| Platform | Use Case |
+|----------|----------|
+| **ARKit** | iOS devices |
+| **ARCore** | Android devices |
+| **WebXR** | Browser AR |
+| **HoloLens** | Enterprise |
+
+---
+
+## 2. Comfort Principles
+
+### Motion Sickness Prevention
+
+| Cause | Solution |
+|-------|----------|
+| **Locomotion** | Teleport, snap turn |
+| **Low FPS** | Maintain 90 FPS |
+| **Camera shake** | Avoid or minimize |
+| **Rapid acceleration** | Gradual movement |
+
+### Comfort Settings
+
+- Vignette during movement
+- Snap vs smooth turning
+- Seated vs standing modes
+- Height calibration
+
+---
+
+## 3. Performance Requirements
+
+### Target Metrics
+
+| Platform | FPS | Resolution |
+|----------|-----|------------|
+| Quest 2 | 72-90 | 1832x1920 |
+| Quest 3 | 90-120 | 2064x2208 |
+| PCVR | 90 | 2160x2160+ |
+| PSVR2 | 90-120 | 2000x2040 |
+
+### Frame Budget
+
+- VR requires consistent frame times
+- Single dropped frame = visible judder
+- 90 FPS = 11.11ms budget
+
+---
+
+## 4. Interaction Principles
+
+### Controller Interaction
+
+| Type | Use |
+|------|-----|
+| **Point + click** | UI, distant objects |
+| **Grab** | Manipulation |
+| **Gesture** | Magic, special actions |
+| **Physical** | Throwing, swinging |
+
+### Hand Tracking
+
+- More immersive but less precise
+- Good for: social, casual
+- Challenging for: action, precision
+
+---
+
+## 5. Spatial Design
+
+### World Scale
+
+- 1 unit = 1 meter (critical)
+- Objects must feel right size
+- Test with real measurements
+
+### Depth Cues
+
+| Cue | Importance |
+|-----|------------|
+| Stereo | Primary depth |
+| Motion parallax | Secondary |
+| Shadows | Grounding |
+| Occlusion | Layering |
+
+---
+
+## 6. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Move camera without player | Player controls camera |
+| Drop below 90 FPS | Maintain frame rate |
+| Use tiny UI text | Large, readable text |
+| Ignore arm length | Scale to player reach |
+
+---
+
+> **Remember:** Comfort is not optional. Sick players don't play.

package/.agent/skills/game-development/web-games/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: web-games
+description: Web browser game development principles. Framework selection, WebGPU, optimization, PWA.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# Web Browser Game Development
+
+> Framework selection and browser-specific principles.
+
+---
+
+## 1. Framework Selection
+
+### Decision Tree
+
+```
+What type of game?
+│
+├── 2D Game
+│   ├── Full game engine features? → Phaser
+│   └── Raw rendering power? → PixiJS
+│
+├── 3D Game
+│   ├── Full engine (physics, XR)? → Babylon.js
+│   └── Rendering focused? → Three.js
+│
+└── Hybrid / Canvas
+    └── Custom → Raw Canvas/WebGL
+```
+
+### Comparison (2025)
+
+| Framework | Type | Best For |
+|-----------|------|----------|
+| **Phaser 4** | 2D | Full game features |
+| **PixiJS 8** | 2D | Rendering, UI |
+| **Three.js** | 3D | Visualizations, lightweight |
+| **Babylon.js 7** | 3D | Full engine, XR |
+
+---
+
+## 2. WebGPU Adoption
+
+### Browser Support (2025)
+
+| Browser | Support |
+|---------|---------|
+| Chrome | ✅ Since v113 |
+| Edge | ✅ Since v113 |
+| Firefox | ✅ Since v131 |
+| Safari | ✅ Since 18.0 |
+| **Total** | **~73%** global |
+
+### Decision
+
+- **New projects**: Use WebGPU with WebGL fallback
+- **Legacy support**: Start with WebGL
+- **Feature detection**: Check `navigator.gpu`
+
+---
+
+## 3. Performance Principles
+
+### Browser Constraints
+
+| Constraint | Strategy |
+|------------|----------|
+| No local file access | Asset bundling, CDN |
+| Tab throttling | Pause when hidden |
+| Mobile data limits | Compress assets |
+| Audio autoplay | Require user interaction |
+
+### Optimization Priority
+
+1. **Asset compression** - KTX2, Draco, WebP
+2. **Lazy loading** - Load on demand
+3. **Object pooling** - Avoid GC
+4. **Draw call batching** - Reduce state changes
+5. **Web Workers** - Offload heavy computation
+
+---
+
+## 4. Asset Strategy
+
+### Compression Formats
+
+| Type | Format |
+|------|--------|
+| Textures | KTX2 + Basis Universal |
+| Audio | WebM/Opus (fallback: MP3) |
+| 3D Models | glTF + Draco/Meshopt |
+
+### Loading Strategy
+
+| Phase | Load |
+|-------|------|
+| Startup | Core assets, <2MB |
+| Gameplay | Stream on demand |
+| Background | Prefetch next level |
+
+---
+
+## 5. PWA for Games
+
+### Benefits
+
+- Offline play
+- Install to home screen
+- Full screen mode
+- Push notifications
+
+### Requirements
+
+- Service worker for caching
+- Web app manifest
+- HTTPS
+
+---
+
+## 6. Audio Handling
+
+### Browser Requirements
+
+- Audio context requires user interaction
+- Create AudioContext on first click/tap
+- Resume context if suspended
+
+### Best Practices
+
+- Use Web Audio API
+- Pool audio sources
+- Preload common sounds
+- Compress with WebM/Opus
+
+---
+
+## 7. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Load all assets upfront | Progressive loading |
+| Ignore tab visibility | Pause when hidden |
+| Block on audio load | Lazy load audio |
+| Skip compression | Compress everything |
+| Assume fast connection | Handle slow networks |
+
+---
+
+> **Remember:** Browser is the most accessible platform. Respect its constraints.

package/.agent/skills/lead-architect/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: lead-architect
+description: >
+  High-stakes technical decisions, system design, cloud infrastructure. Use for Microservices/Monolith, ADRs, RFCs, and scalability.
+license: MIT
+compatibility: Claude Code, Cursor, Gemini CLI, GitHub Copilot
+metadata:
+  author: jhm1909
+  version: "2.0.0"
+  domain: infra
+  estimated_tokens: 4800
+---
+
+# Lead Architect
+
+Architectural guidance for high-scale, distributed systems.
+
+## Knowledge Graph
+
+- **extends**: []
+- **requires**: []
+- **suggests**: [[devops-engineer]], [[backend-developer]], [[ai-engineer]]
+- **conflicts**: []
+- **enhances**: [[project-manager]] (technical specs)
+- **moc**: [[infrastructure-moc]]
+
+## Core Philosophy
+
+1. **Collaboration** — Work with user to design best solution
+2. **Maintainability First** — Clean code above all, then Security, Scalability, Speed
+3. **Ask, Don't Assume** — Clarifying questions before decisions
+4. **Simplicity Wins** — Complexity is technical debt
+
+## Decision Framework
+
+### Phase 1: Context & Discovery
+- Expected scale? (RPS, Data Volume)
+- Constraint priorities? (Cost vs Speed vs Reliability)
+- Legacy systems to integrate?
+- Team familiarity with tech?
+
+### Phase 2: Options Analysis
+- **Option A**: Industry Standard (Safe)
+- **Option B**: Cutting Edge (High Risk/Reward)
+- **Option C**: Good Enough (Fastest Time to Market)
+
+### Phase 3: Decision & Documentation
+- ADR for important decisions
+- RFC for major changes
+- SDD for overall system design
+
+## Architecture Domains
+
+| Domain | Focus |
+|:-------|:------|
+| **Application** | Modular Monolith, Clean Arch, DDD |
+| **System** | Microservices, Composable, Scaling |
+| **Infrastructure** | Cloud Native, K8s, Serverless |
+| **Security** | Zero Trust, Auth patterns |
+
+## References
+
+- `application-architecture.md` — Modular Monolith, DDD
+- `system-architecture.md` — Microservices, Scaling, AI/RAG
+- `infrastructure.md` — Cloud Native, IaC, Security
+- `process.md` — DevOps, DORA metrics
+
+## Templates
+
+| Template | Purpose |
+|:---------|:--------|
+| `adr.md` | Architecture Decision Record |
+| `rfc.md` | Request for Comments |
+| `sdd.md` | System Design Document |
+| `technical-spec.md` | Technical Specification |
+
+## Related Skills
+
+- [[devops-engineer]] — Implementation partner
+- [[backend-developer]] — API architecture
+- [[project-manager]] — Project coordination
+
+---
+
+*Part of [[infrastructure-moc]] | High-level technical authority*

package/.agent/skills/lead-architect/references/application-architecture.md

@@ -0,0 +1,70 @@
+# Application Architecture Guide
+
+This guide defines the standards for structuring applications, managing state, and ensuring code quality.
+
+## Architectural Patterns
+
+### 1. Modular Monolith (Default for New Projects)
+
+Start here before considering microservices.
+
+- **Structure**: Group code by **Domain Feature**, not by technical layer (e.g., `features/cart` vs `components/Button`).
+- **Boundaries**: Modules should interact via public APIs (explicit interfaces), preventing spaghetti dependencies.
+- **Database**: Logical separation of tables (e.g., schemas) per module is recommended.
+
+### 2. Hexagonal / Clean Architecture (Domain-Centric)
+
+Use for complex core logic that must be independent of frameworks.
+
+- **Domain Layer**: Pure business logic (Entities, Value Objects). No external dependencies.
+- **Application Layer**: Use Cases / Interactors. Orchestrates domain objects.
+- **Adapters Layer (Input/Output)**: Controllers, API Resolvers, Database Repositories, External Clients.
+- **Dependency Rule**: Dependencies only point **inward**. Inner layers know nothing of outer layers.
+
+### 3. Domain-Driven Design (DDD)
+
+Use for complex domains with rich behavior.
+
+- **Ubiquitous Language**: Code terminology must match business language exactly.
+- **Bounded Contexts**: Define explicit boundaries where a specific model applies.
+- **Entities vs. Value Objects**: Entities have identity; Value Objects are defined by their attributes and are immutable.
+- **Aggregates**: Cluster of objects treated as a unit for data changes.
+
+## State Management
+
+### Server-Side State
+
+- **Source of Truth**: The database is the primary source of truth.
+- **Caching**: Use aggressively but invalidate intelligently (swr, revalidation tags).
+- **Optimistic UI**: Update UI immediately, rollback on failure.
+
+### Local State (Client)
+
+- **Ephemerality**: Keep state as close to where it's used as possible. Avoid global state for local concerns.
+- **URL as State**: Store filters, pagination, and selection in the URL query params whenever possible for shareability.
+
+### Event Sourcing (Advanced)
+
+- Store _changes_ (events), not just current state.
+- Essential for audit trails and complex temporal logic.
+- **CQRS**: Segregate Command (Write) and Query (Read) responsibilities for performance.
+
+## Code Quality Standards
+
+### Principles
+
+1.  **SOLID**:
+    - **S**ingle Responsibility: One reason to change.
+    - **O**pen/Closed: Open for extension, closed for modification.
+    - **L**iskov Substitution: Subtypes must be substitutable for base types.
+    - **I**nterface Segregation: Many specific interfaces are better than one general-purpose interface.
+    - **D**ependency Inversion: Depend on abstractions, not concretions.
+2.  **DRY (Don't Repeat Yourself)**: Abstract common logic, but beware of "hasty abstraction".
+3.  **YAGNI (You Aren't Gonna Need It)**: Don't build for hypothetical future requirements. Implement what is needed _now_.
+4.  **KISS (Keep It Simple, Stupid)**: Complexity is a liability.
+
+### Implementation
+
+- **Type Safety**: Strict typing (TypeScript) is non-negotiable for enterprise stability.
+- **Testing**: "Pyramid" approach - many Unit tests, fewer Integration tests, few E2E tests.
+- **Error Handling**: Fail fast, handle gracefully. Use Result types or Monads over throwing exceptions for expected errors.

package/.agent/skills/lead-architect/references/infrastructure.md

@@ -0,0 +1,51 @@
+# Infrastructure Guide
+
+This guide defines the standards for cloud-native infrastructure, security, and observability.
+
+## Cloud Native Patterns
+
+### Container Orchestration (Kubernetes)
+
+- **Immutable Infrastructure**: Never patch running servers. Build new images and replace.
+- **Sidecar Pattern**: Attach auxiliary tasks (logging, proxy, auth) to a main container (e.g., Envoy).
+- **Operator Pattern**: Codify operational knowledge to automate application lifecycle management.
+
+### Serverless
+
+- **FaaS (Function as a Service)**: AWS Lambda, Google Cloud Functions.
+  - _Best for_: Event-driven workloads, "glue" code, sporadic traffic.
+- **Serverless Containers**: AWS Fargate, Google Cloud Run.
+  - _Best for_: HTTP services, existing containerized apps, easier developer experience.
+
+## Infrastructure as Code (IaC)
+
+- **Declarative vs. Imperative**: "What I want" (Terraform/K8s manifests) vs. "How to do it" (Shell scripts). Always prefer **Declarative**.
+- **GitOps**: Git repository as the single source of truth for infrastructure state (e.g., ArgoCD).
+- **Tools**:
+  - **Terraform/OpenTofu**: Industry standard, vast provider ecosystem.
+  - **Pulumi**: Use programming languages (TS/Python) for infrastructure. Good for complex logic.
+  - **Crossplane**: Manage cloud resources using Kubernetes APIs.
+
+## Security (Zero Trust)
+
+- **Principles**:
+  - **Verify Explicitly**: Authenticate and authorize every request based on all data points (identity, location, device health).
+  - **Least Privilege**: JIT/JEA (Just-In-Time/Just-Enough-Administration). Limit access to only what is needed.
+  - **Assume Breach**: Design assuming an attacker is already inside the network. Use micro-segmentation.
+- **IAM (Identity & Access Management)**: Centralize identity (OIDC, SAML). Avoid long-lived keys; use short-lived tokens/roles.
+
+## Observability
+
+Move beyond "Monitoring" (is it up?) to "Observability" (why is it broken?).
+
+### The Pillars (MELT)
+
+1.  **Metrics**: Aggregates, counts, gauges. (Prometheus/Grafana). "What is happening?"
+2.  **Events**: Discrete changes. Deployments, scaling events, alerts.
+3.  **Logs**: Structured text records. (ELK, Loki). "Details of distinct events."
+4.  **Traces**: Lifecycle of a request across services. (Jaeger, Zipkin, OpenTelemetry). "Where is the latency?"
+
+### OpenTelemetry (OTel)
+
+- Standardize instrumentation. Avoid vendor lock-in for data collection.
+- Use OTel collectors to route telemetry data to backend analysis tools.

package/.agent/skills/lead-architect/references/process.md

@@ -0,0 +1,42 @@
+# Engineering Process Guide
+
+This guide defines the workflows, metrics, and quality gates for high-performing engineering teams.
+
+## DevOps & Delivery
+
+### Continuous Integration (CI)
+
+- **Pipeline as Code**: Define pipelines in YAML (GitHub Actions, GitLab CI).
+- **Fast Feedback**: Unit tests and linters should run on every commit. Total CI time < 10 mins.
+- **Trunk-Based Development**: Merge small, frequent changes to `main`. Avoid long-lived feature branches which delay integration pain.
+
+### Continuous Deployment (CD)
+
+- **Blue-Green Deployment**: Two identical environments. Switch traffic from Blue (old) to Green (new) instantly. Easy rollback.
+- **Canary Release**: Roll out to small % of users first. Monitor metrics. Ramp up if healthy.
+- **Feature Flags**: Decouple deployment from release. Deploy code behind a flag, toggle it on for users later.
+
+## Metrics (DORA)
+
+Optimize for the "Elite" cluster of DevOps Research and Assessment (DORA) metrics:
+
+1.  **Deployment Frequency**: How often do we deploy? (Elite: On-demand / Multiple times per day).
+2.  **Lead Time for Changes**: Time from commit to running in production. (Elite: < 1 hour).
+3.  **Change Failure Rate**: % of deployments causing failure in production. (Elite: < 5%).
+4.  **Time to Restore Service**: Time to recover from a failure. (Elite: < 1 hour).
+
+## Code Review Standards
+
+### Philosophy
+
+- **Shared Ownership**: The reviewer is just as responsible for the code quality as the author.
+- **Trust but Verify**: Trust the author's intent, verify the implementation details.
+- **Blocking vs. Non-blocking**: Differentiate between "Must Fix" (bugs, spec violation) and "Nitpick" (style, minor pref).
+
+### Checklist
+
+1.  **Correctness**: Does it do what it says? Are edge cases handled?
+2.  **Test Coverage**: Are there tests? Do they actually test the logic or just coverage?
+3.  **Readability**: Is the variable naming clear? Is the complexity necessary?
+4.  **Security/Performance**: Any obvious SQL injection, N+1 queries, or exposed secrets?
+5.  **Architecture**: Does this fit the agreed-upon pattern? (e.g., Domain logic leaking into Controllers).

package/.agent/skills/lead-architect/references/system-architecture.md

@@ -0,0 +1,62 @@
+# System Architecture Guide
+
+This guide covers high-level system design, scalability, reliability, and modern integration patterns.
+
+## Architectural Styles
+
+### 1. Microservices
+
+- **When to use**: Multiple teams working independently, conflicting scalability requirements, diverse tech stacks needed.
+- **Trade-offs**: Increases operational complexity (deployment, observability, networking). Solves organizational scaling problems more than technical ones.
+- **Anti-Pattern**: Distributed Monolith (tight coupling, shared databases).
+
+### 2. Composable Architecture (PBCs)
+
+- **Packaged Business Capabilities (PBCs)**: Independent, interchangeable software components.
+- **API-First**: Everything is exposed via an API.
+- **Headless**: Decouple frontend (head) from backend logic.
+- **Benefits**: Rapid adaptation, vendor independence, "best-of-breed" selection.
+
+## Scalability Patterns
+
+### Database Scaling
+
+- **Sharding (Horizontal Partitioning)**: Distribute data across multiple nodes based on a shard key (e.g., UserID).
+- **Read Replicas**: Offload read traffic to replicas; writes go to primary.
+- **Caching Strategy**:
+  - **Aside (Lazy Loading)**: App checks cache -> DB -> Updates cache.
+  - **Write-Through**: App updates cache and DB simultaneously.
+  - **CDN**: Cache static assets and compute at the edge.
+
+### Compute Scaling
+
+- **Load Balancing**:
+  - **L4 (Transport)**: IP/Port based. Fast, simple.
+  - **L7 (Application)**: HTTP/Path based. Smart routing, SSL termination.
+- **Auto-scaling**: Trigger based on CPU, Memory, or Request Count metrics.
+
+## Reliability & Resilience
+
+- **Circuit Breaker**: Detect failures and stop sending requests to a failing service to prevent cascading failure.
+- **Bulkhead**: Isolate resources (thread pools, connections) so one failing component doesn't bring down the whole system.
+- **Retry with Exponential Backoff**: Retry transient failures with increasing wait times.
+- **CAP Theorem**: Understand the trade-off: in a Partitioned network, you must choose Consistency or Availability.
+  - _CP_: Banking systems.
+  - _AP_: Social media feeds.
+
+## Modern AI Integration
+
+### RAG (Retrieval-Augmented Generation) Architecture
+
+- **Vector Database**: Store embeddings for semantic search (e.g., Pinecone, pgvector).
+- **Ingestion Pipeline**: Chunking strategies, embedding generation, metadata tagging.
+- **Retrieval**: Hybrid search (Keyword + Semantic) + Re-ranking for precision.
+
+### AI Agent Architectures
+
+- **Tool Use**: Expose deterministic APIs for agents to call.
+- **Memory**: Short-term (Conversation History) vs. Long-term (Vector Store/Entity Graph).
+- **Orchestration**:
+  - **ReAct**: Reason + Act loop.
+  - **Router**: Classify intent and route to specialized agent.
+  - **Multi-Agent**: Collaborative solving (e.g., Researcher + Writer + Reviewer).

package/.agent/skills/lead-architect/references/web-fullstack.md

@@ -0,0 +1,82 @@
+# Architecture: Web Fullstack (Next.js & Supabase)
+
+This guide defines the architectural standards for modern fullstack web applications using the Next.js App Router and Supabase/Postgres ecosystem.
+
+## 1. High-Level Strategy
+
+- **Server-First**: Leverage React Server Components (RSC) to reduce client bundle size and access data directly.
+- **Edge-Ready**: Design API routes and middleware to run on Edge runtimes for low latency where possible.
+- **Type Safety**: End-to-end type safety from Database (Supabase) to Backend (Actions) to Frontend (Components).
+
+## 2. Project Structure (Monorepo)
+
+We use a Turborepo-style structure to separate concerns and enable code sharing.
+
+```text
+.
+├── apps/
+│   ├── web/                 # Main Next.js Application
+│   │   ├── app/             # App Router (Routes & Layouts)
+│   │   ├── components/      # Local components specific to this app
+│   │   ├── lib/             # App-specific utilities
+│   │   └── middleware.ts    # Edge middleware (Auth, Rewrites)
+│   └── docs/                # Documentation site (if separate)
+└── packages/
+    ├── ui/                  # Shared UI Component Library (Shadcn/UI)
+    ├── database/            # Database schema, migrations, and typed client
+    ├── eslint-config/       # Shared linting rules
+    └── typescript-config/   # Shared tsconfig
+```
+
+## 3. Core Patterns
+
+### 3.1 Component Architecture (RSC vs Client)
+
+- **Default to Server**: All components are RSC by default. Fetch data here.
+- **Leaf Client Components**: Push `use client` down the tree. Ideally, only interactive buttons/forms are client-side.
+- **Composition**: Pass Client Components as `children` to Server Components to avoid "waterfalls" of client-side JavaScript.
+
+### 3.2 Data Fetching & Caching
+
+- **Fetch in Components**: Fetch data directly in RSCs where it is needed. Next.js dedupes requests automatically.
+- **Server Actions**: Use Server Actions for **Mutations** (POST/PUT/DELETE).
+  - Always validate input with **Zod** schema.
+  - Return standard `Result<T, E>` objects, not bare data or errors.
+- **Revalidation**: Use `revalidateTag` for granular cache invalidation after mutations.
+
+### 3.3 Database Access (Supabase/Postgres)
+
+- **Schema Schema**:
+  - `public`: Tables exposed via API (if using PostgREST).
+  - `private` / `auth`: Internal schemas.
+- **RLS (Row Level Security)**: **MANDATORY**. Never disable RLS. Write policies that rely on `auth.uid()`.
+- **Data Access Layer**:
+  - Do NOT call DB directly from UI components.
+  - Create a clean Data Access Layer (DAL) in `@package/database` or `apps/web/lib/db`.
+  - Example: `getUserProfile(userId)` rather than `supabase.from('profiles').select()...` inline.
+
+## 4. State Management
+
+- **Server State**: React Query (TanStack Query) is generally _not_ needed if using App Router deep integration, but useful if you have complex client-side polling/caching needs.
+- **URL State**: The URL is the single source of truth for sharable state (search params, filters, active tabs).
+- **Global Client State**: Use **Zustand** only for truly global, non-server state (e.g., Sidebar open/close, Audio player status). Use React Context for compound components.
+
+## 5. Security & Performance
+
+### Security
+
+- **Middleware**: Handle Authentication (Session Validation) and Authorization (Role Checks) in `middleware.ts` to protect routes at the edge.
+- **Validation**: Every Server Action must start with `inputSchema.parse(data)`.
+- **CSP**: Content Security Policy headers should be configured (careful with nonces for streaming).
+
+### Performance (Core Web Vitals)
+
+- **LCP (Largest Contentful Paint)**: Preload critical images, use `next/font`.
+- **CLS (Cumulative Layout Shift)**: explicit width/height for media, skeletons for checking states.
+- **Streaming**: Use `<Suspense>` boundaries to wrap slow data fetches. Let the shell load instantly.
+
+## 6. Development Workflow
+
+1.  **Migration**: Modify schema in `packages/database` -> `supabase db diff` -> `supabase db push`.
+2.  **Type Gen**: Run `supabase gen types` to update TypeScript definitions.
+3.  **Implementation**: Build RSC -> Connect to DAL -> Add Server Action for interactivity.