a3tai

Improve the visual design and UX of the VitePress docs site — layout, colors, typography, components, and responsiveness

Build, preview, and update the VitePress documentation site in docs-site/

Run go test with race detector, analyze failures, fix issues, and re-run until green

Review pull requests against repo standards — Go conventions, test coverage, race detector, CHANGELOG, and docs

Create a GitHub release with tag after a PR merge — follows the repo's tag and gh release create workflow

Handle upstream-release issues — read changelog deltas, update spec docs, sync protocol and gateway types, run tests, open PR, tag release

Reviews a @a3tai/mittsu component for keyboard, screen-reader, focus-management, and color-contrast support. Use when reviewing a new component before merging, when a contributor asks "is this a11y-compliant?", when an existing component is reported to misbehave with a screen reader or keyboard, or when a component is being prepped for ✅ status in ROADMAP.md. Walks the WAI-ARIA / WCAG checks specific to each component category and produces a pass/fail rubric.

Cuts a release of one of the @a3tai/mittsu packages (cli, svelte5, or web). Use when the user asks to "release", "publish", "cut a version", "bump", or "tag" the project. Picks semver level from changes since the last tag, updates package.json + registry.json + CHANGELOG, runs the smoke test, creates a git tag, and queues an npm publish.

Scaffolds a new component for the @a3tai/mittsu Svelte 5 registry. Use when the user asks to add a new component (e.g. "add a Tooltip", "we need a Toast", "create a Drawer"), when they ask to extract repeated UI from an app into the registry, or when porting from another library and the porting-components skill points back here for the file scaffolding step. Produces a properly structured <name>.svelte + <name>.css file pair, registers the entry in registry.json, adds a showcase block, and smoke-tests via the local CLI.

Orients Claude to @a3tai/mittsu at the start of any session and picks the next component to build. Use at the start of a new conversation in this repo, when the user asks "what should we build next", "what's next on the plan", "where do we stand", "which wave are we in", "what's the priority", "what's left", or any open-ended request to add a component without naming one. Reads PLAN.md (the wave order) and ROADMAP.md (the catalog), figures out the earliest wave with unshipped 🟡 items, and recommends a specific component plus the rationale. Hands off to the `components` or `porting-components` skill once an item is picked. Does not itself write component files.

The visual rulebook for @a3tai/mittsu. Use when writing or reviewing any component's markup or CSS in this repo, when a contributor asks "what should this look like?", when matching an existing component's chrome, when introducing a new variant, or when porting a component from shadcn/Radix/HIG/Material so it lands in our voice. Covers the macOS-native aesthetic, the --uin-* token system, BEM class conventions, motion language, focus rings, dark-mode discipline, and the rules that keep the kit feeling like one library instead of many.

Port a component from another library (shadcn/ui, Radix, Bits UI, Mantine, Park UI, Apple HIG, Material 3) into @a3tai/mittsu's Svelte 5 conventions. Use when the user references an existing component by name from one of those libraries ("port shadcn's Accordion", "we want HIG's Stepper", "translate Material 3's chip group"), when consulting ROADMAP.md for the next batch, or when the user provides a screenshot/URL of a component they want recreated. Reuses components for the file scaffolding step but adds the source-mapping work that comes before it.