# Propagate Design Change > Cuando se revisa un GDD, escanea todos los ADRs y el índice de trazabilidad para detectar decisiones arquitectónicas obsoletas y guía la resolución. Fuente: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/propagate-design-change Markdown: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/propagate-design-change.md Repositorio: https://github.com/Donchitos/Claude-Code-Game-Studios Autor: Donchitos Licencia: MIT Actualizado: hace 3 meses Coste de contexto: 51 tok instalada, 2k tok al activarse, 2k tok con todos los archivos del bundle Bundle: 1 archivo, 8 KB Permisos que pide: read, glob, grep, write, bash, task ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add Donchitos/Claude-Code-Game-Studios --skill propagate-design-change --agent claude-code # Cursor npx -y skills add Donchitos/Claude-Code-Game-Studios --skill propagate-design-change --agent cursor # Codex npx -y skills add Donchitos/Claude-Code-Game-Studios --skill propagate-design-change --agent codex # Gemini CLI npx -y skills add Donchitos/Claude-Code-Game-Studios --skill propagate-design-change --agent gemini # Windsurf npx -y skills add Donchitos/Claude-Code-Game-Studios --skill propagate-design-change --agent windsurf # Cline npx -y skills add Donchitos/Claude-Code-Game-Studios --skill propagate-design-change --agent cline ``` ## Qué hace - Compara la versión actual de un GDD con la anterior en git para identificar secciones cambiadas - Escanea todos los ADRs en docs/architecture/ para ver cuáles referencian el GDD modificado - Clasifica cada ADR afectado como Still Valid, Needs Review o Likely Superseded - Presenta un informe de impacto y guía al usuario ADR por ADR para resolver cada caso - Actualiza el índice de trazabilidad y genera un documento de change-impact ## Cuándo usarla - Cuando se revisa o modifica un GDD ya existente y hay ADRs escritos contra esa versión anterior - Cuando se necesita verificar si decisiones arquitectónicas siguen siendo válidas tras un cambio de diseño ## Cuándo no - El GDD es nuevo y no tiene historial previo en git (no hay nada que propagar) ## Qué la activa - "/propagate-design-change design/gdd/combat-system.md" - "Cambié el GDD de combate, revisa qué ADRs quedaron desactualizados" - "Analiza el impacto de este cambio de diseño en la arquitectura" ## Antes de instalar - Requiere un repositorio git con historial del GDD y ADRs existentes en docs/architecture/. - Necesita en el PATH: git - runs shell commands - writes to your files ## Archivos - SKILL.md — 8 KB ## SKILL.md Reproducido tal cual desde Donchitos/Claude-Code-Game-Studios bajo MIT. Esta sección es el documento original y está en inglés. # Propagate Design Change When a GDD changes, architectural decisions written against it may no longer be valid. This skill finds every affected ADR, compares what the ADR assumed against what the GDD now says, and guides the user through resolution. **Usage:** `/propagate-design-change design/gdd/combat-system.md` --- ## 1. Validate Argument A GDD path argument is **required**. If missing, fail with: > "Usage: `/propagate-design-change design/gdd/[system].md` > Provide the path to the GDD that was changed." Verify the file exists. If not, fail with: > "[path] not found. Check the path and try again." --- ## 2. Read the Changed GDD Read the current GDD in full. --- ## 3. Read the Previous Version Run git to get the previous committed version: ```bash git show HEAD:design/gdd/[filename].md ``` If the file has no git history (new file), report: > "No previous version in git — this appears to be a new GDD, not a revision. > Nothing to propagate." If git returns the previous version, do a conceptual diff: - Identify sections that changed (new rules, removed rules, modified formulas, changed acceptance criteria, changed tuning knobs) - Identify sections that are unchanged - Produce a change summary: ``` ## Change Summary: [GDD filename] Date of revision: [today] Changed sections: - [Section name]: [what changed — new rule, removed rule, formula modified, etc.] Unchanged sections: - [Section name] Key changes affecting architecture: - [Change 1 — likely to affect ADRs] - [Change 2] ``` --- ## 4. Load Architecture Inputs Read all ADRs in `docs/architecture/`: - For each ADR, read the full file - Extract the "GDD Requirements Addressed" table - Note which GDD documents and requirement IDs each ADR references Read `docs/architecture/architecture-traceability.md` if it exists. Report: "Loaded [N] ADRs. [M] reference [gdd filename]." --- ## 5. Impact Analysis For each ADR that references the changed GDD: Compare the ADR's "GDD Requirements Addressed" entries against the changed sections of the GDD. For each referenced requirement: 1. **Locate the requirement** in the current GDD — does it still exist? 2. **Compare**: What did the GDD say when the ADR was written vs. what it says now? 3. **Assess the ADR decision**: Is the architectural decision still valid? Classify each affected ADR as one of: | Status | Meaning | |--------|---------| | ✅ **Still Valid** | The GDD change doesn't affect what this ADR decided | | ⚠️ **Needs Review** | The GDD change may affect this ADR — human judgment needed | | 🔴 **Likely Superseded** | The GDD change directly contradicts what this ADR assumed | For each affected ADR, produce an impact entry: ``` ### ADR-NNNN: [title] Status: [Still Valid / Needs Review / Likely Superseded] What the ADR assumed about this GDD: "[relevant quote from the ADR's GDD Requirements Addressed section]" What the GDD now says: "[relevant quote from the current GDD]" Assessment: [Explanation of whether the ADR decision is still valid, and why] Recommended action: [Keep as-is | Review and update | Mark Superseded and write new ADR] ``` --- ## 6. Present Impact Report Present the full impact report to the user before asking for any action. Format: ``` ## Design Change Impact Report GDD: [filename] Date: [today] Changes detected: [N sections changed] ADRs referencing this GDD: [M] ### Not Affected [ADRs referencing this GDD whose decisions remain valid] ### Needs Review ([count]) [ADRs that may need updating] ### Likely Superseded ([count]) [ADRs whose assumptions are now contradicted] ``` --- ## 6b. Director Gate — Technical Impact Review **Review mode check** — apply before spawning TD-CHANGE-IMPACT: - `solo` → skip. Note: "TD-CHANGE-IMPACT skipped — Solo mode." Proceed to Phase 7. - `lean` → skip. Note: "TD-CHANGE-IMPACT skipped — Lean mode." Proceed to Phase 7. - `full` → spawn as normal. Spawn `technical-director` via Task using gate **TD-CHANGE-IMPACT** (`.claude/docs/director-gates.md`). Pass: the full Design Change Impact Report from Phase 6 (change summary, all affected ADRs with their Still Valid / Needs Review / Likely Superseded classifications, and recommended actions). The technical-director reviews whether: - The impact classifications are correct (no ADRs under-classified) - The recommended actions are architecturally sound - Any cascading effects on other ADRs or systems were missed Apply the verdict: - **APPROVE** → proceed to Phase 7 resolution workflow - **CONCERNS** → surface the specific ADRs or recommendations flagged; use `AskUserQuestion` with options: `Revise the impact assessment` / `Accept with noted concerns` / `Discuss further` - **REJECT** → do not proceed to resolution; re-analyze the impact before continuing --- ## 7. Resolution Workflow For each ADR marked "Needs Review" or "Likely Superseded", ask the user what to do: Ask for each ADR in turn: > "ADR-NNNN ([title]) — [status]. What would you like to do?" > Options: > - "Mark Superseded (I'll write a new ADR)" — updates ADR status line to `Superseded by: [pending]` > - "Update in place (minor revision)" — opens the ADR for editing; note what to revise > - "Keep as-is (the change doesn't actually affect this decision)" > - "Skip for now (revisit later)" For ADRs marked **Superseded**: - Update the ADR's Status field: `Superseded by ADR-[next number] (pending — see change-impact-[date]-[system].md)` - Ask: "May I update the status in [ADR filename]?" --- ## 8. Update Traceability Index If `docs/architecture/architecture-traceability.md` exists: - Add the changed GDD requirements to the "Superseded Requirements" table: ```markdown ## Superseded Requirements | Date | GDD | Requirement | Changed To | ADRs Affected | Resolution | |------|-----|-------------|------------|---------------|------------| | [date] | [gdd] | [old requirement text] | [new requirement text] | ADR-NNNN | [Superseded/Updated/Valid] | ``` Ask: "May I update the traceability index?" --- ## 9. Output Change Impact Document Ask: "May I write the change impact report to `docs/architecture/change-impact-[date]-[system-slug].md`?" The document contains: - The change summary from step 3 - The full impact analysis from step 5 - Resolution decisions made in step 7 - List of ADRs that need to be written or updated If user approved: Verdict: **COMPLETE** — change impact report saved. If user declined: Verdict: **BLOCKED** — user declined write. --- ## 10. Follow-Up Actions Based on the resolution decisions, suggest: - **ADRs marked Superseded**: "Run `/architecture-decision [title]` to write the replacement ADR. Then re-run `/propagate-design-change` to verify coverage." - **ADRs to update in place**: List the specific fields to update in each ADR - **If many ADRs affected**: "Run `/architecture-review` after all ADRs are updated to verify the full traceability matrix is still coherent." --- ## Collaborative Protocol 1. **Read silently** — compute the full impact before presenting anything 2. **Show the full report first** — let the user see the scope before asking for action 3. **Ask per-ADR** — don't batch decisions; each affected ADR may need different treatment 4. **Ask before writing** — always confirm before modifying any file 5. **Non-destructive** — never delete ADR content; only add "Superseded by" notes ## Dónde encaja - Categoría: [Herramientas para desarrolladores](https://skillsagentes.com/categorias/herramientas-desarrollo.md) — Skills que cambian cómo tu agente escribe, revisa y despliega código. - Creador: [Donchitos](https://skillsagentes.com/creators/donchitos.md) — 73 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Otras skills del mismo repositorio - [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off. - [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first. - [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento. - [Day One Patch](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch.md): Prepara un patch day-one para el lanzamiento de un juego: define alcance, prioriza, implementa y valida con un QA gate ligero, como un mini-sprint con plan de rollback. - [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto. --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)