h-explore

name	h-explore
description	Generate 3-5 genuinely distinct candidate approaches for a current question, with the weakest link of each kept visible. Use when alternatives are needed or one favored approach is prematurely closing the search. This skill is independent: it may work from an inline question, cue, accepted problem, or other current basis. Default to conversational candidates; persist a SolutionPortfolio only on explicit save intent or when current Work supplies a concrete operator-named or agent-inferred receiving use that needs replay.
when_to_use	The current need is option generation, not diagnosis of a failure or comparison of already available options.
argument-hint	[current question, cue, or problem reference]
allowed-tools	Bash Read Grep Glob Agent mcp__haft__haft_problem mcp__haft__haft_solution mcp__haft__haft_note mcp__haft__haft_query

h-explore — Keep distinct possibilities live

Inspect an exact FPF SourceID or UnitID with haft_query(action="fpf", mode="inspect", identifier="..."); otherwise use mode="concern" with the current exploration question. Retrieval is recall; the full pattern body supplies the conditions and result semantics. A candidate_set is incomplete: select by the current condition and required result kind, then inspect one exact PatternID. If no candidate fits, abstain. Never use a query performed after exploration or editing as proof that the earlier work followed that source.

Conditional project-memory orientation

When this exploration is context-heavy, multi-session, or reliance-bearing and the exact EntityOfConcern is not already current, resolve its identity with haft_query(action="memory", memory_request={"mode":"resolve", "contract_version":"haft.memory.v1","basis":{"kind":"project_current"}, "query":"...","max_candidates":5}). Select the exact candidate by the current use rather than rank, then use the closed memory_request neighborhood branch advertised by the tool schema with projection_profile_ref="agent_orientation.v2".

Inspect result_kind before relying on content. project_basis_unavailable, known absence, or explicit abstention is visible but non-blocking: continue the exploration without inventing a profile, entity, artifact, or human gate. This read does not replace code-graph preflight before a later code edit. Never persist typed memory merely because a read failed; persistence requires an explicit operator save request or a concrete operator-named or agent-inferred receiving use supplied by current Work, with provenance.

Procedure

1. Recover the current object, question, constraints, and useful candidate kind. Use an existing ProblemCard when it is relevant, but do not create one merely to satisfy this skill.
2. Generate 3-5 variants that differ in kind, not degree. Use parallel agents when independent directions materially improve diversity.
3. For each variant state: title, mechanism or structural move, expected benefit, weakest link, evidence gap, and whether it opens useful future search space.
4. Keep unattractive but informative stepping stones when they reveal a new action, interface, data source, or method family. Do not keep duplicates for cosmetic diversity.
5. Preserve uncertainty. Candidate generation is not recommendation, choice, authorization, WorkPlan, or performed Work.

Persistence boundary

In ordinary use, return candidates in conversation and stop. Persist only on explicit save intent or when current Work supplies a concrete operator-named or agent-inferred reliance-bearing receiving use. A durable typed portfolio requires each candidate to be an independently addressable ProjectRecord. When that receiving use is current, persist one non-binding candidate-description Note per variant through haft_note, using the same exact entity_ref and bounded_context_ref, and retain each returned record_reference. This is reliance-gated materialization, not an automatic bundle and not a claim that a Note is an FPF solution kind.

If the kernel requires a ProblemCard for the legacy portfolio carrier, use an existing card or ask whether the operator wants the current frame recorded; never invent one silently.

When persistence is justified:

mcp__haft__haft_solution(
  action="explore",
  problem_ref="<existing durable problem ref>",
  entity_ref={
    "ref_kind_id":"U.EntityRef",
    "reference_id":"<exact current EntityOfConcern>"
  },
  bounded_context_ref="<exact current bounded context>",
  variants=[{
    "title":"<name>",
    "description":"<distinct move>",
    "novelty_marker":"<difference in kind>",
    "weakest_link":"<failure boundary>",
    "stepping_stone":false,
    "risks":["<risk>"],
    "strengths":["<strength>"],
    "project_record_ref":{
      "ref_kind_id":"Haft.ProjectRecordRef",
      "reference_id":"<exact record_reference from the candidate Note>"
    }
  }]
)

Do not construct or guess a record ID from an artifact ID. If an exact option record is unavailable, the legacy SolutionPortfolio may still be retained but its typed projection must remain underdetermined; never mint a substitute entity or hide the missing basis.

Result

Present each option in plain language with its main catch. If persisted, pair IDs with titles and report the portfolio's exact record_reference when committed. Stop when the option field is adequate for the current use. Comparison, decision, planning, or implementation occurs only if one of those questions later becomes current; none is an automatic next step.