feedback-learning

name feedback-learning description Classify and record explicit corrective feedback without turning skills or instructions into append-only knowledge dumps. Feedback learning Use this skill when a user explicitly corrects an implementation or design approach, rejects a pattern, or asks the agent to learn from feedback, except when the user invokes the literal learn! trigger. Literal learn! requests are governed exclusively by .github/instructions/learnings.instructions.md and are outside this skill's scope. Do not replace or reinterpret that instruction. Goal Preserve reusable knowledge in the smallest authoritative artifact. A correction is not automatically a permanent rule. Workflow Identify the correction What was wrong? Why was it wrong? What approach did the user prefer? Which paths or subsystem does it affect? Search before writing Check applicable instructions, skills, design documents, tests, and scoped learning files. Update an existing rule instead of adding a duplicate. Classify the feedback Feedback kind Destination Task-specific preference or one-off adjustment Do not persist Concrete behavior that must not regress Regression test Stable subsystem architecture or product invariant Relevant design/specification document Universal repository rule Applicable instruction file Reusable but not yet mature or proven guidance .github/learnings/<area>.md Tool-driven workflow Relevant skill Generalize carefully Preserve the principle, not the incident chronology. Do not include temporary symbol names, line numbers, or implementation details unless they define the durable contract. Do not turn a single rejected implementation into a universal prohibition without broader evidence. Record once Design documents and tests are authoritative. A learning inbox entry is temporary. When promoted, remove the inbox entry in the same change. Never copy the same rule into a skill, instruction, and design document. Before adding an inbox entry, compact the target file using the maintenance rules below. Validate Confirm the destination applies to the affected path. Check links and remove superseded or contradictory guidance. Learning inbox format Create or update .github/learnings/<area>.md using: # Area learning inbox Last reviewed: YYYY-MM-DD ## Short topic - **Scope:** `affected/path/**` - **Learning:** Generalized guidance in one or two sentences. - **Evidence:** Why this is reusable beyond the current task. - **Disposition:** Candidate for `<design document, instruction, skill, or test>` . Keep entries concise. Each area inbox is limited to ten topics and 8 KB. If a new entry would exceed either limit, promote, merge, or remove existing entries before deciding whether the new feedback deserves persistence. Reading learnings Do not inject learning inboxes into every task. Search the relevant file's headings and Scope fields first, then read only matching entries. Learning inboxes supplement source code, tests, and design documents; they are not a prerequisite for unrelated work and are not authoritative over them. Compaction and garbage collection Compact an inbox before every write. Also perform a full review when an inbox is at either limit or its Last reviewed date is more than 90 days old when read. During review: promote stable architectural guidance into the owning specification; encode concrete behavior in tests; merge overlapping entries into one general principle; remove obsolete, contradicted, already-promoted, or weakly supported entries; update Last reviewed after checking every retained entry against the current source and authoritative documentation. An inbox may shrink to zero entries. Do not retain a learning merely because it might be useful someday.