mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-13 04:26:28 +03:00
Magnus HedemarkandGitHub
1037324c2a
* feat: add programming-principles skill (14 classic software books) - SKILL.md v0.2.0 with cross-cutting principles, task-to-book mapping, and code-assessment workflow - 29 reference files (14 mini + 14 full + assessment methodology) - Agent-agnostic frontmatter (compatibility field, no Hermes-specific metadata) - Wire neckbeard routing table: code review/refactoring/quality assessment - Regenerate Claude marketplace + Codex plugin manifests (97 skills) Source: magnus919/programming-principles (standalone repo, v0.1.1). Local copy was v0.2.0 with code-assessment-workflow.md not yet upstreamed. Standalone repo will be archived with redirect after merge. * fix: satisfy validator — frontmatter fields, skill README, catalog entry - Strip version/author/source from frontmatter (unsupported fields) - Move source attribution into metadata (string-to-string map) - Add programming-principles/README.md with required headings - Add catalog entry to root README.md (alphabetical position) Validator passes locally: 107 canonical skills.
2.3 KiB
2.3 KiB
OBEY Refactoring.Guru
When to use
Use when changing existing code where code smells, refactoring technique choice, behavior preservation, and cleanup scope control matter.
Primary bias to correct
Refactoring is not general cleanup or pattern application. It is a small, smell-driven, behavior-preserving treatment with verification and a stop condition.
Decision rules
- Separate refactoring from feature work and bug fixes.
- Diagnose the smell before choosing a technique: symptom, maintenance cost, expected end state, verification path.
- Prefer the smallest treatment that directly reduces the diagnosed smell.
- Keep code runnable and understandable through small named transformations.
- Stop when the named smell is gone or materially reduced.
- Use the Rule of Three: tolerate uncertain duplication early, refactor the third similar occurrence.
- For bloaters, prefer extraction and responsibility splits before creating method objects or subclasses.
- For switch/type-code smells, isolate the decision first; use polymorphism only when variation is stable.
- For change preventers, move behavior and data toward the owner of the changing concept.
- For dispensables, delete or inline unused structure. Check public/generated/reflected uses first.
- For couplers, reduce navigation and private knowledge. Keep delegating layers only when they hide volatile structure.
- Encapsulation is not finished by adding getters and setters. Move behavior inward.
- Avoid speculative abstractions: do not create wrappers, interfaces, or hierarchy variants without a real concept.
Trigger rules
- When a method needs comments or scrolling to understand, try Extract Method.
- When a class has multiple reasons to change, use Extract Class.
- When primitives carry meaning, model the concept if it adds naming, validation, or behavior.
- When a parameter list grows, introduce a parameter object only for a real recurring concept.
- When a class mostly forwards, remove the middle man unless it protects boundary policy.
- When null checks dominate, introduce a null object only if absence obeys the same interface.
Final checklist
- Is this clearly refactoring, feature work, or bug fixing?
- Was the smallest suitable treatment used?
- Did the named smell become materially better?