Minimal Change Engineer

Produces minimum-viable diffs that fix only the stated task without scope creep.

2|Updated May 21, 2026
One-click install
npx skills add https://github.com/tcvdog/agency-agents-hermes --skill minimal-change-engineer-tcvdog
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Minimal Change Engineer
Source: https://github.com/tcvdog/agency-agents-hermes/tree/main/engineering/minimal-change-engineer
Command: npx skills add https://github.com/tcvdog/agency-agents-hermes --skill minimal-change-engineer-tcvdog

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Bug fixes and small features routinely balloon into large, risky pull requests because engineers and AI coding tools over-produce by default, adding unrequested refactors, abstractions, and defensive code that slow reviews and introduce regressions. ## Core Features & Use Cases - Minimum-diff discipline: Every changed line must be justified as explicitly required by the task, keeping bug fixes to one or two files. - Scope creep refusal: Rejects "while I'm here" edits, premature abstractions, defensive code for impossible cases, and backwards-compatibility shims for dead code. - Scope self-check template: A pre-PR checklist that lists touched files with reasons, rejected abstractions, and follow-ups noted but not done. - Use Case: When asked to fix an off-by-one error in a pagination function, it changes exactly one line instead of renaming variables, adding validation, and rewriting the function across 47 lines. ## Quick Start Ask the agent to fix a specific bug or add a small feature and request the smallest possible diff with a line-by-line scope justification.

Frequently Asked Questions about Minimal Change Engineer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep bug fix PRs small and reviewable?▼

Change only the lines the task explicitly requires and justify each changed line before submitting. List any other issues you notice as separate follow-up items rather than including them in the same pull request.

When should I extract a helper function from duplicated code?▼

Wait until the fourth occurrence of similar code before extracting a helper. Three similar lines are acceptable and preferable to a premature abstraction that adds indirection without a proven second caller.

Should I add error handling for edge cases in a bug fix?▼

Only validate at system boundaries such as user input and external APIs. Do not add defensive checks for cases that cannot happen given internal invariants and framework guarantees, as they add untested code paths.

What should I do when a reviewer asks for extra changes in review?▼

Politely decline scope expansion during review and open a follow-up issue instead. Accepting "while you're here" requests in review is how clean, small PRs become messy and hard to verify.

When is a minimal-change approach not appropriate?▼

When the task is genuinely larger than stated, such as a symptom indicating a broken root cause, ask the user to explicitly expand the scope first. Restraint applies to unrequested changes, not to confirmed larger tasks.