
Orch Change Feature
- 2 installs
- 238k repo stars
- Updated August 5, 2026
- affaan-m/ecc
orch-change-feature is a Claude Code skill that orchestrates altering an existing working feature to new behavior by updating its tests first, then changing the implementation, review, and gated commit.
About
orch-change-feature is a Claude Code skill that orchestrates altering an existing, working feature to new desired behavior. A developer uses it when a feature is not broken but should behave differently, updating the existing tests to the new spec first and then changing the implementation to match. It is a thin wrapper over the shared orch-pipeline engine and commits only after plan and pre-commit gates.
- Orchestrates altering an existing, working feature to new desired behavior
- Updates the existing tests to the new spec first, then changes the implementation to match
- Runs a light plan, review, and gated commit through the shared orch-pipeline engine
Orch Change Feature by the numbers
- 2 all-time installs (skills.sh)
- Ranked #13,956 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
orch-change-feature capabilities & compatibility
- Capabilities
- agent orchestration · feature modification · tdd workflow · code review
- Works with
- github
- Use cases
- orchestration · code review · testing
What orch-change-feature says it does
Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit.
not** new → not `orch-add-feature` (the capability already exists).
npx skills add https://github.com/affaan-m/ecc --skill orch-change-featureAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 2 |
|---|---|
| repo stars | ★ 238k |
| Last updated | August 5, 2026 |
| Repository | affaan-m/ecc ↗ |
What it does
Orchestrate changing an existing working feature to new behavior by updating its tests first, then the implementation, behind gates.
Who is it for?
Adjusting an existing, working feature to a new desired behavior.
Skip if: Fixing broken behavior (orch-fix-defect) or adding a capability that does not exist yet (orch-add-feature).
When should I use this skill?
An existing feature works but the desired behavior is different, phrased as change, adjust, make it also, or instead of X do Y.
What you get
Updated tests expressing the new behavior, an implementation changed to green, reviewed, and committed behind plan and pre-commit gates.
- Updated tests for the new behavior
- Changed implementation to green
- Reviewed conventional commit
By the numbers
- Phase mask 0-(1)-2-4-5-6
- 2 human gates
Files
orch-change-feature
Actor · action · target: orch · change · feature. Thin wrapper over the shared engine in `orch-pipeline`.
When to Use
- An existing feature works, but the desired behavior is different ("change",
"adjust", "make it also …", "instead of X do Y").
- Distinguish from siblings:
- not broken → not
orch-fix-defect(no bug to reproduce). - not new → not
orch-add-feature(the capability already exists).
Operation settings
- Default size floor: small — most tweaks are a function or two.
- Phase mask: 0 → (1 only if the new behavior needs research) → light 2 →
4 → 5 → 6.
- First move (phase 4): update the existing tests to express the new
desired behavior, then change the implementation until they pass. Changing the tests first is what separates a tweak from a fix.
How It Works
1. Run the orch-pipeline engine with the settings above. 2. Keep the plan light — only standard+ size warrants the full planner pass. 3. Stop at Gate 1 (plan / changed-test approval) and Gate 2 (pre-commit). 4. Add security-reviewer if the change touches a security trigger.
Example
orch-change-feature: make nws-poller alert at 2 warnings instead of 3
→ update threshold tests to new spec → change impl to green
→ code-review → commit [GATE 2: confirm]Related skills
FAQ
How is it different from a fix?
A change alters correct-but-undesired behavior and updates tests first, while a fix reproduces broken behavior as a failing test before fixing it.
What is the first move?
Update the existing tests to express the new desired behavior, then change the implementation until they pass.