@stacksjs/defaults 0.72.102 → 0.73.0

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

@@ -1,122 +1,168 @@
 ---
 name: stacks-retro
-description: Use for git-based session retrospectives — session detection, commit categorization, focus scores, streak counting, and behavioral observations. Invoke with /stacks-retro.
+description: Use for a retrospective on Stacks work - proposing concrete improvements to the agent's environment (navigation pointers, automated checks, AGENTS.md, skills, tool economy) from what actually went wrong, backed by git-derived session data. Invoke with /stacks-retro.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob
 ---
 
-# /stacks-retro — Session Retrospective
-
-Generate a retrospective analysis of recent development work based on git history.
-
-## Step 1: Session Detection
-
-Detect sessions using a **45-minute gap threshold** between commits.
+# /stacks-retro - session retrospective
+
+A retrospective here is not a report card. You are proposing improvements to the
+**environment** the next session runs in, so that the mistakes this session made
+become impossible or cheap to catch. Pass 1 finds the improvements. Pass 2 backs
+them with data from git.
+
+Call the Skill tool with `stacks-writing-for-agents` before proposing any change
+to a document. Half the candidates below are edits to files agents read, and a
+retro that adds sediment to `AGENTS.md` has made things worse.
+
+Credit: the environment-improvement framing is adapted from Matt Pocock's `retro`
+skill (MIT), <https://github.com/mattpocock/skills>.
+
+## Pass 1: environment improvements
+
+### Read the primary sources
+
+Read the session the user names, defaulting to the current one. Where the session
+is not in context, reconstruct it from the diff, the commits, and any session
+logs on this machine. Work from what actually happened, not from a summary.
+
+### Look for candidates in these categories
+
+- **Navigation.** How easy was it to find the right file? Are there hidden
+  dependencies between files? Would a **navigation pointer** in `AGENTS.md`, or a
+  `Key paths` block in the relevant skill, have shortened it? *Use when* the
+  session spent a long time hunting for one piece of information.
+- **Automated checks.** Could a check have caught this mistake? `pickier` rules,
+  a type, a test, a contract test in `tests/unit/`, a `buddy` command that
+  validates a registry. *Use when* the agent made a mistake a machine could have
+  caught. This is the strongest category, because a check does not depend on
+  anyone reading anything.
+- **Coding standards.** Should the review get a new rule to enforce, or should an
+  existing one be removed or clarified? *Use when* `/stacks-review` missed
+  something it should have caught.
+- **AGENTS.md.** Are there steering instructions that belong in a check or a
+  skill instead? Is anything in it a **no-op**, an instruction the model already
+  obeys by default? *Use when* the file is large and unwieldy, in the repo or in
+  the user's global scope.
+- **Skills.** Did the agent guess at an API a skill documents? Then the skill's
+  **description** is the bug, not its body: the pointer did not fire. Did the
+  agent read a skill and still get it wrong? Then the body is the bug. Did the
+  work touch a subsystem with no skill? That is a new one under `app/Skills/`.
+- **Tool economy.** Did the agent make expensive calls that could be streamlined?
+  Is a custom command or MCP server particularly token-inefficient? *Use when*
+  one call dominated the session.
+- **Information access.** Could the agent have been given more? Teeing
+  `buddy dev` output to a file it can read, `storage/logs/stacks.log`, read-only
+  access to a dashboard or a third-party console. *Use when* a crucial fact was
+  simply not reachable.
+- **Generated artifacts going stale.** Did the session trip over
+  `storage/framework/types/*.d.ts`, an auto-import manifest, or a migration that
+  no longer matched its model? The fix is usually a check that regenerates and
+  diffs in CI, not a line asking someone to remember.
+
+### Present them
+
+In order of severity, each as: what happened, which category, the specific change
+to make, and where it goes. Be concrete. "Add a note about migrations" is not a
+candidate. "Add a contract test in `tests/unit/` that fails when
+`database/types.d.ts` is missing a table any migration creates" is.
+
+Ask before writing any of them.
+
+## Pass 2: the data
+
+Back the observations with git rather than impressions.
+
+### Session detection
+
+Detect sessions with a **45-minute gap threshold** between commits.
 
 ```bash
 git log --all --format="%H|%ai|%an|%s" --since="7 days ago"
 ```
 
-Adjust `--since` if user specifies a range ("today", "this week", etc.).
+Adjust `--since` for the range the user asked for. Default to 7 days.
 
-## Step 2: Commit Categorization
+### Commit categorization
 
 | Category | Indicators | Icon |
