propagate-design-change
Skill40 starsChanged 7 months agoMITView on GitHub
When a PRD is changed, scans all ADRs, dependent PRDs, stories, and the traceability index to identify what is now potentially stale. Produces a change-impact report and walks the user through resolving each downstream artifact. Use immediately after editing a PRD that other artifacts reference.
9 other projects use a version of this.
Adopted by
Most recently taken up by
- striderZA/OpenCodeGameStudiostheir own version, first seen Nov 4, 2026
- Donchitos/Claude-Code-Game-Studiostheir own version, first seen Oct 19, 2026
- venus2099/codex-game-studiostheir own version, first seen Oct 17, 2026
- ShiningPlague/shiningplague-studiotheir own version, first seen Oct 11, 2026
- HunLuanZhiZhu/Game-Studios-Plugintheir own version, first seen Oct 5, 2026
- dawn840705/claude-code-studiostheir own version, first seen Aug 28, 2026
Used with
Projects with it also use vertical-slice.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
hongyuancSkillvertical-slice
Build and evaluate a production-quality vertical slice before advancing from Pre-Production to Production.
Also in 4 projects that use this
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- striderZA/OpenCodeGameStudios★ 118same name
- dawn840705/codex-code-studios★ 17same name
- lilangMax/ClaudeCodeGameStudios★ 8same name
- hongyuanc/codex-game-studios★ 5same name
- dawn840705/claude-code-studios★ 1same name
- HunLuanZhiZhu/Game-Studios-Plugin★ 1same name
- venus2099/codex-game-studios★ 1same name
- ShiningPlague/shiningplague-studio★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository77 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- design/CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- src/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- adoptSkill
- architecture-decisionSkill
- architecture-reviewSkill
- asset-auditSkill
- asset-specSkill
- balance-checkSkill
- brainstormSkill
- bug-reportSkill
- bug-triageSkill
- changelogSkill
- code-reviewSkill
- consistency-checkSkill
- content-auditSkill
- create-architectureSkill
- create-control-manifestSkill
- create-epicsSkill
- create-storiesSkill
- day-one-patchSkill
- design-bibleSkill
- design-reviewSkill
- design-systemSkill
- dev-storySkill
- estimateSkill
- extractSkill
- gate-checkSkill
- helpSkill
- hotfixSkill
- launch-checklistSkill
- localizeSkill
- map-systemsSkill
- milestone-reviewSkill
- onboardSkill
- patch-notesSkill
- perf-profileSkill
- prd-reviewSkill
- project-stage-detectSkill
- prototypeSkill
- qa-planSkill
- quick-designSkill
- regression-suiteSkill
- release-checklistSkill
- retrospectiveSkill
- reverse-documentSkill
- review-all-prdsSkill
- scope-checkSkill
- security-auditSkill
- setup-frameworkSkill
- skill-improveSkill
- skill-testSkill
- smoke-checkSkill
- soak-testSkill
- sprint-planSkill
- sprint-statusSkill
- startSkill
- story-doneSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 9 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Read-only — no file edits.
- Very specific: line 30
All ADRs in docs/architecture/
- Very specific: line 32
All stories in production/epics/
- Distinctive: line 43
If the user did not describe what changed, ask:
- Distinctive: line 55
If user picks "I don't know" or "interface changed", skip to Phase 2 and rely on full scan.
- Very specific: line 62
Every TR-ID in the PRD (TR-<system>-NNN)
- Distinctive: line 63
Every configurable value name (Section 6)
- Distinctive: line 64
Every interface / event / endpoint name (Section 3 / 5)
- Distinctive: line 159
If yes: for each artifact in the chosen list, present:
- Distinctive: line 169
After each, capture user's intent (free text) — "skip", "fix later", "fix now".
- Distinctive: line 196
PRD path is ambiguous: ask which one.
- Distinctive: line 202
Every downstream reference is named with file path + anchor
- Distinctive: line 203
Every CRITICAL / BLOCKED state surfaces an immediate action
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Propagate a Design Change
A PRD edit invalidates downstream work in proportion to how many artifacts referenced it. This skill enumerates that impact in one pass so nothing slips through.
Read-only — no file edits. The user runs follow-up skills (/architecture-decision, /design-system retrofit, /sprint-plan) to apply changes.
Purpose / When to Run
Run when:
- A PRD has just been edited (any section)
- A configurable value, formula, or interface in a PRD has changed
- A new edge case or acceptance criterion was added
- The user wants to know "if I change X, what breaks?"
Inputs
- Path to the changed PRD (required)
- Optional: a description of what changed (free text); skill is more accurate with this hint
- All ADRs in
docs/architecture/ docs/architecture/tr-registry.yamlif present- All stories in
production/epics/ - All other PRDs
Outputs
- A printed change-impact report
Phase 1: Identify the Change
If the user did not describe what changed, ask:
- Prompt: "What changed in this PRD?"
- Options:
New requirement addedExisting requirement modifiedConfigurable value changed (default or range)Edge case added or modifiedAcceptance criterion changedInterface to another system changed (data shape / event)Dependency added / removedI don't know — scan and find out
If user picks "I don't know" or "interface changed", skip to Phase 2 and rely on full scan.
Phase 2: Identify Anchors
Build the list of "anchors" in the changed PRD that downstream work might reference:
- Every TR-ID in the PRD (
TR-<system>-NNN) - Every configurable value name (Section 6)
- Every interface / event / endpoint name (Section 3 / 5)
- The PRD's filename itself (some artifacts cite the path)
- Each entity name from the registry that this PRD owns (
source: <this-prd>)
These anchors are the things downstream artifacts could cite.
Phase 3: Scan for Downstream References
For each anchor, grep the project:
docs/architecture/ADR-*.mddocs/architecture/tr-registry.yamlproduction/epics/*/EPIC.mdproduction/epics/*/story-*.md- Other
design/prd/*.md design/ux/*.mdtests/(test names that reference TR-IDs)
Record every hit: file path + the anchor that matched.
Phase 4: Classify Impact
For each downstream artifact that has a hit, classify:
- STALE — REVIEW REQUIRED — the artifact references something whose definition just changed; must be re-read to confirm it still aligns.
- POTENTIALLY STALE — the artifact references the PRD generally but not a specific changed anchor; may not be affected.
- BLOCKED — for stories: a story
Status: In Progressthat references a changed TR-ID. Halt that work until the change is reconciled.
ADR-specific:
- Status
Acceptedand references a changed anchor → may need to be updated or superseded (/architecture-decision retrofit ...) - Status
Proposedand references a changed anchor → revise before accepting
Story-specific:
- Status
Readyand references a changed TR-ID → re-read the story; may need to update Acceptance Criteria - Status
In Progress→ BLOCKED — surface to the engineer immediately - Status
Complete→ check if test evidence still passes against the new criteria; if not, file a regression task
PRD-specific (cross-PRD):
- Another PRD references a configurable value whose default just changed → that PRD's expectations may be wrong
- Another PRD references an interface whose shape just changed → must update
Phase 5: Produce the Impact Report
# Change Impact: <prd-path>
## What changed
<summary from Phase 1, or "scanned without explicit summary">
## Downstream impact
### ADRs (<N total, M stale)
- ADR-NNNN: <title> — Status: <Accepted | Proposed>
References: TR-foo-001
Action: re-read; if decision still valid, no change. If interface details have shifted, run `/architecture-decision retrofit docs/architecture/<adr>.md`.
### Stories (<N total, M stale, K blocked)
- production/epics/<epic>/story-NNN-<slug>.md — Status: <X>
References: TR-foo-001 (changed), TR-foo-003 (unchanged)
Action: <re-read | block | update acceptance criteria>
### Other PRDs (<N total, M stale)
- design/prd/<other>.md — references configurable `paywall_trigger_count` (default changed)
Action: confirm the dependent PRD's expectations still hold.
### UX specs
- <list>
### Tests (regression risk)
- tests/integration/<...>_test.<ext> — Status: <pass | unknown>
Action: re-run after changes propagate; failing tests indicate the change broke a verified behavior.
## Summary
- ADRs to revise: <N>
- Stories blocked: <N>
- Stories to re-validate: <N>
- PRDs to re-check: <N>Phase 6: Walk Through Resolution
Use AskUserQuestion:
- Prompt: "Want to walk through these one by one?"
- Options:
Yes — start with the blocked storiesYes — start with the stale ADRsNo — I'll handle them on my own
If yes: for each artifact in the chosen list, present:
- The file path
- The specific anchor reference
- The relevant section of the changed PRD
- A recommendation:
- For stories: re-read; suggest acceptance criteria diff
- For ADRs: suggest
/architecture-decision retrofit ...or a supersession - For other PRDs: suggest
/design-system retrofit ... - For tests: suggest re-running before merging
After each, capture user's intent (free text) — "skip", "fix later", "fix now". Tally these for a summary at the end.
Phase 7: Closing Summary
Print:
## Resolution log
- Acknowledged: <N>
- Action items captured: <N>
- Skipped: <N>
## Recommended sequence
1. Unblock in-progress stories first (talk to the engineer, update the story)
2. Update or supersede affected Accepted ADRs
3. Refresh other PRDs whose interface assumptions shifted
4. Re-run `/architecture-review` once stale ADRs are reconciled
5. Re-run `/consistency-check` once registry-affecting changes are pushed back to the registryEdge Cases
- No downstream references found: print "No downstream artifacts reference this PRD's anchors. Change is isolated." Useful confirmation.
- The change involved deleting a TR-ID: surface this loudly — any artifact citing it has lost its anchor and should be rewritten or deleted.
- PRD path is ambiguous: ask which one.
Quality Gates
- Every downstream reference is named with file path + anchor
- Every CRITICAL / BLOCKED state surfaces an immediate action
- The skill never edits files itself
- The skill never silently deletes references — only reports
Examples
User edited design/prd/auth.md, changing the rate limit from 5 to 3 per minute.
- 2 ADRs reference the rate limit
- 1 story
In Progressreferences it (BLOCKED — engineer needs the new value) - 3 other PRDs reference the auth rate limit indirectly
- Tests in
tests/integration/auth/need to update their expected value - Report walks through each, recommends
/architecture-decision retrofitfor ADR-0007, story update for the in-progress one
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

