Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions .claude/rules/delegation-ladder.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# Delegation ladder

**Pick the cheapest tier that is reliable for the task.**

The ladder, principles, and patterns apply on every surface (Code, Chat, Cowork, Design). The Mechanics section applies only where the surface can spawn sub-agents (currently Code and Cowork); elsewhere, apply the principles to whatever decomposition the surface allows.
Comment on lines +1 to +5

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Restore the RIQAPP-1100 reference if it is part of this PR’s contract.

The PR objective says this document references RIQAPP-1100, but the supplied file contains no ticket reference. Add it or update the objective/canonical copy so the intended traceability requirement is met.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.claude/rules/delegation-ladder.md around lines 1 - 5, Restore the
RIQAPP-1100 ticket reference in the “Delegation ladder” document if this PR is
expected to satisfy that traceability contract; otherwise update the related
objective or canonical copy to remove the requirement. Keep the reference
aligned with the project’s established ticket-linking format.


## The ladder

When **Fable** (or any Mythos-class model) is the lead:

| Tier | Delegate to it |
|---|---|
| Opus | Deep investigation and evidence-gathering, adversarial review of code/docs against sources of truth, design/planning input on complex systems |
| Sonnet | Contained implementation or authoring from a precise spec, structured codebase/doc mapping, API/`gh` inspection tasks |
| Haiku | Mechanical bulk (sweeps, renames, conversions), dry-run/operability checks, simple verification passes |

When **Opus** is the lead, the lead absorbs the top tier and each remaining role moves down one: Opus keeps deep investigation and final judgment itself; Sonnet does implementation, authoring, and exploration; Haiku does mechanical bulk and dry-runs.

**The human tier.** Below Haiku sits the person: sub-minute UI actions (delete a line in a web editor, approve a dialog, trash a page) where any prompt, at any tier, costs more than the click. Don't automate these — hand them back as a named action item. Override only when getting it off the person's plate is itself the point — then do it knowingly, not by default.

## Choosing the lead

Pick the lead by how often the session needs Fable-grade judgment — then never call upward.