-|----------|-----------|------|
+|---|---|---|
 | Feature | `feat:`, new files, new exports | 🟢 |
-| Fix | `fix:`, corrective changes | 🔴 |
-| Refactor | `refactor:`, structural changes | 🔵 |
+| Fix | `fix:` | 🔴 |
+| Refactor | `refactor:` | 🔵 |
 | Test | `test:`, test file changes | 🟡 |
 | Docs | `docs:`, README changes | 📝 |
 | Chore | `chore:`, deps, config, CI | ⚙️ |
 | Style | `style:`, formatting, lint | 🎨 |
 
-Parse `gitlint`-style conventional commit prefixes. Stacks uses these scopes: `core`, `auth`, `database`, `router`, `buddy`, `ui`, `build`, etc.
+Parse the conventional-commit prefixes and the scopes from `config/git.ts`.
 
-## Step 3: Session Analysis
+### Focus
 
-### Focus Score (0-100)
 ```
-focus_score = (commits_in_primary_area / total_commits) × 100
+focus = (commits in the primary area / total commits) × 100
 ```
 
-Primary area = most-touched `storage/framework/core/*/` package or top-level directory.
-
-- **80-100**: Deep focus
-- **50-79**: Moderate focus
-- **0-49**: Scattered
+The primary area is the most-touched `storage/framework/core/*/` package or
+top-level directory. 80+ is deep focus, 50 to 79 is moderate, below 50 is
+scattered.
 
 ```
-### Session [N]: [start] → [end] ([duration])
-**Focus**: [score]/100 — [assessment]
-**Primary area**: [package/directory]
+### Session [N]: [start] to [end] ([duration])
+**Focus**: [score]/100
+**Primary area**: [package or directory]
 **Commits**: [count]
 
 | Time | Category | Message | Files |
-|------|----------|---------|-------|
-
-**Observation**: [one behavioral insight]
+|---|---|---|---|
 ```
 
-## Step 4: Streaks
+### Signals worth reading
 
-```bash
-git log --all --format="%ad" --date=short | sort -u
-```
+A pattern in the data is only interesting when it points at a Pass 1 candidate:
 
-```
-## Streaks
-🔥 Current streak: [N] days
-📈 Longest streak: [N] days ([range])
-📅 Active days: [N] / [total]
-```
-
-## Step 5: Per-Contributor Metrics (if multiple)
-
-```
-| Contributor | Commits | Primary Focus | Top Category | Avg Focus |
-|-------------|---------|---------------|--------------|-----------|
-```
-
-## Step 6: Behavioral Observations
-
-2-4 observations backed by data:
-
-- "You wrote 12 fix commits after the auth refactor — consider adding tests before next refactor session."
-- "Focus score drops in afternoon sessions. Morning sessions average 85."
-- "No test commits this week despite 8 feature commits. Test debt accumulating."
-- "3/4 sessions started with chore commits. Consider batching into a maintenance session."
+- A run of `fix:` commits after one `refactor:` is a missing check or a missing
+  test at that seam.
+- Feature commits with no test commits is accumulating debt with a name and a
+  location.
+- Repeated chore commits at the start of every session is a setup step that wants
+  automating.
+- A low focus score across a week where each session is individually focused is
+  usually a navigation problem, not a discipline one.
 
 ## Output
 
 ```
-# Retrospective: [date range]
+# Retrospective: [range]
 
-## Overview
-- **Period**: [range]
-- **Sessions**: [count]
-- **Total commits**: [count]
+## Improvements
+[candidates, most severe first, each with its category and the exact change]
 
-## Category Breakdown
-[icons and counts]
+## Data
+- Period, sessions, commits
+- Category breakdown
+- Sessions and focus
+- Signals
 
-## Sessions
-[session details]
-
-## Streaks
-[streak data]
-
-## Observations
-[behavioral insights]
-
-## Suggested Focus for Next Session
+## Next session
 [one specific suggestion]
 ```
 
 ## Rules
 
-- **Data-driven only.** Every observation backed by commits/metrics.
-- **No judgment on work hours.** Don't comment on when someone works.
-- **Default to 7 days** if no range specified.
-- **Handle messy history gracefully.** Squash/merge/rebase can distort sessions.
+- **Every observation is backed by a commit, a diff or a log line.** No vibes.
+- **Propose environment changes, not personal ones.** No comment on when someone
+  works or how fast.
+- **Prefer a check to a sentence.** A rule nobody reads is a rule that does not
+  exist.
+- **Deleting counts.** A no-op line removed from `AGENTS.md` is as good a
+  candidate as a new one added.
+- **Handle messy history gracefully.** Squash, merge and rebase distort session
+  boundaries. Say so rather than inventing precision.
+
+## Downstream
+
+> Candidate accepted? `/stacks-writing-for-agents` for anything that lands in a
+> document, `/stacks-tdd` for anything that lands as a test.

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

