mirror of https://github.com/magnus919/agent-skills.git synced 2026-09-12 03:56:53 +03:00

Files

T

Magnus HedemarkandGitHub 1037324c2a feat: add programming-principles skill (14 classic software books) (#92 )

* 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.

2026-07-21 17:29:56 -04:00

2.5 KiB

Raw Blame History

OBEY Refactoring by Martin Fowler

When to use

Use when changing existing code, preparing a feature or bug fix, reviewing cleanup, or reducing structural friction without intending to change observable behavior.

Primary bias to correct

Refactoring is behavior-preserving design work in small steps. Do not turn cleanup into a rewrite, a hidden feature change, or speculative architecture.

Decision rules

Preserve observable behavior during refactoring. Isolate behavior changes from structural changes.
Work in small, reversible, buildable, testable, reviewable steps. Split a patch when it is too large to reason about locally.
Establish or identify a safety net before risky refactoring. Use characterization tests for unclear behavior.
Use preparatory and follow-up refactoring around feature work: reshape blocking structure first, make the behavior change, then clean debt.
Refactor the current blocking smell, not every smell in sight: duplication, long functions, long parameter lists, globals, divergent change, shotgun surgery, feature envy, primitive obsession, repeated conditionals, temporary fields, middle men, speculative generality.
Prefer the simplest named move: rename, extract, inline, move, introduce parameter object, encapsulate, decompose conditionals, use guard clauses, substitute algorithm.
Make names and functions reveal intent. Rename before deeper work when bad names block understanding.
Put behavior and state with the concept that owns them. Split classes with multiple reasons to change.
Simplify conditionals honestly. Use polymorphism, state, strategy, or tables only when variation is real and repeated.
Keep patch intent reviewable. Group related refactorings. Avoid giant mixed patches.
Stop when the requested change is easy, the blocking smell is gone, and the next cleanup would be speculative.

Trigger rules

When adding behavior, first ask what structural friction blocks the change.
When fixing a bug in unclear code, characterize the current failure first.
When the same edit appears a third time, remove duplication.
When a function mixes responsibilities, rename, extract, or split.
When one change forces edits across many files, centralize the knowledge.
When tempted to rewrite, choose the next small behavior-preserving transformation.

Final checklist

Observable behavior preserved?
Structural change, behavior change, and test updates separated?
At least one real source of friction removed?
Patch still reviewable and runnable?

2.5 KiB Raw Blame History