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

Run the orch-pipeline engine with the settings above.
Keep the plan light — only standard+ size warrants the full planner pass.
Stop at Gate 1 (plan / changed-test approval) and Gate 2 (pre-commit).
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]

Files1

1 files · 1.0 KB

Select a file to preview

Overall Score

78/100

Grade

B

Good

Safety

82

Quality

76

Clarity

85

Completeness

70

Summary

This skill orchestrates controlled changes to existing working features by first updating tests to the new desired behavior, then modifying the implementation to match. It wraps the shared `orch-pipeline` engine with specific phase masking and gating rules, designed for feature adjustments that are neither bug fixes nor entirely new features.

Detected Capabilities

orchestrationtest modificationcode review coordinationgated workflow execution

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

adjust feature behaviorchange threshold parametertweak working featuremodify feature logicfeature behavioral change

Use Cases

Adjust thresholds or parameters in working features
Change feature behavior without breaking existing tests first
Update feature logic while maintaining test-driven discipline
Coordinate feature changes through approval gates

Quality Notes

Clear use-case delineation distinguishes this skill from `orch-fix-defect` and `orch-add-feature`
Explicit instruction to update tests first before implementation is a strong best practice
Security reviewer trigger is appropriately conditional ('if the change touches a security trigger')
Phase mask and gating strategy are well-documented and appropriate for the workflow
Concrete example makes the intended workflow immediately clear
Skill appropriately defers core logic to `orch-pipeline` rather than duplicating
No documented limitations or edge cases (e.g., what happens if tests cannot be written first, or if the feature touches multiple subsystems)

Model: claude-haiku-4-5-20251001Analyzed: Jun 7, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

orch-change-feature

orch-change-feature

When to Use

Operation settings

How It Works

Example

Summary

Detected Capabilities

Trigger Keywords

Use Cases

Quality Notes

Reviews

Command Palette