Catalog
affaan-m/orch-change-feature

affaan-m

orch-change-feature

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. Use when behavior is not broken but should be different.

global
origin:ECC
New~401
v1.1Saved Jul 14, 2026

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]
Files1
1 files · 1.0 KB

Select a file to preview

Overall Score

88/100

Grade

A

Excellent

Safety

92

Quality

86

Clarity

92

Completeness

78

Summary

This skill orchestrates the workflow for modifying an existing, working feature to implement new desired behavior. It wraps the shared `orch-pipeline` engine with specific configuration: update tests to the new spec first, change implementation to match, conduct code review, and gate commit at two approval points. It is designed for behavioral adjustments rather than bug fixes or new features.

Detected Capabilities

orchestration-via-pipelinetest-modificationcode-review-gatingcommit-approval-gatingconditional-security-review-routing

Trigger Keywords

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

change feature behaviormodify existing featuretweak feature thresholdadjust feature spectest-first refactorbehavioral adjustment

Use Cases

  • Adjust feature thresholds or trigger conditions (e.g., change alert threshold from 3 to 2 warnings)
  • Modify existing feature behavior without fixing a bug (e.g., 'make search also include archived results')
  • Update feature specification by changing tests first, then implementation
  • Route security-sensitive behavioral changes through security review before commit

Quality Notes

  • Well-scoped: clearly distinguishes 'change' from 'fix' and 'add-feature' use cases
  • Clear phase workflow: test-first approach is explicitly stated as a core principle
  • Gating strategy well-defined: two explicit approval gates (plan/test approval, pre-commit)
  • Security consideration documented: skill routes to security-reviewer when change touches security
  • Concise: the entire skill is brief and actionable — no unnecessary detail
  • Practical example provided: demonstrates the expected workflow with a concrete scenario
  • Lightweight assumption: acknowledges that most tweaks require 'small' effort, not full planner pass
  • Dependency transparency: clearly notes this is a wrapper over orch-pipeline engine
Model: claude-haiku-4-5-20251001Analyzed: Jul 14, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

v1.1

Content updated

2026-07-14

Latest
v1.0

No changelog

2026-06-07

Use affaan-m/orch-change-feature in your dev environment

Command Palette

Search for a command to run...