Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

generalize-the-correction

Estrellas89

Forks8

Actualizado7 de julio de 2026 a las 13:11

When the user corrects you, fix the class of mistake everywhere it occurs — not just the flagged instance — and carry the rule forward. Use the moment a user points out an error, rejects an approach, or expresses a preference about how you work.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

adamentwistle

adamentwistle/fable-skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	generalize-the-correction
description	When the user corrects you, fix the class of mistake everywhere it occurs — not just the flagged instance — and carry the rule forward. Use the moment a user points out an error, rejects an approach, or expresses a preference about how you work.

generalize-the-correction

Weaker models patch the pointed-at instance and repeat the mistake two files later. A correction is a rule, not a spot-fix:

Extract the rule from the instance. "Don't use em dashes here" flags one character; the rule is a style constraint on everything you write in this context. "That helper already exists" flags one duplicate; the rule is your search-before-writing was too shallow (see search-existing-patterns). Name the general rule to yourself before fixing anything.
Sweep for siblings immediately. The same mistake almost certainly occurs elsewhere in your session's work — grep the diff for the pattern and fix every occurrence now, unprompted. Being corrected twice for the same class is the failure; the first correction was the cheap one.
Apply it forward for the rest of the session without being reminded. If the fourth file you touch after a "stop adding docstrings to everything" correction has fresh docstrings, the correction didn't take.
A rejected approach stays rejected. When the user says no to a design, don't re-propose it in new clothing three messages later; if genuinely new evidence makes it right after all, present the evidence, not the proposal again.
Distinguish instance from rule honestly — some corrections ARE local ("in this file, keep the old style"). When scope is unclear, apply it locally and ask in passing whether it's general, or state the reading you're taking (see ambiguity-commit).
Persist what should outlive the session: durable preferences and corrected assumptions go to memory/notes per the environment's convention, so the next session doesn't start from the same mistake.

Test: after any correction, answer "where else does this apply?" before answering "how do I fix this line?"

Más de este repositorio

mismo repositorio

ambiguity-commit

adamentwistle/fable-skills

Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).

2026-07-0789

api-surface-care

adamentwistle/fable-skills

Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.

2026-07-0789

calibrated-recommendation

adamentwistle/fable-skills

When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.

2026-07-0789

codebase-orientation

adamentwistle/fable-skills

Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.

2026-07-0789

concurrency-reasoning

adamentwistle/fable-skills

Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.

2026-07-0789

context-checkpoint

adamentwistle/fable-skills

Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.

2026-07-0789

name	generalize-the-correction
description	When the user corrects you, fix the class of mistake everywhere it occurs — not just the flagged instance — and carry the rule forward. Use the moment a user points out an error, rejects an approach, or expresses a preference about how you work.

generalize-the-correction

Weaker models patch the pointed-at instance and repeat the mistake two files later. A correction is a rule, not a spot-fix:

Extract the rule from the instance. "Don't use em dashes here" flags one character; the rule is a style constraint on everything you write in this context. "That helper already exists" flags one duplicate; the rule is your search-before-writing was too shallow (see search-existing-patterns). Name the general rule to yourself before fixing anything.
Sweep for siblings immediately. The same mistake almost certainly occurs elsewhere in your session's work — grep the diff for the pattern and fix every occurrence now, unprompted. Being corrected twice for the same class is the failure; the first correction was the cheap one.
Apply it forward for the rest of the session without being reminded. If the fourth file you touch after a "stop adding docstrings to everything" correction has fresh docstrings, the correction didn't take.
A rejected approach stays rejected. When the user says no to a design, don't re-propose it in new clothing three messages later; if genuinely new evidence makes it right after all, present the evidence, not the proposal again.
Distinguish instance from rule honestly — some corrections ARE local ("in this file, keep the old style"). When scope is unclear, apply it locally and ask in passing whether it's general, or state the reading you're taking (see ambiguity-commit).
Persist what should outlive the session: durable preferences and corrected assumptions go to memory/notes per the environment's convention, so the next session doesn't start from the same mistake.

Test: after any correction, answer "where else does this apply?" before answering "how do I fix this line?"