Special

special

The audit skills walk the line looking for what is broken. special walks the walk-in looking for what is possible. The chef sees what is fresh and plentiful on the shelves and proposes the dish worth adding to the board tonight, the one that uses what is already in the kitchen. A special is not invented out of nothing; it is the obvious next thing made from what you already have.

Core principle: every proposal is grounded in evidence already in the repo. If you cannot point to the signal in the walk-in, it is not a special, it is a daydream. No trend-chasing, no wishlist, no feature you cannot tie to something that already exists.

Read-only. special proposes; it never builds. Picking the dish and cooking it are later steps.

What this is not

• Not the audit trio. line-check, bug-hunt, and security-sweep find problems. special finds opportunities. A bug is not a feature.
• Not mise. mise designs an idea you already have. special finds the idea worth designing. A chosen special flows into mise next.

Read the kitchen first

Before proposing anything, read what the project says it is and is not: README, CLAUDE.md / AGENTS.md, docs, declared roadmap, stated non-goals. A proposal that contradicts a declared non-goal is cut, or flagged as a deliberate challenge to it with that called out. Know the dish before you suggest the next course.

The signals (where specials come from)

Each lens reads the existing repo for evidence of an obvious next step. With parallel subagents, one finder per lens; otherwise sequential.

A proposal with no lens behind it does not get written down.

Each proposal earns its place

For every candidate that survives, write a card:

• The dish: what to build, concretely, in one or two sentences.
• Signal: the evidence in the repo, with a file reference. This is the load-bearing field; no signal, no card.
• Who it serves: the concrete user or operator need. If you cannot name the need, YAGNI cuts it.
• Fits because: the existing abstractions, patterns, or data it reuses. A special that needs a rewrite to exist is not a special.
• Smallest version: the minimum that delivers the value; note any larger ambition as a later course, do not propose the mega-feature.
• Effort: S / M / L.
• Leverage: impact relative to effort, the sort key.
• Confidence + open questions: direction is the user's call, so flag every assumption and what they must confirm. Mark speculative proposals plainly.

Scope

Default: the whole repo, since opportunities live in the gaps between parts. Narrow on request to a subsystem, a package, or "what does this one module want next". special branch reads only what the current branch changed and proposes the natural follow-ups to that work.

Output shape

Its own artifact, the specials board, leverage-sorted, and audit-format-compatible so a picked item composes into the same backlog:

## special: <repo> (<date>)

### The board
One paragraph: the strongest opportunity and the through-line across the proposals.

### Specials (leverage-sorted)
#### [LEVERAGE: high/med/low] The dish
- **Signal:** evidence + file:line
- **Who it serves:** the need
- **Fits because:** existing abstractions reused
- **Smallest version:** the minimum slice
- **Effort:** S / M / L
- **Confidence:** high/med/low + open questions for the user

### Considered and cut
- idea - why it was cut (ungrounded / contradicts a non-goal / already exists)

Boundaries

• A chosen special hands to mise to design, then recipe to plan, then fire to build. special stops at the board.
• Problems found along the way route to the audit trio, not into the board. A missing test is a line-check finding, a wrong result is a bug-hunt finding.
• Direction is the user's decision. special recommends and ranks; it does not commit the project to anything.

Common mistakes