HodeTech

Add a new Board Support Package (BSP) crate to the Tyrne workspace — from crate skeleton through boot checklist to first QEMU or hardware boot.

Propose and draft a new Architecture Decision Record (ADR) in MADR format for Tyrne.

Run an independent verification pass over artefacts in `Proposed` / `In Review` waiting-for-promotion states. Distinct from code-review (style + correctness on a diff) and security-review (adversarial axis pass) — this skill verifies that the artefacts' claims about their own state match reality and produces a Done-promotion verdict.

Produce a review artifact in `docs/analysis/reviews/<type>-reviews/`, following that type's master plan. Works for business / code / security / performance-optimization reviews.

Change an existing Tyrne standard correctly — write or update the motivating ADR first, then update the standard file.

Add a new Rust crate to the Tyrne workspace following the dependency policy in `infrastructure.md`.

Introduce or audit an `unsafe` region in Tyrne — writing the `SAFETY:` comment, adding the audit-log entry, and queuing security review.

Run a structured code-review pass on a pull request or branch, applying the Tyrne code-review standard.

Add a new LLM provider adapter behind the LLMProvider seam in packages/llm without leaking a single vendor SDK type across it: implement the seam interface, normalize system-prompt placement / tool schema / tool-call round-trip / streaming events / stop reasons / usage to the canonical Relavium types, map the provider into the generated model catalog for cost, wire it into the fallback runner config, and add the per-provider conformance test (recorded fixtures on PR, live nightly). USE FOR: integrating a new model provider into @relavium/llm. DO NOT USE FOR: adding a new top-level workspace package (use ../add-package/SKILL.md), changing the seam *interface* itself (that supersedes ADR-0011 — use ../write-adr/SKILL.md), or restating the seam contract (it has one canonical home in docs/reference/shared-core/llm-provider-seam.md).

Review a Relavium diff, PR, or branch against docs/standards/, the ADRs, and the CLAUDE.md non-negotiables, then report findings as file:line — severity — issue — impact — fix, sorted by severity. USE FOR: reviewing a proposed change before merge, walking a PR, or self-reviewing your own branch before requesting review. DO NOT USE FOR: implementing the change (use implement-task), a secrets/SSRF/sandbox deep-dive (use security-review), or general code questions unrelated to a diff.

