How do I install the Implement Change skill?

Run npx skillmds@latest add jbaehne/implement-change in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Implement Change safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Implement Change?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Implement Change free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Implement Change?

jbaehne (@jbaehne) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Implement Change by jbaehne — Agent Skill

Name: Implement Change
Rating: 4.666666666666667 (3 reviews)
Author: jbaehne

Implement Change

Implement an explicitly authorized plan as the smallest coherent change, preserving unrelated work and local conventions. Use when the user asks to implement, apply, or make a specified change. Do not use for planning-only requests, merge approval, commits, pushes, or deploys.

jbaehne Updated Sep 22, 2026

File contents

Implement change

Make the authorized change and nothing beyond it. Implementation is not verification, review, or permission to publish.

Authorization

Proceed only when the user has explicitly asked you to implement. A plan, a review comment, or access to the repo is not authorization.

If repository conventions or the change boundary are unclear, use repository-archaeology before editing. If a written plan exists, follow its in-scope list. If new work appears mid-change, stop and report it instead of absorbing it.

Repository-local instructions override this skill.

While editing

Match local conventions you have actually seen.
Preserve unrelated working-tree changes. Do not revert, reformat, or commit them.
Prefer the smallest coherent change that meets the acceptance criteria.
When behavior changes, update the tests and the authoritative docs that this repository already uses for that behavior. Do not create new doc systems.
When the risk mapping is unclear, use test-design before adding a large test surface.
Do not add dependencies, services, accounts, or credentials unless the authorized scope says so.

After editing

Run the narrowest relevant checks the repository already provides, when that is permitted and practical. Record the exact command and whether it passed, failed, or did not run. An environment failure is not_run or a limitation, not a pass.

Do not commit, push, open a pull or merge request, merge, deploy, or approve the change unless the user explicitly asks for that action in addition to implementation. Even then, do not approve work you just implemented.

Output

## Files changed
- `path` — why it changed

## Behavior changed

## Validation
- `command`: passed — what it verified
- `command`: failed — what failed
- Not run: `command` — reason

## Limitations and unresolved decisions

## Git status
- Paths this change touched
- Unrelated dirty paths left untouched

This implementation is not approval, and it was not committed unless you asked for a commit.

When handing off, record files, behavior, verification, and state.implemented from ../_sdlc/evidence.yaml. Set state.verified only for checks that actually ran and passed for this revision. Leave state.reviewed and state.human_approved false.

Suite boundaries: ../_sdlc/LIFECYCLE.md.

---name: implement-changedescription: Implement an explicitly authorized plan as the smallest coherent change, preserving unrelated work and local conventions. Use when the user asks to implement, apply, or make a specified change. Do not use for planning-only requests, merge approval, commits, pushes, or deploys.---# Implement changeMake the authorized change and nothing beyond it. Implementation is not verification, review, or permission to publish.## AuthorizationProceed only when the user has explicitly asked you to implement. A plan, a review comment, or access to the repo is not authorization.If repository conventions or the change boundary are unclear, use `repository-archaeology` before editing. If a written plan exists, follow its in-scope list. If new work appears mid-change, stop and report it instead of absorbing it.Repository-local instructions override this skill.## While editing- Match local conventions you have actually seen.- Preserve unrelated working-tree changes. Do not revert, reformat, or commit them.- Prefer the smallest coherent change that meets the acceptance criteria.- When behavior changes, update the tests and the authoritative docs that this repository already uses for that behavior. Do not create new doc systems.- When the risk mapping is unclear, use `test-design` before adding a large test surface.- Do not add dependencies, services, accounts, or credentials unless the authorized scope says so.## After editingRun the narrowest relevant checks the repository already provides, when that is permitted and practical. Record the exact command and whether it passed, failed, or did not run. An environment failure is `not_run` or a limitation, not a pass.Do not commit, push, open a pull or merge request, merge, deploy, or approve the change unless the user explicitly asks for that action in addition to implementation. Even then, do not approve work you just implemented.## Output```markdown## Files changed- `path` — why it changed## Behavior changed## Validation- `command`: passed — what it verified- `command`: failed — what failed- Not run: `command` — reason## Limitations and unresolved decisions## Git status- Paths this change touched- Unrelated dirty paths left untouchedThis implementation is not approval, and it was not committed unless you asked for a commit.```When handing off, record files, behavior, verification, and `state.implemented` from [`../_sdlc/evidence.yaml`](../_sdlc/evidence.yaml). Set `state.verified` only for checks that actually ran and passed for this revision. Leave `state.reviewed` and `state.human_approved` false.Suite boundaries: [`../_sdlc/LIFECYCLE.md`](../_sdlc/LIFECYCLE.md).

Frequently asked questions