Agent skill
implement-change
Execute code changes from an implementation plan. Use when someone says "implement this", "build this", "code this", "start building", "let's implement", "execute the plan", "make the changes", "do the work", or has an approved implementation plan ready for coding. Takes implementation plans and produces working code, phase by phase with verification.
Install this agent skill to your Project
npx add-skill https://github.com/teambrilliant/dev-skills/tree/main/skills/implement-change
SKILL.md
Implement Change
Execute an implementation plan phase by phase, producing working code with verification at each step.
Design Philosophy
While implementing, consult references/software-design-philosophy.md for code-level design principles. Watch for red flags: shallow modules, information leakage, pass-through methods, temporal decomposition.
Principles
- Understand before coding — read all relevant files thoroughly first
- Phase by phase — complete one phase before starting the next
- Verify as you go — run checks after each phase, fix issues before proceeding
- Adapt to reality — plans are guides, not rigid scripts; handle mismatches thoughtfully
- Track progress — keep todos updated, check off items as completed
Input
This skill expects an implementation plan (from /dev-skills:implementation-planning). If no plan exists, create one first — don't start coding without a plan.
Process
1. Understand the Work
Read the plan completely. Read all files mentioned or related. Create a todo list tracking each phase.
If the plan has checkboxes, check for existing [x] marks — resume from first unchecked item.
2. Implement Phase by Phase
For each phase:
- Implement — make the code changes
- Verify — run the specified checks (tests, typecheck, lint)
- Fix — address any failures before moving on
- Update — mark todos complete, check boxes in plan file
3. Handle Mismatches
When reality differs from the plan, surface it:
- What the plan says vs what you found
- Why it matters
- How you suggest proceeding
Don't silently deviate — get guidance.
4. Final Verification
After all phases complete:
- Run full test suite
- Run typecheck and lint
- Verify the original acceptance criteria are met
Working Guidelines
Do:
- Read files thoroughly — full files for small ones, targeted sections for large ones
- Follow existing code patterns in the codebase
- Keep changes focused on the plan scope
- Update progress frequently
Don't:
- Make unrelated "improvements"
- Skip verification steps
- Proceed past failures without fixing them
- Assume — ask when unclear
Progress Tracking
Use todos to track each phase, verification steps, and blockers.
Update the plan file checkboxes as you complete items:
- [x] Completed item
- [ ] Pending item
Resuming Work
If picking up existing work:
- Check for
[x]marks in the plan - Trust completed work unless something seems wrong
- Start from first unchecked item
- Verify previous work only if you hit unexpected issues
Handoffs
- After all phases pass verification → suggest
/dev-skills:qa-testfor browser verification - If acceptance criteria need revision during implementation → flag it, don't modify them
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
product-discovery
Validate whether a product idea is worth building before committing engineering investment. Use when someone says "should we build this", "validate this idea", "discovery", "run an experiment", "test this hypothesis", "what are the risks", "is this worth building", "feasibility check", "prototype plan", or when a team has a shaped feature or product idea and needs to assess risks and design experiments before building. Sits between product-thinker (should we?) and shaping-work (what exactly?) — this skill answers "will this actually work?" by identifying what you don't know, designing the cheapest way to find out, and defining evidence gates that justify (or kill) the investment. Also trigger when someone has a feature request and you sense high uncertainty — if the team is about to spend weeks building something nobody tested, this skill should intervene.
implementation-planning
Create technical implementation plans and architecture designs. Use when someone needs a detailed technical approach before coding begins — "create a plan", "plan this ticket", "how should we implement this", "technical design", "architect this", "design the approach", "plan the migration", "refactor plan", "how should we structure this", or when shaped work or a groomed ticket needs a concrete implementation strategy with phases, file changes, and verification steps.
qa-test
Browser-based QA verification after any implementation. Use when someone says "QA this", "test this in browser", "verify the feature", "qa test", "browser test", or after completing an /implement-change to verify acceptance criteria in a real browser. Opens Chrome via MCP, exercises each acceptance criterion, verifies via DOM snapshots, and reports pass/fail. The "closer" for every implementation — proof it works, not just that tests pass.
shaping-work
Shape rough ideas into clear, actionable work definitions. Use this skill whenever someone has an unstructured idea that needs to become a concrete work definition — feature requests, bug reports, PRDs, customer feedback, Slack threads, stakeholder asks, or vague "we should do X" statements. Trigger phrases include "shape this", "scope this", "write a PRD", "define this work", "turn this into a ticket", "flesh this out", "spec this out", "what should we build for X", "I have an idea for...", or any rough input that needs structure before implementation can begin.
product-primitives
Break down complex products, features, or systems into fundamental primitives and building blocks from a software creator's perspective. Use when starting a new application, designing a large feature, or needing to understand a complex system's moving parts before building. Trigger phrases: "break down X", "decompose this", "what are the primitives", "building blocks of Z", "map the architecture", "what are the moving parts", "analyze this system", or any situation where you need to identify the atomic, reusable capabilities that compose a system. Complements product-thinker (user perspective) with the builder's perspective (system-level connections).
loop-check
Assess what's needed to make feedback loops autonomous in a repo. Use when someone says "loop check", "what do I need to work autonomously", "check my feedback loops", "what's manual here", "what should I automate", "can an agent iterate here", or before starting work in an unfamiliar repo to understand what's missing for autonomous iteration. Also use when the user asks "what do you need to make this autonomous?" or describes a workflow they want to close the loop on. NOT for: full repo audits (use tap-audit), coding, test writing, or implementation.
Didn't find tool you were looking for?