Feature Addition

---
name: feature-addition
description: Compose foundation skills for adding new features to an existing project with regression-first verification. Use when planning, slicing, implementing, scheduling, or reviewing new capabilities that should preserve existing behavior, use acceptance tests, reuse prior test suites, and only opt into parity or dependency alignment when risk requires it.
---

# Feature Addition

Use this composition for new capabilities in an existing system. It is not a
rewrite loop.

## Default Policy

```yaml
verification_strategy: regression_first
default_first_gate: compatibility_regression
behavior_parity: not_required_by_default
dependency_alignment: only_when_new_or_replaced_capability_needs_it
dag_mode: dry_run_first
unit_model: minimum_independently_verifiable_work_unit
```

New feature completion is proven by acceptance tests and writer verification.
Old behavior is protected by existing test suites and targeted regression paths.
Use `behavior_parity` only when the feature changes or replaces existing public
behavior.

## Foundation Routing

- Use `work-unit-slicing` to cut the feature into independently verifiable work
  units.
- Use `phase-dag-execution` when units have real artifact dependencies, shared
  paths, resource locks, or useful parallelism.
- Use `review-gate` for `compatibility_regression` and any selected risk gates.
- Use `crate-recon` and `dependency-alignment` only when the feature introduces
  dependencies, replaces a lower capability, or creates shared dependency risk.
- Use `env-bootstrap` only when the feature introduces a new seam or unproven
  environment.

## Feature Unit Record

```yaml
id: feature-unit
status: planned
intended_outcome: ""
acceptance_tests: []
regression_checks: []
existing_behavior_surface: []
required_reviews:
  - compatibility_regression
optional_reviews: []
not_required:
  behavior_parity: "new behavior, no old/new implementation replacement"
rollback_or_disable: ""
dag: {}
```

## Workflow

1. Read project facts, existing tests, public workflows, and relevant code.
2. Slice the feature into units with acceptance and regression evidence.
3. Identify old behavior surfaces that could break.
4. Declare phase template, artifacts, owned paths, locks, and review needs.
5. Bootstrap new seams only if needed.
6. Implement one unit at a time or schedule ready nodes through a dry-run DAG.
7. Run unit acceptance tests plus regression checks before review.
8. Run `compatibility_regression` first, then selected gates by risk.
9. Release only units with passing acceptance, regression, required reviews, and
   rollback/disable notes.

## Non-Negotiables

- Do not run py2rs behavior parity by habit.
- Do not skip regression checks because the work is "new".
- Do not add dependency alignment work unless a real dependency decision exists.
- Do not use DAG shards as execution order.
- Do not let project-specific daily operation leak into this generic
  composition; generate practice skills when paths and commands stabilize.