claas-rollant-46

Record a design decision as a traceable sphinx-needs architecture decision - Context/Decision/Consequences structure, alternatives considered, and links to the needs it affects. Use when a design decision was made and should be captured, when the user says "record this decision" / "write an ADR", or at the end of a design discussion worth keeping.

Disciplined diagnosis loop for bugs and regressions - reproduce, minimise, hypothesise, instrument, fix, regression-test - wired into the issue lifecycle like /tdd. Use when the user reports a bug, says something is broken/throwing/failing, describes a performance regression, or hands over a bug issue to fix.

Interview the user relentlessly about a plan or design until reaching shared understanding, walking every branch of the decision tree and resolving dependencies between decisions one by one. Use when the user wants to stress-test a plan, get grilled on a design, or says "grill me" / "poke holes in this".

Grilling session that challenges a plan against the project's recorded domain model - existing decisions, requirements, and glossary terms from the sphinx-needs spec - and updates term and decision directives inline as the discussion crystallises. Use when the user wants to stress-test a plan against their project's documented language and decisions, or says "grill me with docs" / "check this plan against our decisions".

Build a throwaway prototype to answer a specific design question before committing to an approach - a runnable terminal app for state/data-model/algorithm 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".

Interactive QA session - the user reports bugs and observations conversationally while testing, and each report is filed as an issue on the configured backend with duplicate detection. Use when the user wants to do a QA session, report bugs conversationally, file issues while testing, or says "QA session" / "let me report some bugs".

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes in parallel - Standards (does the code follow this repo's documented rules?) and Spec (does it deliver what the originating issue and its linked requirements asked for?). Use when the user wants to review a branch, a PR, or work-in-progress changes, or says "review since X" / "review this before I merge".

Configure a repo for the patdhlk-skills workflows - reads or scaffolds ubproject.toml, persists the issue backend (github or sphinx-needs) and the role map, sets up a sphinx-needs spec via uv, detects/installs ubc, and offers devcontainer and CI. Use when the user runs /setup-patdhlk-skills or asks to set up patdhlk-skills, configure the issue backend, or scaffold a sphinx-needs spec for agent workflows.

Test-driven development in vertical slices - red-green-refactor against real behavior, wired into the issue lifecycle (picks up an issue, sets in-progress, closes done). Use when the user wants to build a feature or fix a bug test-first, mentions TDD or red-green-refactor, or hands over an issue ID to implement.

Slice a PRD's requirements into independently-grabbable issues on the configured backend - sphinx-needs issue directives or GitHub issues with two-way traceability links. Use when the user wants to break a PRD/feature/plan into issues, create implementation tickets, or says "turn this into issues" / "create the tickets".

Turn the current conversation context into a PRD as a living sphinx-needs spec document - one feature directive plus child requirement directives, traceably linked. Use when the user wants to create a PRD, capture a feature plan as requirements, or says "turn this into a PRD" / "write this up as a spec".

Drive issues through the triage state machine - route incoming issues to needs-info, ready-for-agent, ready-for-human, or wontfix, and keep states legal on both backends (sphinx-needs status edits or GitHub labels). Use when the user wants to triage issues, review the backlog, prepare issues for an agent, or says "triage" / "go through the open issues".