decision-propagation

name	decision-propagation
model	opus
description	Produces a set of surgical edits across all documents affected by an architectural decision, plus a decisions block in STATUS.md that serves as the coherence checkpoint. Use when: 'propagate this decision through the system', 'trace where this decision echoes', 'this decision changes the scope — where else must it flow'.
category	agent-orchestration
triggers	["propagate this decision through the system","trace where this decision echoes","this decision changes the scope where else must it flow"]
tier	1
agents	["primary"]
tool_dependencies	["file_system"]
inputs	[{"name":"decision","type":"string","description":"The architectural decision to propagate through the system","required":true},{"name":"affected_docs","type":"string[]","description":"List of document paths known to be affected","required":false}]
outputs	[{"name":"propagation_edits","type":"string","description":"Set of surgical edits across affected documents and STATUS.md decisions block"}]

Decision-Propagation Protocol

I. The Philosophy

Architectural decisions are not isolated events. When a decision arrives—especially to an open question in an existing document—it creates ripples across an entire ecosystem of interdependent files. A decision like "auth bypass" doesn't just answer one scout's question; it changes scope in the master plan, triggers deferrals in other scouts, and reshapes the STATUS file's summary of the architecture.

Without a propagation protocol, decisions become stranded. A spec answers a question, but the master plan still lists it as open. A scout defers work, but the dependency graph hasn't updated. The system becomes incoherent—different documents contradict each other about what is decided and when.

This skill prevents that dissonance by treating decision-propagation as a deliberate, multi-document process. The human provides the decision once, in one place. Your job is to trace where that decision echoes and update each location.

II. When to Use This Skill

Use the decision-propagation protocol when:

• A human provides answers to open questions in a scout or specification
• An architectural decision changes the scope of a release or work track
• A decision in one document affects the content, sequencing, or priorities of others
• You need to defer work from one release to a later one based on new information
• The STATUS file or master tracking document is out of sync with the decisions living in specs and scouts
• Any time a decision made in one place must be reflected in many places

III. The Workflow: Five Steps

Step 1: Record Decisions at Source

Locate the document where the decision was made (scout, spec, or master plan section).

Replace the "Open Questions" section with "Decisions ([Name], [Date])". Number each decision:

## Decisions (Cruz, 2026-02-11)

1. Entity Backend is v0.2.0 Priority
   - Decision: Build entity-centric backend first, before other subsystems.
   - Reasoning: Reduces scope of v0.2.1 and focuses team on core abstraction.
   - Implication: Defers non-entity tasks to v0.2.1; reshuffles parallel track allocation.

2. Auth Bypass
   - Decision: Skip production auth layer in v0.2.0; ship with debug token instead.
   - Reasoning: Unblocks frontend integration work; auth hardening moves to v0.2.2.
   - Implication: Changes v0.2.0 scope (removes auth), changes v0.2.2 scope (adds auth).

For each decision, capture the exact words, the reasoning (why the human chose this), and any stated implications. If the decision adds or removes scope, note it explicitly.

Step 2: Trace Document Dependencies

Before editing anything, make the complete list of documents affected. Common dependency patterns:

• → typically affected in: scope blocks, dependency graph, constraints, parallel track allocation, next steps