propagatelisted

# Spec Forge — Propagate ## ⚡ Execution Entry Point (READ THIS FIRST) **Begin executing Step 1 immediately; never fall back to a manual workflow or stop to ask what to do.** --- Walk a doc change downstream and keep the whole chain consistent. ## Iron Law **EVERY UPSTREAM CHANGE PROPAGATES OR FAILS LOUDLY. Partial propagation is worse than no propagation — it creates the illusion of consistency where there is none.** ## When to Use - After editing a PRD / SRS / tech-design / feature-spec — find and update every doc that references the changed concepts - After running `/spec-forge:prd` or another generator that modified an existing doc in place - Periodically, with `--since {git-ref}`, to catch accumulated drift across recent commits - Before a release, to make sure no doc is silently stale relative to its upstream - When `spec-forge:analyze` or `spec-forge:audit` flags inconsistencies between upstream and downstream docs This skill is the symmetric counterpart to `code-forge:fix --review` (which propagates code review findings into code changes). Where `code-forge:fix` walks *up* from a bug to the spec, `spec-forge:propagate` walks *down* from a spec change to the docs and code that depend on it. ## Command Format ``` /spec-forge:propagate [@source-doc.md] [--since git-ref] [--scope all|docs|code] [--dry-run] [--save] ``` | Argument / Flag | Default | Description | |-----------------|---------|-------------| | `@source-doc.md` | — | The upstream doc whose changes