- **Repeatedly, or interleaved with execution** → Fable leads. The lead-seat premium is bounded (the lead's long context is mostly cache reads) while lead errors multiply downstream, so the lead seat is the cheapest place in the system to buy quality.
- **Never** (the plan exists, the work is contained) → Opus leads; Fable doesn't appear.
- **Exactly once, at the start or end** → phase split: a Fable-led planning session emits the plan and agent specs as artifacts; a fresh Opus-led execution session runs them; Fable reviews the final artifact.

**No upward delegation.** The lead never consults a higher tier mid-session: the briefing is lossy compression of exactly the context that judgment needs most, and integrating a higher tier's output inverts the review invariant. Downward handoffs between sessions replace upward calls within one. Failure escalation tops out at the lead's own tier — if a task genuinely needs a tier above the lead, the lead was mis-chosen; re-scope the session rather than consulting upward.

## Principles (all surfaces)

- **Review invariant.** Reviewer ≠ author, and reviewer tier ≥ author tier. When the lead authors an artifact itself, the reviewer is a *parallel* agent at the lead's own tier — a Fable lead gets a parallel Fable reviewer, an Opus lead a parallel Opus reviewer — so the review is independent of the author's context.
- **Verification vs. review litmus.** If the checklist can be written in advance, it's verification — Haiku runs it. If the reviewer has to generate the checklist, it's review — it goes up-ladder.
- **Don't-delegate floor.** If writing a self-contained spec costs more than doing the task, the lead does it directly.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Qualify the “investigate before editing” requirement.

Line 50 requires launching an evidence-gathering agent before any assumption-based change, while line 35 says not to delegate when specification cost exceeds task cost. Add an exception for trivial work the lead can verify directly.

Suggested wording
- Investigate before editing. Launch an evidence-gathering agent before changing anything based on an assumption — including the user's stated assumption.
+ Investigate before editing. Verify assumptions before changing anything, launching an evidence-gathering agent when the task is above the don't-delegate floor.

Also applies to: 50-50

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.claude/rules/delegation-ladder.md at line 35, Update the “Don’t-delegate
floor” guidance and the “investigate before editing” requirement in the
delegation ladder to explicitly exempt trivial changes the lead can verify
directly. Preserve the evidence-gathering-agent requirement for assumption-based
changes that are not trivial, while allowing the lead to proceed without
delegation when direct verification is sufficient.

- **On failure.** One retry with a corrected spec. On a second failure, escalate one tier or the lead absorbs the task. Never re-run a failing agent on an unchanged spec.

## Mechanics (agent-spawning surfaces)

**Label every sub-agent with its model.** Prefix the agent's `description` (the short text shown in the FleetView row) with the human-readable name of the model it runs as, in square brackets — `[<Model> <version>] <task>`. If the agent inherits the lead's model (no explicit `model`), use the lead's model name. Keep the rest of the description within its normal 3–5 words.

Examples with the current lineup (July 2026 — update names on release; the rule itself is version-agnostic):

- `[Opus 4.8] Explore teaching-claude-plugin repo`
- `[Sonnet 4.6] Explore ET course harness`
- `[Haiku 4.5] Explore TIC course harness`

## Patterns that work

- **Investigate before editing.** Launch an evidence-gathering agent before changing anything based on an assumption — including the user's stated assumption. Surface contradictions with evidence instead of encoding them into the change.
- **Parallelize on disjoint write-sets.** Independent agents go in a single message so they run concurrently; sequence only when one agent's output feeds another's prompt. "Independent" means disjoint write-sets — no shared files, branches, or tickets — not merely unrelated prompts. Anything sharing a write target gets sequenced. (In Code, worktrees give you disjoint write-sets by construction.)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Do not claim that worktrees guarantee disjoint write-sets.

Worktrees isolate checkout/branch state, but not shared tickets, external services, or other side effects. Keep the independent-write-set requirement explicit.

Suggested wording
- (In Code, worktrees give you disjoint write-sets by construction.)
+ (In Code, worktrees can isolate checkout write-sets; still verify shared tickets and external side effects.)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- **Parallelize on disjoint write-sets.** Independent agents go in a single message so they run concurrently; sequence only when one agent's output feeds another's prompt. "Independent" means disjoint write-sets — no shared files, branches, or tickets — not merely unrelated prompts. Anything sharing a write target gets sequenced. (In Code, worktrees give you disjoint write-sets by construction.)
- **Parallelize on disjoint write-sets.** Independent agents go in a single message so they run concurrently; sequence only when one agent's output feeds another's prompt. "Independent" means disjoint write-sets — no shared files, branches, or tickets — not merely unrelated prompts. Anything sharing a write target gets sequenced. (In Code, worktrees can isolate checkout write-sets; still verify shared tickets and external side effects.)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.claude/rules/delegation-ladder.md at line 51, Update the “Parallelize on
disjoint write-sets” guidance in delegation-ladder.md to remove the claim that
worktrees guarantee disjoint write-sets. Clarify that worktrees isolate checkout
and branch state only, while shared tickets, external services, and other side
effects still require sequencing; preserve the explicit disjoint-write-set
requirement.

- **Author low, review high.** Content authored by a lower tier gets an adversarial review by a higher tier against the actual sources of truth (code, configs, live systems) — then the lead applies the fixes itself rather than looping another author pass.
- **Prove operability at the target tier.** A doc/runbook/command meant to be executed by a small model gets a read-only dry-run by that same model (e.g. Haiku narrates exactly what it would run); its confusions are the defect list.
- **Write self-contained agent specs.** Exact paths, expected outputs, hard boundaries ("read-only", "do not touch X", "report, don't fix"). A vague prompt wastes the tier's entire run.
6 changes: 6 additions & 0 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,12 @@

Helpthread is an open-source serverless helpdesk (AGPL-3.0 core; a Resonant IQ, Inc. product). **CHARTER.md is the constitution** — read it before substantive work.

## Delegation ladder

Shared rule (mirrored from the resonantiq canonical doc) — imported so it loads in every session that reads this repo.

@.claude/rules/delegation-ladder.md

## References & provenance

- Helpthread is an independent implementation. No code copied or derived from copyleft-licensed projects, ever.
Expand Down
Loading