---
name: project-change-request
description: Use mid-development when the user adds, changes, removes, or defers a feature, idea, requirement, or UI element while planning artifacts (brainstorm/PRD/architecture/implementation plan) already exist — e.g. "what if we add X", "make this work differently", "drop this", "add this to the UI", "park this for later". Classifies the change and cascades it through the existing artifacts instead of silently editing them or just coding it.
---

# Project Change Request

Use this skill when work is already underway and the user injects a new idea or a
change to an existing one. It is the conductor for mid-development change: it
classifies the ask, captures it, confirms scope, and cascades it through the
existing planning artifacts — reusing `project-request-intake`,
`project-document-branch`, `project-decision-ledger`, the planning skills, and
`project-traceability-sync` as steps.

## Iron Law

```text
CAPTURE AND CONFIRM SCOPE BEFORE CASCADING; NEVER SILENTLY EDIT PLANNED TRUTH OR JUST START CODING.
```

## Step 1: Classify the change

| The user says… | Type |
| --- | --- |
| "add feature X", "add this idea", "add this to the UI", "it also needs to be fast/offline/secure" | **add** (new scope) |
| "make this feature do Y instead", "this requirement should mean…", "undo the decision about…" | **change** (modify existing) |
| "drop this", "we don't need X", "cut this scope" | **remove** (descope) |
| "park this for later", "do this part first", "let me just try something quickly" | **park** (defer / reorder / spike) |

## Step 2: Capture (do not edit mainline artifacts yet)

- **add** → a `REQ-*` (type `feature`) via `project-request-intake`, linked to the
  affected `PRD-*`/`ARCH-*`/`IMP-*`.
- **change** → a `DBR-*` document branch via `project-document-branch` holding the
  proposed delta to the PRD/architecture/plan (use the `prd-delta`,
  `architecture-delta`, `plan-delta` templates). If it reverses a prior decision,
  also supersede the `DEC-*` via `project-decision-ledger`.
- **remove** → a `REQ-*` (type `refactor`/`feature`) or `DBR-*` describing what is
  cut and why; never delete records, mark them superseded.
- **park** → a `REQ-*` left `proposed`/deferred (or a `DBR-*` for a spike). Stop
  here; do not cascade. The current `TRK-*`/`IMP-TASK-*` resumes untouched.

## Step 3: Scope checkpoint

A mid-development change is a **scope change** — a key decision. Apply
`project-decision-policy`: in `key_decision`/`guided`, state the impact and
confirm before cascading ("this adds N requirement(s) and ~M plan tasks; fold in
now, or defer?"). In `autonomous`, proceed but record the choice. Record the
decision (`DEC-*` with `decided_by`/`autonomy_tier`) when it changes direction.

Do not give a timescale; rate the change by complexity and confidence (see
`.prd_plugin/method/estimation.md`).

## Step 4: Cascade by type (only after confirmation)

Touch only the affected slice — do not re-run the whole planning chain.

- **add**: capture a brainstorm note if the idea is fuzzy → add the new
  `PRD-REQ-*` (+ acceptance criteria) via `project-prd` → update
  `project-architecture` if components/interfaces change → add the new
  `IMP-TASK-*`(s) + `IMP-VAL-*` via `project-implementation-plan` → open/Update a
  `TRK-*`.
- **change**: promote the `DBR-*` delta into the affected `PRD-REQ-*`/`ARCH-*`/
  `IMP-TASK-*` → flag and re-validate downstream items the change could break
  (regression conditions) → supersede the old `DEC-*` if any.
- **remove**: mark the affected `PRD-REQ-*`/`ARCH-*`/`IMP-TASK-*` superseded or
  removed → find and clean now-orphaned tasks/branches (a `project-health` /
  `project-traceability-review` pass helps) → keep evidence and history → record
  a `CHG-*` noting the descope.
- **park**: nothing to cascade.

Then run `project-traceability-sync` so brainstorm → PRD → architecture → plan →
tracking links stay intact, and record a `CHG-*` for what changed.

## Step 5: Implement (if "do it now")

Hand off to `project-test-driven-implementation` on a branch
(`project-git-workflow`), then `project-verification-before-completion` and
`project-code-review`. UI changes still need real verification evidence
(screenshots / a driven browser), not just "looks right".

## Boundary

- This skill **orchestrates**; the capture/record mechanics live in
  `project-request-intake` (REQ), `project-document-branch` (DBR), and
  `project-decision-ledger` (DEC). Use those directly when there is no
  mid-development cascade to drive.
- For brand-new projects with no artifacts yet, start at
  `project-planning-lifecycle`, not here.

## Staleness Coverage

Apply the shared policy in `.prd_plugin/method/staleness-rules.md`. Before
cascading a change, check whether the artifacts it touches are already stale or
have open `DBR-*`/`REQ-*` covering the same area; fold into the existing record
instead of creating a duplicate.

## Red Flags

- Editing the PRD/architecture/plan directly from a verbal "what if" without a
  `REQ-*`/`DBR-*` and a scope checkpoint.
- Coding the change before updating the artifacts and tasks it affects.
- Silently expanding the current task's scope instead of confirming.
- Deleting requirements/tasks on a "remove" instead of superseding them.
- Giving a time estimate for the change.