# Planner Anti-Patterns and Specificity Examples
> Reference file for gsd-planner agent. Loaded on-demand via `@` reference.
> For sub-200K context windows, this content is stripped from the agent prompt and available here for on-demand loading.
## Checkpoint Anti-Patterns
### Bad — Asking human to automate
```xml
Deploy to Vercel
Visit vercel.com, import repo, click deploy...
```
**Why bad:** Vercel has a CLI. Claude should run `vercel --yes`. Never ask the user to do what Claude can automate via CLI/API.
### Bad — Too many checkpoints
```xml
Create schema
Check schema
Create API
Check API
```
**Why bad:** Verification fatigue. Users should not be asked to verify every small step. Combine into one checkpoint at the end of meaningful work.
### Good — Single verification checkpoint
```xml
Create schema
Create API
Create UI
Complete auth flow (schema + API + UI)
Test full flow: register, login, access protected page
```
### Bad — Mixing checkpoints with implementation
A plan should not interleave multiple checkpoint types with implementation tasks. Checkpoints belong at natural verification boundaries, not scattered throughout.
## Specificity Examples
| TOO VAGUE | JUST RIGHT |
|-----------|------------|
| "Add authentication" | "Add JWT auth with refresh rotation using jose library, store in httpOnly cookie, 15min access / 7day refresh" |
| "Create the API" | "Create POST /api/projects endpoint accepting {name, description}, validates name length 3-50 chars, returns 201 with project object" |
| "Style the dashboard" | "Add Tailwind classes to Dashboard.tsx: grid layout (3 cols on lg, 1 on mobile), card shadows, hover states on action buttons" |
| "Handle errors" | "Wrap API calls in try/catch, return {error: string} on 4xx/5xx, show toast via sonner on client" |
| "Set up the database" | "Add User and Project models to schema.prisma with UUID ids, email unique constraint, createdAt/updatedAt timestamps, run prisma db push" |
**Specificity test:** Could a different Claude instance execute the task without asking clarifying questions? If not, add more detail.
## Context Section Anti-Patterns
### Bad — Reflexive SUMMARY chaining
```markdown
@.planning/phases/01-foundation/01-01-SUMMARY.md
@.planning/phases/01-foundation/01-02-SUMMARY.md
@.planning/phases/01-foundation/01-03-SUMMARY.md
```
**Why bad:** Plans are often independent. Reflexive chaining (02 refs 01, 03 refs 02...) wastes context. Only reference prior SUMMARY files when the plan genuinely uses types/exports from that prior plan or a decision from it affects the current plan.
### Good — Selective context
```markdown
@.planning/PROJECT.md
@.planning/STATE.md
@.planning/phases/01-foundation/01-01-SUMMARY.md
```
## Scope Reduction Anti-Patterns
**Prohibited language in task actions:**
- "v1", "v2", "simplified version", "static for now", "hardcoded for now"
- "future enhancement", "placeholder", "basic version", "minimal implementation"
- "will be wired later", "dynamic in future phase", "skip for now"
If a decision from CONTEXT.md says "display cost calculated from billing table in impulses", the plan must deliver exactly that. Not "static label /min" as a "v1". If the phase is too complex, recommend a phase split instead of silently reducing scope.
## Comment-Text Discipline (HARD GATE)
> Enforced at plan-write time by `verify.plan-structure` (the `validate_plan` step). Issue #429.
When an `` or `` block uses a **negative grep** — `grep -c 'LITERAL' file == 0`, meaning "this literal must NOT appear in the file" — that same `LITERAL` must not appear verbatim anywhere in an `` body. Verbatim code blocks, JSDoc samples, head-comment references, and "what NOT to do" illustrations get echoed into the file the executor writes, so the executor's commit-time gate fails on the *comment text*, not on a real code regression. The work is correct; the gate output is semantically wrong; the executor wastes cycles and learns to distrust the gate.
**The gate:** plan creation FAILS (error, `valid: false`) when a confidently-extracted (quoted) negative-grep literal also appears in an `` block. When the grep literal is unquoted and cannot be extracted unambiguously, the gate WARNS instead of failing (so you still get the plan, with the risk surfaced).
### Bad — JSDoc sample echoes the forbidden literal
```xml
Add a `?from=` query param to the share link. Do NOT reintroduce the old
`?from=` referrer hack the JSDoc warned about.
grep -c '?from=' src/animal-detail.tsx == 0
```
### Good — rephrase the comment by concept
```xml
Add the share-link query param. Do NOT reintroduce the legacy referrer hack.
grep -c '?from=' src/animal-detail.tsx == 0
```
### Allowlist escape hatch
When the literal MUST appear in the plan body verbatim — e.g. the plan documents the test file that exercises the gate itself, or the literal is part of the verification command's own grep regex — add a marker on its own line so the gate skips that literal:
```
```
One marker per literal. The marker exempts only the exact literal it names.
## Region-Scoped Negative Gates
> Surfaced at plan-write time by `verify.plan-structure` (the `validate_plan` step), WARN-level. Issue #968.
A **negative grep** — `! grep -Eq 'PAT' file` or `grep -c 'PAT' file == 0` — asserts a construct is absent. `grep` is file-scoped by nature: it has no notion of function or region. This breaks down when a phase splits one file across parallel tasks with legitimately opposite needs for the same construct in different regions:
- **Task A** bans the construct file-wide — a synchronous factory must not block on a refresh: `! grep -Eq 'await .*refresh' app/page.py`.
- **Task B** legitimately requires it elsewhere in the same file — a post-reindex handler must `await bridge.refresh()` to repopulate state.
Both occurrences are real, correct production code in different functions of one file. A file-wide negative grep cannot say "absent in function X, present in function Y", so the two gates are mutually unsatisfiable with a direct call — the executor is pushed into an indirection whose only purpose is to relocate the matched string out of the file (pure gate-appeasement, zero behaviour change). This is distinct from Comment-Text Discipline (#429): there is no comment echo and no allowlist helps — the construct must genuinely be present in one region and absent in another.
**The fix:** region-scope the negative gate so "absent in region X" stops implying "absent file-wide."
### Bad — file-wide ban unsatisfiable against a sibling's real code
```xml
! grep -Eq 'await .*refresh' app/page.py
Add a post-reindex handler in app/page.py that awaits bridge.refresh().
app/page.py
```
Task B writing `await bridge.refresh()` trips Task A's file-wide gate, though both are correct.
### Good — scope the gate to the factory region
```xml
! awk '/^def make_page/,/^def /' app/page.py | grep -Eq 'await .*refresh'
! sed -n '12,40p' app/page.py | grep -Eq 'await .*refresh'
```
The factory region is asserted clean; the reindex handler elsewhere in the same file keeps its required `await bridge.refresh()`. Both gates pass with no code restructuring. Prefer an AST/structural check or a focused unit test where region extraction is fragile.
### When the split is intentional and unavoidable
If region-scoping is genuinely impractical and the file split is intentional, suppress the warning with a marker naming the pattern:
```
```
One marker per pattern. The marker exempts only the exact pattern it names. Prefer region-scoping over suppression.
## CLI Output Format Anchor Mismatch (#1478)
`pnpm ls vite | grep -E '^vite@7\.'` looks correct but silently fails. `pnpm ls` uses tree characters as line prefixes:
```
my-project@1.0.0
└── vite@7.3.5
```
Lines begin with `└──`, not `vite`. The `^` anchor matches line start, which is a tree character — the grep finds nothing.
**Bad:** `pnpm ls vite | grep -E '^vite@7\.'`
**Good:** `pnpm ls vite | grep -E 'vite@7\.'`
**Good (strict):** `pnpm ls vite | grep -E '(└|├)── vite@7\.'`
Same trap: `npm ls`, `yarn list`, `docker ps` column output, `kubectl get` table output.
## Fabricated Numeric Baselines (#1478)
Never emit `grep '714 tests'` or `grep '52 test files'` unless you ran the count command in this session. Model-recalled counts are stale from training.
**Bad:** `npm test 2>&1 | grep '714 passed'`
**Good:** `npm test 2>&1 | grep -E '[0-9]+ passed'` or just `npm test`
## Error-Suppressing Fallbacks in Verify Gates (#1479)
`2>/dev/null || echo "0"` in an assignment that feeds a comparison converts any failure into a passing gate that measures nothing.
**Bad — both sides default to "0" when files are missing:**
```bash
EN_KEYS=$(jq 'keys | length' i18n/en.json 2>/dev/null || echo "0")
DE_KEYS=$(jq 'keys | length' i18n/de.json 2>/dev/null || echo "0")
[ "$EN_KEYS" = "$DE_KEYS" ] && echo "ok"
```
If files don't exist (wrong path, etc.), both sides become `"0"`. Comparison passes. Gate certifies parity while measuring nothing.
**Good — let failure propagate:**
```bash
EN_KEYS=$(jq 'keys | length' src/i18n/en.json)
DE_KEYS=$(jq 'keys | length' src/i18n/de.json)
[ "$EN_KEYS" = "$DE_KEYS" ] && echo "ok"
```
**Good — explicit guard:**
```bash
test -f src/i18n/en.json && test -f src/i18n/de.json || { echo "missing input files"; exit 1; }
```
**When `|| echo "default"` is acceptable:** only when absence is semantically the default AND the result is NOT used in a comparison that should detect absence.