Suggestion: add "verify existing state before coding a fix" discipline to planning phase

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Suggestion to improve Claude Code's pre-implementation planning process by adding a "verify existing state before coding a fix" discipline. This would prevent "fixes that fix nothing" and improve user trust in deliveries.

Context

I've been using Claude Code intensively for ~2 months on a personal financial dashboard project ("Pulse"), with a trio workflow:

• Human user (decision maker)
• Claude.ai web (methodology + long-term project memory)
• Claude Code (technical execution)

The setup has been very productive overall — this report is meant to contribute to continuous improvement, not to flag a bug.

Concrete case that motivated this feedback

During Phase 2 of a feature brief (correlation matrix for portfolio), Claude Code delivered a module price_backfill.py intended to fill price_usd IS NULL entries in a SQLite table score_snapshots, using Yahoo Finance (stocks) and CoinGecko (crypto, 30 days).

After delivery and post-implementation SQL verification:

| Metric | Value |
|---|---|
| Days of data in score_snapshots | 2 |
| Snapshots with NULL price | 0 |
| Pairs with 60+ common days | 0 |

The backfill module executes but does literally nothing because it only fills existing NULL rows — and there were zero NULLs to fill. A trivial preliminary SQL query (SELECT COUNT(*) WHERE price_usd IS NULL) would have caught this immediately.

It's not a serious problem (the module remains useful for the future if assets are added with missing prices), but the effort was miscalibrated. A user with less SQL knowledge might not have caught it at all.

Suggested improvement

Integrate a "verify the existing state" step into Claude Code's planning process whenever a feature depends on the current state of data. Three discipline questions to ask before coding:

1. Before coding: Does the problem I'm about to solve actually exist in the current data state? (Preliminary SQL query or exploration)
2. During coding: Is my solution addressing the root cause or just the symptoms?
3. After coding: How will I verify that my solution has actually changed something?

This is the discipline of an experienced senior developer. Embedding it into Claude Code's default planning approach would reduce "fixes that fix nothing" and increase user confidence in deliveries.

Why this matters for autonomous coding

The more autonomous Claude Code becomes, the more critical this verification discipline gets. In a manual review workflow, a senior developer would catch "this backfill won't do anything" before merging. In an agentic workflow where the user trusts the agent's output, this kind of unverified assumption can accumulate over months without detection.

Possible implementation paths

• Prompt-level guidance: include this discipline in the default system behavior, particularly for tasks tagged as "fix", "migrate", "backfill", "cleanup"
• Workflow nudge: when a task description implies acting on existing data ("fill the NULLs", "remove duplicates", "migrate old entries"), prompt Claude Code to run a verification query first and report findings before proposing an implementation
• Self-check at delivery: encourage a "did this actually change anything?" post-implementation check, with quantified results in the delivery report (e.g., "filled X NULL rows out of Y existing")

Severity

Not a blocker. Just a continuous improvement opportunity reported by an intensive user.

Thanks for reading — and for the great work on Claude Code overall.

Proposed Solution

see up

Alternative Solutions

see up

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

_No response_

Additional Context

_No response_