Architecture Deviation Protocol (/propose-architecture-update)

In plain terms

Use this when something you want to do clashes with the project's architecture rules: it proposes a proper change to those rules instead of quietly working around them.

What this skill does

Use when a user request conflicts with ARCHITECTURE.md or introduces a new design pattern

Trigger: You have identified that the user's request: 1. Conflicts with docs/ARCHITECTURE.md (e.g., wrong color, direct DB access) 2. Introduces a New Pattern not currently documented (e.g., new UI component library) 3. Relies on Missing Guidelines (e.g., asking for a "Card" when no card style is defined)

[!NOTE] docs/ARCHITECTURE.md is the canonical location for architecture rules. Always update docs/ARCHITECTURE.md as the authoritative source.

---

1. PAUSE WORK

DO NOT write code to implement the requested change yet. Resolve the architectural conflict first.

2. Analyze the Deviation

• Current Rule: What does docs/ARCHITECTURE.md currently say? (Or is it validly silent?)
• User Request: What is the user asking for?
• Impact: Does this break consistency? Does it introduce technical debt?

3. Consult the User

Present the conflict using this template:

Architecture Update Required

Issue: You requested [User Request], but docs/ARCHITECTURE.md [CONTRADICTS this / is MISSING a rule for this].

Action Required — choose one: 1. Update Architecture: Should I add/change the rule to support this? 2. Exception: Is this a one-off exception (won't be repeated)? 3. Correction: Should we stick to the existing rules?

4. Execution (Post-Decision)

If User says "Update": 1. Update docs/ARCHITECTURE.md with the new rule 2. Proceed with the coding task

If User says "Exception": 1. Proceed with the task (ignore the rule for this instance) 2. (Optional) Add a comment in the code: // NOTE: Exception to architecture rule — [reason]

If User says "Correction": 1. Proceed with the task using the original rule from docs/ARCHITECTURE.md