orch-change-feature
SkillDev toolsorch-change-feature is an agent skill for changing the behavior of an existing, working feature. Instead of treating the change as a bug fix, it first updates the feature's tests to describe the new desired behavior, then adjusts the implementation until those tests pass. It reviews the resulting diff and pauses at approval gates before planning and again before committing.
Available today. Use it from your connected AI after setup.
No other account needed.
Have an existing feature that works but whose behavior should be different.
Then ask your AI: use the orch-change-feature skill
What your AI can do with it
- Updates existing tests to express the new desired behavior before touching code
- Changes the implementation until the updated tests pass
- Runs a code review of the diff before committing
- Stops at Gate 1 for plan and changed-test approval
- Stops at Gate 2 for confirmation before committing
- Adds a security-reviewer pass when the change touches a security trigger
Getting started
- Have an existing feature that works but whose behavior should be different.
- Add the orch-change-feature skill to your agent's available skills.
- Invoke it with a plain instruction describing the new behavior, such as changing a threshold from one value to another.
- Approve the plan and updated tests at Gate 1, then confirm the commit at Gate 2.
- Add the security-reviewer step if the change involves a security trigger.
What this skill tells your AI
The instructions your AI receives, as published by affaan-m/ecc in skills/orch-change-feature/SKILL.md and read by ahel’s review.
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).
- not broken → not
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
- Run the
orch-pipelineengine with the settings above. - Keep the plan light — only
standard+ size warrants the fullplannerpass. - Stop at Gate 1 (plan / changed-test approval) and Gate 2 (pre-commit).
- Add
security-reviewerif 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]
Signals
- GitHub stars
- 268k
- Forks
- 40k
- Last commit
- Sep 2026
Questions
- When should this be used instead of a fix or add-feature skill?
- Use it when the feature is not broken and not new, the capability already exists but the desired behavior is different, like "instead of X do Y" or "make it also...". Broken behavior calls for orch-fix-defect; missing capability calls for orch-add-feature.
- Why are tests changed first?
- Updating the existing tests to the new spec first is what separates a behavior tweak from a bug fix. The implementation is then changed until those updated tests pass.
Advanced
- Item type
- skill
- Key
orch-change-feature- Source
- github.com/affaan-m/ecc