boring-ui

Drive one ready artifact through implementation, proof, review, and owner handoff.

Review the named UI scenario or emit one bounded improvement packet.

Teach a boring-ui child app how to enable Google signup with @hachej/boring-core. Use when the user asks for Google auth, Google OAuth, social signup, or how to turn on Google sign-in/sign-up in a child app.

Ask which Boring skill or workflow fits your situation. A router over the local Boring skills.

Run an extremely strict maintainability review for abstraction quality, giant files, spaghetti-condition growth, and code-judo simplification opportunities.

Route a request to the right Boring v2 workflow skill without doing the work.

Create a GitHub issue from user feedback with safe context and simple labels. Never implement.

Implement one ready issue or slice safely, with proof, review, and PR handoff.

Turn an issue or conversation into a spec and, when needed, tracer-bullet implementation slices with blockers and proof.

Classify existing issues or PRs with the simple Boring state model and record the next action.

Cut a boring-ui-v2 npm release from main and update the local/global boring-ui CLI install. Use when Julien says cut a release, new release, publish boring-ui, update global boring-ui CLI, or install latest boring-ui CLI.

Generate a polished Nextra documentation site from any source repo. Use when building a docs site, "docs site for this repo", MDX docs, or deploying docs to Vercel.

Use for /feedback: create one enriched GitHub issue with safe context, lean labels, first plan, and queued or grill-blocked state.

Use for /loop-grill: clarify one Kanzen issue with grill-me and ask-user, then return it to triage or keep it blocked.

Use for /loop-implement: implement one Kanzen issue or approved plan, open/update the PR, run review/fix/re-review, gather proof, and prepare owner or fast-track merge handoff.

Use for /loop-plan: turn a Kanzen issue or PR that is too risky, unclear, large, or multi-slice for direct implementation into an issue-linked plan with acceptance, flag path, proof, review budget, and next slice.

Use for scheduled /triage: refresh GitHub, run the first unmet gate, collect proof, and merge only fast-track-safe PRs.

Use for /triage in boring-ui: refresh GitHub state, classify issues/PRs, choose the first unmet gate, route grill/plan/implement/proof/merge, and decide fast-track versus owner-review routing.

Compatibility command for /loop-grill. Use boring-loop-grill for the actual Kanzen grill workflow.

Compatibility command for /loop-implement. Use boring-loop-implement for the actual Kanzen implementation workflow.

Compatibility command for /loop-plan. Use boring-loop-plan for the actual Kanzen planning workflow.

Craft professional README.md files for GitHub open source projects.‍​‌‌​​‌‌​​‌‌​​​​‌​‌‌​​​‌​ Generates hero sections, installation instructions, feature tables, and architecture diagrams. Use when creating or revising a README, documenting a CLI tool, library, or open source project, or when user asks about README structure, badges, or project documentation.

Stress-test a plan or design by surfacing unknown unknowns — classify gaps into four quadrants, run seven blindspot lenses against real code, and grill one material decision at a time. Use when asked to "grill this plan", find "unknown unknowns", "stress test the plan", or hunt "blind spots".

Convert markdown plans into beads with dependencies using br CLI. Use when‍​‌‌​​‌‌​​‌‌​​​​‌​‌‌​​​‌​ creating task graphs, polishing beads before implementation, or bridging planning to agent swarm execution.

Comprehensive markdown planning methodology for software projects. Use when starting a new project, creating implementation plans, or refining architecture before coding.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.

Scaffold, customize, and ship a new boring-ui app from an idea. Covers choosing the right reference app, creating app identity, wiring plugins, configuring auth/mail/domain/env, and deploying with smoke checks. Use when the user wants a new boring-ui app, a child app, a branded deployable shell, or asks to go from idea to shipped app.

Build or shape a boring-ui plugin for a shipped app or playground. Covers choosing runtime vs app/internal plugin shape, where files live, how to register plugins, and when to use static composition vs defaultPluginPackages. Use when the user asks for plugin shape, new panels/tabs/catalogs/tools, or app-specific workspace extensions.

Capture feedback safely: file confirmed bugs as GitHub issues and route feature ideas to the Product Backlog. Never implement.

Route a tracked request from a small TODO through a reviewed plan or dependency-aware Beads graph.

Route a request to the right Boring v2 workflow skill without doing the work.

Explicit router for creating a skill or reducing an existing skill's active context size.

Read-only independent review of a plan, diff, or PR for overlooked mistakes, omissions, risks, broken acceptance, and missing proof.

Stress-test a plan/design for unknown unknowns using grounded blindspot lenses and one material decision at a time.

Classify existing issues or PRs with the Boring state model and record the next action.

Create and edit boring.generated-pane JSON specs from predefined safe component catalogs.

Create, extend, update, or install boring-ui workspace plugins — authoring new hot-reloadable user plugins and app-default plugins (React panels, file visualizers, surface resolvers, static server integrations, Pi/agent contributions), and installing existing or published plugins from npm/git/local sources. Use when the user asks to build, extend, configure, modify, add, or install a boring-ui plugin.