orch-add-feature
Actor · action · target: orch · add · feature. Thin wrapper over the shared
engine in 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
- Run the
orch-pipeline engine with the settings above.
- Classify size first; small / trivial features collapse toward 4 → 5 → 6.
- Stop at Gate 1 (plan approval) and Gate 2 (pre-commit).
- 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]
---
name: orch-add-feature
description: Orchestrates building a new feature end-to-end by delegating research, planning, TDD implementation, review, and gated commit to specialized agents.
---
# orch-add-feature
Actor · action · target: **orch · add · feature**. Thin wrapper over the shared
engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
## 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]
```
