rhanka

Use when bringing the harness method to a NEW or non-sentropic repo — maps the repo's conventions into a harness profile so the same scope/branch/verify kernel applies anywhere.

Use before any creative/design work (a feature, a package, an evolution) — explores intent and design via the spec-ladder with multi-peer adversarial review BEFORE implementation.

Use on any bug, test failure, or unexpected behaviour BEFORE proposing a fix — runs the generic evidence-first root-cause loop.

Use when you have a spec/decisions and need an executable plan — writes a lot-based BRANCH.md from the template and completes with track for realization state.

Use when completing a feature, a design step, or before merging — runs a ≥2-peer consensus review and reconciles the findings, instead of a single rubber-stamp pass.

Use when adding or evolving tests for a feature/bugfix — applies the sentropic test-pyramid, scoped-test loop, environment isolation, and AI-flaky policy.

Load FIRST in any sentropic repo — establishes the harness method (branch/scope/test/debug/review/brainstorm/plan) and supersedes superpowers for those acts.

Verify modified files against branch allowed/forbidden/conditional paths (via @sentropic/harness)

Route repository work through the sentropic harness method. Use in a sentropic repo for branch scope, brainstorming, planning, debugging, testing, review, or adopting harness conventions in a new repo.

Load FIRST in any sentropic repo — establishes the harness method (branch/scope/test/debug/review/brainstorm/plan) and replaces legacy superpowers for those acts.

Use when the user asks for a track report, status, or advancement/progress report — run the CLI `track report` from the repo root and return its AI-prepared, cited output verbatim; never substitute the deterministic `track_report` MCP projection for a human AI report. Also use when an agent needs to read, update, import, or verify track state; when a BRANCH.md or plan/NN-BRANCH_*.md changed; or when deciding between Track MCP and CLI. MCP remains read-only, writes/imports use the CLI, and .track is append-only/single-writer.

Coordinate with other CLI agents (Claude Code, Codex, Gemini) via the h2a protocol — open a live session, list peers, exchange messages, drive a signed negotiation or objective loop. Use when the user wants the current CLI to interact with another agent through a shared workspace.

Use at a branch merge or branch-close to protect track's event log from merge-time loss and to refresh acceptance. DETECT-and-GUIDE only, never auto-repair: judge git ancestry in the shell, detect STRUCTURAL event loss via `track events-contains` (NOT audit.orphan, which is blind to a reparent lost toward a valid parent), recover OPPORTUNISTICALLY from a surviving ref/reflog before declaring anything irrecoverable, then re-anchor acceptance freshness with query/report --require-accepted + consolidate and RE-READ to surface done-but-skipped items. Orchestrates the existing CLI; reimplements nothing.

Use when an agent must present a complex, irreversible, cross-owner, security/contract-affecting, costly, or genuinely balanced decision to a human owner — or must choose between decide-and-trace, a quick ask, and a full decision dossier. The agent presents at the level of the stakes, never sells its preferred option, and records the decision in track. This is agent→human; it is NOT h2a (h2a ATTENTION is the inter-agent presenter).

Use when a flat track backlog has grown past a handful of items and needs structuring into a small set of perennial workpackages (WPs) — durable themes by owning concern, not milestones — so a conductor can pilot %-by-WP. The skill reads the backlog, clusters by durable concern, and EMITS A PROPOSAL (the WP set + a per-item reparent plan) the human ratifies before anything is written. It never auto-restructures; for a consequential restructuring it composes present-decision. This is agent→human structuring of one repo's own backlog.

Close a branch — final validation, PR creation, merge, archive plan file

Initialize a new branch with worktree, BRANCH.md from template, and environment setup

Run a source adapter against fixture data and verify the extracted output

Run lot gate checks — typecheck, lint, and scoped tests for the current lot

Update rules and skills after a branch merges — absorb learnings, refine patterns

Verify modified files against branch allowed/forbidden/conditional paths

Bootstrap a new source-feasibility spike in packages/radar-sources/src/sources/_spikes/

Use when adding or fixing OpenERP browser workflows that cross apps/web, apps/api, seeded local data, or Playwright live validation.

Use when reviewing OpenERP UI/UX, design-system adoption, visual regressions, accessibility states, locale behavior, or Demo Slice screen quality.

Use when OpenERP UI, UX, product, IA, accessibility, locale, or workflow orientation needs a clear decision or user arbitration.

Run @sentropic/design-system-skills against a target and return findings as JSON for DS linting.

Run @sentropic/design-system-skills against a target and return findings as JSON for DS linting.

any input (code, docs, papers, images) -> knowledge graph -> clustered communities -> static Ontology Studio + JSON + audit report. Use when user asks any question about a codebase, project content, architecture, or file relationships, especially if .graphify/ exists. Provides persistent graph with god nodes, community detection, and BFS/DFS query tools.

Use when the user asks for a track report, a status, an advancement/progress report, or says 'fais-moi un track report' / 'un track report' — run the CLI `track report` (default table) from the repo root and paste its FAIT/À-FAIRE/DÉCISIONS-ACTIONS table verbatim; NEVER use the `track_report` MCP tool to render a human report (it returns machine JSON). Also use when an agent needs to read, update, import, or verify track state in a repo; when a BRANCH.md or plan/NN-BRANCH_*.md file changed; when a session reports that track write/import is not exposed; or when deciding whether to use track MCP versus the track CLI. The skill enforces the contract: MCP is read-only, writes/imports use the track CLI from the target repo root, and .track is append-only/single-writer.