Skip to content

skill: classify by intent first, not by commit/uncommit alone#875

Merged
charankamarapu merged 1 commit into
mainfrom
skill/intent-check-first
Jun 9, 2026
Merged

skill: classify by intent first, not by commit/uncommit alone#875
charankamarapu merged 1 commit into
mainfrom
skill/intent-check-first

Conversation

@charankamarapu

Copy link
Copy Markdown
Contributor

Summary

Replace the "uncommitted edit → Case 1 mandatory" gate with a symmetric intent check that applies to BOTH committed and uncommitted source changes on the failing handler's path.

Why

Validation runs against cursor-agent --print repeatedly misclassified scenarios:

  • Uncommitted regression (S1) — model saw the working-tree edit, framed it as "your source change", and went Case 2b (patch the mock) to "preserve" it. Wrong: the uncommitted edit IS the bug.
  • Committed intentional change (S4 mid-iteration) — model saw the commit message, jumped straight to Case 2b-patch without confirming the change was the intended new contract.

The literal rule was correct, but the two-bucket framing (uncommitted = revert, committed = mock) gave the model a permission gradient that flipped its decision on the wrong axis. It rationalized either way based on commit state instead of intent.

What changes

Before:

Any uncommitted edit touching the failing handler's source → Case 1, mandatory. Revert (or ask the dev); do NOT proceed to commit-history reasoning.

After:

Any code change on the failing handler's path — committed OR uncommitted — check intent FIRST, then classify. Was the change EXPECTED (intentional contract change) or UNEXPECTED (regression)? ...ASK THE DEV in one short question and stop. Once intent is known: expected → Case 2 (fix test data on the branch); unexpected → Case 1 (revert the source change). Never patch a mock to "preserve" an uncommitted edit without confirming intent...

Key shifts:

  • Symmetric treatment of committed + uncommitted
  • Explicit intent question when the diff doesn't decide
  • Bans the "preserve your source change" failure mode by name
  • Frames the asymmetry (revert is cheap; bad mock patch silently ships regressions)

Test plan

  • Synced from the live .cursor/skills/keploy/SKILL.md in the test-12 workspace
  • Verbatim-quote probe confirms the new wording reaches the model's context
  • Re-run S1-S7 against cursor-agent post-merge — expect Case 1 vs Case 2 classification by intent, not commit state

🤖 Generated with Claude Code

@charankamarapu charankamarapu force-pushed the skill/intent-check-first branch from 0436c4a to eb2dfb5 Compare June 9, 2026 10:44
Replace the "uncommitted edit → Case 1 mandatory" gate with a
symmetric intent check that applies to BOTH committed and uncommitted
source changes on the failing handler's path — AND only when the
change could plausibly be causing the failure.

Why: validation runs against cursor-agent --print repeatedly
misclassified scenarios. The two-bucket framing
(uncommitted = revert, committed = mock) gave the model a permission
gradient that flipped its decision on the wrong axis. It rationalized
"preserve your source change" and silently patched the mock for what
was actually a half-finished regression.

The new wording:
  - treats committed and uncommitted symmetrically
  - ties the check to the actual failure (does the diff touch the
    drifted field / SQL / header / status code in the report?)
  - forces an explicit intent question when the diff doesn't decide
  - bans the most common misclassification phrase the model
    produces ("patch a mock to preserve an uncommitted edit")

Mirrored from .cursor/skills/keploy/SKILL.md in the test-12
validation workspace.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Charan Kamarapu <kamarapucharan@gmail.com>
@charankamarapu charankamarapu force-pushed the skill/intent-check-first branch from e910879 to 108c9fb Compare June 9, 2026 10:45
@charankamarapu charankamarapu merged commit 45df405 into main Jun 9, 2026
7 checks passed
@charankamarapu charankamarapu deleted the skill/intent-check-first branch June 9, 2026 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants