tribunal-kit 6.0.1 → 7.0.0

package/.agent/skills/data-validation-schemas/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before designing schemas or parsing untrusted data boundaries, you MUST inspect:
+
 1. Universal Trust Boundary Rule (Section 25) → Enforce explicit Zod/Pydantic schemas on API bodies, query params, env vars, and webhooks
 2. Server-Side Mandatory Validation (Section 16) → Never rely solely on client-side UX validation; execute schema validation on the server
 3. Environment Startup Parse (Section 173) → Parse `process.env` with Zod at app startup to crash immediately on missing keys
@@ -60,7 +61,7 @@ Trust Boundaries:
 ### Basic Schemas
 
 ```typescript
-import { z } from "zod";
+import { z } from 'zod';
 
 // Primitives with constraints
 const Email = z.string().email().toLowerCase().trim();
@@ -70,14 +71,14 @@ const Username = z
   .min(3)
   .max(30)
   .regex(/^[a-zA-Z0-9_]+$/);
-const URL = z.string().url().startsWith("https://");
+const URL = z.string().url().startsWith('https://');
 
 // Object schema
 const CreateUserSchema = z.object({
   name: z.string().min(2).max(100),
   email: Email,
   age: Age.optional(),
-  role: z.enum(["admin", "editor", "viewer"]).default("viewer"),
+  role: z.enum(['admin', 'editor', 'viewer']).default('viewer'),
   metadata: z.record(z.string(), z.unknown()).optional(),
 });
 
@@ -98,9 +99,9 @@ const BaseUserSchema = z.object({
 const CreateUserSchema = BaseUserSchema.extend({
   password: z.string().min(8),
   confirmPassword: z.string(),
-}).refine((data) => data.password === data.confirmPassword, {
+}).refine(data => data.password === data.confirmPassword, {
   message: "Passwords don't match",
-  path: ["confirmPassword"],
+  path: ['confirmPassword'],
 });
 
 const UpdateUserSchema = BaseUserSchema.partial(); // all fields optional
@@ -118,14 +119,14 @@ const FullProfileSchema = BaseUserSchema.merge(AddressSchema);
 
 ```typescript
 // ✅ Server-side: validate at the boundary, type-safe downstream
-import { z } from "zod";
+import { z } from 'zod';
 
 // Define once, use everywhere
 const QuerySchema = z.object({
   page: z.coerce.number().int().min(1).default(1),
   limit: z.coerce.number().int().min(1).max(100).default(20),
-  sort: z.enum(["created", "updated", "name"]).default("created"),
-  order: z.enum(["asc", "desc"]).default("desc"),
+  sort: z.enum(['created', 'updated', 'name']).default('created'),
+  order: z.enum(['asc', 'desc']).default('desc'),
   search: z.string().max(200).optional(),
 });
 
@@ -135,7 +136,7 @@ function validate<T extends z.ZodType>(schema: T) {
     const result = schema.safeParse(req.body);
     if (!result.success) {
       return res.status(400).json({
-        error: "Validation failed",
+        error: 'Validation failed',
         issues: result.error.flatten().fieldErrors,
       });
     }
@@ -144,7 +145,7 @@ function validate<T extends z.ZodType>(schema: T) {
   };
 }
 