The primary end-to-end flow for implementing any non-trivial change in Relavium — scope, plan, build against the standards, self-check the seam rule, run the toolchain, update docs, commit, and hand off to review. USE FOR: features, fixes, refactors, or new adapters/nodes that touch real code in packages/* or apps/*. DO NOT USE FOR: a one-line typo, a pure docs edit (use documentation-style directly), reviewing someone else's diff (use code-review), or a security-only pass (use security-review).

Run the binding Relavium security pass over a diff/branch — keys never leave the keychain or reach the frontend/logs, SSRF on custom provider base URLs, the run_command sandbox, prompt-injection posture, dependency provenance, and never hand-roll crypto. USE FOR: any change touching keys, the keychain bridge, IPC, network/base-URL handling, the command sandbox, prompt/tool-call construction, the DB encryption path, or a new dependency. DO NOT USE FOR: a general correctness review (use code-review) or implementing the change (use implement-task).

Supersede an existing Accepted ADR by writing a new one, flipping the old Status to "Superseded by", and repointing live references — never deleting or rewriting the old body. USE FOR: overriding a settled decision, reversing a prior choice, replacing one approach with another. DO NOT USE FOR: a first-time decision (use ../write-adr/SKILL.md) or a typo/clarity fix to an existing ADR (ADRs are append-only history, not living docs).

Format Conventional Commits with a per-package scope, reference the ADR/task in the body, end with the Co-Authored-By trailer, and write a PR description with a conformance checklist. USE FOR: committing finished work and opening a PR. DO NOT USE FOR: authoring a decision (use ../write-adr/SKILL.md), scoping work (use ../start-task/SKILL.md), or the pre-commit conformance screen (use ../standards-check/SKILL.md first).

Fast, mostly-grep conformance gate over a diff before deeper review — strict TS/no-any, no new dep without an ADR, no vendor type across the @relavium/llm seam, engine zero platform imports, secrets never plaintext/in logs, one-canonical-home docs, conventional commits. USE FOR: a quick pass/fail screen before requesting review or committing. DO NOT USE FOR: a full code review (use the relavium-reviewer agent / code-review.md) or a deep security audit (use security-review.md).

Author a new Architecture Decision Record in docs/decisions/ using the condensed MADR form and update the index. USE FOR: recording a settled non-trivial architectural/product/process decision, adding a new runtime dependency, justifying a stack or seam choice. DO NOT USE FOR: replacing an existing Accepted decision (use ../supersede-adr/SKILL.md), restating a spec (that belongs in docs/reference/), or scoping a unit of work (use ../start-task/SKILL.md).

Propagate a settled decision (e.g. a pinned-technology choice) consistently across the whole docs tree — the canonical docs, the relevant ADRs, and every stale terminology reference — and verify it. USE FOR: rippling an already-made decision so the tree stays self-consistent after a tech choice, a substrate swap, or a scope refinement. DO NOT USE FOR: recording the decision in the first place (use ../write-adr/SKILL.md) or reversing one (use ../supersede-adr/SKILL.md).

Deeply review a competitor or reference (an open-source repo or a product) and write a structured, evidence-cited teardown plus a Provna-implications synthesis INTO docs/private/. USE FOR: a code-level or doc-level intelligence dossier on a rival/reference (e.g. an agent- governance toolkit, an IFC engine, a durable-execution substrate) mapped to Provna's four pillars. DO NOT USE FOR: writing public docs (use ../write-doc/SKILL.md) — teardowns are internal and public docs never reference them.

The consistency gate for the docs tree — run before finishing ANY documentation change. Fast and mostly machine: no docs/private leak, English-only public docs, relative links resolve, ASCII-safe Mermaid, single H1 / no front-matter; then a short list of judgment checks the script cannot make. USE FOR: a pass/fail self-gate after editing docs. DO NOT USE FOR: a deep adversarial review (use ../review-docs/SKILL.md or the provna-docs-reviewer agent).

The primary end-to-end flow for delivering a non-trivial Provna roadmap workstream — scope, align, inspect, plan, do the work, gate it, update the canonical docs, commit, and hand off to review. USE FOR: a Phase-0 PoC or a substantial planning/spec/deliverable from docs/roadmap/current.md (and, once the monorepo lands, a feature/fix in the data-plane or control-plane). DO NOT USE FOR: a one-line edit, recording a decision (use write-adr), a quick docs gate (use docs-check), or reviewing someone else's work (use review-docs).

Deep, multi-dimension adversarial review of a docs change or the whole tree — terminology, quantitative consistency, technical accuracy vs the pinned decisions, cross-references, scope discipline, the no-docs/private rule, honesty, and conventions — with each candidate finding verified before it is reported. USE FOR: a thorough review before a milestone or after a large change. DO NOT USE FOR: the quick pass/fail gate (use ../docs-check/SKILL.md) or writing/fixing docs (this produces findings, it does not edit).

Reverse or replace an Accepted decision by writing a NEW ADR and marking the old one Superseded — ADRs are append-only and history is never rewritten. USE FOR: changing a decision that an Accepted ADR already records (a substrate swap, a reversed scope call, a new pinned technology that displaces an old one). DO NOT USE FOR: recording a brand-new decision (use ../write-adr/SKILL.md), or merely refining wording/propagating an unchanged decision across docs (use ../apply-decision/SKILL.md).

Author a new Architecture Decision Record in docs/decisions/ using Provna's condensed-MADR form and register it in the index. USE FOR: recording a settled non-trivial architectural / product / process / tech decision, pinning a stack or seam choice, or justifying a new core dependency. DO NOT USE FOR: reversing an Accepted decision (use ../supersede-adr/SKILL.md), propagating an already-recorded decision across the tree (use ../apply-decision/SKILL.md), or writing a normal doc (use ../write-doc/SKILL.md).

Add or update a page in the docs/ tree (architecture, business, compliance, roadmap, standards, a pillar, the glossary) so it obeys Provna's conventions and the one-canonical-home rule. USE FOR: writing a new public doc, restructuring or expanding an existing one, adding a Mermaid-first architecture page. DO NOT USE FOR: recording a decision (use ../write-adr/SKILL.md), propagating a settled decision tree-wide (use ../apply-decision/SKILL.md), or writing internal competitive analysis (use ../competitive-teardown/SKILL.md, which targets docs/private/).

Use this skill when preparing a ForgeLM release. Walks through version bump, changelog finalization, tag, publish, and post-release sync per docs/standards/release.md. Triggered by requests like "cut v0.4.0", "release ForgeLM", "prepare the next version".

Use this skill when editing any docs/reference/* or other bilingual documentation pairs in ForgeLM. Keeps the .md and -tr.md mirrors structurally aligned per docs/standards/localization.md. Triggered by requests like "update the configuration docs", "add a section about X to the usage guide", "translate the new feature docs".

Use this skill when adding a new YAML configuration field to ForgeLM. Handles Pydantic model update, cross-field validation, config_template.yaml sync, bilingual docs, and tests. Triggered by requests like "add a new config option for X", "expose Y as a YAML field", "make Z configurable".

Use this skill when writing new tests for ForgeLM. Applies conventions from docs/standards/testing.md — fixture factory patterns, mock boundaries, no-GPU-no-network discipline, coverage floor. Triggered by requests like "add a test for X", "cover function Y", "write a test that triggers error Z".

Use this skill when adding a substantial end-to-end feature to ForgeLM's training pipeline — a new alignment method, a new evaluation gate, a new quantization backend, a new distributed scheme. Differs from add-config-field by touching multiple modules and requiring integration tests. Triggered by requests like "add support for algorithm X", "integrate library Y for training", "implement feature from roadmap Phase N".

Use this skill when reviewing a pull request to ForgeLM, whether your own (self-review before requesting review) or someone else's. Applies the code-review standard, catches anti-patterns, and produces actionable feedback. Triggered by requests like "review this PR", "check if PR

Use this skill when reviewing a pull request to ForgeLM, whether your own (self-review before requesting review) or someone else's. Applies the code-review standard, catches anti-patterns, and produces actionable feedback. Triggered by requests like "review this PR", "check if PR