Works on the example, breaks on the edges
示例能跑，边界就崩
The agent implements what passes the example and stops. Empty input, null, boundaries and failure paths are not handled.
Applies to: Claude Code · Cursor · Codex · Copilot agent
Symptom
Crashes on an empty list, a missing file, invalid JSON, or the first or last element. The demo worked.
Why it happens
"Agents focus on the happy path. They implement what passes the example, then stop." (agent-review). It lists AR029 (missing edge case) and AR030 (unhandled error path).
Example
From the agent-review taxonomy (AR029, AR030).
tsfunction median(xs: number[]): number {
return xs[xs.length / 2 | 0]; // empty? even-length? unsorted?
}
const cfg = JSON.parse(fs.readFileSync("cfg.json", "utf8"));
// throws if file missing or JSON invalid
Copy-paste fixes
Pick the files for the agents you use. Snippets are in English so they work in any repo.
Claude Code: add to CLAUDE.md
CLAUDE.md## Edge cases are part of the task
- For every function you write or change, list its edge cases (empty, null/undefined, zero,
boundary values, very large input, invalid format, I/O failure) and either handle each or say why it can't happen.
- Add at least one test for an edge case and one for a failure path, not only the happy path.
- Every new network, file or parse call needs an explicit failure behavior.
Codex, Copilot coding agent and others: add to AGENTS.md
AGENTS.md## Edge cases are part of the task
- For every function you write or change, list its edge cases (empty, null/undefined, zero,
boundary values, very large input, invalid format, I/O failure) and either handle each or say why it can't happen.
- Add at least one test for an edge case and one for a failure path, not only the happy path.
- Every new network, file or parse call needs an explicit failure behavior.
Cursor: project rule
.cursor/rules/happy-path-only.mdc---
description: "AgentFails: Works on the example, breaks on the edges"
alwaysApply: true
---
## Edge cases are part of the task
- For every function you write or change, list its edge cases (empty, null/undefined, zero,
boundary values, very large input, invalid format, I/O failure) and either handle each or say why it can't happen.
- Add at least one test for an edge case and one for a failure path, not only the happy path.
- Every new network, file or parse call needs an explicit failure behavior.
Fresh-context review skill (subagent reviews the diff, not the chat)
Follows the habit Anthropic describes in its code-review post: verify first, then have a subagent review the diff with fresh context. Named review-diff to avoid clashing with built-in or popular /code-review skills.
.claude/skills/review-diff/SKILL.md---
name: review-diff
description: Review the current diff with fresh context before a PR. Use after /verify passes.
---
# Review the diff
Start a subagent that has NOT seen this conversation. Give it only:
- the original request (one paragraph, verbatim),
- the output of `git diff origin/main...HEAD`,
- the names of the test/build commands.
Ask it to report, with file:line for each finding:
1. **Wrong feature**: does the diff do what the request asked? Quote the request line each change serves.
2. **Bugs**: logic errors, missing edge cases (empty, null, boundary), unhandled errors,
unawaited promises, invented APIs or packages, swallowed exceptions.
3. **Overreach**: changes no request line needs (refactors, renames, formatting, dependency or
config edits, public API changes, weakened tests).
4. **Evidence gaps**: claims in the PR description that no command output supports.
Then fix real findings, or list them under "Known issues" in the PR. Do not argue with the reviewer
in the PR text; either fix or explain in one line.