-app.post("/api/users", validate(CreateUserSchema), async (req, res) => {
+app.post('/api/users', validate(CreateUserSchema), async (req, res) => {
   // req.body is now fully typed and validated
   const user = await createUser(req.body);
   res.status(201).json(user);
@@ -186,13 +187,13 @@ if (!result.success) {
 ```typescript
 // ✅ Validate ALL env vars at startup — crash immediately if invalid
 const EnvSchema = z.object({
-  NODE_ENV: z.enum(["development", "production", "test"]),
+  NODE_ENV: z.enum(['development', 'production', 'test']),
   PORT: z.coerce.number().default(3000),
   DATABASE_URL: z.string().url(),
   REDIS_URL: z.string().url().optional(),
-  JWT_SECRET: z.string().min(32, "JWT_SECRET must be ≥ 32 characters"),
+  JWT_SECRET: z.string().min(32, 'JWT_SECRET must be ≥ 32 characters'),
   API_KEY: z.string().min(1),
-  LOG_LEVEL: z.enum(["debug", "info", "warn", "error"]).default("info"),
+  LOG_LEVEL: z.enum(['debug', 'info', 'warn', 'error']).default('info'),
 });
 
 export const env = EnvSchema.parse(process.env);
@@ -241,15 +242,19 @@ async def create_user(user: CreateUserRequest):
 
 ```tsx
 // ✅ React Hook Form + Zod = type-safe forms
-import { useForm } from "react-hook-form";
-import { zodResolver } from "@hookform/resolvers/zod";
-import { z } from "zod";
+import { useForm } from 'react-hook-form';
+import { zodResolver } from '@hookform/resolvers/zod';
+import { z } from 'zod';
 
 const SignupSchema = z.object({
-  email: z.string().email("Invalid email address"),
-  password: z.string().min(8, "Password must be at least 8 characters").regex(/[A-Z]/, "Must contain uppercase letter").regex(/[0-9]/, "Must contain a number"),
+  email: z.string().email('Invalid email address'),
+  password: z
+    .string()
+    .min(8, 'Password must be at least 8 characters')
+    .regex(/[A-Z]/, 'Must contain uppercase letter')
+    .regex(/[0-9]/, 'Must contain a number'),
   terms: z.literal(true, {
-    errorMap: () => ({ message: "You must accept the terms" }),
+    errorMap: () => ({ message: 'You must accept the terms' }),
   }),
 });
 
@@ -265,15 +270,15 @@ function SignupForm() {
   });
 
   return (
-    <form onSubmit={handleSubmit((data) => signup(data))}>
-      <input {...register("email")} />
+    <form onSubmit={handleSubmit(data => signup(data))}>
+      <input {...register('email')} />
       {errors.email && <span>{errors.email.message}</span>}
 
-      <input type="password" {...register("password")} />
+      <input type="password" {...register('password')} />
       {errors.password && <span>{errors.password.message}</span>}
 
       <label>
-        <input type="checkbox" {...register("terms")} />I accept the terms
+        <input type="checkbox" {...register('terms')} />I accept the terms
       </label>
       {errors.terms && <span>{errors.terms.message}</span>}
 

package/.agent/skills/database-design/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before designing schemas or writing SQL migrations, you MUST inspect:
+
 1. Timezone Timestamp Standard (Section 17) → Use `TIMESTAMPTZ` for all timestamp columns; ban bare `TIMESTAMP`
 2. Primary Key Index Performance (Section 18) → Use `BIGINT GENERATED ALWAYS AS IDENTITY` or UUID v7 (time-ordered); ban random UUID v4 as primary key
 3. Foreign Key Indexing (Section 19) → Create explicit indexes on all foreign key columns (`CREATE INDEX idx_... ON table(fk_id)`) to prevent full table scans during cascading deletes
@@ -137,7 +138,7 @@ CREATE POLICY tenant_isolation ON projects
 const result = await db
   .select({ id: users.id, name: users.name })
   .from(users)
-  .where(and(eq(users.role, "admin"), eq(users.isActive, true)))
+  .where(and(eq(users.role, 'admin'), eq(users.isActive, true)))
   .orderBy(desc(users.createdAt))
   .limit(20);
 

package/.agent/skills/delight/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before implementing micro-delight moments, you MUST inspect:
+
 1. Action frequency context → Keep high-frequency delight (performed 50+ times/day) under 100ms and non-intrusive
 2. `prefers-reduced-motion` CSS media query → Provide fallback states for particle bursts and spring animations
 3. Morphing State Checkmark rules (Section 24) → Hold confirmation icon for 1.5s before smoothly morphing back
@@ -31,18 +32,23 @@ Elevate everyday digital interactions with subtle, memorable details that make s
 ## 5 Micro-Delight Patterns
 
 ### 1. The Morphing State Checkmark
+
 - When clicking "Copy Link" or "Save", morph the button icon or label smoothly into a checkmark icon with a quick spring bounce (`scale(1.15) -> scale(1)` over `180ms`), holding for 1.5 seconds before morphing back.
 
 ### 2. Micro-Confetti & Particle Bursts
+
 - On completing a key milestone (e.g. completing onboarding, submitting a project), trigger a lightweight 12-particle CSS/canvas burst anchored directly to the submit button.
 
 ### 3. Tactile Drag & Reorder Haptics
+
 - When dragging list items, elevate the item with a slight tilt ($2^\circ$), drop shadow increase, and scale (`scale(1.02)`), giving a physical card feeling.
 
 ### 4. Playful Empty State Animations
+
 - Transform boring zero-data states with subtle floating illustrations, witty microcopy, and a prominent primary action button.
 
 ### 5. Keyboard Shortcut Badges with Tooltips
+
 - Display subtle keyboard shortcut hints (e.g. `⌘K` or `Ctrl+K`) inside inputs or hover tooltips that respond with a subtle keypress press animation when pressed.
 
 ---

package/.agent/skills/deployment-procedures/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before deploying application releases or database migrations, you MUST inspect:
+
 1. Expand-and-Contract DB Migrations (Section 104) → Migrate schema FIRST (expand/copy data), then deploy code SECOND, contract legacy columns THIRD
 2. Instant Rollback Contingency (Section 116) → Tag every Docker image with Git SHA (`myapp:a1b2c3d`) for split-second image swaps during failure
 3. Zero-Downtime Traffic Switching (Section 29) → Use Blue/Green or Rolling updates with active health check verification before draining old instances
@@ -71,7 +72,7 @@ name: Production Deploy
 
 on:
   push:
-    branches: ["main"]
+    branches: ['main']
 
 # Concurrency limits prevent race conditions if two commits are pushed rapidly
 concurrency:

package/.agent/skills/design-lab/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before generating design variants or conducting design experiments, you MUST inspect:
+
 1. Structural Variant Difference Rule (Section 39) → Ensure generated layout variants are structurally distinct; ban micro-variations (differing only by 1px or hex color)
 2. Interactive Refinement Protocol (Section 32) → Ask targeted constraint questions before outputting final component implementations
 3. Visual Hierarchy Mapping (Section 26) → Map visual hierarchy explicitly to project design tokens before presenting options
@@ -33,14 +34,18 @@ Conduct rapid design experiments, explore multiple structural variants, and iter
 ## 3 Design Lab Phases
 
 ### Phase 1: Context & Constraint Gathering
+
 Ask 2 targeted questions to map out design direction:
+
 1. What aesthetic tone fits best? (e.g. Minimalist Editorial vs High-Impact Brutalist vs Clean Corporate SaaS)
 2. What component variants would you like to explore? (e.g. Card layout options A vs B)
 
 ### Phase 2: Generating Distinct Structural Variants
+
 Generate 2 distinct visual variants (e.g. Option A: Centered Minimalist vs Option B: Asymmetrical Card Grid).
 
 ### Phase 3: Interactive Refinement
+
 Synthesize feedback on preferred elements and build the polished final component.
 
 ---

package/.agent/skills/devops-engineer/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before building Dockerfiles, Docker Compose, or GitHub Actions pipelines, you MUST inspect:
+
 1. Non-Root Docker Container Rule (Section 47) → Explicitly specify a non-root user (`USER appuser`) in production Dockerfiles
 2. Deterministic Package Installation (Section 28) → Use `npm ci` (or yarn/pnpm equivalent with lockfiles) in Docker and CI; ban `npm install`
 3. CI/CD Concurrency Group Cancellation (Section 142) → Configure `concurrency.cancel-in-progress: true` on PR workflows to cancel stale builds
@@ -102,7 +103,7 @@ services:
       context: .
       target: runner
     ports:
-      - "3000:3000"
+      - '3000:3000'
     environment:
       - DATABASE_URL=postgres://postgres:postgres@db:5432/myapp
       - REDIS_URL=redis://redis:6379
@@ -122,7 +123,7 @@ services:
     volumes:
       - pgdata:/var/lib/postgresql/data
     healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      test: ['CMD-SHELL', 'pg_isready -U postgres']
       interval: 5s
       timeout: 3s
       retries: 5

package/.agent/skills/devops-incident-responder/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before responding to production outages or performing incident triage, you MUST inspect:
+
 1. Stabilization-First Rule (Section 25) → Immediately rollback/mitigate first (revert commit, flip flag, shed load); perform root cause analysis AFTER system is stable
 2. Circuit Breaker Severance (Section 42) → Sever failing downstream dependencies immediately to prevent cascading overload across the system
 3. Triage Hierarchy (Section 73) → Analyze metrics (what) → traces (where) → logs (why) sequentially to pinpoint root causes
@@ -74,7 +75,7 @@ const breaker = new CircuitBreaker(fetchUser, {
   resetTimeout: 30000, // Open the circuit (stop sending requests) for 30s
 });
 
-breaker.fallback(() => ({ id: "cached-user", status: "degraded" }));
+breaker.fallback(() => ({ id: 'cached-user', status: 'degraded' }));
 ```
 
 **Heavy Mitigation Tactics:**

package/.agent/skills/diagnosing-bugs/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before attempting bug diagnostics or proposing code fixes, you MUST inspect:
+
 1. Red-Capable Feedback Loop Rule (Section 34) → Construct a fast, deterministic, automated feedback loop command that reproduces the bug (goes red) BEFORE making code edits
 2. Falsifiable Hypotheses Formulation (Section 107) → Formulate 3–5 falsifiable hypotheses (`"If X is cause, then Y prediction"`) before testing any single theory
 3. Tagged Debug Logging & Cleanup (Section 123) → Tag debug log instrumentation (`[DEBUG-id]`) and sweep clean before finalizing regression fixes
@@ -66,6 +67,7 @@ Build the right feedback loop, and the bug is 90% fixed.
 ### Tighten the Loop
 
 Treat the loop as a product. Once you have a loop, tighten it:
+
 - **Can I make it faster?** (Cache setup, skip unrelated init, narrow the test scope.)
 - **Can I make the signal sharper?** (Assert on the specific symptom, not "didn't crash".)
 - **Can I make it more deterministic?** (Pin time, seed RNG, isolate filesystem, freeze network.)
@@ -79,21 +81,23 @@ The goal is not a clean repro but a higher reproduction rate. Loop the trigger 1
 ### When You Genuinely Cannot Build a Loop
 
 Stop and say so explicitly. List what you tried. Ask the user for:
+
 1. Access to whatever environment reproduces it.
 2. A captured artifact (HAR file, log dump, core dump, screen recording with timestamps).
 3. Permission to add temporary production instrumentation.
 
-*Do not proceed to hypothesise without a loop.*
+_Do not proceed to hypothesise without a loop._
 
 ### Phase 1 Completion Criterion — A Tight Loop That Goes Red
 
 Phase 1 is done when the loop is tight and red-capable: you can name **one command** — a script path, a test invocation, a curl — that you have already run at least once (paste the invocation and its output), and that is:
+
 - ✅ **Red-capable**: Drives the actual bug code path and asserts the user's exact symptom, going red on this bug and green once fixed. Not "runs without erroring" — it must catch this specific bug.
 - ✅ **Deterministic**: Same verdict every run (or high, pinned reproduction rate).
 - ✅ **Fast**: Seconds, not minutes.
 - ✅ **Agent-runnable**: Runnable unattended (HITL only via `scripts/hitl-loop.template.sh`).
 
-*If you catch yourself reading code to build a theory before this command exists, stop. No red-capable command, no Phase 2.*
+_If you catch yourself reading code to build a theory before this command exists, stop. No red-capable command, no Phase 2._
 
 ---
 
@@ -102,11 +106,13 @@ Phase 1 is done when the loop is tight and red-capable: you can name **one comma
 Run the loop. Watch it go red — the bug appears.
 
 ### Confirm
+
 1. The loop produces the failure mode the user described — not a different failure nearby. (Wrong bug = wrong fix.)
 2. The failure is reproducible across multiple runs (or at a high enough reproduction rate).
 3. You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix addresses it.
 
 ### Minimise
+
 Once it's red, shrink the repro to the smallest scenario that still goes red. Cut inputs, callers, config, data, and steps one at a time, re-running the loop after each cut — keep only what's load-bearing for the failure.
 
 > 🎯 **Why bother**: A minimal repro shrinks the hypothesis space in Phase 3 (fewer moving parts left to suspect) and becomes the clean regression test in Phase 5.
@@ -134,6 +140,7 @@ Show the ranked list to the user before testing. (Proceed with your ranking if t
 Each probe must map to a specific prediction from Phase 3. Change one variable at a time.
 
 ### Tool Preference
+
 1. **Debugger / REPL Inspection**: If the environment supports it. One breakpoint beats ten logs.
 2. **Targeted Logs**: Place logs at boundaries that distinguish hypotheses. Never "log everything and grep".
 3. **Tag Every Debug Log**: Prefix every debug log with a unique tag, e.g. `[DEBUG-a4f2]`. Cleanup at the end becomes a single grep.
@@ -150,6 +157,7 @@ A correct seam is one where the test exercises the real bug pattern as it occurs
 If no correct seam exists, note it. The codebase architecture is preventing the bug from being locked down. Flag this for Phase 6.
 
 ### If a Correct Seam Exists:
+
 1. Turn the minimised repro into a failing test at that seam.
 2. Watch it fail.
 3. Apply the fix.
@@ -161,6 +169,7 @@ If no correct seam exists, note it. The codebase architecture is preventing the
 ## Phase 6 — Cleanup + Post-Mortem
 
 ### Required Before Declaring Done
+
 - [ ] Original repro no longer reproduces (re-run Phase 1 loop)
 - [ ] Regression test passes (or absence of seam is documented)
 - [ ] All `[DEBUG-...]` instrumentation removed (grep the prefix)
@@ -168,6 +177,7 @@ If no correct seam exists, note it. The codebase architecture is preventing the
 - [ ] Correct hypothesis stated in commit / PR message
 
 ### Post-Mortem Handoff
+
 Ask: **What would have prevented this bug?** If the answer involves architectural debt (no good test seam, tangled callers, hidden coupling), hand off to `/improve-codebase-architecture` with specific findings.
 
 ---

package/.agent/skills/distill/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before decluttering UI layouts, you MUST inspect:
+
 1. Active screen components → Identify core primary user task and secondary/tertiary options
 2. Container Reduction rules (Section 25) → Replace nested card containers and redundant borders with whitespace grid gaps
 3. Progressive Disclosure patterns (Section 30) → Move advanced parameters into collapsible accordions or popovers
@@ -31,18 +32,22 @@ Systematically strip away visual clutter, redundant controls, and cognitive fric
 ## The 4 Distillation Steps
 
 ### 1. Identify & Remove Visual Noise
+
 - **Container Reduction**: Eliminate unnecessary nested cards, boxes inside boxes, and decorative borders. Use whitespace instead of lines to separate content blocks.
 - **Icon Pruning**: Remove decorative icons that restate obvious text labels (e.g. an envelope icon next to a button that clearly says "Send Email").
 
 ### 2. Collapse Secondary Actions
+
 - **Primary vs Overflow**: Keep only 1 primary action button and max 1 secondary button visible. Hide tertiary actions inside an overflow dropdown (`...` menu).
 - **Progressive Disclosure**: Hide advanced settings or non-essential controls behind an "Advanced Settings" accordion or popover.
 
 ### 3. Trim Copy & Microcopy
-- **Cut Conversational Filler**: Strip verbose instructions. Change *"Please fill out the form below to register your account"* to *"Create account"*.
-- **Shorten Button Labels**: Change *"Click here to update your profile settings"* to *"Save profile"*.
+
+- **Cut Conversational Filler**: Strip verbose instructions. Change _"Please fill out the form below to register your account"_ to _"Create account"_.
+- **Shorten Button Labels**: Change _"Click here to update your profile settings"_ to _"Save profile"_.
 
 ### 4. Group Related Fields
+
 - **Consolidate Form Inputs**: Merge separate "First Name" and "Last Name" fields into "Full Name" if separate values aren't strictly required. Merge city/state/zip into single address lookup where possible.
 
 ---

package/.agent/skills/documentation-templates/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before creating or editing documentation, API references, or comments, you MUST inspect:
+
 1. Target Audience Identification (Section 27) → Match template strictly to audience (README for 10-min quickstart, API docs for payload contracts, Runbook for on-call triage)
 2. Explain "Why", Not "What" in Code Comments (Section 147) → Document non-obvious business rules or bug workarounds; ban restating obvious code syntax
 3. AI-Friendly Documentation Mapping (Section 171) → Maintain `ARCHITECTURE.md` and `@purpose:` annotations for codebase mental models and automated ingestion
@@ -149,8 +150,8 @@ Creates a new user account.
 **Example**
 \`\`\`bash
 curl -X POST /api/users \
- -H "Content-Type: application/json" \
- -d '{"email": "user@example.com", "name": "Jane"}'
+-H "Content-Type: application/json" \
+-d '{"email": "user@example.com", "name": "Jane"}'
 \`\`\`
 ```
 

package/.agent/skills/domain-modeling/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before designing domain entities or business modeling, you MUST inspect:
+
 1. Ubiquitous Language Uniformity (Section 25) → Standardize 1 explicit term across UI, code, and DB (e.g. Customer vs User); ban interchangeable synonyms
 2. Bounded Context Separation (Section 30) → Isolate models per context (e.g. Inventory Product vs Catalog Product); ban 60-column monolithic entities
 3. Aggregate Root Invariants (Section 34) → Mutate child entities strictly through Aggregate Root methods (`order.addItem(...)`); ban direct child mutations
@@ -33,30 +34,37 @@ Model business domain concepts cleanly before committing to database schemas or
 ## 4 Domain Modeling Rules
 
 ### 1. Establish Ubiquitous Language
+
 - Agree on strict, unambiguous terms used identically across domain experts, code variable names, database tables, and UI copy.
-  - ❌ *User*, *Account*, *Member*, *Client* used interchangeably for the same concept.
+  - ❌ _User_, _Account_, _Member_, _Client_ used interchangeably for the same concept.
   - ✅ Define 1 clear term: **Customer** (for billing context) vs **User** (for authentication context).
 
 ### 2. Define Bounded Contexts
-- Separate large systems into distinct bounded contexts. An entity named `Product` in the *Inventory Context* (stock level, warehouse bin) has different attributes than `Product` in the *Catalog Context* (hero image, pricing).
+
+- Separate large systems into distinct bounded contexts. An entity named `Product` in the _Inventory Context_ (stock level, warehouse bin) has different attributes than `Product` in the _Catalog Context_ (hero image, pricing).
 
 ### 3. Aggregates & Invariants
+
 - An **Aggregate Root** (e.g. `Order`) enforces internal business invariants across child entities (`OrderItem`).
 - Never mutate a child entity (`OrderItem`) directly without passing through the aggregate root method (`order.addItem(product, qty)`).
 
 ### 4. Value Objects Over Primitives
+
 - Wrap primitives into type-safe Value Objects to enforce validation logic:
+
 ```typescript
 // Value Object enforcing domain rule
 export class EmailAddress {
   private readonly value: string;
 
   constructor(email: string) {
-    if (!email.includes("@")) throw new Error("Invalid email domain");
+    if (!email.includes('@')) throw new Error('Invalid email domain');
     this.value = email.toLowerCase().trim();
   }
 
-  public toString(): string { return this.value; }
+  public toString(): string {
+    return this.value;
+  }
 }
 ```
 

package/.agent/skills/duckdb-analytical-sql/SKILL.md

@@ -18,6 +18,7 @@ skills:
 ## Mandatory Pre-Flight Context Inspection
 
 Before writing analytical queries:
+
 1. Direct File Querying → Query Parquet/CSV/JSON directly without importing into a traditional DB
 2. Memory Allocation → Set explicit memory limit (`SET max_memory = '4GB'`) to prevent OOM
 3. Vectorized Engine Usage → Use column-oriented aggregation over line-by-line loops
@@ -29,11 +30,12 @@ import { Database } from 'duckdb-async';
 
 export async function runAnalyticalReport(parquetGlobPath: string) {
   const db = await Database.create(':memory:');
-  
+
   // Set memory limits for embedded execution
   await db.exec("SET max_memory = '2GB'; SET threads = 4;");
 
-  const rows = await db.all(`
+  const rows = await db.all(
+    `
     SELECT 
         date_trunc('day', timestamp) as event_day,
         event_type,
@@ -43,7 +45,9 @@ export async function runAnalyticalReport(parquetGlobPath: string) {
     GROUP BY 1, 2
     ORDER BY 1 DESC
     LIMIT 100
-  `, [parquetGlobPath]);
+  `,
+    [parquetGlobPath],
+  );
 
   return rows;
 }

package/.agent/skills/edge-ai-mobile/SKILL.md

@@ -18,6 +18,7 @@ skills:
 ## Mandatory Pre-Flight Context Inspection
 
 Before deploying on-device AI models:
+
 1. Model Quantization → Use 4-bit/8-bit quantized models (GGUF/ONNX) to fit mobile RAM budgets (<500MB)
 2. Hardware Acceleration → Bind inference engine to Apple Neural Engine (ANE) or Android NPU
 3. Fallback Mechanism → Fall back gracefully to cloud LLM API if local inference exceeds latency budget (>200ms)
@@ -32,7 +33,10 @@ export async function runLocalEmbeddings(textTokens: number[]): Promise<Float32A
     executionProviders: ['cpu'], // Accelerates via ANE/NNAPI internally
   });
 
-  const tensor = new ort.Tensor('int64', new BigInt64Array(textTokens.map(BigInt)), [1, textTokens.length]);
+  const tensor = new ort.Tensor('int64', new BigInt64Array(textTokens.map(BigInt)), [
+    1,
+    textTokens.length,
+  ]);
   const feeds = { input_ids: tensor };
 
   const results = await session.run(feeds);

package/.agent/skills/edge-computing/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before engineering edge computing handlers or Cloudflare Workers, you MUST inspect:
+
 1. Edge Runtime Restrictions (Section 25) → Strictly ban Node.js native core modules (`fs`, `child_process`, native `bcrypt`); use Web APIs (`fetch`, `crypto.subtle`)
 2. Stale-While-Revalidate Caching (Section 47) → Use `Cache-Control: s-maxage=60, stale-while-revalidate=86400` and asynchronous `ctx.waitUntil()` cache puts
 3. Edge Database Access (Section 81) → Never open direct raw TCP connections to DBs; use HTTP connection poolers (Prisma Accelerate, LibSQL, Supabase Pooler)
@@ -48,11 +49,11 @@ Edge functions (Cloudflare Workers, Vercel Edge) run on V8 Isolates, NOT standar
 
 ```typescript
 // ❌ BAD: Attempting to use Node native core modules
-import fs from "fs";
-import bcrypt from "bcrypt"; // Has C++ bindings, will instantly crash on V8 edge
+import fs from 'fs';
+import bcrypt from 'bcrypt'; // Has C++ bindings, will instantly crash on V8 edge
 
 // ✅ GOOD: Utilizing standard Web APIs (Fetch, CryptoKey)
-const hashBuffer = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(password));
+const hashBuffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(password));
 ```
 
 ---
@@ -79,7 +80,7 @@ export default {
       // Instructs the Edge CDN: Serve the stale version instantly to the user,
       // but fire an async request in the background to update the cache for the next user.
       response = new Response(response.body, response);
-      response.headers.set("Cache-Control", "s-maxage=60, stale-while-revalidate=86400");
+      response.headers.set('Cache-Control', 's-maxage=60, stale-while-revalidate=86400');
 
       // 4. Store in Cache asynchronously (do not block the user response)
       ctx.waitUntil(cache.put(request, response.clone()));
@@ -104,14 +105,14 @@ Running logic globally while querying a monolithic database in `us-east-1` is co
 
 ```typescript
 // ✅ Turso / LibSQL (Distributed Edge DB) usage:
-import { createClient } from "@libsql/client/web";
+import { createClient } from '@libsql/client/web';
 
 const client = createClient({
   url: env.TURSO_DATABASE_URL,
   authToken: env.TURSO_AUTH_TOKEN,
 });
 
-const result = await client.execute("SELECT * FROM users WHERE id = ?", [userId]);
+const result = await client.execute('SELECT * FROM users WHERE id = ?', [userId]);
 ```
 
 ---
@@ -137,9 +138,9 @@ export class ChatRoom {
     pair.server.accept();
 
     // Handle incoming Chat messages
-    pair.server.addEventListener("message", (msg) => {
+    pair.server.addEventListener('message', msg => {
       // Broadcast to all other connected edge users
-      this.sessions.forEach((session) => session.send(msg.data));
+      this.sessions.forEach(session => session.send(msg.data));
     });
 
     return new Response(null, { status: 101, webSocket: pair.client });