orch-add-feature

orch-pipeline

When to Use

• The user wants a capability that does not exist yet ("add", "build", "implement", "support …").
• It is net-new behavior — not a correction (

  orch-fix-defect

  ) and not an alteration of existing behavior (

  orch-change-feature

  ).

Operation settings

• Default size floor: standard — run Research + Plan unless clearly small.
• Phase mask: 0 → 1 → 2 → 4 → 5 → 6 (skip 3 Scaffold; that is MVP-only).
• First move (phase 4): write new failing tests for the new behavior, then implement to green.

How It Works

1. Run the

   orch-pipeline

   engine with the settings above.
2. Classify size first; small / trivial features collapse toward 4 → 5 → 6.
3. Stop at Gate 1 (plan approval) and Gate 2 (pre-commit).
4. Add

   security-reviewer

   if the feature touches a security trigger.

Related:

/feature-dev

is a standalone version of this flow.

orch-add-feature

differs by sharing the

orch-pipeline

engine — the size classifier and the two gates — with the rest of the family, so it right-sizes trivial features to 4 → 5 → 6.

Example

orch-add-feature: add OAuth2 login to nws-poller
→ research existing auth libs → plan task_list  [GATE 1: approve]
→ TDD each task → code-review (+ security-reviewer: auth path)
→ commit  [GATE 2: confirm]