principle-encode-lessons-in-structure
cursor/plugins
Encode recurring corrections as lint rules, metadata flags, and runtime checks instead of repeating instructions.
What is principle-encode-lessons-in-structure?
This principle guides you to capture recurring fixes and errors as structural mechanisms—lint rules, metadata flags, runtime checks, or automation scripts—rather than textual instructions. Apply it when you notice yourself writing the same instruction twice or making the same correction repeatedly.
- Identify recurring corrections and errors as learning signals
- Convert textual instructions into structural enforcement mechanisms (lint rules, metadata flags, runtime checks, scripts)
- Route fixes to the appropriate layer: one-off issues to notes, recurring patterns to rules, systemic issues to principles
- Close feedback loops by implementing structural fixes rather than just documenting them
- Prioritize stronger mechanisms (compile-time checks over runtime checks over documentation) to ensure compliance
How to install principle-encode-lessons-in-structure
npx skills add https://github.com/cursor/plugins --skill principle-encode-lessons-in-structureHow to use principle-encode-lessons-in-structure
- 1.When you catch yourself writing the same instruction or correction a second time, pause and ask: can this be a lint rule, metadata flag, runtime check, or script?
- 2.If yes, encode the rule into the appropriate mechanism and remove the textual instruction
- 3.If no (requires judgment), make the instruction more prominent and document the failure mode with an example
- 4.Prioritize stronger mechanisms: unrepresentable states that fail to compile, then lint/CI failures, then canonical helpers, then runtime checks
- 5.Capture every correction from human feedback or test failures and decide if it's a one-off or a recurring pattern
- 6.Route the fix to the right layer and implement it, closing the loop rather than just documenting it
Use cases
- You've written the same code review comment three times; encode it as a lint rule or banned API check
- A test repeatedly fails for the same reason; add a runtime validation or metadata constraint to prevent the issue
- Team members keep making the same mistake in a particular file type; create a metadata flag or helper function that enforces the correct pattern
- You notice a recurring pattern in corrections during code review; implement an automated check in CI instead of relying on human review
- Software engineers and architects designing systems with repeatable patterns
- Teams managing code quality and consistency across projects
- Developers building linters, automation scripts, or validation frameworks
- Anyone working with agents or code generation who wants to enforce learned rules automatically
principle-encode-lessons-in-structure FAQ
Encode it structurally if it's recurring or critical. Use textual instructions only for one-off guidance or when structural enforcement is impossible. If you find yourself writing the same instruction twice, it's time to encode it.
Lint rules and compile-time checks are strongest (fail before code runs). Metadata flags guide behavior without code changes. Runtime checks validate at execution time. Scripts automate repetitive tasks. Choose the strongest mechanism your situation allows.
If it happens once, it's a one-off—make a brain note. If you catch yourself correcting it a second time or see it in multiple places, it's a pattern—encode it structurally.
Acknowledging a problem without recording it ('I'll keep that in mind'), recording it without implementing a fix, or fixing one instance while leaving the recurring pattern intact. Always close the loop by implementing the structural fix.
Agents copy patterns from surrounding code. A structural mechanism (lint rule, runtime check, metadata constraint) is more reliable than textual instructions because it enforces the rule automatically without requiring the agent to read and remember instructions.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-encode-lessons-in-structure description: "Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text." disable-model-invocation: true
Encode Lessons in Structure
Encode recurring fixes in mechanisms (tools, code, metadata, automation) instead of textual instructions. Every error, human correction, and unexpected outcome is a learning signal. Capture it, route it, and close the loop.
Why: Textual instructions are easy to miss. They require the reader to notice, remember, and comply. Structural mechanisms (lint rules, metadata flags, runtime checks, automation scripts) enforce the rule without cooperation.
Pattern: When you catch yourself writing the same instruction a second time:
- Ask: can this be a lint rule, a metadata flag, a runtime check, or a script?
- If yes, encode it. Delete the instruction
- If no (requires judgment), make the instruction more prominent and add an example of the failure mode
Pick the strongest mechanism. When more than one mechanism would work, choose the strongest the situation allows (an unrepresentable state that cannot compile, then a lint or banned API that fails CI, then a canonical helper, then a runtime check), because agents copy whatever the surrounding code already does and a weaker guard becomes the next template.
Corollary: If the fix is structural, only use the structural fix. The instruction is the symptom.
Feedback loop:
- Capture every correction. When the human intervenes or tests fail, decide if it's a one-off or a pattern.
- Route to the right layer. One-off -> brain note. Recurring fix -> skill or lint rule. Systemic issue -> principle.
- Close the loop. Don't just record. Apply now or create a concrete todo.
Anti-patterns:
- Acknowledging without recording ("I'll keep that in mind" does not persist)
- Recording without routing (a brain note about a lint rule that should exist is wasted unless the lint rule gets implemented)
- Fixing without generalizing (fixing one instance while leaving the recurring pattern intact)
Related skills
More from cursor/plugins and the wider catalog.
principle-exhaust-the-design-space
Explore 2-3 competing prototypes before committing to novel UI or architectural decisions.
principle-experience-first
Prioritize user delight over implementation convenience—ship fewer polished features instead of many rough ones.
principle-fix-root-causes
Trace bugs to root causes instead of patching symptoms during debugging.
principle-foundational-thinking
Design data structures and core types before writing logic to make downstream code obvious.
principle-guard-the-context-window
Manage finite context by routing bulk data to subagents and keeping summaries in the main thread.
principle-laziness-protocol
Bias toward deletion and minimal changes—apply when refactoring, evaluating diffs, or tempted by abstractions.