rengwu

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

A relentless interview to sharpen a plan or design, which also creates docs (ADRs and glossary) as we go.

Compact the current conversation into a handoff document so a fresh agent can continue the work.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating spec/PRD asked for?). Use when the user wants to review a branch, work-in-progress changes, or asks to "review since X".

Turn the current conversation into a spec, saved to `.plan/` — no interview, just synthesis of what you've already discussed.

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, saved to `.plan/`.

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

Deeply analyze a codebase for architectural improvements, refactoring opportunities, and testability issues. Walks through exploration, candidate presentation, and a collaborative implementation loop with the user. Use when the codebase feels messy, untested, hard to navigate, or when preparing for feature work that touches core structures.

Run systematic technical quality checks on frontend code across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with prioritized fix recommendations. Use for pre-ship checks, codebase health assessments, or before significant redesigns.

UX and visual planning for a frontend feature before any code is written. Produces a structured design brief that guides implementation. Use for any new UI surface, component, page, or significant visual redesign. Does not write code — only plans. Complements plan-then-build (which handles architecture and data flow).

One-time design context setup for a project. Interviews the user to capture strategic design intent, then writes .context/PRODUCT.md and optionally .context/DESIGN.md. Use before any design work (new project, or first time using design skills in an existing project). Not for backend-only projects.

Final shipping readiness pass on a UI surface, component, or page. Checks for completeness, consistency, edge cases, micro-interactions, and copy polish. Use after implementation is functionally complete but before declaring it done. Not for finding bugs — for finding gaps between "it works" and "it ships."

Reads staged git changes, recent commit history, and project context to generate a well-structured conventional commit message. Present it to the user for approval before committing.

Collaborative feature planning and implementation skill. The user brings an idea; you analyze the codebase, surface options, grill the user (and yourself) on tradeoffs, and only write code once the plan is fully crystallized and explicitly approved. Use for any new feature, significant refactor, or architectural change.

Reads the latest timestamped context files from .context/ to understand the current project state, tech stack, recent changes, and blockers before continuing development. Use at the start of any session when you need to catch up on where the project stands.

Break a plan, spec, or PRD into independently-grabbable iudex tickets using tracer-bullet vertical slices, and register them in the iudex queue with their dependencies. Use when the user wants to convert a plan into tickets, create implementation tickets, or break down work into the iudex queue.

Turn the current conversation context into a PRD and write it to .context/prd/ so it can be sliced into iudex tickets. Use when the user wants to create a PRD from the current context.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (a domain glossary and ADRs under .context/) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

Find deepening opportunities in a codebase, informed by the domain language in .context/ and the decisions in .context/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".