generalize-from-cases

# Generalize from cases The request arrived as examples, not as a rule. Recover the rule. Two failures mirror each other: **overfit** treats the example's incidental details as requirements, so the change lands on one instance and stops; **overgeneralize** strips too much, so the change lands where it was never wanted. Both come from skipping the split between what is the point and what is circumstance. This skill edits nothing. The deliverable is a stated rule with a boundary. Whatever applies it runs afterwards, against the rule rather than the examples. ## Case set Collect every example before reading any of them as a rule. - **Positives** — instances the user pointed at approvingly or asked to have repeated. - **Negatives** — anything named as "not that", including an earlier attempt the user rejected. A rejected attempt is the most informative case in the set, because it kills hypotheses no positive can. - **Size** — one positive and no negatives is the common case and the weakest. The hypothesis space is wide and step 4 carries the whole result. State the set size in the output so the reader knows how much evidence stands behind the rule. ## Method 1. **Split each case into features.** List every observable attribute of each case: subject, location, shape, trigger, wording, scale, whatever it exhibits. Attributes, not impressions. "Returns early on nil" is a feature; "is clean" is not. 2. **Mark invariant against incidental.** An attribute present in every posit...