autodarts-xconfig
autodarts-xconfig contains 18 collected skills from thomasasen, with repository-level occupation coverage and site-owned skill detail pages.
Skills in this repository
Package or verify an autodarts-xconfig userscript release. Use only for explicit release, finalize, package, ship, publish, version bump, `dist/` refresh, or publication-state verification work. Do not use for ordinary code changes.
Use for explicit SonarQube issue cleanup, Sonar code smells, low-risk static-analysis fixes, and touched-scope Sonar remediation. Do not use for normal validation unless cleanup is explicitly requested.
Use for live browser, DOM inspection, Playwright MCP, Chrome DevTools MCP, Autodarts page inspection, reproduction, console/network checks, and UI verification tasks. Do not use for ordinary static code review.
Choose and report the smallest sufficient local validation for an autodarts-xconfig change. Use after meaningful source changes, when validation scope is unclear, or when final reporting must include residual risk. Do not use for Tier 0-only edits unless needed to document skipped validation.
Recover known-good behavior from `.oldrepo` without reintroducing the old structure. Use when the current modular implementation diverges from proven legacy behavior and the task is to recover that behavior in the right modern layer. Do not use for greenfield features with no legacy predecessor.
Use when adding, fixing, or reviewing xConfig administration previews for feature effects, especially hover/focus previews that must reflect the real runtime effect without leaking timers, classes, DOM state, or fake CSS-only behavior.
Normalize and verify bundled Dart marker PNG assets in autodarts-xconfig. Use when a file under `src/assets/darts/` is added, changed, replaced, visually misaligned, or when Dart marker tips no longer sit exactly on the board marker. Also use when updating Dart image geometry constants or asset tests.
Use for dartboard SVG selection, surface snapshots, overlay root detection, board group heuristics, radius/group semantics, and shared board truth.
Use for Cricket/Tactics target state, grid coloring, board coloring, active-player perspective, DOM parsing, and target-set rules.
Use for CPU/GPU efficiency, observers, render loops, scheduled rendering, DOM query reduction, cache behavior, and performance-oriented refactors.
Use for X01 checkout route logic, finish suggestions, checkout targets, score pulse, TV Board Zoom checkout interactions, bull semantics, and route/target regression analysis.
Implement or refactor source-layer behavior in autodarts-xconfig when no narrower domain skill fits. Use for config behavior, runtime logic, UI behavior, effects, themes, selectors, observers, mount logic, or module wiring. Do not use for docs/guidance-only, test-only, release-only, or `.oldrepo` parity work.
Curate, update, or audit `CHANGELOG.md` in autodarts-xconfig. Use only when changelog editing, release notes, compare-link maintenance, or changelog consistency checks are explicitly in scope.
Diagnose Autodarts overlay, board, and animation bugs that may stem from DOM churn, node replacement, observer rerenders, or weak CSS motion. Use when a blink, pulse, glow, or board overlay looks stuck, barely visible, twitchy, or inconsistent between targets, themes, or cards, especially when MCP browser evidence is needed.
Harden Cricket or Tactics rendering against unstable Autodarts DOM structure. Use when merged rows, shifted player columns, bull-row exceptions, stale node replacement, observer lifecycle issues, or unchanged-signature rebuilds break an otherwise correct render. Do not use when the semantic state itself is wrong; use `$cricket-state-parity` for that.
Keep Cricket or Tactics semantics correct across board and grid. Use when rules, target-state derivation, mark normalization, scoring pressure, active-player perspective, or board/grid meaning may be wrong. Do not use for pure DOM selector breakage, observer timing issues, or release-only work.
Keep user-facing wording aligned with shipped behavior in autodarts-xconfig. Use when feature names, config labels, defaults, README sections, menu descriptions, or module wording need to stay in sync. Do not use for pure internal refactors with no user-facing text impact.
Design or update regression coverage for autodarts-xconfig. Use when a bug fix, feature change, or refactor needs tests at the domain, runtime, config, or DOM harness layer. Do not use for release-only work or README-only edits.