Ask better questions
More model effort does not help if the question names the wrong problem, hides a system boundary, or treats one attractive option as inevitable. The agent may produce a better implementation of the wrong thing.
Haft helps the agent identify what kind of result is needed before it generates more work. It does not impose one process on every task.
Start with the situation you recognize
| What is happening? | Useful Haft capability | First useful result |
|---|---|---|
| Everyone is discussing solutions, but the problem is still fuzzy | h-frame | A bounded problem, constraints, and acceptance |
| A failure has several plausible causes | h-diagnose | Rival hypotheses tested against observations |
| The team needs genuinely different approaches | h-explore | Distinct options with a weakest link each |
| Options exist, but the comparison keeps moving | h-compare | One comparison basis and visible trade-offs |
| An old decision may no longer fit reality | h-verify | Current evidence against the recorded claim |
| You do not yet know which of these situations you have | h-reason | The smallest appropriate route and result |
Completion of one capability does not require the next. Exploration may end with several live options. Diagnosis may end with one supported cause. A clear mechanical edit can proceed without any FPF query at all.
What h-reason does
- Recovers the project thing and the current question about it.
- Separates known facts, assumptions, constraints, and missing evidence.
- Retrieves relevant source from the version of FPF bundled with Haft when a pattern choice matters.
- Uses the smallest capability that can produce the needed result.
- Stops at that result instead of manufacturing a complete workflow.
/h-reason We keep adding retries to checkout. Work out whether the
current problem is reliability, latency, or an upstream contract failure.
Show what we know, what we are assuming, and what evidence would separate them. FPF without the entrance exam
The First Principles Framework is a large pattern language for systems, reasoning, and engineering work. Haft does not paste the whole framework into every conversation. It searches the pinned source for the current concern, opens the exact pattern when needed, and keeps a return path to the source.
The important boundary is simple: retrieval gives the agent source material, not a correct answer. The agent still has to check whether the pattern fits this situation. A high-ranked result is not automatically the right method, a recommendation, or a work order.
Advanced: inspect the FPF source directly
haft fpf query "How should I frame this concern?" --json
haft fpf lookup "E.11.PUA" --json
haft fpf inspect "E.11.PUA" --role pattern_body --json | Command | What it returns |
|---|---|
query | Compact source candidates for a concern |
lookup | An exact source identifier when it resolves |
inspect | One exact full source unit, or an honest no-result |
For a non-English question, Haft keeps the original wording and adds precise English or FPF terms as retrieval context. It does not silently replace the user's question with a hidden translated route.
Reasoning does not have to become memory
A useful answer can remain in the conversation. Haft saves records when the operator asks, or when later work has a concrete reason to depend on the result: handoff, replay, audit, automation, delayed evidence, or costly reversal. An empty project graph is not a reason to fill it.
What this costs
- The agent spends more time clarifying expensive questions before producing code.
- Someone still has to judge whether the framing and evidence are good.
- Overusing the method on obvious, reversible work creates ceremony without value.