ax-next

Use this skill for any ax-next UX or usability question — it carries the project-specific framework (non-technical-user north star, four lenses, shadcn constraints, voice rules) that Claude cannot apply correctly without consulting it. Trigger whenever asked to: review whether a UI surface, flow, or screen is clear or confusing to a non-technical/first-time user; rewrite an error message, empty state, label, tooltip, button text, or onboarding copy for any ax-next UI; decide what to show vs. hide (progressive disclosure) in admin, settings, chat, or wizard screens; do a UX or usability pass before shipping a UI change; or answer "is this overwhelming?", "what should we show instead of this error?", "how do I make this simpler for first-timers?", "does a regular person understand this?". Covers chat, admin, settings, onboarding wizard, credentials UI, error pages, empty states. Advisory — never edits files.

Use when the user wants to connect a service or data source — "connect my Salesforce", "set up Google Drive", "add a GitLab integration", "hook up an MCP server". Authors a connector (the access) and installs it with one approval card.

Use when the user wants to create, author, build, or modify a skill — e.g. "make a skill for Linear", "turn this workflow into a skill", "teach the assistant how to do X". Writes the know-how and references the connector it needs.

Use when asked to autonomously drain the "TO DO" GitHub project board — watch the To Do lane (token-free, once a minute), review dependencies on every change, ship each dep-free card via yolo-ship (up to 3 in flight), merge the green PRs through a serialized queue, and loop continuously. Also decomposes a finished design doc into PR-sized To Do cards (deps wired) before draining. Drain triggers: "drain the board", "run auto-ship", "watch the To Do board and ship ready tasks", "work the board autonomously", "fan out the To Do lane and ship it". Design-intake triggers: "auto-ship --design <path>", "decompose this design into cards", "plan this design into PR-sized tasks and ship it", "break this design into cards". For a SINGLE task, use yolo-ship instead.

Use when asked to implement, build, or ship a task or feature end-to-end with minimal supervision and you are expected to own it from request to a passing, review-clean pull request. Triggers on "implement X end to end", "build X and open a PR", "take this and run with it autonomously", "ship this task", or any request to deliver a unit of work with minimal back-and-forth.

Use when the user wants to verify expected behavior in the browser UI against the local kind cluster `ax-next-dev` and iterate until it works. The verification mechanism is Playwright MCP — drive the chat UI (or whatever surface the user names) in a real browser, observe outcomes (console, network, DOM snapshot), and loop on failures. Picks between an image-rebuild loop (Dockerfile / chart / env / runner-side code) and a fast hostPath-mounted dist loop (host-side TypeScript only). Triggers on phrases like "get this working in the browser against ax-next-dev", "loop until the chat sends a response", "fix until the UI shows X", "use playwright to verify Y in the cluster", or any request to keep fixing until a browser-observable outcome passes. Works for scripted procedures in `deploy/MANUAL-ACCEPTANCE.md`, ad-hoc bug repros, or any scenario the user describes in UI terms.

Use when you want to QA / pressure-test / smoke-test / regression-sweep the chat UI against the local kind cluster ax-next-dev and get a findings report — not fix one bug, but run a fixed battery of common activities (new chat, npx, skills, attachments, artifacts, reload old sessions, title generation, parallel sessions) plus fault injection (sandbox killed mid-turn, host killed, provider error, network blip) and report what broke or glitched. Triggers on "pressure test the chat", "QA the chat UI", "run a chat smoke sweep", "chaos-test chat", "find UI glitches", "make sure chat still works end to end".

Use at session start to read project memory in `.claude/memory/`, during the session to capture corrections / dead ends / "remember this" / "log that", and at session end ("done", "wrap up", PR opened, tests pass) to update it. Five files — context.md, decisions.md, patterns.md, mistakes.md, meta.md — keep project facts, decisions, reusable patterns, mistakes to avoid, and self-observations about how I work on this project. Also handles first-session bootstrap (creating the directory, seeding files, committing them).

Use when writing or modifying any AX plugin or hook — covers the five invariants (transport/storage-agnostic hooks, no cross-plugin imports, no half-wired plugins, one source of truth, capabilities explicit and minimized), the plugin manifest format, hook bus mechanics, the boundary review checklist, and common patterns

Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset". **Monorepo:** ax-next is a pnpm monorepo and the shadcn workspace lives in `packages/channel-web` — every shadcn CLI call must include `-c packages/channel-web` or the CLI errors with `monorepo_root`.

Use when adding or modifying — sandbox boundaries, IPC handlers, plugin loading or manifests, hook payloads carrying model/tool/external-system output, dependencies in package.json, or code that uses caller-provided file paths / spawns processes / opens network connections. Walks three threat models (sandbox escape, prompt injection, supply chain) and produces a structured PR security note. Rigid checklist — every item must be answered, "N/A" requires a reason.