Explore AI Agent Skills & Claude Prompts

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).

schedule Updated 19 days ago

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.

schedule Updated 19 days ago

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-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-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.

schedule Updated 19 days ago

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).

schedule Updated 20 days ago

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.

schedule Updated 26 days ago

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).

schedule Updated 26 days ago

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.