Skip to main content
ClaudeWave
Skill1.4k repo starsupdated 1mo ago

h-reason

h-reason is the manual entry point for FPF-style structured reasoning work when the operator's request is ambiguous across framing, exploration, or comparison, or when they explicitly invoke it. It surfaces the complete reasoning palette including problem framing, solution exploration, comparison, verification, and specialized patterns like Goldilocks problem selection and scaling-law analysis. Use this umbrella skill when spanning multiple workflow steps in one session or when the signal doesn't clearly point to a single specialized skill, but always call underlying haft kernel tools rather than providing ephemeral chat analysis.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/m0n0x41d/haft /tmp/h-reason && cp -r /tmp/h-reason/packages/haft-pi/skills/h-reason ~/.claude/skills/h-reason
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

<!-- haft-contract-source: kernel_interface_catalog source_digest=sha256:26e174fdd87993d53721c925be9727239d77e8a425b7c52d28fd9f833b6d1153 -->

# h-reason — Source-first FPF entry

Contract truth: source-native FPF Query and typed-memory resolve, neighborhood,
and recall are **V9 CONTRACT** capabilities. Source, schema, skill, or
local-test presence is not installed-runtime proof and does not establish Pi
host parity. A readiness claim requires current
**EXACT-CANDIDATE EVIDENCE** from P14 tied to one exact candidate; RC or release
status additionally requires release authority. Pi support is an experimental
compatibility carrier; stable host parity is not proven. Do not infer
**CURRENT PRODUCT** status from contract inclusion or evidence alone.

For purely mechanical, status-only, or exact project-lookup work where no FPF
pattern choice is material, caller abstention is the result: skip FPF Query and
do the bounded work directly. Do not fabricate
`QueryResult(kind="abstained")`; no query ran. Query when pattern applicability
is material or uncertain.

Name the current object, question, relations, constraints, evidence, and
smallest useful result. Query `haft_query(action="fpf", mode="concern",
query="<object + question + terms>")`; compare README practical-use cards, use
the source ToC as the identifier/keyword index, recover exact source units with
`mode="lookup"` or non-broadening `mode="inspect"`, and inspect the selected
pattern's full body. Retrieval returns source candidates. Returned source
material is not applicability, selection, recommendation, evidence,
precedence, or authority.

For a non-English concern, keep the operator's wording in `query` and add
precise English or FPF terms in `known_context`. Those terms are required: the
bundled source is English, a measured 6 of 6 Russian concerns returned zero
candidates without them, and the same concerns with English `known_context`
resolved to the exact card at rank 1. Do not translate `query` itself.

In ordinary working use, identify the selected direct pattern by `PatternID`,
title, and stable source reference. Do not routinely reproduce source spans,
repository-local paths, line ranges, hashes, revisions, or other provenance.
Request trace or audit provenance only when the current use requires it.

Keep exact identifier namespaces separate:

- FPF `PatternID`, `SourceID`, or `UnitID` ->
  `haft_query(action="fpf", mode="lookup|inspect", identifier="<id>")`;
- canonical Haft artifact ID ->
  `haft_query(action="related", artifact_ref="<id>")`;
- code symbol or `SymbolAnchor` ->
  `haft_query(action="node", symbol="<name>")` or `anchor_id="<anchor>"`;
- typed-memory `EntityID` or `EntityAlias` ->
  `haft_query(action="memory", memory_request={"mode":"resolve","query":"<id-or-alias>",...})`;
  never coerce it into another namespace.

After exact resolution, use the closed `memory_request` branch whose nested
`mode` is `neighborhood` to hydrate the EntityOfConcern graph, or `recall` for
bounded lexical recall inside that exact scope. Mode-specific required fields
come from the tool schema. When the project is not ready for these reads, use
`haft_onboard(action="status")` and follow its readable next action; do not
invent or expose an internal schema-selection step. Resolution, projection
inclusion, and recall rank are not truth, applicability, authority, or Work
order.

`known_absent` alone authorizes nothing. A concrete durability-requiring
receiving use may be operator-named or agent-inferred from current Work. Infer
it when cross-session continuation, handoff, audit, automation, delayed or
expensive feedback, or costly reversal already depends on stable identity; the
operator does not need to pre-name it. When identity, context, and aliases are
recoverable, establish the minimum EntityOfConcern without asking for separate permission.
Do not infer this use from an empty graph or generic future usefulness. Call
`haft_entity(action="establish", entity_id=..., label=...,
bounded_context_ref=..., aliases=[...],
persistence_reason="named_receiving_use",
request_provenance_ref=..., idempotency_key=...)`.

The task-level tool owns alias conflict checks, validation, internal project
basis, admission, and post-commit resolution. Use an `established` result's
exact `next_read` unchanged. Preserve `identity_conflict`, `alias_conflict`,
`idempotency_conflict`, `onboarding_required`,
`restart_required`, `rejected`, or `commit_outcome_unknown`; never invent
success. Retry `restart_required` with the unchanged idempotency key.

For an exact current concern, use the closed outer
`action="memory", memory_request={...}` envelope. Put the exact nested mode,
`contract_version="haft.memory.v1"`, `basis={kind:"project_current"}`,
projection profile
`agent_orientation.v2`, explicit requested facets, and a dimensioned read
budget. Inspect `result_kind`, `snapshot_basis`, `projection_basis`,
`interpretation_contract`, facet coverage, item semantic/lifecycle/evidence/
projection postures, and `applied_budget`. Only `complete` supports known
emptiness for that exact facet/profile/snapshot/context. Partial, unavailable,
stale, abstained, or retry-required results must keep their limitation. Honor
`hydrate_before_reliance`. Read affordances obtain more basis; they never
select a capability or next action.

Use `memory.resolve` only when identity is missing, and scoped `memory.recall`
only after exact entity/context resolution. Recall candidates and scores are
discovery, not truth, applicability, recommendation, freshness, authority, or
work priority. Enter FPF Query when pattern applicability, an unfamiliar kind,
or missing method basis is current.

On `wrong_identifier_namespace` with `same_call_retryable=false`, do not retry
the same action or ask for acknowledgement. Execute the exact `recovery_call`
when it names an available read-only surface; otherwise report that the
required surface is unavailable.

For code-area or flow orientation without an exa