About hrt-dark-mode-routing
hrt-dark-mode-routing is a skill that defines where non-auto-resolved findings go during specified development phases when dark mode is active. It is for workflows using the related hrt skills, and centralizes rules that would otherwise be repeated in phase instructions.
Key features
- 01Checks for dark.md before routing
- 02Routes findings by phase and type
- 03Keeps security decisions with the user
- 04Supports planning-only and implementation variants
- 05Records gate reasoning in dark.md
Use cases
- 01Route proposal, specs, and design findings
- 02Handle alignment decisions and high findings
- 03Review apply-phase blockers and code findings
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/hrt-dark-mode-routingin Claude Code to confirm it loaded.
Details
From the project READMEhrt-dark-mode-routing
dark.md existing is the only signal dark mode is active (created by hrt-dark-mode-opt-in). This skill holds the routing rules that were previously copied into every phase instruction. A phase instruction points here with one line; the rules live here.
If dark.md does not exist, this skill does nothing — every finding follows its normal path to the user.
The rule, by calling phase
A finding that would normally escalate to the user is routed as below. Everything that auto-resolves outside dark mode still auto-resolves — dark mode never changes the auto-resolve rule, only where the non-auto-resolved findings go.
| Phase | Routes to hrt-dark-mode-decision-gate | Still goes to the user | dark.md section |
|---|---|---|---|
proposal (hrt-adversarial-authoring, artifact: proposal) | a single-reviewer UNANCHORED finding | everything hrt-security-pass decided; the hrt-change-size-gate "one change or several?" question | Proposal |
specs (hrt-adversarial-authoring, artifact: specs) | a single-reviewer UNANCHORED finding | everything hrt-security-pass decided | Specs |
design (hrt-adversarial-authoring, artifact: design) | a single-reviewer UNANCHORED finding | everything hrt-security-pass decided | Design |
align (hrt-align-consistency-review) | every ALIGN DECISION and HIGH finding | nothing extra — but VERIFY and WALKTHROUGH are unchanged, and WALKTHROUGH stays the mandatory closing review; the user is also shown dark.md | Align (tag each entry with its cycle number) |
apply Phase 1 (tdd loop) | a seam-mismatch blocker (the gate can weigh an alternative seam against code, design, and specs) | any other Phase 1 blocker | Apply |
apply Phase 2 (hrt-apply-code-review) | every finding that would otherwise surface to the user | nothing extra | Apply |
Invariants across all phases
- ANCHORED findings, and findings both independent reviewers raised, auto-resolve in the calling skill and never reach this routing at all.
- A finding that is a security requirement or mitigation already decided by
hrt-security-passALWAYS goes to the user, never tohrt-dark-mode-decision-gate. That decision is a hard constraint, not an opposing case to weigh. - The
hrt-change-size-gate"one change or several?" question ALWAYS goes to the user. The answer depends on the user's capacity and priorities, which no grounding artifact holds. - WALKTHROUGH in
alignstays mandatory and fully manual in every dark-mode variant. hrt-dark-mode-decision-gateis always a fresh subagent, always writes its reasoning to the matchingdark.mdsection, and never escalates to the user from within itself — it always produces a decision. See that skill for the steel-manning procedure.
Planning-only vs +implementation
dark.md's header names the variant.
- planning-only: routing applies through
align.applyis out of scope — ifdark.md's header is planning-only,applySTOPS and tells the user planning-only dark mode ends at WALKTHROUGH. - +implementation: routing also applies to
applyPhase 1 and Phase 2 as in the table. After Phase 2,dark.mdis presented in full alongside the code diff as a second closing review before the user commits.