How do I install the Principle Generalize From Rejection skill?

Run npx skillmds@latest add edbertchan/principle-generalize-from-rejection in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Principle Generalize From Rejection safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Principle Generalize From Rejection?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Principle Generalize From Rejection free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Principle Generalize From Rejection?

EdbertChan (@edbertchan) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Principle Generalize From Rejection by edbertchan

Name: Principle Generalize From Rejection
Author: EdbertChan

Principle Generalize From Rejection

Apply when a mechanical gate — a lint, validator, blocked-command guard, or CI check — rejects your output for the same reason twice in one session. Fix the generation pattern producing the violation, not just the specific instance.

EdbertChan 690b108 3 files · 4.0 KB Updated Sep 17, 2026

File contents

Generalize from Rejection

When a repo-specific gate rejects you, the lesson is the rule it's enforcing, not the one output that tripped it. Fix the pattern that's generating violations, so the next output doesn't need the same correction.

Why: A rejection with an explanation is free information — the gate already told you what's wrong and often why. Treating each rejection as an isolated retry (change one thing, resubmit, hope) burns turns and tokens re-discovering the same rule against new inputs, when the fix generalizes across all of them.

Pattern:

On the first rejection, read the full message, not just the pass/fail. Most validators explain the rule, not just that it failed.
Before retrying, ask: does this fix apply only to the thing you just submitted, or to how you've been generating this class of output? If the latter, fix the generation step, not just this instance.
If the same class of rejection fires a second time in the same session, stop and generalize explicitly — don't submit a third variation before checking whether the underlying pattern is still present elsewhere in what you're about to submit.
Escalating a fix's parameters (a longer timeout, a different retry count) without changing what's actually being checked is not generalizing — it's the same mistake with a bigger dial.

Battle-tested: a corpus retrospective found this three separate ways in one pass. A PR-body/review-unit validator rejected the same "one review unit per PR" violation 8 times outright plus 33 warnings, across at least 4 different branches in one session — the agent kept drafting multi-unit PR bodies instead of internalizing the rule after the first rejection. A blocked-command guard (long-running sleep calls) fired on the identical command three separate times at different points in the same session. And a disk-usage probe over SSH was retried five times with an escalating timeout (30s → 60s → 45s → 90s → 100s) before the agent finally diagnosed the real cause — degraded disk I/O — instead of continuing to guess at a bigger number.

---name: principle-generalize-from-rejectiondescription: Apply when a mechanical gate — a lint, validator, blocked-command guard, or CI check — rejects your output for the same reason twice in one session. Fix the generation pattern producing the violation, not just the specific instance.---# Generalize from RejectionWhen a repo-specific gate rejects you, the lesson is the rule it's enforcing, not the one output that tripped it. Fix the pattern that's generating violations, so the next output doesn't need the same correction.**Why:** A rejection with an explanation is free information — the gate already told you what's wrong and often why. Treating each rejection as an isolated retry (change one thing, resubmit, hope) burns turns and tokens re-discovering the same rule against new inputs, when the fix generalizes across all of them.**Pattern:**- On the first rejection, read the full message, not just the pass/fail. Most validators explain the rule, not just that it failed.- Before retrying, ask: does this fix apply only to the thing you just submitted, or to how you've been generating this class of output? If the latter, fix the generation step, not just this instance.- If the same class of rejection fires a second time in the same session, stop and generalize explicitly — don't submit a third variation before checking whether the underlying pattern is still present elsewhere in what you're about to submit.- Escalating a fix's *parameters* (a longer timeout, a different retry count) without changing *what's actually being checked* is not generalizing — it's the same mistake with a bigger dial.**Battle-tested:** a corpus retrospective found this three separate ways in one pass. A PR-body/review-unit validator rejected the same "one review unit per PR" violation 8 times outright plus 33 warnings, across at least 4 different branches in one session — the agent kept drafting multi-unit PR bodies instead of internalizing the rule after the first rejection. A blocked-command guard (long-running `sleep` calls) fired on the identical command three separate times at different points in the same session. And a disk-usage probe over SSH was retried five times with an escalating timeout (30s → 60s → 45s → 90s → 100s) before the agent finally diagnosed the real cause — degraded disk I/O — instead of continuing to guess at a bigger number.

Frequently asked questions