diff --git a/.agents/skills/frontend-design/LICENSE.txt b/.agents/skills/frontend-design/LICENSE.txt
new file mode 100644
index 0000000..f433b1a
--- /dev/null
+++ b/.agents/skills/frontend-design/LICENSE.txt
@@ -0,0 +1,177 @@
+
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
+
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+ 1. Definitions.
+
+ "License" shall mean the terms and conditions for use, reproduction,
+ and distribution as defined by Sections 1 through 9 of this document.
+
+ "Licensor" shall mean the copyright owner or entity authorized by
+ the copyright owner that is granting the License.
+
+ "Legal Entity" shall mean the union of the acting entity and all
+ other entities that control, are controlled by, or are under common
+ control with that entity. For the purposes of this definition,
+ "control" means (i) the power, direct or indirect, to cause the
+ direction or management of such entity, whether by contract or
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ outstanding shares, or (iii) beneficial ownership of such entity.
+
+ "You" (or "Your") shall mean an individual or Legal Entity
+ exercising permissions granted by this License.
+
+ "Source" form shall mean the preferred form for making modifications,
+ including but not limited to software source code, documentation
+ source, and configuration files.
+
+ "Object" form shall mean any form resulting from mechanical
+ transformation or translation of a Source form, including but
+ not limited to compiled object code, generated documentation,
+ and conversions to other media types.
+
+ "Work" shall mean the work of authorship, whether in Source or
+ Object form, made available under the License, as indicated by a
+ copyright notice that is included in or attached to the work
+ (an example is provided in the Appendix below).
+
+ "Derivative Works" shall mean any work, whether in Source or Object
+ form, that is based on (or derived from) the Work and for which the
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
+ of this License, Derivative Works shall not include works that remain
+ separable from, or merely link (or bind by name) to the interfaces of,
+ the Work and Derivative Works thereof.
+
+ "Contribution" shall mean any work of authorship, including
+ the original version of the Work and any modifications or additions
+ to that Work or Derivative Works thereof, that is intentionally
+ submitted to Licensor for inclusion in the Work by the copyright owner
+ or by an individual or Legal Entity authorized to submit on behalf of
+ the copyright owner. For the purposes of this definition, "submitted"
+ means any form of electronic, verbal, or written communication sent
+ to the Licensor or its representatives, including but not limited to
+ communication on electronic mailing lists, source code control systems,
+ and issue tracking systems that are managed by, or on behalf of, the
+ Licensor for the purpose of discussing and improving the Work, but
+ excluding communication that is conspicuously marked or otherwise
+ designated in writing by the copyright owner as "Not a Contribution."
+
+ "Contributor" shall mean Licensor and any individual or Legal Entity
+ on behalf of whom a Contribution has been received by Licensor and
+ subsequently incorporated within the Work.
+
+ 2. Grant of Copyright License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ copyright license to reproduce, prepare Derivative Works of,
+ publicly display, publicly perform, sublicense, and distribute the
+ Work and such Derivative Works in Source or Object form.
+
+ 3. Grant of Patent License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ (except as stated in this section) patent license to make, have made,
+ use, offer to sell, sell, import, and otherwise transfer the Work,
+ where such license applies only to those patent claims licensable
+ by such Contributor that are necessarily infringed by their
+ Contribution(s) alone or by combination of their Contribution(s)
+ with the Work to which such Contribution(s) was submitted. If You
+ institute patent litigation against any entity (including a
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
+ or a Contribution incorporated within the Work constitutes direct
+ or contributory patent infringement, then any patent licenses
+ granted to You under this License for that Work shall terminate
+ as of the date such litigation is filed.
+
+ 4. Redistribution. You may reproduce and distribute copies of the
+ Work or Derivative Works thereof in any medium, with or without
+ modifications, and in Source or Object form, provided that You
+ meet the following conditions:
+
+ (a) You must give any other recipients of the Work or
+ Derivative Works a copy of this License; and
+
+ (b) You must cause any modified files to carry prominent notices
+ stating that You changed the files; and
+
+ (c) You must retain, in the Source form of any Derivative Works
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
+
+ (d) If the Work includes a "NOTICE" text file as part of its
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
+
+ You may add Your own copyright statement to Your modifications and
+ may provide additional or different license terms and conditions
+ for use, reproduction, or distribution of Your modifications, or
+ for any such Derivative Works as a whole, provided Your use,
+ reproduction, and distribution of the Work otherwise complies with
+ the conditions stated in this License.
+
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
+ any Contribution intentionally submitted for inclusion in the Work
+ by You to the Licensor shall be under the terms and conditions of
+ this License, without any additional terms or conditions.
+ Notwithstanding the above, nothing herein shall supersede or modify
+ the terms of any separate license agreement you may have executed
+ with Licensor regarding such Contributions.
+
+ 6. Trademarks. This License does not grant permission to use the trade
+ names, trademarks, service marks, or product names of the Licensor,
+ except as required for reasonable and customary use in describing the
+ origin of the Work and reproducing the content of the NOTICE file.
+
+ 7. Disclaimer of Warranty. Unless required by applicable law or
+ agreed to in writing, Licensor provides the Work (and each
+ Contributor provides its Contributions) on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied, including, without limitation, any warranties or conditions
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+ PARTICULAR PURPOSE. You are solely responsible for determining the
+ appropriateness of using or redistributing the Work and assume any
+ risks associated with Your exercise of permissions under this License.
+
+ 8. Limitation of Liability. In no event and under no legal theory,
+ whether in tort (including negligence), contract, or otherwise,
+ unless required by applicable law (such as deliberate and grossly
+ negligent acts) or agreed to in writing, shall any Contributor be
+ liable to You for damages, including any direct, indirect, special,
+ incidental, or consequential damages of any character arising as a
+ result of this License or out of the use or inability to use the
+ Work (including but not limited to damages for loss of goodwill,
+ work stoppage, computer failure or malfunction, or any and all
+ other commercial damages or losses), even if such Contributor
+ has been advised of the possibility of such damages.
+
+ 9. Accepting Warranty or Additional Liability. While redistributing
+ the Work or Derivative Works thereof, You may choose to offer,
+ and charge a fee for, acceptance of support, warranty, indemnity,
+ or other liability obligations and/or rights consistent with this
+ License. However, in accepting such obligations, You may act only
+ on Your own behalf and on Your sole responsibility, not on behalf
+ of any other Contributor, and only if You agree to indemnify,
+ defend, and hold each Contributor harmless for any liability
+ incurred by, or claims asserted against, such Contributor by reason
+ of your accepting any such warranty or additional liability.
+
+ END OF TERMS AND CONDITIONS
diff --git a/.agents/skills/frontend-design/SKILL.md b/.agents/skills/frontend-design/SKILL.md
new file mode 100644
index 0000000..5be498e
--- /dev/null
+++ b/.agents/skills/frontend-design/SKILL.md
@@ -0,0 +1,42 @@
+---
+name: frontend-design
+description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
+license: Complete terms in LICENSE.txt
+---
+
+This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
+
+The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
+
+## Design Thinking
+
+Before coding, understand the context and commit to a BOLD aesthetic direction:
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
+- **Constraints**: Technical requirements (framework, performance, accessibility).
+- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
+
+**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
+
+Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
+- Production-grade and functional
+- Visually striking and memorable
+- Cohesive with a clear aesthetic point-of-view
+- Meticulously refined in every detail
+
+## Frontend Aesthetics Guidelines
+
+Focus on:
+- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
+- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
+- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
+- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
+- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
+
+NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
+
+**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
+
+Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
diff --git a/.agents/skills/grill-me/SKILL.md b/.agents/skills/grill-me/SKILL.md
new file mode 100644
index 0000000..bd04394
--- /dev/null
+++ b/.agents/skills/grill-me/SKILL.md
@@ -0,0 +1,10 @@
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
diff --git a/.agents/skills/grill-with-docs/ADR-FORMAT.md b/.agents/skills/grill-with-docs/ADR-FORMAT.md
new file mode 100644
index 0000000..da7e78e
--- /dev/null
+++ b/.agents/skills/grill-with-docs/ADR-FORMAT.md
@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.
diff --git a/.agents/skills/grill-with-docs/CONTEXT-FORMAT.md b/.agents/skills/grill-with-docs/CONTEXT-FORMAT.md
new file mode 100644
index 0000000..ddfa247
--- /dev/null
+++ b/.agents/skills/grill-with-docs/CONTEXT-FORMAT.md
@@ -0,0 +1,77 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A concise description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+
+## Relationships
+
+- An **Order** produces one or more **Invoices**
+- An **Invoice** belongs to exactly one **Customer**
+
+## Example dialogue
+
+> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
+> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed."
+
+## Flagged ambiguities
+
+- "account" was used to mean both **Customer** and **User** — resolved: these are distinct concepts.
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
+- **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution.
+- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.
+- **Show relationships.** Use bold term names and express cardinality where obvious.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+- **Write an example dialogue.** A conversation between a dev and a domain expert that demonstrates how the terms interact naturally and clarifies boundaries between related concepts.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.
diff --git a/.agents/skills/grill-with-docs/SKILL.md b/.agents/skills/grill-with-docs/SKILL.md
new file mode 100644
index 0000000..5ea0aa9
--- /dev/null
+++ b/.agents/skills/grill-with-docs/SKILL.md
@@ -0,0 +1,88 @@
+---
+name: grill-with-docs
+description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+---
+
+
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+
+
+
+
+## Domain awareness
+
+During codebase exploration, also look for existing documentation:
+
+### File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│ └── adr/
+│ ├── 0001-event-sourced-orders.md
+│ └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│ └── adr/ ← system-wide decisions
+├── src/
+│ ├── ordering/
+│ │ ├── CONTEXT.md
+│ │ └── docs/adr/ ← context-specific decisions
+│ └── billing/
+│ ├── CONTEXT.md
+│ └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+
+
diff --git a/.agents/skills/microinteractions/SKILL.md b/.agents/skills/microinteractions/SKILL.md
new file mode 100644
index 0000000..c82ef31
--- /dev/null
+++ b/.agents/skills/microinteractions/SKILL.md
@@ -0,0 +1,239 @@
+---
+name: microinteractions
+description: 'Design the small details -- triggers, rules, feedback, loops and modes -- that separate good products from great ones. Use when the user mentions "microinteraction", "button feedback", "loading state", "toggle design", "animation detail", "interaction polish", "state transitions", or "input feedback". Also trigger when designing form validation responses, progress indicators, confirmation dialogs, or any UI element where the user expects immediate feedback. Covers trigger design, state rules, feedback mechanisms, and progressive loops. For overall UI polish, see refactoring-ui. For affordance design, see design-everyday-things.'
+license: MIT
+metadata:
+ author: wondelai
+ version: "1.1.0"
+---
+
+# Microinteractions Framework
+
+A systematic approach to designing the tiny, contained product moments that users interact with every day -- toggles, password fields, loading indicators, pull-to-refresh, like buttons. Based on Dan Saffer's four-part structure (Trigger, Rules, Feedback, Loops & Modes), this framework turns invisible details into the polish that separates forgettable products from beloved ones.
+
+## Core Principle
+
+**The difference between a product you tolerate and a product you love is almost always in the microinteractions.** A microinteraction is a contained product moment built around a single use case: changing a setting, syncing data, setting an alarm, picking a password. They are so small that users rarely think about them consciously -- but they feel them. Every microinteraction follows the same four-part structure: a Trigger initiates it, Rules determine what happens, Feedback shows what is happening, and Loops & Modes define its long-term behavior.
+
+## Scoring
+
+**Goal: 10/10.** When reviewing or creating microinteractions, rate them 0-10 based on adherence to the principles below. A 10/10 means every interactive moment has a deliberate trigger, clear rules, immediate feedback, and thoughtful loop/mode behavior. Lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.
+
+## The Microinteraction Structure
+
+Six areas of focus for designing world-class microinteractions:
+
+### 1. Triggers
+
+**Core concept:** The trigger is what initiates a microinteraction. It can be manual (user-initiated -- a tap, click, swipe, voice command) or system-initiated (a condition is met -- time, location, incoming data, error state). The trigger is the front door of every microinteraction.
+
+**Why it works:** Without a clear trigger, users cannot discover or initiate the interaction. Without a system trigger, the product cannot respond to changing conditions. Well-designed triggers make functionality discoverable and set accurate expectations for what will happen next.
+
+**Key insights:**
+- Manual triggers live inside existing UI controls: buttons, switches, icons, form fields, gestures
+- System triggers fire automatically when conditions are met: time elapsed, threshold reached, data received
+- A trigger must communicate three things: that it exists, what it does, and what state it is in
+- Trigger affordance should match the importance of the action -- high-stakes actions need prominent triggers
+- Invisible triggers (gestures, shake, proximity) must be paired with a visible alternative for discoverability
+- Trigger states -- default, hover, active, disabled, loading -- must be visually distinct
+
+**Product applications:**
+
+| Context | Application | Example |
+|---------|-------------|---------|
+| **Toggle controls** | Manual trigger with binary state | iOS Wi-Fi switch: tap to toggle, position shows state |
+| **Pull-to-refresh** | Hidden gesture trigger with visible affordance | Pulling down past threshold triggers refresh animation |
+| **System alerts** | System trigger on condition met | Low battery notification at 20% threshold |
+| **Search fields** | Manual trigger with auto-suggest system trigger | Typing initiates search; results appear as system trigger |
+| **Hover reveals** | Manual trigger using proximity | Toolbar actions appear on card hover |
+
+**Ethical boundary:** Never hide critical triggers behind gestures or invisible interactions without a visible fallback. Users should always be able to discover essential functionality.
+
+See: [references/trigger-design.md](references/trigger-design.md)
+
+### 2. Rules
+
+**Core concept:** Rules determine what happens once a microinteraction is triggered. They define the sequence of events, the constraints on what can and cannot happen, the algorithm that processes input, and when the microinteraction ends. Rules are the invisible logic -- users never see them directly, but they feel when rules are wrong.
+
+**Why it works:** Rules create the mental model users build about how the interaction works. When rules are consistent and match expectations, the interaction feels natural. When rules violate expectations -- a toggle that does not toggle, a slider that jumps in value -- users lose trust.
+
+**Key insights:**
+- Define the goal of the microinteraction first, then derive rules from it
+- Rules should feel natural -- match existing mental models and platform conventions
+- Constrain inputs to prevent errors: limit character counts, set value ranges, enforce formats
+- Handle edge cases explicitly: what happens at zero, at maximum, on repeated triggers, on interruption
+- Simple rules produce complex-feeling interactions; complex rules produce confusing interactions
+- The best rules are invisible -- users do not think about them, they just work
+
+**Product applications:**
+
+| Context | Application | Example |
+|---------|-------------|---------|
+| **Password strength** | Rules evaluate input in real-time | Meter updates as user types; color shifts from red to green |
+| **Character counter** | Rule constrains and displays remaining | Twitter/X: counter decreases, turns red at limit |
+| **Volume control** | Rule maps input to output with constraints | Slider snaps to 5% increments; long-press mutes |
+| **Shopping cart** | Rules manage quantity and state | Cannot go below 1; shows "max 10" at limit |
+| **Undo action** | Rule sets time window for reversal | Gmail "Undo send" available for 30 seconds |
+
+**Ethical boundary:** Rules should be transparent and predictable. Do not create hidden rules that manipulate user behavior, such as making unsubscribe require more steps than subscribe.
+
+See: [references/rules-and-state.md](references/rules-and-state.md)
+
+### 3. Feedback
+
+**Core concept:** Feedback communicates the rules of the microinteraction to the user. It answers: "What is happening right now?" Feedback can be visual (color, animation, movement), auditory (clicks, chimes), or haptic (vibrations). The key constraint is showing only what matters -- minimal, meaningful, contextual.
+
+**Why it works:** Without feedback, users cannot tell if their action registered, if the system is working, or if the operation succeeded. Feedback closes the Gulf of Evaluation. Too little feedback creates anxiety; too much creates noise. The right feedback at the right time makes interactions feel responsive, trustworthy, and alive.
+
+**Key insights:**
+- Feedback must be immediate -- under 100ms for direct manipulation
+- Use the least noticeable feedback that still communicates: a subtle color change before a modal dialog
+- Feedback should map to the significance of the event: small action = small feedback, big result = big feedback
+- Visual feedback is primary; audio and haptic are supplementary and should never be the only channel
+- Progress indicators reduce perceived wait time even when actual time stays the same
+- Feedback should use existing elements when possible -- animate the button, not a separate notification
+
+**Product applications:**
+
+| Context | Application | Example |
+|---------|-------------|---------|
+| **Button press** | Visual state change on click | Button depresses, color shifts, text changes to "Saving..." |
+| **Form validation** | Inline feedback as user types | Green checkmark appears next to valid email field |
+| **File upload** | Progress indicator with percentage | Progress bar fills; percentage and estimated time shown |
+| **Error state** | Contextual error near the source | Red border on field + message "Password must be 8+ characters" |
+| **Success confirmation** | Brief, non-blocking affirmation | Checkmark animation replaces submit button for 1.5 seconds |
+
+**Ethical boundary:** Feedback should be honest. Do not use fake progress bars, manipulative countdown timers, or deceptive completion percentages to create false urgency.
+
+See: [references/feedback-patterns.md](references/feedback-patterns.md)
+
+### 4. Loops and Modes
+
+**Core concept:** Loops determine the meta-rules of a microinteraction -- what happens over time. Does the interaction change after the 100th use? Does it expire? Does it adapt? Modes are forks in the rules -- temporary states where the microinteraction behaves differently (e.g., edit mode vs. view mode).
+
+**Why it works:** Products that never evolve feel stale. Products that shift behavior unpredictably feel unreliable. Thoughtful loops let microinteractions mature gracefully -- reducing friction for power users while remaining discoverable for new ones. Modes, when used sparingly, let a single control serve multiple purposes without cluttering the interface.
+
+**Key insights:**
+- Open loops continue until explicitly stopped (a repeating alarm); closed loops run once and end (a timer)
+- Long loops change the microinteraction over time: first use might show a tooltip; 50th use does not
+- Progressive reduction: strip away scaffolding as users demonstrate mastery
+- Modes are dangerous -- they violate the principle that the same action should produce the same result
+- If you must use modes, make the current mode extremely visible (Caps Lock indicator, edit mode banner)
+- Avoid mode errors by minimizing the number of modes and making mode transitions deliberate
+
+**Product applications:**
+
+| Context | Application | Example |
+|---------|-------------|---------|
+| **Onboarding tooltips** | Long loop removes hints after N uses | First 3 sessions show "Swipe to archive"; then stop |
+| **Alarm clock** | Open loop repeats daily until disabled | Alarm fires every weekday at 7am until toggled off |
+| **Text editing** | Mode: view vs. edit | Banner reads "Editing" with a "Done" button to exit mode |
+| **Smart defaults** | Long loop learns preferences | Email app learns you always CC your manager; suggests it |
+| **Notification frequency** | Long loop adapts delivery | Reduces notifications if user ignores 5 in a row |
+
+**Ethical boundary:** Loops should benefit the user, not the business. Do not use adaptive loops to increase notification frequency or make opt-outs progressively harder.
+
+See: [references/loops-modes.md](references/loops-modes.md)
+
+### 5. Signature Moments
+
+**Core concept:** A signature moment is a microinteraction so distinctive that it becomes part of the product's identity. It transforms a functional necessity into a brand-defining detail -- the Facebook Like thumbs-up, the iPhone slide-to-unlock, Slack's loading messages. Not every microinteraction should be a signature moment, but every product should have one or two.
+
+**Why it works:** Signature moments create emotional memory. They make products feel crafted rather than assembled. When users describe your product to others, signature moments are what they demonstrate first. They turn utility into personality.
+
+**Key insights:**
+- Signature moments work best on frequent, visible actions -- not buried settings
+- They must be functional first, delightful second -- never sacrifice usability for novelty
+- Animation, sound, and copy are the three most common tools for creating signature moments
+- Signature moments should align with brand personality: playful brands get playful moments
+- Restraint matters -- if everything is a signature moment, nothing is
+- Test whether users would miss the detail if it were removed; if not, it is decoration, not signature
+
+**Product applications:**
+
+| Context | Application | Example |
+|---------|-------------|---------|
+| **Social reaction** | Animated response to engagement | Facebook Like: thumbs-up animates with particles |
+| **Loading state** | Branded waiting experience | Slack: rotating quotes during load |
+| **Completion** | Celebratory confirmation | Stripe payment: animated checkmark with confetti |
+| **Empty state** | Personality in absence of content | Dropbox: illustrated scenes with friendly copy |
+| **Error recovery** | Graceful failure with personality | GitHub 404: parallax Octocat illustration |
+
+**Ethical boundary:** Signature moments should never obscure important information or delay the user to show off an animation. Function always precedes delight.
+
+See: [references/signature-moments.md](references/signature-moments.md)
+
+### 6. Reducing and Simplifying
+
+**Core concept:** The best microinteraction is one the user barely notices because it is so simple and fast. Reduction means doing less -- fewer options, fewer steps, fewer decisions. Simplifying means making what remains feel effortless. The goal is to distill every microinteraction to its absolute essence.
+
+**Why it works:** Every option, field, and decision adds cognitive load. Users do not want to configure a toggle switch. They want the toggle to work. Reduction fights feature creep at the smallest level. The most elegant microinteractions have zero configuration, one action, and immediate results.
+
+**Key insights:**
+- If a microinteraction needs instructions, it is too complex
+- Remove options by choosing smart defaults -- pick the best choice and commit to it
+- Collapse multi-step interactions into a single action where possible
+- Use progressive disclosure: show simple first, reveal complexity only when requested
+- Avoid "settings within settings" -- if a microinteraction has its own preferences, reconsider
+- The number of rules should be proportional to the frequency of use: common actions need few rules
+
+**Product applications:**
+
+| Context | Application | Example |
+|---------|-------------|---------|
+| **Smart defaults** | Eliminate configuration | Camera app defaults to photo mode, not settings |
+| **Inline editing** | Remove modal, edit in place | Spreadsheet cell: click to edit, Enter to save |
+| **Auto-detection** | System handles instead of user | Credit card type detected from first digits |
+| **Single action** | One tap replaces multi-step flow | Double-tap to like instead of open menu, select reaction |
+| **Anticipatory design** | Predict and pre-fill | Shipping form pre-fills city and state from ZIP code |
+
+**Ethical boundary:** Simplification should not remove user control over meaningful choices. Do not auto-opt users into features that benefit the business at the user's expense.
+
+See: [references/trigger-design.md](references/trigger-design.md) for reducing trigger complexity.
+
+## Common Mistakes
+
+| Mistake | Why It Fails | Fix |
+|---------|-------------|------|
+| **No feedback on action** | Users do not know if their tap registered | Add immediate visual state change to every interactive element |
+| **Overdesigning simple moments** | Complex animations slow down frequent actions | Reserve rich animation for infrequent, high-impact moments |
+| **Ignoring edge cases** | Interaction breaks at zero, at max, or on double-tap | Map every state: empty, loading, partial, full, error, disabled |
+| **Invisible triggers** | Users cannot discover functionality | Pair gesture triggers with a visible alternative |
+| **Mode errors** | Same action produces different results depending on hidden state | Make current mode visible; minimize number of modes |
+| **Ignoring long loops** | Interaction feels the same on day 1 and day 100 | Use progressive reduction to streamline for returning users |
+| **Feedback overload** | Every action triggers a toast, sound, or animation | Use the smallest feedback that communicates; reserve big feedback for big events |
+| **Fake progress indicators** | Users feel deceived when they discover the bar is fake | Use honest, deterministic progress; show indeterminate spinner when unknown |
+
+## Quick Diagnostic
+
+Audit any microinteraction:
+
+| Question | If No | Action |
+|----------|-------|--------|
+| Is there a clear, discoverable trigger? | Users cannot initiate the interaction | Add a visible control or affordance |
+| Does the trigger show its current state? | Users cannot tell if it is on, off, or loading | Add distinct visual states for every trigger state |
+| Are the rules simple and predictable? | Users are confused by what happened | Simplify rules; match platform conventions |
+| Is there immediate feedback? | Users question whether their action worked | Add visual response within 100ms |
+| Does feedback match the significance of the event? | Small actions feel dramatic or big actions feel trivial | Scale feedback to match event importance |
+| Does the interaction evolve over time? | Power users are still seeing beginner hints | Add progressive reduction through long loops |
+| Is the interaction free of unnecessary modes? | Users perform wrong action in wrong mode | Remove modes or make current mode highly visible |
+| Could a first-time user figure it out without help? | Interaction needs explanation | Simplify or add a one-time hint via long loop |
+
+## Reference Files
+
+- [trigger-design.md](references/trigger-design.md): Manual and system triggers, trigger affordances, trigger states, invisible trigger design, placement and visibility
+- [rules-and-state.md](references/rules-and-state.md): Defining rules, state management, constraints, error states, edge cases
+- [feedback-patterns.md](references/feedback-patterns.md): Visual, audio, and haptic feedback, timing, progressive disclosure, preventing overload
+- [loops-modes.md](references/loops-modes.md): Open and closed loops, long loops, modes, mode errors, progressive complexity
+- [signature-moments.md](references/signature-moments.md): Brand-defining microinteractions, examples, when to invest, making mundane interactions delightful
+- [case-studies.md](references/case-studies.md): Detailed design breakdowns of form submission, toggle/switch, pull-to-refresh, loading states, and notifications
+
+## Further Reading
+
+This skill is based on Dan Saffer's definitive guide to designing the details that separate good products from great ones:
+
+- [*"Microinteractions: Designing with Details"*](https://www.amazon.com/Microinteractions-Full-Color-Designing-Details/dp/1491945923?tag=wondelai00-20) by Dan Saffer
+
+## About the Author
+
+**Dan Saffer** is a designer, author, and design leader who has led design teams at Twitter, Jawbone, and Smart Design. He is known for his work on interaction design at the detail level -- the small, contained moments that make up the bulk of user experience. *Microinteractions* codified a framework that design teams at companies worldwide use to audit, design, and improve the small details that make products feel polished and alive. Saffer has also authored *Designing for Interaction* and *Designing Gestural Interfaces*, and he speaks regularly at design conferences on the craft of interaction design.
diff --git a/.agents/skills/microinteractions/references/case-studies.md b/.agents/skills/microinteractions/references/case-studies.md
new file mode 100644
index 0000000..d6c70b5
--- /dev/null
+++ b/.agents/skills/microinteractions/references/case-studies.md
@@ -0,0 +1,371 @@
+# Microinteraction Case Studies
+
+Detailed design breakdowns of common UI patterns, analyzed through the four-part microinteraction structure: Trigger, Rules, Feedback, and Loops & Modes. Each case study documents the interaction from first use through edge cases, providing a practical blueprint for implementation.
+
+## Table of Contents
+1. [Case Study 1: Form Submission](#case-study-1-form-submission)
+2. [Case Study 2: Toggle / Switch](#case-study-2-toggle-switch)
+3. [Case Study 3: Pull-to-Refresh](#case-study-3-pull-to-refresh)
+4. [Case Study 4: Loading States](#case-study-4-loading-states)
+5. [Case Study 5: Notifications (Toast / Snackbar)](#case-study-5-notifications-toast-snackbar)
+6. [Cross-Cutting Patterns](#cross-cutting-patterns)
+
+---
+
+## Case Study 1: Form Submission
+
+A form submission microinteraction covers the moment from when the user taps "Submit" to when they receive confirmation of success or details of failure. It is one of the highest-stakes microinteractions because users have invested time and data.
+
+### The Four Parts
+
+**Trigger:**
+- Manual trigger: "Submit" button (primary action, full-width or prominent)
+- Keyboard trigger: Enter key in last field (convention, not always expected)
+- System trigger: Auto-save draft after 30 seconds of inactivity (background)
+
+**Rules:**
+1. On trigger, validate all required fields client-side before sending to server
+2. If validation fails, prevent submission and highlight first invalid field
+3. If validation passes, disable submit button and show loading state
+4. Send data to server
+5. On server success (200), show success feedback and redirect or reset form
+6. On server error (4xx/5xx), show error message and preserve all input
+7. On network timeout (>15 seconds), show retry option with preserved input
+
+**Feedback:**
+
+| State | Visual | Copy | Duration |
+|-------|--------|------|----------|
+| **Idle** | Blue "Submit" button, normal state | "Submit" or "Create Account" | Persistent |
+| **Validating** | Button briefly disabled | "Checking..." | 0-500ms |
+| **Validation error** | Red border on invalid fields, scroll to first error | "Please enter a valid email" inline | Until corrected |
+| **Submitting** | Button shows spinner, text changes | "Submitting..." | Server response time |
+| **Success** | Green checkmark replaces spinner | "Done! Redirecting..." | 1-2 seconds |
+| **Server error** | Red banner at top, button re-enabled | "Something went wrong. Please try again." | Until dismissed |
+| **Network error** | Yellow banner, retry button | "Connection lost. Your data is saved locally." | Until retry succeeds |
+
+**Loops & Modes:**
+- Auto-save loop: draft saved to local storage every 30 seconds (open loop)
+- Long loop: after 3+ submissions, hide optional tooltips and field hints
+- No modes (single-purpose interaction)
+
+### Edge Cases
+
+| Edge Case | Handling |
+|-----------|---------|
+| User double-clicks submit | Disable button on first click; debounce server request |
+| User navigates away mid-submission | Show "Unsaved changes" dialog; save draft to local storage |
+| Session expires during submission | Queue submission; re-authenticate and retry |
+| Very long form (20+ fields) | Show progress indicator; validate sections independently |
+| Paste of formatted text | Strip formatting; accept plain text only |
+| Autofill conflict | Accept autofill values; re-validate on submit |
+
+### Implementation Notes
+
+| Platform | Key Detail |
+|----------|-----------|
+| **Web** | Use `