---
name: should
description: Recognize when an agent step is a bounded decision — yes/no, approve/reject, match/no-match, route/escalate — and handle it as one: delegate it to a should() decision tool when one is available in the session, and audit codebases for LLM calls that are really bounded decisions. Use when deciding whether to call a tool, checking something against a policy or brief, gating an action, or when asked to find bounded-decision candidates in a project.
---

# should — a probabilistic if statement

Version 0.1 · developer preview · https://www.hypermindz.ai/developers/skills/should

Traditional software evaluates exact conditions. Agentic software increasingly
has to evaluate semantic conditions: *should I call this tool, does this
satisfy the policy, does this product match the brief, should a human review
this?* Many of those steps are not generation or deep-reasoning problems.
They are **bounded decisions** — a small answer space, sufficient context in
hand, and a judgment that can be made explicit, bounded, and measurable:

```ts
const d = await should("Should this action execute?", context)
// → { yes: true, confidence: 0.97, decision_id: "dec_…" }
```

The mental model: **LLMs reason. Decision models decide. Governance permits.
Agents act.** This skill teaches you (the agent) to notice when a step is a
bounded decision and to treat it as one.

## Recognizing a bounded decision

A step is a bounded-decision candidate when ALL of these hold:

1. **Small answer space.** The useful output is yes/no, approve/reject,
   match/no-match, route/escalate, or a choice from a short fixed list — not
   prose, not a plan, not generated content.
2. **Context is already in hand.** Everything needed to decide is present in
   the call (the brief, the offer, the policy text, the candidate). No
   research, retrieval, or multi-step reasoning is required.
3. **The question is decidable.** A competent reviewer given the same context
   would usually reach the same answer. Genuine ambiguity means it is not a
   bounded decision yet — it is a reasoning problem.

Typical shapes: "Does this seller product satisfy the buyer brief?" · "Should
this counteroffer be accepted?" · "Does this creative satisfy the policy?" ·
"Does this change still match the original objective?" · "Is confidence high
enough to skip human review?"

## What to do with one

**If a `should()` decision tool (MCP) is available in this session:** call it
with a single yes/no question and the minimal sufficient context, and use the
returned `{ yes, confidence, decision_id }`. Keep the question phrased so
that "yes" means "proceed".

**If no decision tool is available:** still make the structure explicit.
Answer the bounded question yourself in one line — `YES/NO · confidence ·
one-sentence reason` — before acting on it, so the decision is visible and
auditable rather than buried inside a longer chain of reasoning.

## What NEVER to delegate on confidence alone

A confidence score is an input to policy, not an authorization. Regardless of
how high the reported confidence is:

- Never execute an irreversible, external, or financially consequential
  action purely because a decision model said yes. Deterministic policy,
  authorization, and (where configured) human approval decide what is
  *permitted*; the decision only says what *appears appropriate*.
- Never use should() where the answer space is genuinely open, the context is
  incomplete, or the question is a matter of taste or strategy.
- Never treat a confidence score as calibrated unless the runtime says it is.
  Low confidence, or confidence below the caller's threshold, means
  **escalate**, not guess.

## Audit mode — finding candidates in a codebase

When asked to find bounded decisions in a project (for example: "find places
where I'm using a frontier model for a bounded decision"):

1. Locate LLM/inference call sites (SDK clients, completion/chat calls,
   prompt templates, agent tool-selection logic).
2. For each, classify the *shape of the answer actually consumed* by the
   surrounding code: generation, reasoning/planning, or bounded decision
   (the code branches on a yes/no, a label, or a short enum parsed from the
   response).
3. Report candidates as a table: file/function · the implicit question ·
   answer space · whether context is self-contained · suggested primitive
   (`should()` for binary, a bounded multi-choice for accept/counter/
   reject/escalate-shaped calls).
4. Do not fabricate savings numbers. If asked for impact, count the calls
   and describe the substitution qualitatively; measured cost and latency
   come from running the decision runtime, not from estimates.

## Boundaries

This skill is behavioral guidance, not a wrapper for any particular provider.
It does not replace LLM reasoning, deterministic business rules, or human
approval — it sits between reasoning and action and makes one class of step
explicit. The should() API and MCP surface are in developer preview:
https://www.hypermindz.ai/developers/skills/should