@stacksjs/defaults 0.72.103 → 0.73.0

package/ai/skills/stacks-office-hours/SKILL.md

@@ -1,15 +1,29 @@
 ---
 name: stacks-office-hours
-description: Use for structured product brainstorming about Stacks features — two modes (startup diagnostic for new ideas, builder generative for existing features). Produces design documents, never code. Invoke with /stacks-office-hours.
+description: Use for structured product brainstorming about Stacks features - two modes, a startup diagnostic for new ideas and a builder generative mode for existing features. Produces design documents, never code. Invoke with /stacks-office-hours.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob
 ---
 
-# /stacks-office-hours — Product Brainstorming
+# /stacks-office-hours - Product Brainstorming
 
 You are a product thinking partner for the Stacks ecosystem. You produce **design documents and strategic analysis**, never code.
 
+## How to run it
+
+Call the Skill tool with `stacks-grilling` and run the questions below through
+it: ask the whole frontier in one round, number each question, give your
+recommended answer, and wait. That skill also carries the rule that matters most
+here, which is that finding **facts** is your job and only the **decisions**
+belong to the user. Do not ask what `config/`, `app/Models/` or `buddy list`
+would have told you.
+
+Where a term comes up that the project has not settled, call the Skill tool with
+`stacks-domain-modeling` and settle it there and then. In a Stacks app the name
+becomes the model, the table, the route and the event, so it is cheaper to get
+right now.
+
 ## Determine Mode
 
 - **New idea** → Startup Mode (diagnostic)

package/ai/skills/stacks-orm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-orm
-description: Use when working with the Stacks ORM — defining models with defineModel(), model relationships (hasOne, hasMany, belongsTo, belongsToMany, morphOne, hasManyThrough), attributes, traits, factories, computed properties, query building, transactions, or the 50+ built-in models. Covers @stacksjs/orm, storage/framework/orm/, and storage/framework/defaults/app/Models/.
+description: Use when working with the Stacks ORM - defining models with defineModel(), model relationships (hasOne, hasMany, belongsTo, belongsToMany, morphOne, hasManyThrough), attributes, traits, factories, computed properties, query building, transactions, or the 50+ built-in models. Covers @stacksjs/orm, storage/framework/orm/, and storage/framework/defaults/app/Models/.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript, SQLite >= 3.47.2
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-path/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-path
-description: Use when working with file paths in Stacks — 100+ framework-aware path builder functions for every directory in the project (actions, app, config, database, models, routes, storage, etc.), plus Node.js path utilities (join, resolve, basename, dirname, etc.). Covers @stacksjs/path.
+description: Use when working with file paths in Stacks - 100+ framework-aware path builder functions for every directory in the project (actions, app, config, database, models, routes, storage, etc.), plus Node.js path utilities (join, resolve, basename, dirname, etc.). Covers @stacksjs/path.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-payments/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-payments
-description: Use when implementing payment processing in Stacks — Stripe charges, subscriptions, checkout sessions, customer management, payment methods, invoices, coupons, promo codes, products, prices, webhooks, or the Payment facade. Covers @stacksjs/payments and config/payment.ts.
+description: Use when implementing payment processing in Stacks - Stripe charges, subscriptions, checkout sessions, customer management, payment methods, invoices, coupons, promo codes, products, prices, webhooks, or the Payment facade. Covers @stacksjs/payments and config/payment.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob
@@ -25,6 +25,7 @@ Full Stripe integration via the Payment facade. Uses Stripe API version `2026-01
 - All billable modules (`manageCharge`, `manageCustomer`, `manageSubscription`, etc.)
 - `stripe` -- raw Stripe SDK instance
 - `Stripe` -- re-exported Stripe types namespace
+- `stacksIdempotencyKey`, `freshIdempotencyKey` -- see Idempotency below
 
 ## Payment Facade
 
@@ -347,6 +348,39 @@ authenticated user. Subscription and payment-method reads are provider-backed
 and may be unavailable when the application User override is not billable.
 Render that as an explicit unavailable state, not sample plans or fake cards.
 
+## Idempotency
+
+Stripe calls that **create or attach** a resource are not idempotent by default.
+The classic failure: `createStripeCustomer(user)` succeeds at Stripe, the
+follow-up `user.update({ stripe_id })` fails, the next request sees no
+`stripe_id` and creates a second Stripe customer with no link to the local user.
+
+Pass an idempotency key on every create, attach or update call. Stripe caches
+the response under that key for 24 hours, so a retry returns the original object
+instead of making a new one.
+
+```typescript
+import { stacksIdempotencyKey } from '@stacksjs/payments'
+
+await stripe.customers.create(params, {
+  idempotencyKey: stacksIdempotencyKey('customer.create', user.id),
+})
+```
+
+Keys are built as `stacks:<scope>:<parts...>:v1`, hashed when they would exceed
+Stripe's 255-character limit, and deterministic: the same inputs always produce
+the same key, which is the whole point.
+
+- **`stacksIdempotencyKey(scope, ...parts)`** is the one to reach for. `scope` is
+  a stable operation name and never user input; `parts` scope it within the
+  user's lifetime.
+- **`freshIdempotencyKey(scope, ...parts)`** appends randomness, so it does *not*
+  deduplicate. Use it only when a repeat call is genuinely a new operation (a
+  second, deliberate charge of the same amount), never as a way to get past a
+  cached response.
+- Bump the `v1` suffix in `idempotency.ts` when an operation's parameters change
+  in a way that should not collide with a cached response.
+
 ## config/payment.ts
 
 ```typescript

