treylom/tofu-harness/harness-help

/harness-help — what this is, what you have, what to do next

Why this exists: a feature list tells you what exists; it does not tell you what is running here. Those diverge fast — a gate whose settings entry was never reloaded, a skill installed under a different marketplace, a rule file copied but never filled in. This command answers from the machine, then points at exactly one next step.

The rule

Report measured state, never a remembered feature list. Every "installed ✓" in your output must come from something you checked in this session. If you could not check something, print ? and say why — a confident wrong inventory is worse than an honest gap, because the user stops looking.

STEP 1 — Measure

Check and record, quietly, before printing anything:

1. Harness — Claude Code (~/.claude/settings.json, <project>/.claude/settings.json) or Codex (~/.codex/hooks.json).
2. Skills — which of this bundle's skills resolve.
3. Gates — parse the settings file(s) and list which hooks are wired, to which events. Read both the user-level and project-level file; hooks merge across them, and a hook present in one is easy to miss when you only read the other.
4. Companions — conversation memory, structured brainstorming, knowledge capture: installed? responding?
5. Rules — which rule files are present, and how many ▶ Fill in: markers remain unfilled:

``bash grep -o '▶ Fill in' rules/*.md | wc -l ` Use grep -o … | wc -l, not grep -c — grep -c` counts lines, so a line carrying two markers is undercounted.

STEP 2 — Print this

HARNESS: <Claude Code | Codex>          settings: <paths actually read>
 
SKILLS
  /tofable         run a task under the working discipline      [installed ✓ | missing]
  /harness-audit   check harness docs for drift after a model release
  /harness-setup   stand the whole stack up in one pass
  /install-hooks   wire the gates and prove each one fires
  /harness-help    this
 
GATES        <n> wired  ·  group: <core | recommended | full | mixed>
  <hook> → <event>                                   [live | wired-but-unproven]
  not wired: <list>
 
COMPANIONS
  conversation memory   [installed ✓ · last indexed <date> | missing]
  structured brainstorm  [installed ✓ | missing]
  knowledge capture      [installed ✓ | missing]
 
RULES        <n> files  ·  <m> markers still unfilled   ← these rules are inactive until filled
 
NEXT: <exactly one step>

STEP 3 — Pick the one next step

Print one, chosen by the first row that matches:

Do not print a list of five things. A single next step gets done; a menu gets postponed.

What each piece buys you

Say this in plain language when asked "what does X do" — lead with the failure it prevents, not the mechanism.

Be honest about the size of the effect. The measured benchmark numbers in `bench/results.md` come from an earlier model generation; a stronger model needs fewer of these corrections. The direction holds, the magnitude shrinks. Do not quote those figures as what the user should expect on their own setup.

Turning things off

FABLE_GATE_OFF=1 disables the gates. FABLE_GATE_PILOT=<session-name> scopes them to one session — use it for the first day in a shared project, then widen. Per-hook switches: `hooks/README.md`.

Always print the kill switch when asked for help. Someone reading help is often reading it because something is in their way.

Anti-patterns