@@ -1,135 +1,243 @@
 ---
 name: stacks-review
-description: Use when reviewing code changes in the Stacks project — two-pass code review with critical issue detection, test coverage audit, and auto-fix workflow. Invoke with /stacks-review.
+description: Use when reviewing code changes in a Stacks project - a PR, a branch, staged work, or the diff since a fixed point. Reviews on two axes, Standards (does it follow this repo's rules and avoid the smell baseline) and Spec (does it do what was asked), plus a test coverage audit and an auto-fix pass. Invoke with /stacks-review.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob
 ---
 
-# /stacks-review — Code Review
+# /stacks-review - code review
 
-You are performing a structured two-pass code review for the Stacks framework. Be direct, specific, and opinionated. Every finding must reference a specific file and line number.
+Two-axis review of a diff. Be direct, specific and opinionated. Every finding
+references a file and a line.
 
-## Determine Scope
+- **Standards**: does the code follow this repo's rules, and is it free of the
+  smell baseline below?
+- **Spec**: does the code faithfully implement what the originating issue, spec
+  or conversation asked for?
 
-1. If the user provides a PR number or branch, review the diff against the base branch
-2. If no scope is given, review staged changes (`git diff --cached`). If nothing staged, review unstaged (`git diff`)
-3. If no changes at all, ask what to review
+A change can pass one axis and fail the other. Code that follows every rule and
+implements the wrong thing passes Standards and fails Spec. Code that does
+exactly what the issue asked while breaking the project's conventions does the
+reverse. Reporting them separately stops one axis from masking the other, so
+**do not merge or rerank across axes**.
 
-Read changed files in full to understand context around the changes.
+Credit: the two-axis structure and the Fowler smell baseline are adapted from
+Matt Pocock's `code-review` skill (MIT), <https://github.com/mattpocock/skills>.
 
-## Pass 1: Critical Issues
+## 1. Pin the scope
 
-Scan for issues that **must be fixed before merge**. Only flag with confidence 8/10+:
+1. If the user gives a PR number, branch, tag or commit, that is the fixed point.
+   Diff with `git diff <fixed-point>...HEAD` (three dots, so the comparison is
+   against the merge base) and list the commits with
+   `git log <fixed-point>..HEAD --oneline`.
+2. If no scope is given, review staged changes (`git diff --cached`). If nothing
+   is staged, review unstaged (`git diff`).
+3. If there are no changes at all, ask what to review.
 
-### Security
-- SQL injection, XSS, command injection, path traversal
-- Hardcoded secrets, API keys, tokens (check `config/services.ts`)
-- Missing auth/authorization checks on API routes
-- Unsafe deserialization or eval usage
-- Improper input validation at system boundaries
+Confirm the ref resolves (`git rev-parse <fixed-point>`) and the diff is
+non-empty before going further. A bad ref should fail here, not inside two
+parallel sub-agents.
 
-### Correctness
-- Race conditions, missing `await` on async calls
-- Off-by-one errors, null/undefined access without guards
-- Resource leaks (unclosed database connections, missing `db.close()`)
-- Incorrect error handling (swallowed errors, wrong error types)
-- Logic errors in ORM model definitions or migration files
+Read the changed files in full. A diff without its surrounding context produces
+confident nonsense.
 
-### Stacks-Specific
-- Incorrect model attribute definitions (wrong validator types, missing `factory` for seeder)
-- Broken route definitions (missing middleware, wrong action paths)
-- Misconfigured `config/*.ts` files
-- Breaking changes to `@stacksjs/*` package exports
-- Migration files that won't work on SQLite (check preprocessing quirks)
+## 2. Identify the spec source
 
-For each critical finding:
+Look for what the change was supposed to do, in this order:
+
+1. Issue references in the commit messages (`#123`, `Closes #45`), fetched with
+   `gh issue view`.
+2. A path the user passed as an argument.
+3. A spec or plan under `docs/`, `.scratch/`, or a design document from
+   `/stacks-office-hours` or `/stacks-plan-review`.
+4. The conversation itself, if the work happened in this session.
+
+If nothing is found, ask. If the user says there is no spec, the Spec axis
+reports "no spec available" and you review Standards only.
+
+## 3. Run both axes
+
+Both axes run as **parallel sub-agents** so they do not pollute each other's
+context, then this skill aggregates. Give each the diff command, the commit list,
+and its own brief.
+
+### Standards axis
+
+Sources, in order of authority:
+
+1. `AGENTS.md` at the repo root. It is the project's own rules and it **wins over
+   everything below**.
+2. The relevant `stacks-*` skill for whatever the diff touches. A model change is
+   reviewed against `stacks-models`, a route change against `stacks-router`.
+3. The smell baseline below, which applies even where nothing is documented.
+
+Skip anything tooling already enforces. `pickier` catches formatting and lint,
+`tsgo` catches types, so a finding that repeats them is noise.
+
+#### Critical findings
+
+Must be fixed before merge. Only flag at confidence 8/10 or higher.
+
+**Security**: SQL injection, XSS, command injection, path traversal. Hardcoded
+secrets, keys or tokens (check `config/services.ts` and anything env-shaped).
+Missing auth or authorization on a route. Unsafe deserialization or `eval`.
+Missing validation at a system boundary.
+
+**Correctness**: races and missing `await`. Off-by-one. Null or undefined access
+with no guard. Resource leaks, including unclosed database connections. Swallowed
+errors and wrong error types. Logic errors in model definitions or migrations.
+
+**Stacks-specific**:
+
+- Model attributes with the wrong validator type, or a fillable attribute with no
+  `factory` where `useSeeder` is on.
+- A model change with no regenerated migration, or a generated migration nobody
+  read.
+- Routes pointing at an action path that does not resolve, or missing the
+  middleware their siblings carry.
+- A registry that silently drops the entry: `app/Routes.ts`, `app/Events.ts`,
+  `app/Middleware.ts`, `app/Listener.ts`, `app/Scheduler.ts`. These fail by doing
+  nothing.
+- Breaking changes to a `@stacksjs/*` package's public exports, and relative type
+  imports that escape the package, which degrade consumers to `any`.
+- Migrations that will not run on SQLite.
+- Vanilla JS in an stx template (`var`, `document.*`, `window.*`), a hand-rolled
+  SVG icon path, a new icon or animation dependency.
+- An em-dash in any user-visible string.
 
 ```
 🔴 CRITICAL: [title]
 File: [path]:[line]
 Issue: [specific description]
-Impact: [what can go wrong]
-Fix: [concrete fix, not "consider doing X"]
+Impact: [what goes wrong]
+Fix: [the concrete fix]
 ```
 
-## Pass 2: Informational
-
-Scan for non-blocking issues:
-
-- Run `bunx --bun pickier` compliance (don't flag what pickier catches)
-- TypeScript best practices (avoid `any`, prefer discriminated unions, use `satisfies`)
-- Naming clarity (misleading variable/function names)
-- Missing error context (errors that lose stack traces)
-- Test gaps (changed logic without corresponding test changes)
-- Dead code introduced by the change
-- Performance concerns (N+1 queries in ORM, unnecessary re-renders)
-- Conventional commit compliance for the PR title (`gitlint` standards)
-
-For each:
+#### Smell baseline
+
+A fixed set of Fowler code smells (*Refactoring*, ch.3) that applies even when a
+repo documents nothing. Two rules bind it: **the repo overrides**, so where
+`AGENTS.md` or a `stacks-*` skill endorses something the baseline would flag,
+suppress it. And each smell is **always a judgement call**, a labelled heuristic
+("possible feature envy"), never a hard violation.
+
+Each reads *what it is* then *how to fix*. Match against the diff:
+
+- **Mysterious name**: a function, variable or type whose name does not reveal
+  what it does. Rename it, and if no honest name comes, the design is murky.
+- **Duplicated code**: the same logic shape in more than one hunk or file.
+  Extract the shape and call it from both. In this framework, the fifth
+  near-identical action usually wants to be a trait.
+- **Feature envy**: a method reaching into another object's data more than its
+  own. Move it onto the data it envies.
+- **Data clumps**: the same few fields travelling together, a type wanting to be
+  born. Bundle them.
+- **Primitive obsession**: a string or number standing in for a domain concept.
+  Give the concept its own small type, and its own name in `CONTEXT.md`.
+- **Repeated switches**: the same cascade on the same type recurring across the
+  change. Replace with polymorphism, a driver, or one shared map.
+- **Shotgun surgery**: one logical change forcing scattered edits across many
+  files. Gather what changes together.
+- **Divergent change**: one file edited for several unrelated reasons. Split so
+  each module changes for one reason.
+- **Speculative generality**: abstraction, params or hooks added for needs the
+  spec does not have. Delete it. One adapter is a hypothetical seam.
+- **Message chains**: long `a.b().c().d()` navigation the caller should not
+  depend on. Hide the walk behind one method.
+- **Middle man**: a class or function that mostly delegates onward. Call the real
+  target.
+- **Refused bequest**: a subclass that ignores most of what it inherits. Use
+  composition.
 
 ```
 🟡 INFO: [title]
 File: [path]:[line]
-Note: [observation]
+Note: [observation, and which smell if it is one]
 Suggestion: [improvement]
 ```
 
-## Test Coverage Audit
+Also flag here: `any` where a discriminated union or `satisfies` would do,
+misleading names, errors that lose their stack, dead code introduced by the
+change, N+1 queries through a relationship, and a PR title that fails the
+conventional-commit rules in `config/commit.ts`.
+
+### Spec axis
 
-1. Identify all changed functions/methods
-2. Search for existing tests (`bun test` files)
-3. List untested paths
+Report:
+
+- Requirements the spec asked for that are **missing or partial**.
+- Behaviour in the diff that **was not asked for**, which is scope creep.
+- Requirements that look implemented but where the implementation looks **wrong**.
+
+Quote the spec line for each finding. Keep it under 400 words.
+
+## 4. Test coverage audit
+
+1. Identify every changed function, action, model attribute and route.
+2. Search `tests/` for existing coverage.
+3. List the untested paths.
 
 ```
-## Test Coverage
+## Test coverage
 
-| Changed Function | Test File | Covered? |
-|-----------------|-----------|----------|
-| [function] | [test file or "none"] | ✅ / ❌ |
+| Changed | Test file | Covered? |
+|---|---|---|
+| [function or route] | [path or "none"] | ✅ / ❌ |
 
 Missing coverage:
 - [untested path or edge case]
 ```
 
-## Auto-Fix Workflow
+Judge the tests you find, not just their existence. A test that mocks an internal
+collaborator or recomputes its own expected value is worse than no test, because
+it reports green. `stacks-tdd` has the anti-pattern list.
 
-After presenting findings, ask:
+## 5. Auto-fix
 
-> "Want me to fix the mechanical issues? (formatting, imports, simple type fixes)"
+After presenting the findings, ask:
 
-If yes, fix ONLY mechanical issues. After fixing, run `bunx --bun pickier . --fix`.
+> Want me to fix the mechanical issues? Formatting, imports, simple type fixes.
 
-Do NOT auto-fix: architectural decisions, logic changes, anything with multiple valid approaches.
+If yes, fix **only** mechanical issues, then run `./buddy lint:fix` and
+`./buddy typecheck`. Never auto-fix architectural decisions, logic changes, or
+anything with several valid approaches.
 
-## Output Format
+## Output
 
 ```
-# Code Review: [brief description]
+# Code review: [brief description]
 
-## Pass 1: Critical Issues
-[findings or "No critical issues found."]
+## Standards
+[critical findings, then informational]
 
-## Pass 2: Informational
-[findings]
+## Spec
+[findings, or "no spec available"]
 
-## Test Coverage
+## Test coverage
 [table]
 
 ## Summary
-- Critical: [count]
-- Informational: [count]
+- Standards: [count], worst: [issue]
+- Spec: [count], worst: [issue]
 - Test gaps: [count]
 ```
 
+The summary names the worst issue **within each axis**. Do not pick a single
+winner across axes, because that is the reranking the separation exists to
+prevent.
+
 ## Rules
 
-- Never say "consider" or "you might want to" — it's a problem or it isn't
-- Every finding must have a concrete fix
-- Don't flag style issues that `pickier` would catch
-- Don't review generated files, lock files, or `storage/framework/types/` auto-generated types
-- For Stacks monorepo changes, check cross-package impacts — a change in `core/` might affect 15+ downstream packages
+- Never say "consider" or "you might want to". It is a problem or it is not.
+- Every finding carries a concrete fix.
+- Do not flag what `pickier` or `tsgo` already catches.
+- Do not review generated files, lock files, `storage/framework/types/*.d.ts`, or
+  anything under a `dist/`.
+- For monorepo changes, check cross-package impact. A change in
+  `storage/framework/core/` can reach 15+ downstream packages.
 
 ## Downstream
 
-> **Review complete.** Run `/stacks-browse` to QA in the browser, or `/stacks-retro` to reflect on this session.
+> **Review complete.** Run `/stacks-browse` to QA in the browser, or
+> `/stacks-retro` to turn the findings into environment improvements.

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-router
-description: Use when working with routing in a Stacks application — defining routes, HTTP methods, route groups, middleware, named routes, URL generation, request enhancement (Laravel-style input/query/file helpers), response helpers, error responses, route model binding, or rate limiting. Covers @stacksjs/router, routes/, and app/Routes.ts.
+description: Use when working with routing in a Stacks application - defining routes, HTTP methods, route groups, middleware, named routes, URL generation, request enhancement (Laravel-style input/query/file helpers), response helpers, error responses, route model binding, or rate limiting. Covers @stacksjs/router, routes/, and app/Routes.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-routes
-description: Use when defining or organizing route files in a Stacks application — creating route files in routes/, registering them in app/Routes.ts, using route prefixes and middleware groups, or the default API routes structure. For the router API itself (request helpers, response helpers, middleware classes), see stacks-router.
+description: Use when defining or organizing route files in a Stacks application - creating route files in routes/, registering them in app/Routes.ts, using route prefixes and middleware groups, or the default API routes structure. For the router API itself (request helpers, response helpers, middleware classes), see stacks-router.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-scaffolding
-description: Use when generating new code with Stacks — buddy make commands, project scaffolding, component/page/store/layout generation, or project templates. Covers buddy make:* commands and STX scaffolding utilities.
+description: Use when generating new code with Stacks - buddy make commands, project scaffolding, component/page/store/layout generation, or project templates. Covers buddy make:* commands and STX scaffolding utilities.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-scheduler
-description: Use when scheduling tasks in a Stacks application — defining scheduled tasks, cron-like scheduling, or task automation. Covers @stacksjs/scheduler, @stacksjs/cron, and app/Scheduler.ts.
+description: Use when scheduling tasks in a Stacks application - defining scheduled tasks, cron-like scheduling, or task automation. Covers @stacksjs/scheduler, @stacksjs/cron, and app/Scheduler.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-search-engine/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-search-engine
-description: Use when implementing search in Stacks — full-text search with Meilisearch or Algolia backends, document indexing, search settings management, the useSearch model trait for automatic indexing, or search driver configuration. Covers @stacksjs/search-engine and config/search-engine.ts.
+description: Use when implementing search in Stacks - full-text search with Meilisearch or Algolia backends, document indexing, search settings management, the useSearch model trait for automatic indexing, or search driver configuration. Covers @stacksjs/search-engine and config/search-engine.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-security
-description: Use when implementing security in Stacks — password hashing (bcrypt/argon2), app key generation, AES encryption/decryption, hash verification, rehashing detection, or security configuration (firewall, rate limiting, IP allowlists). Covers @stacksjs/security and config/security.ts.
+description: Use when implementing security in Stacks - password hashing (bcrypt/argon2), app key generation, AES encryption/decryption, hash verification, rehashing detection, or security configuration (firewall, rate limiting, IP allowlists). Covers @stacksjs/security and config/security.ts.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

package/ai/skills/stacks-security-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stacks-security-audit
-description: Use when performing security analysis on a Stacks application — OWASP Top 10, STRIDE threat modeling, attack surface mapping, dependency audit. Requires concrete exploit scenarios. Invoke with /stacks-security-audit.
+description: Use when performing security analysis on a Stacks application - OWASP Top 10, STRIDE threat modeling, attack surface mapping, dependency audit. Requires concrete exploit scenarios. Invoke with /stacks-security-audit.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-server
-description: Use when working with the Stacks development or production server — server configuration, server middleware, or server startup. Covers @stacksjs/server and storage/framework/server/.
+description: Use when working with the Stacks development or production server - server configuration, server middleware, or server startup. Covers @stacksjs/server and storage/framework/server/.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob

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

@@ -1,6 +1,6 @@
 ---
 name: stacks-shell
-description: Use when executing shell commands in a Stacks application — running system commands, process management, or using the shell operator. Covers @stacksjs/shell which wraps Bun's native $ operator.
+description: Use when executing shell commands in a Stacks application - running system commands, process management, or using the shell operator. Covers @stacksjs/shell which wraps Bun's native $ operator.
 license: MIT
 compatibility: Bun >= 1.3.0, TypeScript
 allowed-tools: Read Edit Write Bash Grep Glob