m0n0x41d
UserEngineering decisions engine that know when they're stale. Frame, compare, decide — with evidence decay and parity enforcement. For Claude Code, Cursor, Gemini CLI, Codex and more.
Categories
Indexed Skills (15)
h-abduct
INTERNAL SUBROUTINE — used by h-diagnose for parallel rival-hypothesis generation. Manual invocation possible but the right user-facing entry point is almost always h-diagnose (which uses h-abduct internally with parallel testing). Generates ≥3 typed rival explanations for an observed signal per FPF B.5.2 abductive cycle. Do not auto-select this skill — when failure investigation is needed, select h-diagnose; when problem framing is needed, select h-frame.
h-boundary-unpack
INTERNAL SUBROUTINE — decomposes a boundary statement (API contract, service definition, policy text, SLA prose) into Laws / Admissibility / Deontics / Evidence quadrants per FPF A.6.B. Use only on specific boundary statements that mix statement types and need quadrant-by-quadrant cleanup. Do not auto-select for general work — for code review use Claude Code review; for problem framing use h-frame; for spec consistency audits use h-semio-review.
h-commission
Creates a WorkCommission — bounded execution authority — from an active DecisionRecord. MANUAL ONLY: operator must explicitly type /h-commission. Never auto-invoked: commissions are execution-authority grants under Transformer Mandate. Runs freshness check, scope check, derives an ImplementationPlan, snapshots the autonomy envelope, then STOPS before execution unless explicit execute authority is granted. NOT for the decision itself (use /h-decide first). NOT for running tests or one-off tasks (the operator's coding agent handles those directly).
h-compare
Compares 2+ candidate variants under parity discipline and returns a Pareto front (not a scalar winner) — declares the selection policy and parity plan BEFORE scoring, then scores each dimension across all variants in parallel to prevent anchoring bias. Make sure to use this skill whenever the user asks "A or B", "which is better", "compare X and Y", "trade-off between X and Y", "should we pick X or Y", "Pareto for these options", "PostgreSQL vs MySQL", "NATS vs Kafka", "library A vs library B" — anywhere two or more viable approaches are on the table and a fair, recorded comparison is wanted before committing. Also use when /h-explore has just produced a SolutionPortfolio. NOT for generating new variants (use h-explore first). NOT for committing to the winner — that requires manual /h-decide per Transformer Mandate.
h-decide
Records a binding DecisionRecord with full FPF DRR discipline — problem frame, decision/contract, rationale, consequences. MANUAL ONLY — the operator must explicitly type /h-decide. Never auto-invoked: per Transformer Mandate, the human principal records binding choices, not the agent. Use after framing, exploring, and comparing are done and a chosen variant is ready to commit. For tactical reversible changes (under 2-week blast radius) pass mode="tactical" with explicit _skips and _skip_reason. For irreversible / security / cross-team / public-API / data-migration changes pass mode="deep" — all DRR fields required, no skips accepted.
h-diagnose
Diagnoses a failure with parallel rival-hypothesis testing — multiple read-only subagents test distinct explanations in parallel, then rank by evidence weight while keeping losing rivals visible so the root cause is found honestly, not just plausibly. Make sure to use this skill whenever the user reports something broken with an unclear cause — "tests fail", "test is failing", "X doesn't work", "Y crashes", "why is Z happening", "investigate this bug", "what's causing this", "the bug is unclear", "something's wrong with X", "X used to work and now doesn't", "this is flaky" — or any failure report where the next diagnostic step isn't already obvious to the user. NOT for feature requests (use h-frame). NOT for performance work with a known bottleneck (use h-frame). NOT for verifying a hypothesis already recorded in a DecisionRecord (use h-verify).
h-explore
Generates 3–5 genuinely distinct candidate solution variants for a framed problem — each variant differs in KIND (not just degree), carries an explicit weakest-link so weak options surface before implementation, and optionally marks stepping-stones that open future search space. Make sure to use this skill whenever the user asks "what are our options", "how could we do X", "brainstorm approaches", "give me alternatives", "different ways to X", "what variants should we consider", "what else could we try", or whenever they are about to commit to one approach without having generated alternatives. Also use when a problem is framed but only one solution sits on the table. NOT for comparing existing options head-to-head (use h-compare). NOT for hypothesis testing on a failure (use h-diagnose).
h-frame
Frames an engineering problem before any solution is explored — stabilizes the signal, names what is actually broken, declares acceptance criteria, and records a ProblemCard. Make sure to use this skill whenever the user proposes a refactor, rewrite, redesign, restructure, or rebuild without first naming the underlying problem or what acceptance looks like; whenever they say "let's rebuild X", "switch from Y to Z", "we should restructure", "I want to change A to B", "refactor this", "let's redo this" without stating success criteria; whenever a proposed solution arrives before the problem is defined; whenever scope is fuzzy and acceptance is unstated. Also catches explicit framing intent — "let me think about X", "before we solve this", "what's actually going on", "I want to understand X first". For broken tests or failing code with unclear cause prefer h-diagnose. For micro-decisions with rationale use h-note.
h-note
Records a micro-decision with rationale into the haft artifact graph — lighter than a full DecisionRecord but persisted so future sessions and conflict detection can surface it. Make sure to use this skill whenever the user says "remember that", "FYI for later", "note that we chose X", "side note", "let's record we ruled out Y", "remember we decided X", "for the record", "worth noting", "TIL", "important caveat", "save this thought" — or whenever a small choice with stated rationale belongs in project memory but does not justify the full DRR ceremony. The kernel rejects content-free notes — rationale is required. For binding choices use h-decide (manual-only). For framing problems use h-frame.
h-onboard
First-setup ceremony for a project that does not yet use haft — the agent reads the repository, drafts the minimum FPF carriers (target system, enabling system, term map) from observed code/docs, and presents them to the operator for review. The operator is NOT asked to author spec files from scratch — that defeats the value of having an AI agent. Make sure to use this skill whenever the repository has no `.haft/` directory yet, when the user says "set up haft here", "onboard this project", "initialize FPF", "first time using haft in this repo", "let's add haft to this project", "scaffold haft for this codebase" — or whenever they want to start recording decisions but the artifact graph is not scaffolded. NOT for ongoing work in a project that already has `.haft/` (use h-status). NOT for framing one specific problem (use h-frame).
h-reason
Umbrella for FPF-style structured reasoning in a haft project. Carries the full reasoning palette in one place: framing, exploration, comparison, verification, notes, plus slideument patterns (NQD, Goldilocks, BLP, Scaling-Law Lens). Make sure to use this skill whenever the operator wants structured thinking but the workflow isn't pre-named — phrases like "давай подумаем", "помоги разобраться", "let's think this through", "structured approach", "apply FPF here", "FPF reasoning", "haft this" — or whenever a request is ambiguous between framing, exploration, and comparison. Also the manual entry point: /h-reason or /h-fpf alias. For sharp signals dedicated skills still fire (h-frame, h-diagnose, h-explore, h-compare, h-verify, h-status, h-note, h-onboard, h-spec-cover); binding choices use manual /h-decide; commissioning uses manual /h-commission.
h-semio-review
INTERNAL SUBROUTINE — semiotic / fanout audit on a concept rename, deprecation sweep, or doc-vs-code consistency check. Walks all carriers (filenames, manifests, stale refs, review surfaces, dashboards, prompts) until fixed-point clean, because one-shot text replacement creates rework when carriers diverge. Manual invocation only. Do not auto-select for general work — for code review use Claude Code review; for FPF reasoning about decisions use h-frame / h-decide.
h-spec-cover
Surfaces uncovered files in modules that already have recorded decisions — highlights drift before it accumulates and suggests where new decisions are needed. Make sure to use this skill whenever the user asks "is X documented", "what's covered", "spec coverage", "drift detection", "what decisions apply here", "are we tracking this module", "what's undecided in X" — or whenever they are about to modify code in a module with existing DecisionRecords and should be reminded which decisions apply. Also use when /h-status flags large counts of undecided files in a module. NOT for looking up decisions affecting one specific file (use mcp__haft__haft_query action=related). NOT for verifying one decision's predictions (use h-verify).
h-status
Project state dashboard for haft — read-only consolidation of active problems, pending decisions, refresh-due artifacts, open work commissions, recent notes, and module coverage. Make sure to use this skill whenever the user asks "where are we", "what's pending", "what's stale", "project status", "what needs attention", "show me the state", "what's in flight", "what did we decide on X recently", "haft status" — or whenever a session resumes after a break and situational awareness is needed before deciding what to work on. Cheap, read-only, zero commitments. For verifying a single decision use h-verify. For managing commission lifecycle use h-commission.
h-verify
Verifies that a recorded DecisionRecord still holds — baseline-vs-measure evidence loop with drift detection per FPF Evidence Decay. Make sure to use this skill whenever the user asks "did dec-X work", "is decision Y still valid", "did the prediction come true", "check if the migration held", "is X stale", "measure that decision against reality", "did we actually fix Z", "is our caching decision still right" ��� or whenever a shipped decision needs a post-implementation reality-check before further work relies on it. Also use when /h-status surfaces a refresh-due decision. NOT for ad-hoc sanity checks (just run the tests directly). NOT for re-framing the underlying problem (use h-frame).
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.