Bound it before you build it. Use when a decision is blocked by "we don't have data", an estimate looks suspiciously precise, someone asks "is this even feasible?", "how much capacity do we need?", "will this scale?", or a claimed number has never been cross-checked by a second method.
How this skill is triggered — by the user, by Claude, or both
Slash command
/zetetic-team-subagents:estimationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Problem shape:** a quantity is needed for a decision, but there is no
Problem shape: a quantity is needed for a decision, but there is no measurement — or there is a single number with false precision and no bracket. The move is order-of-magnitude decomposition, two-sided bounds, and limits derived before methods are chosen.
| Agent | Use when |
|---|---|
| fermi | decision blocked by missing data; single number with no bracket; feasibility check before committing resources; sanity-check a claimed figure |
| erlang | capacity planning, queue sizing, arrival-vs-service balance, latency exploding near saturation (Little's law audits) |
| thompson | "will this design survive 10x scale?" — surface-to-volume and allometric scale-break analysis |
| laplace | priors need eliciting; estimates need updating as evidence arrives; forecaster calibration is unknown |
| carnot | efficiency claims with no derived theoretical limit; "where is the irreversible loss?" |
| erdos | existence/threshold questions on large combinatorial spaces — probabilistic method instead of enumeration |
tools/genius-invoker.sh route "<problem>" and take the top ranked match.tools/genius-invoker.sh invoke <agent> "<problem>", then read
agents/genius/<agent>.md in full.<workflow> step by step and answer in its
<output-format>. Every estimate ships as a two-sided bracket with the
dominant uncertainty named — never a bare point value.npx claudepluginhub cdeust/cortex --plugin zetetic-team-subagentsGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.