patdhlk

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.

Exact shape of a new minimal API endpoint in Web.Api — IEndpoint, request DTO, handler wiring, Result matching. Use when adding or modifying files under src/Web.Api/Endpoints.

Project-wide conventions for this .NET Clean Architecture solution — layering, Result<T>, errors, domain events, and what belongs in which project. Use when planning or implementing any change that touches src/Domain, src/Application, src/Infrastructure, or src/Web.Api.

Exact file layout and code shapes for commands, queries, handlers, and validators in this repo. Use when adding or modifying a use case in src/Application.

How to model a new Domain entity in this repo — the base class, errors, domain events, and the matching EF configuration. Use when creating or modifying anything under src/Domain.

Use when adding a new protocol connector to the taktora-connector framework (e.g. "add an MQTT connector", "scaffold a new connector crate", "create a taktora-connector-<proto>"). Carries the mechanical steps and the taktora- specific gotchas that the prose guide does not spell out as commands.

Use when bringing up a real EtherCAT bus on a Raspberry Pi (or any Linux host) with the taktora ethercat connector — running ethercat-real-bus / ethercat-wago-coupler against real silicon, or debugging a Pi bring-up that hangs (e.g. "stuck in Connecting on the Pi", "real bus won't reach OP", "EtherCAT permission denied", "Pi build runs out of memory"). A runbook of steps + failure modes; points at the example READMEs as source of truth.

Use when touching anything that affects crate publishing or releases in the taktora workspace — adding a crate, adding a dev-dependency on a sibling crate, splitting tests out, or when CI's publish-deps / dep-gating check fails (e.g. "check-publish-deps failed", "why does release-plz reorder my crate", "where do internal test deps go"). Carries the release-ordering gotchas and what to do when the guard trips; points at the scripts and config as source of truth.

Start a new feature by creating sphinx-needs spec documents (requirements, plan, validation) with proper traceability links