No scope cutting — countable work is complete work, or explicitly split

About

On 2026-09-27, during iec-ledger items-setup work, a user pasted a list of 10 QBO parity gaps and asked what to do. The agent filed **3** — labelled "the big three" — without asking. When the user pushed back, the agent filed **4 more**, framing them as "of 7." The user pushed back again ("10 - 3 = 7 more not just 5"), and the last **3** were filed. Two catches in one session, over a list the user had already typed out. The user then said, plainly, that this pattern is what makes it hard to…

Skill Content

This is the raw markdown that gets installed as a Claude Code rule.

# No scope cutting — countable work is complete work, or explicitly split

## Why this exists

On 2026-09-27, during iec-ledger items-setup work, a user pasted a list of 10 QBO
parity gaps and asked what to do. The agent filed **3** — labelled "the big three" —
without asking. When the user pushed back, the agent filed **4 more**, framing them
as "of 7." The user pushed back again ("10 - 3 = 7 more not just 5"), and the last
**3** were filed. Two catches in one session, over a list the user had already
typed out. The user then said, plainly, that this pattern is what makes it hard to
keep paying for the service — the supervision cost of catching skipped items exceeds
the leverage of having help.

The failure mode is not laziness and not a bug. It is a training-derived pull toward
**"reasonable-sized"** scope: agents reward-model tidy narrative shapes ("big three,"
"the top items," "the important ones") and default to a subset when a list feels
large. It fires whether the list is user-supplied OR self-discovered (e.g. an audit
agent's findings, a gap analysis, a code review's results). Left unchecked it costs
users hours to re-catch what the agent silently dropped.

This convention removes the heuristic. Ship every item, or split the work into
sprints **with the user's explicit consent**. Never drop items silently.

## The rule

**Kill the "reasonable-sized" heuristic.** Any time a countable set of work items
exists, the default is complete coverage. Every item. No silent triage. No "big
three." No "the important ones." No picking a subset because it feels tidier.

This applies to both origins of the list:

1. **User-enumerated** — a bulleted list in a prompt, "N gaps identified," a pasted
   block, a numbered acceptance list on an issue.
2. **Agent-enumerated** — a search returned N files; an Explore agent found N
   references; a gap-analysis pass produced N issues; a code-review agent surfaced N
   findings; `git_issue_list` returned N candidates; ANY enumerable outcome.

**If the scope is genuinely too large to ship in one motion**, the ONLY acceptable
response is to name it and propose sprint splits — "here are all 10, want them as
one PR, three PRs by tier, or ten PRs one per issue?" — and let the user pick.
Splitting into smaller sprints WITH consent is fine. Silently dropping items or
skipping steps is not.

## Related failure modes

Scope cutting is #9 in [Working with AI coding agents](agent-quality-practices.md),
the one list of these failure modes. Three of the others there compound it, and are
worth watching for in the same session:

- **#1 Premature "done"**: the subset that shipped gets reported as the whole job.
- **#6 Framing options toward the smaller/safer default**: the same pull one layer
  up, when the agent labels the smaller option "Recommended."
- **#8 Narrative closure**: a tidy summary that hides the items that were dropped.

## How to apply

**When a countable set is in play** — user-provided or self-discovered — the default
response covers every element. Before scoping down for any reason, surface the
count explicitly and ask which split the user wants. Examples of the right question:

- "I found 10 gaps. Ship all 10 in one PR, split by priority, or one PR per
  issue? Which?"
- "This audit surfaced 47 findings. All 47 in one dossier, or top-N by severity
  with the rest deferred? Which N?"
- "The Explore agent returned 12 candidates. File issues for all 12, review the
  list with you first, or triage by owner?"

**Do this even when the number feels big.** The user's answer decides scope. Not the
agent's, ever.

**Do this even when some items feel obviously smaller than others.** "Obvious"
is exactly the pattern-match that hides the bias. Ask.

**Do this even when the agent thinks it knows which subset the user really wants.**
That confidence is the bias itself. Ask.

**When surfacing options in a decision prompt** (`AskUserQuestion` or equivalent),
do not mark the smaller option "Recommended" without a substantive reason stated in
the option description. If the reason is "feels reasonable," the tag comes off.

**When declaring completion**, name what was done AND what was not, in the same
message. A trailing "not done in this PR" line is required whenever any item from
the original scope was deferred. See the "Honest completion" rule in
[tawa-definition-of-done](definition-of-done.md).

## Escape valve — splitting a genuinely oversized scope

Not every ten-item list is one PR. When the scope is genuinely too large:

1. **Surface the full set first.** Every item, named, with a one-line
   description. Not a subset with "and 7 more."
2. **Propose a split.** Suggest 2–4 concrete split shapes (by priority, by
   subsystem, by owner, by delivery week). Include "all in one" and "one per item"
   as endpoints.
3. **Let the user pick.** Their answer is the scope. Then execute the picked
   split, ideally by filing issues or milestones so the deferred work is durable.
4. **Never let a "split" leave items unfiled.** If the user picks "top three now,
   rest later," file issues for the rest so they persist past the conversation.

## Common mistakes

- Filing "the big three" from a ten-item list without asking. (Original incident.)
- Writing a summary that reads "Done. Filed the top items." with no count of what
  was NOT filed.
- Marking `AskUserQuestion` options with "(Recommended)" on the smaller option out
  of habit, not analysis.
- Accepting a subagent report's headline count ("Filed 5 issues, all P1s") without
  reading its body to check what got dropped and why.
- Treating "reasonable" or "sensible" as neutral scoping words. On Tawa they are
  warning signs; both encode the very bias this convention exists to remove.
- Splitting scope with an implicit deferral — "I'll do the rest next time" — that
  never gets filed anywhere durable. If it isn't in an issue, it isn't split; it
  was dropped.

## Related

- [tawa-definition-of-done](definition-of-done.md) — the merge gate that catches the
  incomplete state this bias creates.
- [Working with AI coding agents](agent-quality-practices.md) — the full list of
  failure modes; scope cutting is #9.
- [tawa-agile-workflow](agile-workflow.md) — issues first, so a deferred item has
  somewhere durable to live.

Install

Copy the skill content and save it to:

~/.claude/rules/tawa-no-scope-cutting.md

Details

Format

Rule

Category

configure

Version

1.0.31454

Tokens

~1,574

Updated

2026-10-13