project-ax

Use when modifying logging, error handling, or diagnostic messages — logger setup, transports, error diagnosis patterns in src/logger.ts and src/errors.ts

Use when modifying the trusted host process — server orchestration, message routing, IPC handler, request lifecycle, event streaming, file handling, plugin loading, or agent delegation in src/host/

Use when modifying the sandboxed agent process — runner, IPC client, local/IPC tools, tool catalog, prompt building, or identity loading in src/agent/

Use when modifying agent sandbox isolation -- Docker, Apple Container (macOS), or k8s providers in src/providers/sandbox/

Use when modifying IPC protocol between host and agent — schemas, actions, length-prefix framing, or Zod validation in ipc-schemas.ts and ipc-server.ts

AX project architecture and coding skills - use sub-skills for specific subsystems (agent, host, cli, providers, etc.)

Use this skill when the user asks for a capability the agent doesn't yet have — a new integration (Linear, GitHub, Notion, Slack, etc.), a new workflow, a new tool, or "can you check our team's X" where X is a service the agent has no existing connector for. Creates a proper AX skill under .ax/skills/<name>/ with the right frontmatter, credentials, and domain allowlist so the capability becomes permanent after admin approval. Use this skill whenever you'd otherwise be tempted to improvise with one-off scripts, `npm install`, or `execute_script` to reach an external service.

Petstore REST API via mock OpenAPI (e2e test fixture — do not use in production)

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).