package/ai/skills/stacks-plan-review/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: stacks-plan-review
-description: Use for architecture review of Stacks changes — scope review (CEO-level), data flow analysis, dependency analysis, test matrices, and implementation plans. Invoke with /stacks-plan-review.
+description: Use for architecture review of Stacks changes - scope review, data flow analysis, dependency and interface analysis, test matrices, and an implementation plan sliced into tracer bullets. Invoke with /stacks-plan-review.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob
 ---
 
-# /stacks-plan-review — Architecture Review & Planning
+# /stacks-plan-review - Architecture Review & Planning
 
 You analyze proposed changes at two levels: scope review (are we building the right thing?) and engineering review (are we building it right?).
 
@@ -14,9 +14,21 @@ You analyze proposed changes at two levels: scope review (are we building the ri
 
 If `/stacks-office-hours` produced a design document, read it. Don't ask the user to re-explain.
 
+## Vocabulary
+
+Call the Skill tool with `stacks-codebase-design` before Step 3. Every interface
+and seam judgement below uses its terms exactly (**module**, **interface**,
+**depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles:
+the deletion test, the interface is the test surface, and one adapter means a
+hypothetical seam while two mean a real one. Do not drift into "component",
+"service" or "boundary".
+
+Where the plan is still soft enough that questions outnumber answers, run
+`stacks-grilling` first and come back with the decision tree settled.
+
 ## Step 1: Scope Review
 
-### Expansion Analysis — Is this doing too much
+### Expansion Analysis - Is this doing too much
 
 ```
 | Addition | Core to goal? | Can ship separately? | Risk if included |
@@ -24,7 +36,7 @@ If `/stacks-office-hours` produced a design document, read it. Don't ask the use
 | [item] | [yes/no] | [yes/no] | [risk] |
 ```
 
-### Reduction Analysis — Is this doing too little
+### Reduction Analysis - Is this doing too little
 
 ```
 | Missing piece | Needed for v1? | Cost of deferring |
@@ -120,7 +132,14 @@ P0: Must have before merge. P1: Should have. P2: Nice to have.
 1. [specific rollback step]
 ```
 
-Each phase should be independently mergeable. Run `bun test` at each checkpoint.
+Each phase should be independently mergeable, which is the same bar
+`stacks-new-feature` sets for a **tracer bullet**: a narrow but complete path
+through model, migration, action, route and test. Hand the phases to that skill
+to slice and build, and give each one its blocking edges here so the frontier is
+obvious. A change whose blast radius makes a vertical slice impossible is a
+**wide refactor**, and it is sequenced expand, migrate, contract instead.
+
+Run `./buddy typecheck` and `bun test` at each checkpoint.
 
 ## Output
 
@@ -149,4 +168,6 @@ Each phase should be independently mergeable. Run `bun test` at each checkpoint.
 
 ## Downstream
 
-> **Plan complete.** After implementation, run `/stacks-review` for code review, `/stacks-security-audit` for security, or `/stacks-browse` for QA.
+> **Plan complete.** Build it with `/stacks-new-feature`, driving `/stacks-tdd`
+> inside each slice. Then `/stacks-review` for the two-axis review,
+> `/stacks-security-audit` for security, or `/stacks-browse` for QA.

package/ai/skills/stacks-plugins/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-plugins
-description: Use when working with the Stacks preload chain and Bun plugins — the env plugin, the framework preloader, how auto-imports get injected into globalThis, why a command does or does not see framework globals, the bun-plugin-stx static-serve plugin, or writing a Bun plugin. Covers bunfig.toml preload and storage/framework/defaults/resources/plugins/preloader.ts.
+description: Use when working with the Stacks preload chain and Bun plugins - the env plugin, the framework preloader, how auto-imports get injected into globalThis, why a command does or does not see framework globals, the bun-plugin-stx static-serve plugin, or writing a Bun plugin. Covers bunfig.toml preload and storage/framework/defaults/resources/plugins/preloader.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-prototype/LOGIC.md

@@ -0,0 +1,103 @@
+# Logic prototype
+
+A single, self-contained HTML file that lets anyone drive a state model by
+clicking buttons. Use this when the question is about **business logic, state
+transitions, or data shape**: the kind of thing that looks reasonable on paper
+and only feels wrong once you push it through real cases.
+
+Because it is one file with nothing to install, you can hand it to a
+non-developer (a designer, a PM, a domain expert) and let them feel the model for
+themselves. So it speaks their language, not the code's.
+
+If the question is "what should this look like", this is the wrong branch. Use
+[UI.md](UI.md).
+
+## Process
+
+### 1. State the question
+
+Before writing code, write down what state model you are prototyping and what
+question you are asking of it. One paragraph, at the top of the demo, in a
+visible intro rather than a comment. A prototype that answers the wrong question
+is pure waste.
+
+### 2. Isolate the logic in a portable module
+
+Put the logic that answers the question in a single `<script>` block, written as
+a small pure module that could be lifted out and dropped into the real codebase.
+The page around it is throwaway. This module is not.
+
+Pick the shape that fits the question:
+
+- **A pure reducer**, `(state, action) => state`. Good when actions are discrete
+  events and state is a single value.
+- **A state machine** with explicit states and transitions. Good when "which
+  actions are even legal right now" is part of the question.
+- **A small set of pure functions** over a plain data type. Good when there is no
+  implicit current state, just transformations.
+- **A module with a clear method surface**, when the logic genuinely owns ongoing
+  internal state.
+
+Keep it pure: no DOM, no `document`, no button handlers reaching inside it. The
+page calls into it, nothing flows the other way. That is what makes the answer
+liftable: once the question is settled, the validated reducer or machine moves
+into an action, a job or a model on its own.
+
+### 3. Build the shareable HTML file
+
+One file, plain HTML, CSS and JS. No framework, no bundler, no server,
+everything inline so it opens by double-click and survives being emailed around.
+This is the one place in a Stacks project where hand-written vanilla JS is
+correct, because the artifact has to run with nothing installed. It is not stx
+and it never ships.
+
+Write it for a non-developer. Every label is in **domain language**, not code.
+Use the terms from `CONTEXT.md` if the project has one.
+
+Lay it out top to bottom:
+
+1. **Title and one-line explanation** of what the demo lets you explore, which is
+   the question from step 1.
+2. **Current state**, rendered as a readable labelled panel rather than a raw
+   JSON dump, re-rendered after every click so the change is visible.
+3. **Free-play buttons**, one per action, always available, so anyone can poke at
+   the model in any order.
+4. **Guided walkthroughs**: a set of scenarios, one per tab. Each tab holds a
+   short plain-language description of the situation and what to watch for, and
+   under it the ordered buttons to press. Each step is a real button: clicking it
+   performs that action and moves to the next. Starting a walkthrough resets to a
+   known initial state so the scenario runs the same way every time.
+
+Choose scenarios that demonstrate the awkward cases: the happy path, a tricky
+edge, and an attempt at something that should be illegal.
+
+Keep it clean but restrained. Clean typography, generous spacing, one accent
+colour, no animation. Nothing that competes with the state and the buttons.
+
+### 4. Hand it over
+
+Send the file or open it. The interesting moments are "wait, that should not be
+possible" and "huh, I assumed X would be different". Those are bugs in the
+*idea*, which is the whole point. If they want new actions or another scenario,
+add them. Prototypes evolve.
+
+### 5. Capture the answer and the prototype
+
+Once the question is answered, capture the answer, then capture the prototype the
+way [SKILL.md](SKILL.md) describes. The validated reducer, machine or function
+set lifts into the real module. The HTML shell rides along to the
+`prototype/<name>` branch, where being one self-contained file keeps it trivially
+re-runnable.
+
+## Anti-patterns
+
+- **Adding tests.** A prototype that needs tests is no longer a prototype.
+- **Wiring it to the real database.** In-memory state, unless the question is
+  specifically about persistence.
+- **Generalising.** No "what if we wanted to support X later". One question.
+- **Blurring the logic and the page together.** If the pure module touches the
+  DOM, it is no longer liftable.
+- **Reaching for a framework, bundler or server.** One file the recipient
+  double-clicks. A dev server defeats "shareable".
+- **Shipping the HTML shell.** The page is optimised for being clicked through by
+  hand. The module behind it is the part worth keeping.

package/ai/skills/stacks-prototype/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: stacks-prototype
+description: Use when a design question needs a runnable answer rather than an argument - does this state model hold up, what should this page look like, is this API shape right. Builds throwaway code that answers one question, either a single shareable HTML demo or several stx view variants.
+license: MIT
+compatibility: Bun >= 1.3.0, TypeScript
+allowed-tools: Read Edit Write Bash Grep Glob
+---
+
+# Prototype
+
+A prototype is **throwaway code that answers a question**. The question decides
+the shape.
+
+Credit: adapted from Matt Pocock's `prototype` skill (MIT),
+<https://github.com/mattpocock/skills>.
+
+## Pick a branch
+
+Identify which question is being answered, from the user's prompt, the
+surrounding code, or by asking if the user is around:
+
+- **"Does this logic or state model feel right?"** goes to [LOGIC.md](LOGIC.md).
+  A single shareable HTML file, free-play buttons plus tabbed guided
+  walkthroughs, that pushes the state machine through cases that are hard to
+  reason about on paper and that a non-developer can drive.
+- **"What should this look like?"** goes to [UI.md](UI.md). Several radically
+  different stx variants of one view, switchable in the browser.
+
+The two branches produce very different artifacts, so getting this wrong wastes
+the whole prototype. If the question is genuinely ambiguous and the user is not
+reachable, default by where the code lives (a model, action or job means logic, a
+view or component means UI) and state the assumption at the top of the prototype.
+
+## Rules that apply to both
+
+1. **Throwaway from day one, and marked as such.** Put the prototype next to
+   what it is prototyping for, so context is obvious, and name it so a casual
+   reader can see it is not production.
+2. **Trivial to run.** A UI prototype starts from `buddy dev`. A logic demo is a
+   single HTML file the user double-clicks. No thinking required to start it.
+3. **No persistence by default.** State lives in memory. Persistence is the thing
+   the prototype is *checking*, not something it should depend on. If the
+   question genuinely involves the database, point it at the testing SQLite file
+   or a clearly named scratch one.
+4. **Skip the polish.** No tests, no error handling beyond what makes it
+   runnable, no abstractions. The point is to learn something fast.
+5. **Surface the state.** After every action, or on every variant switch, render
+   the full relevant state so the user can see what changed.
+6. **Capture it when done.** Fold the validated decision into the real code, then
+   keep the prototype itself as a **primary source**: commit it to a
+   `prototype/<name>` branch, out of `main`, and leave a pointer to that branch
+   on the issue. Capture the answer too, the verdict and the question it settled.
+   `main` keeps only the validated decision.
+
+## What a prototype is not
+
+Not a spike you promote. The code was written under prototype constraints, so
+rewrite it properly when you fold it in. Not a design deliverable either: for
+production UI quality, `stacks-design-taste` and the aesthetic skills own that
+bar, and this skill only answers "which direction".
+
+## Downstream
+
+> Answer in hand? Take it into `/stacks-plan-review` or `/stacks-new-feature`.
+> If the winning variant is the one you will build, `/stacks-design-taste` sets
+> the bar for the real implementation.

package/ai/skills/stacks-prototype/UI.md

@@ -0,0 +1,112 @@
+# UI prototype
+
+Generate **several radically different variants** of one view and let the user
+flip between them in the browser, pick one (or steal bits from each), and throw
+the rest away.
+
+If the question is about logic or state rather than what something looks like,
+this is the wrong branch. Use [LOGIC.md](LOGIC.md).
+
+## When this is the right shape
+
+- "What should this page look like?"
+- "I want to see a few options for this dashboard before committing."
+- "Try a different layout for the settings screen."
+- Any time the user would otherwise spend a day picking between three vague
+  mockups in their head.
+
+## Judge it against the real app
+
+A variant is much easier to judge when it is **butting up against the rest of the
+app**: real layout, real data, real density. A throwaway page on its own is a
+vacuum where every variant looks fine. So prefer, in order:
+
+1. **Variants inside the existing view.** The route already exists and its data
+   already loads. Only the rendered subtree swaps. Pick this whenever there is a
+   plausible host page, including for something new that would naturally live
+   inside one (a new section of a dashboard, a new card on a settings screen).
+2. **Throwaway views**, only when the thing genuinely has no existing page to
+   live inside.
+
+## Process
+
+### 1. State the question and pick N
+
+Default to **3** variants. Past 5 they stop being radically different and start
+being noise, so cap there. Write the plan in one line at the top of the host
+view:
+
+> Three variants of the settings page, switchable from the prototype bar, on the
+> existing settings view.
+
+### 2. Generate radically different variants
+
+Draft each variant as an stx component under
+`resources/components/prototype/<name>/VariantA.stx` (and B, C). Hold each one
+to:
+
+- The page's purpose and the data it actually has.
+- Crosswind utilities, Iconify classes for icons, and signals or composables in
+  `<script>` blocks. The project's frontend rules do not relax for a prototype:
+  no `var`, no `document.*`, no `window.*`, no animation library, no em-dash in
+  any visible copy.
+- A clear component name and a one-line description of the idea behind it.
+
+Variants must be **structurally different**: different layout, different
+information hierarchy, different primary affordance. Not different colours. Three
+slightly tweaked card grids is wallpaper, not a prototype. If two drafts come out
+too similar, redo one under an explicit constraint ("no card grid").
+
+### 3. Wire them together
+
+Two mechanics, and both are fine. Pick by how the host view already gets its
+state:
+
+- **One view per variant.** Add `resources/views/prototype/<name>/a.stx`,
+  `b.stx`, `c.stx`, each rendering one variant inside the real layout. Views are
+  file-routed, so these are reachable immediately, though a newly nested
+  directory usually needs a `buddy dev` restart before it stops 404ing.
+- **One view, switched on a signal**, when the host view already reads request
+  state. Render `@if` on the variant and default to A.
+
+Either way the variants sit inside the real layout and the real data, which is
+the point.
+
+### 4. Build the floating switcher
+
+One shared stx partial under `resources/partials/`, included by each prototype
+view:
+
+- Links or buttons to the previous and next variant, wrapping around.
+- The current variant key and its name, for instance `B (sidebar layout)`.
+- Fixed to the bottom centre, high contrast, visually distinct from the page so
+  it is obviously not part of the design being judged.
+- Rendered only outside production. Gate it on the app environment so a stray
+  merge cannot ship the bar to users.
+
+### 5. Hand it over
+
+Give the user the URLs. The interesting feedback is almost always "I want the
+header from B with the sidebar from C", which is the design they actually want.
+
+### 6. Capture the answer and clean up
+
+Once a variant wins, capture the answer (which one and why), then capture the
+prototype the way [SKILL.md](SKILL.md) describes:
+
+- Fold the winner into the real view, rewritten to production standard against
+  `stacks-design-taste`.
+- Move the losing variants, the prototype views and the switcher partial onto the
+  `prototype/<name>` branch. They rot fast in `main` and confuse the next reader.
+- Run `./buddy lint:fix` and remove the prototype directory from `main`.
+
+## Anti-patterns
+
+- **Variants that differ only in colour or copy.** That is a tweak. Real variants
+  disagree about structure.
+- **Sharing too much between variants.** A shared layout defeats the point. Each
+  variant should be free to throw the layout out.
+- **Wiring variants to real mutations.** Read-only is fine. The question is what
+  it should look like, not whether the backend works.
+- **Promoting the prototype straight to production.** Rewrite it when you fold it
+  in.

package/ai/skills/stacks-push/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-push
-description: Use when implementing push notifications in Stacks — sending via Expo Push Service or Firebase Cloud Messaging (FCM legacy and v1 APIs), configuring push drivers, batch sending, multicast, topic subscriptions, push notification payloads, token validation, or receipt checking. Covers @stacksjs/push.
+description: Use when implementing push notifications in Stacks - sending via Expo Push Service or Firebase Cloud Messaging (FCM legacy and v1 APIs), configuring push drivers, batch sending, multicast, topic subscriptions, push notification payloads, token validation, or receipt checking. Covers @stacksjs/push.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-query-builder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-query-builder
-description: Use when building database queries in a Stacks application — constructing SQL queries, using the fluent query API, or configuring the query builder. Covers @stacksjs/query-builder which wraps bun-query-builder, and config/query-builder.ts.
+description: Use when building database queries in a Stacks application - constructing SQL queries, using the fluent query API, or configuring the query builder. Covers @stacksjs/query-builder which wraps bun-query-builder, and config/query-builder.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript, SQLite >= 3.47.2
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-queue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-queue
-description: Use when working with job queues in a Stacks application — creating jobs, dispatching, workers, batches, failed jobs, queue events, health checks, testing, Redis/database/sync drivers, rate limiting, or scheduled jobs. Covers @stacksjs/queue, config/queue.ts, and app/Jobs/.
+description: Use when working with job queues in a Stacks application - creating jobs, dispatching, workers, batches, failed jobs, queue events, health checks, testing, Redis/database/sync drivers, rate limiting, or scheduled jobs. Covers @stacksjs/queue, config/queue.ts, and app/Jobs/.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-realtime/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-realtime
-description: Use when implementing real-time features in Stacks — WebSocket broadcasting, public/private/presence channels, emit to users, the Channel class, broadcast discovery, server lifecycle, or realtime configuration. Covers @stacksjs/realtime and config/realtime.ts.
+description: Use when implementing real-time features in Stacks - WebSocket broadcasting, public/private/presence channels, emit to users, the Channel class, broadcast discovery, server lifecycle, or realtime configuration. Covers @stacksjs/realtime and config/realtime.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-registry/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-registry
-description: Use when working with the Stacks extension registry — framework extension metadata, package discovery, or the registry system. Covers @stacksjs/registry.
+description: Use when working with the Stacks extension registry - framework extension metadata, package discovery, or the registry system. Covers @stacksjs/registry.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-repl/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-repl
-description: Use when working with the Stacks REPL — interactive TypeScript sessions, tinker sessions, debugging, or exploring the framework interactively. Covers @stacksjs/repl and @stacksjs/tinker.
+description: Use when working with the Stacks REPL - interactive TypeScript sessions, tinker sessions, debugging, or exploring the framework interactively. Covers @stacksjs/repl and @stacksjs/tinker.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob