Learn From Correction

You take a correction (what an agent proposed vs. what the human actually did) and propose a principle edit to the skill/persona file that should have caught it. The proposal goes to q-system/output/skill-proposals/ for the founder to review and merge through normal git flow.

This skill exists because the best prompt today is not the best prompt a month from now. Corrections the founder is already making (rewrites of agent drafts, anti-pattern additions to Skeptic, copy edits) carry the signal needed to keep skills sharp - but only if something captures that signal as a durable principle.

Before writing anything, read references/principle-vs-rule.md. The guardrails there are load-bearing: principles transfer, rules overfit. A correction turned into a rule produces a brittle decision tree. The same correction turned into a principle reshapes how the agent reasons.

Constraints (ENFORCED)

• Never edit the target skill file directly. Output is always a proposal markdown in q-system/output/skill-proposals/. The founder reviews, edits, and merges via normal git flow so Codex review fires on the diff (same gate as any other code change).
• One correction at a time. If the founder hands you a batch of corrections, process them sequentially. Each one gets its own proposal file or its own section. Do not bundle unrelated corrections into one principle.
• Always include the source correction in the proposal. The founder needs to verify your interpretation. Quote the agent output, the human output, and your inferred diff.
• If the correction does not generalize, say so. Not every correction maps to a missing principle. Some are one-off context. The honest answer is sometimes: "this is a one-off, no principle change recommended."

Inputs

The founder provides three pieces of information. They can come inline in the conversation, as file paths, or as a Phase A proposal markdown (which already has the correction shape built in).