What 370 Files Reveal About
How You Plan

backnotprop/plannotator · Jan 7 – Mar 18, 2026
202 denials · 168 annotations · 71 days
1. The story in the data
Across 71 days you denied or revised 202 plans before any code was written. The single most common reason—appearing in 1 out of 4 denials—was the same: the agent jumped to implementation without telling you what it was building, why, or how. Missing narrative. Missing context. Missing the story. Your expectations evolved from “does it work?” in January to “tell me the story and be confident” by March.
25.7%
Denials for missing narrative
50%
Plans revised before coding
12
Distinct denial categories
2. Why plans get denied
1
Missing Narrative / Overview
"This plan is denied without narrative detail and rationales."
25.7%
2
Clarification Needed
"What does this Mean???"
16.8%
3
Testing / Procedural
"I'm denying so you can create a diff."
13.9%
4
Wrong Approach / Over-Engineered
"Why are we doing difficult shit here? I want a hover experience."
9.4%
5
Process Requirement
"Make sure you feature branch."
7.9%
6
Confidence / Risk Check
"Take a step back, breathe, make sure we're not being irrational."
7.4%
7
Content Removal
"I don't want this in the plan."
6.9%
8
Implementation Bug Found
5.9%
9
Design / UX Issue
5.4%
10
Naming / Terminology
"Why do you keep calling it Simplified????"
4.0%
3. How your expectations evolved
January
"Does it work?"
Bug-hunting phase. You were hands-on testing View Logs, iterating on session scoping heuristics. 60% of denials were implementation bugs and verification failures. No mention of “narrative” or “overview” yet.
26 denials · 0 narrative requests
February
"Follow the process"
Process gates emerged: feature branches, Linear tickets, pull main. 40% of denials were procedural (diff testing). UX polish intensified. The first narrative demands appeared: “I want a narrative under each section.”
48 denials · 6 narrative requests
March
"Tell me the story"
Narrative became the #1 gate. You created a “Missing overview” label and applied it systematically. Confidence checks became standard. You began telling agents to “take a step back, breathe, and analyze.”
128 denials · 25+ narrative requests
4. What works vs. what doesn't
✓
What approved plans do
  • Lead with a narrative overview: what exists, what changes, why
  • State confidence and identify risks proactively
  • Reference existing codebase patterns before proposing new code
  • Use explicit, transparent naming (not euphemisms)
  • Break large work into phases with evaluation gates
  • Include example output for user-facing changes
  • Specify feature branch and ticket creation steps
✗
What agents keep getting wrong
  • Jump to implementation steps without narrative context
  • Over-engineer: Shift+Click when hover works, MCP tool when a README suffices
  • Introduce new code for things the codebase already solves
  • Propose work on top of failing lint/type checks
  • Use vague or euphemistic naming (“Accept” instead of “Git Add”)
  • Wait to be asked for confidence instead of stating it
  • Rush to modify instead of reporting what they see
5. The actionable output
The analysis produced 17 specific prompt instructions that, if embedded in a planning prompt, would address ~70% of all denial reasons. The biggest three:
1
Every plan MUST start with a Solution Overview
What exists, what changes, why, how. This alone addresses 1 in 4 denials.
2
End every plan with a Confidence Assessment
Don’t wait to be asked. State your confidence, identify risks, flag uncertainties.
3
Search for existing patterns before proposing new code
Explicitly state what you found in the codebase. Prefer reuse over new implementation.
6. Your most-used phrases
"narrative"50+
"I don't want this in the plan"10
"feature branch"8+
"confidence"8+
"Missing overview"14
"front-end design skill"16
"separation of concerns"6
"Take a step back, breathe"6
"how does this work"5+
"what the fuck"4
"create a ticket"4+
"reusable"19+
7. The corrective prompt
These 17 instructions were extracted directly from your denial patterns. Embedding them in a planning prompt would address approximately 70% of all denial reasons.
planning-instructions.md 
# Planning Instructions
# Derived from 370 files of denial & annotation analysis

1. STRUCTURE: Every plan MUST begin with a "Solution Overview"
   containing 2-3 paragraphs of narrative prose explaining:
   - What exists today (current state)
   - What will change and why
   - How it will be built (approach summary)
   Do NOT skip this. Do NOT replace it with bullet points.

2. NARRATIVE: Every major section must include a rationale
   paragraph — not just what will be done, but WHY this
   approach was chosen over alternatives.

3. FEATURE BRANCH: Always specify implementation will occur
   on a feature branch. State the branch name. Never plan
   to work directly on main.

4. EXISTING PATTERNS: Before proposing any new implementation,
   search the codebase for existing patterns that solve the
   same problem. Explicitly state what you found and whether
   you will reuse it. Prefer reuse over new code.

5. CONFIDENCE STATEMENT: End the plan with a "Confidence
   Assessment" section. State your confidence level, identify
   risks or edge cases, and note uncertainties. Do not wait
   to be asked.

6. PHASING: For plans with more than 3 steps, break them into
   numbered phases. After each phase, note "Pause for
   evaluation" so the reviewer can assess before proceeding.

7. ISSUE TRACKING: If the project uses Linear or GitHub Issues,
   include a step to create relevant tickets BEFORE
   implementation. Backlog items should be separate tickets.

8. SIMPLICITY: Choose the simplest approach that meets
   requirements. Do not introduce modifier keys when hover
   works. Do not build a framework when a README suffices.

9. NAMING: Use explicit, transparent names for user-facing
   features. Do not euphemize Git operations ("Git Add"
   not "Accept"). Match existing product naming conventions.

10. CODE QUALITY: State that implementation will follow clean
    code principles: modular architecture, separation of
    concerns, no circumventing lint or type checks.

11. CLEAN FOUNDATION: If the codebase has failing lint or type
    checks, address these BEFORE proposing new features. State
    the current CI/CD state.

12. PRIVACY: For features involving data storage or sharing,
    explicitly state privacy guarantees. Require user
    confirmation before storing data.

13. EXAMPLES: When the plan involves user-facing output or UI,
    include an example of what it will look like.

14. FOCUSED SCOPE: Do not include sections that are obvious,
    boilerplate, or previously asked to be removed. Keep the
    plan focused rather than comprehensive.

15. DESIGN SKILL: For any frontend/UI work, invoke the
    front-end design skill to validate the approach. Note
    this invocation explicitly in the plan.

16. VERIFICATION STEP: For refactors or multi-file changes,
    include a verification step with line-by-line comparison
    of affected code paths.

17. DELIBERATION: If the plan involves a dramatic shift, state
    that you have re-evaluated the approach, traced through
    affected files mentally, and are confident in the plan.
    Do not rush.
These instructions are yours — derived from your feedback, your language, your standards. Copy them into your planning prompt and watch the deny rate drop.