feat: implement branded discord embeds and versioning

.agent/skills/create-ticket/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: create-ticket
+description: Create a ticket for a task that needs to be worked on.
+---
+
+# Skill: create-ticket
+
+## Purpose
+
+Decompose high-level objectives into "Atomic Tickets" to maximize development velocity and minimize cognitive overhead.
+
+## Execution Rules
+
+1. **Directory Check:** Scan `.agent/work/tickets/`. Determine sequence number `NNN`.
+2. **Naming:** `.agent/work/tickets/NNN-brief-description.md`.
+3. **The Atomic/Velocity Test:** - Max 3 files modified.
+   - Max 80 lines of logic.
+   - Must be verifiable via a single command or test suite.
+   - If it exceeds these, **split it.**
+4. **Context Injection:** Include relevant code snippets or interface definitions directly in the ticket to prevent "context hunting."
+5. **No Breaking Changes:** If a ticket changes a shared interface, it must include the refactor for consumers or be split into a "Transition" ticket.
+
+## Ticket Template
+
+### Context & Goal
+
+[Why this matters + the specific problem it solves.]
+
+### Dependencies
+
+- [e.g., Ticket #NNN]
+
+### Affected Files
+
+- `path/to/file_A.ext`: [Specific change description]
+- `path/to/file_B.ext`: [Specific change description]
+
+### Technical Constraints & Strategy
+
+- [e.g., Implementation: Use the existing X wrapper instead of a new fetch call.]
+- [e.g., Constraint: Maintain backward compatibility with Y.]
+
+### Definition of Done (Binary)
+
+- [ ] Criterion 1 (e.g., `npm test` passes for `X.test.ts`)
+- [ ] Criterion 2 (e.g., UI component renders without hydration errors)
+- [ ] Criterion 3 (e.g., API response matches the schema in `types.ts`)
+
+### New Test Files
+
+- `path/to/test_A.ext`: [What is being tested]

.agent/skills/review/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: code-review
+description: A "Default-to-Fail" audit of codebase changes. Observation only; no file modifications.
+---
+
+# Skill: code-review
+
+## Purpose
+
+Protect the codebase from "feature creep," technical debt, and weak validation. This skill assumes the latest changes are flawed until they pass a rigorous audit.
+
+## Execution Rules
+
+1. **Read-Only Protocol:** This is a diagnostic skill. **Under no circumstances should any files be modified.** Provide feedback only.
+2. **Default-to-Fail:** Assume the code is broken or insufficient. The burden of proof lies on the code and its tests.
+3. **The Atomic Veto:** - Check the diff. If it exceeds 3 files or 80 lines of logic, **Veto immediately.**
+   - Reason: "Change exceeds atomic threshold; high risk of cognitive load."
+4. **Strictness Audit (Tests):**
+   - **Veto** if assertions are fuzzy (e.g., `toBeTruthy()`).
+   - **Veto** if there is no "Red Path" (failure case) test.
+   - **Veto** if the test is "loose" (e.g., doesn't check specific property values).
+5. **Direct Feedback:** No sycophancy. Use "Blockers" for issues and "Verdict: APPROVE" only when the code is bulletproof.
+
+## Review Template
+
+### Verdict: [FAIL / APPROVE]
+
+**Primary Blocker:** [One sentence identifying the biggest reason for rejection.]
+
+---
+
+### 1. Atomic Constraint Check
+
+- **Files Changed:** [Count] / 3
+- **Logic Lines:** [Count] / 80
+- **Status:** [PASS / FAIL (Veto if FAIL)]
+
+### 2. Test Strictness Audit
+
+- **Assertion Quality:** [List specific lines with fuzzy matchers. Demand strict equality.]
+- **Failure Coverage:** [Does a test exist for the 'Error/Empty' state? If no, FAIL.]
+- **Logic Sync:** [Does the test actually exercise the logic added, or just side effects?]
+
+### 3. Logic & Resilience
+
+- **Unchecked States:** [Identify unhandled nulls, undefineds, or missing error catches.]
+- **Efficiency:** [Is there a faster path or a redundant operation?]
+
+### 4. Direct Actionables
+
+_Note: The reviewer does not apply these. The user/agent must create a ticket or apply fixes manually._
+
+1. [Specific fix for Blocker 1]
+2. [Specific fix for Blocker 2]