Honey Superpowers

---
name: honey-superpowers
description: "Inject Honey levers into dispatched subagent prompts."
version: 1.3.1
author: GreenPT
license: MIT
metadata:
  hermes:
    tags: [token-efficiency, coding]
---

# Honey × Superpowers

Honey is turned on by the session's SessionStart hook — which lives in **your**
(the orchestrator's) context. Superpowers dispatches **fresh subagents with
isolated context**; they never inherit the hook. So every implementer, reviewer,
and fixer runs **Honey-off**: full-fat code (Lever 1 dark) and verbose reports
(Lever 2 dark) — multiplied per dispatch. That's the leak. Close it by pasting
the directive into the dispatch prompt itself.

The two skills already pull cost the same way Honey does — cheap model per task,
file handoffs over pasted text, one-line narration. **Don't fight them; stack on
top.** Honey adds what they don't: less code in the worker, terser reports both
ways.

## When it fires

Any time you are about to dispatch a subagent under a Superpowers-style workflow:

- `subagent-driven-development` — implementer / task-reviewer / fixer per task
- `dispatching-parallel-agents` — one agent per independent domain
- `executing-plans` — parallel-session execution
- any orchestrator → worker handoff with isolated context

## What to inject

**On Claude Code with the Honey plugin, skip the paste**: the plugin's
`SubagentStart` hook ([`hooks/honey-subagent.js`](../../hooks/honey-subagent.js))
injects the matching directive into every spawned subagent automatically
(reviewer-shaped agent types get the reviewer variant). The blocks below are for
other harnesses, or when the hook isn't installed.

Paste the matching block into the dispatch prompt body — inline text, not a Skill
call (invoking burns a round-trip; the subagent only needs the rules).

**Worker / implementer / fixer / parallel-domain agent:**

```
Apply Honey: write the minimum code that needs to exist — YAGNI, stdlib/native
before custom; no speculative params, branches, or single-caller abstractions.
Never cut validation, error handling, auth, or anything the task asked for.
Keep code, identifiers, paths, and the brief's exact spec values verbatim.
Report terse: status, commits, one-line test summary, concerns. No narration.
```

**Reviewer:**

```
Report findings tersely: id · severity · file:line · one-line fix. Don't narrate
or restate the diff. Honey governs your prose only — never your verdict or
severity. Flag everything you normally would; raise false positives for the
controller to adjudicate. Do not suppress or downgrade a finding to save words.
```

## Why the reviewer variant is different

Lever 1 (less code) and Lever 2 (less prose) compress what a *worker* emits. A
reviewer emits *judgments* — compress its prose, never its verdict. This matches
Superpowers' hard rule ("never tell a reviewer what not to flag") and Honey's own
safety carve-out (keep exact anything asked for; auth/money/migrations/deletes
stay explicit). A terser review is fine; a leniter review is a regression.

## Carve-outs (inherit Honey's)

Never elide, in any variant: input validation at trust boundaries, error handling
that prevents data loss, auth/escaping/secrets, accessibility basics, and anything
the task or plan explicitly mandated. Spec values (numbers, magic strings,
signatures, test cases) stay verbatim — that's Lever 2's "keep exact," and it's
also what the brief is the single source of truth for.

## What Honey can't shrink here

The skill prompts Superpowers loads into context are input tokens you've already
paid for — Honey can't out-compress them. They're lazy-loaded, so only triggered
skills cost anything. The big realized savings are the cheap-model-per-task rule
(Superpowers' own — don't skip it) plus Honey inside every dispatched subagent.