@@ -0,0 +1,14 @@
+# Local, machine-specific settings (not shared)
+settings.local.json
+
+# Claude Code worktrees
+worktrees/
+# Local plan/scratch artifacts, if any
+/plans/
+
+# Session/runtime artifacts
+projects/
+todos/
+shell-snapshots/
+statsig/
+.credentials.json
@@ -0,0 +1,88 @@
+---
+name: architecture-review
+description: Review a code change against Code On The Go's architecture — ARCHITECTURE.md and the ADRs in docs/adr/. Forces a read of those authoritative docs (they are NOT reliably in context otherwise), then checks the diff against UDF/state, Koin DI, Room-vs-SQLite, Compose, module boundaries, ABI flavors, dependency substitution, @Parcelize, and strings placement, reporting violations with the ADR/section each comes from. Use when asked to review architecture alignment, check a change against ARCHITECTURE.md/the ADRs, or as the §10 step of a code review.
+metadata:
+  author: Hal Eisen
+  keywords:
+  - architecture
+  - review
+  - adr
+  - udf
+  - code-review
+  - codeonthego
+---
+
+## Why this is a skill (not just REVIEW.md §10)
+
+ARCHITECTURE.md (~4.9k tokens) and the ADRs (~7.3k) are **not** in context during normal work, and prose links in REVIEW.md are not reliably followed. This skill exists to **guarantee the read**: it opens the authoritative docs, then checks the diff against them. Do not review architecture from memory or from the summary in this file alone.
+
+## When to invoke
+
+- "Review this against the architecture / ARCHITECTURE.md / the ADRs."
+- "Does this change follow our patterns?" / architecture-alignment review.
+- As the §10 step of a full code review — its output feeds REVIEW.md's evidence ledger.
+
+## Step 1 — Scope the diff
+
+Pick the target and get the changed files + hunks:
+- Working tree: `git diff --stat` and `git diff`.
+- This branch vs the integration branch: `git diff origin/stage...HEAD` (feature branches are based on `stage`).
+- A GitHub PR: `gh pr diff <N>`.
+
+**Exclude vendored/generated code** — it's not held to our patterns: `composite-builds/build-deps*`, `subprojects/{aaptcompiler,builder-model-impl,flashbar,xml-dom}`, `termux/`, `eventbus/`, `LayoutEditor/`, `**/build/`, generated `R`/`BuildConfig`. Review only first-party Kotlin/Java/XML/Gradle changes.
+
+## Step 2 — READ the authoritative docs (mandatory)
+
+Before judging anything, read:
+- `ARCHITECTURE.md` (whole file — module map, dependency rules, tech stack, **State Management**, testing).
+- **Every** file in `docs/adr/*.md`. At minimum open the ones a diff can plausibly violate: 0001 (Room), 0003 (substitution), 0005 (flavors), 0006 (Koin), 0009 (Compose). Read the rest if the change is broad.
+
+Do not skip this because the rules "look familiar" — they are the source of truth and they change.
+
+## Step 3 — Check the diff against the rules
+
+For each changed first-party file, check the applicable rules. Each rule cites its source so findings are traceable.
+
+| # | Rule | Source |
+|---|---|---|
+| 1 | **UDF:** new screens use `ViewModel` + `StateFlow<UiState>`, sealed `UiEvent`/`UiEffect`, a repository for data; composables collect via `collectAsStateWithLifecycle()` (lifecycle-aware, Android's strongly-recommended default; `collectAsState()` is only for platform-agnostic/KMP code, which we don't have); no I/O or business logic in composables/Activities/Fragments. | ARCHITECTURE.md → State Management |
+| 2 | **Sealed state for mutually-exclusive states** (loading/content/error/…): not a `data class` of independent `Boolean`s that can contradict each other ("boolean hell"). | ARCHITECTURE.md → State Management |
+| 3 | **Koin DI**, constructor injection; register new singletons/ViewModels in the module. No hand-rolled singletons/service locators (the documented `ServiceLocator` aside). | ADR 0006 |
+| 4 | **Persistence:** Room is the default for relational data; raw SQLite only for a justified exception (prebuilt read-only DB, perf/allocation-critical indexing, cross-boundary schema) — and the PR must say which. Non-relational → filesystem/preferences (DataStore). | ADR 0001 |
+| 5 | **`@Parcelize`** (`kotlin-parcelize`) for `Parcelable`; never hand-implement it unless Parcelize genuinely can't. | ARCHITECTURE.md → Parceling |
+| 6 | **New UI is Jetpack Compose** — a new XML-layout / `Fragment`-rendered screen for the IDE's own UI is a violation (existing XML screens are fine until reworked). | ADR 0009 |
+| 7 | **Module boundaries / dependency direction:** UI → ViewModel → Repository → data source; features depend on `common`/`utils`, not the reverse; no new cross-feature or upward dependency. | ARCHITECTURE.md → module map |
+| 8 | **ABI flavors:** new Android modules get `v7`/`v8` via `composite-builds/build-logic` centrally — no per-module flavor blocks, no flavorless `assembleDebug`. (`:plugin-api` is intentionally flavorless.) | ADR 0005 |
+| 9 | **Dependency substitution:** don't add a Maven coordinate for something already vendored/substituted (`build-deps*`); don't add a new dependency without checking `gradle/libs.versions.toml` first. | ADR 0003 |
+| 10 | **Strings** live in the `:resources` module's `strings.xml` (not per-module, not inline literals). | REVIEW.md §7 |
+| 11 | **UI never drawn over the two system bars** (top status bar, bottom navigation bar). | CLAUDE.md |
+| 12 | **Text scales:** new/changed screens verified at font scale 1.0 and 2.0 — `sp` for text and `dp` for spacing (no `sp` dimen used as margin/padding), no text boxed in a fixed `dp` size, a scroll container on content that can grow, and `maxLines`/`singleLine`/`ellipsize` only on genuinely disposable text. | CLAUDE.md, REVIEW.md §8 |
+
+Rules 1, 2, 6, 10, 11, 12 apply to UI changes; 4, 5 to data/model changes; 8, 9 to Gradle changes; 3 wherever a dependency, singleton, or ViewModel is introduced; 7 wherever a module's dependencies or cross-module imports change. Any rule not listed here is still checked whenever the diff touches its subject. Judge by what the diff touches — don't flag rules a file doesn't engage.
+
+For a **large diff (~15+ first-party files)**, fan out: spawn a subagent per dimension (UI/state, DI, persistence, Gradle/modules), each instructed to read the relevant ADR and report only its dimension's findings; then merge. For a small diff, do it inline.
+
+## Step 4 — Report
+
+Output a findings table, most-severe first. Every finding must cite the rule source and give a concrete fix. If a rule was checked and passes, say so (the evidence ledger wants pass/fail, not silence).
+
+```
+### Architecture review — <scope>
+Docs read: ARCHITECTURE.md, docs/adr/0001,0003,0005,0006,0009 (+others as needed)
+
+| Verdict | File:line | Rule | Source | Fix |
+|---|---|---|---|---|
+| ❌ | ui/FooScreen.kt:42 | Mutually-exclusive state as booleans | ADR 0001 sibling / State Mgmt | Model as a sealed FooUiState (Loading/Content/Error) |
+| ⚠️ | data/BarStore.kt:10 | Raw SQLite without stated justification | ADR 0001 | Use Room, or state which exception applies in the PR |
+| ✅ | — | Koin DI | ADR 0006 | new VM registered in module, constructor-injected |
+
+Summary: <n> violations, <n> warnings, <n> checks passed.
+```
+
+- **❌ violation** = contradicts a rule; blocking. **⚠️ warning** = likely issue / missing justification. **✅** = checked and clean.
+- If nothing architectural changed (e.g. a docs- or test-only diff), say so explicitly rather than inventing findings.
+
+## Notes
+
+- This is a *conformance* check against our documented patterns — not a general bug hunt (use `/code-review` for correctness). Keep findings tied to a specific ADR/section.
+- If a rule seems wrong or outdated for the change at hand, flag it as a possible ADR update rather than forcing the code to fit — the ADRs are `Proposed`, not immutable.
@@ -0,0 +1,172 @@
+---
+name: retro
+user-invocable: true
+description: Run a retrospective with transcript analysis and log feedback. Use when the user explicitly invokes /retro, when a full plan implementation is complete, or after creating a PR or addressing code review feedback (if a retro hasn't happened yet this session).
+---
+# Retrospective
+
+Run this skill when:
+- The user explicitly invokes `/retro`
+- A full plan implementation is complete (all work packages done and verified)
+- After creating a PR (offer a quick retro, if a retro hasn't happened yet this session)
+- After receiving and addressing code review feedback (offer, if a retro hasn't happened yet this session)
+
+For the last two triggers, use a lightweight prompt: "Good moment for a quick retro. Want me to run `/retro`?" Do NOT auto-run — just offer. If the user declines, move on.
+
+## Session Mode
+
+Determine whether this is a **human-led** or **autonomous** session:
+- **Human-led**: A human is actively participating in the conversation (they've been sending messages, answering questions, etc.)
+- **Autonomous**: The agent is running independently (ticket agent, background task, no human interaction in the session)
+
+This affects Steps 3 and 5 below. All other steps run the same regardless of mode.
+
+## Steps
+
+1. **Session time analysis**: Run the transcript analysis script to extract timing data. Do NOT write custom parsing code or use a subagent for JSONL extraction. Note the current time before starting — you'll record how long this analysis took in the retro log.
+
+   **How to run the analysis:**
+   - Find the transcript: glob `~/.claude/projects/<converted-cwd>/*.jsonl` sorted by modification time (convert cwd slashes to dashes, e.g., `/Users/me/myproject` → `-Users-me-myproject`). Pick the most recent.
+   - Run the script: `python3 scripts/analyze_transcript.py <path-to-jsonl>` — the script lives in `scripts/` alongside this SKILL.md.
+   - The script outputs: per-turn breakdown (full user text, assistant word count, tools, errors) and timing stats (reading at 150 wpm, typing at 60 wpm, 1 min buffer per turn, overlapping turns merged).
+   - System-injected messages (skill injections, /mcp outputs, system reminders) are automatically filtered out.
+
+   **What you do with the output:**
+   - Read the turn-by-turn output to understand what happened
+   - Group turns into high-level phases (plan, build, review, etc.) based on what was being worked on
+   - Use the adjusted hands-on time as the hands-on metric
+   - Identify pain points from the turn data: errors, user corrections, repeated tool calls
+
+   Present as a time breakdown table with proportional bars and a metrics summary:
+
+   | Started | Phase | 👤 Hands-On Time | 🤖 Agent Time | Problems |
+   |---------|-------|-----------------|---------------|----------|
+   | Feb 10 10:00am | Build (engine restart, voice recog, UI tweaks) | ██████ 60m | ███ 30m | ⚠ 5 fix cycles |
+   | Feb 10 11:30am | Research (BT routing for AirPods + external mics) | | █████ 45m | |
+   | Feb 10 1:00pm | Review (code review, docs, feedback log) | | ██ 15m | |
+
+   **Format rules:**
+   - **Started**: Date and wall-clock time when the phase began (from transcript timestamps)
+   - **Bars**: Use █ blocks proportional to time (each █ ≈ 10min), followed by the minute label (e.g., `███ 30m`)
+   - **Empty cells**: Leave the column blank if that role wasn't involved in the phase
+   - **Problems**: Inline with ⚠ marker — only for phases that had real friction or rework
+   - **Sort**: Chronological (by start time)
+   - **Brevity**: Keep the table to 10 rows max. A 4-row table is better than a 12-row table.
+
+   | Metric | Duration |
+   |--------|----------|
+   | Total wall-clock | X hours |
+   | Hands-on | X hours (Y%) |
+   | Automated agent time | X hours (Y%) |
+   | Idle/away | X hours (Y%) |
+
+2. **Key observations from transcript**: Before asking the user for feedback, identify patterns yourself:
+   - Where did Claude work most independently? Why?
+   - Where were the most user interactions needed? What caused them?
+   - Were there avoidable back-and-forth cycles (bugs that better testing would have caught, unclear requirements that better planning would have resolved)?
+   - What was the ratio of productive work to debugging/rework?
+
+   In human-led mode, present these observations to the user as conversation starters. In autonomous mode, use them as input to Step 4. For each observation, also suggest what kind of action might address it (see Step 4 for action types).
+
+3. **Gather feedback** (mode-dependent):
+
+   **Human-led mode:** Ask the user in a single prompt:
+   - What worked well in how we approached this?
+   - What was frustrating or slower than expected?
+   - Anything I should do differently?
+
+   Wait for their response — don't assume or fill in answers.
+
+   **Autonomous mode:** Skip this step. Use only the transcript observations from Step 2 as input to Step 5.
+
+4. **Propose concrete actions**: For each issue identified (from your observations in Step 2 AND the user's feedback from Step 3 if human-led), investigate the right action and propose a specific deliverable.
+
+   **4a. Launch CLAUDE.md review in parallel.** While investigating actions below, launch a Task agent (`general-purpose` type) to audit CLAUDE.md. In the prompt, include your key observations from Step 2 and the user's feedback from Step 3 (if human-led). The agent should:
+   - Glob for all `**/CLAUDE.md` files in the project
+   - Read each one and evaluate whether any sections need additions or updates based on the session observations and feedback you provided
+   - Return specific proposed edits (section + exact change), not vague suggestions
+   - If nothing needs changing, say so
+
+   Call this Task in the same message as your first tool calls for 4b — they'll run in parallel naturally. Do NOT use `run_in_background`.
+
+   **4b. Investigate actions for each issue.** Each action must be one of these types:
+
+   | Action Type | When to use | What to do |
+   |-------------|-------------|------------|
+   | **Update a skill** | A skill's behavior caused the issue, or a skill should enforce a new practice | Read the skill's SKILL.md, propose the specific edit |
+   | **Update CLAUDE.md** | A new rule or convention should be followed in all future sessions | Propose the specific addition to the relevant section |
+   | **Update docs** | Architecture, decisions, or learnings are wrong/missing | Propose the specific edit to the doc |
+   | **Create a ticket** | The fix requires implementation work beyond a doc/config change | Draft the ticket title + description |
+   | **No action needed** | The issue was a one-off or already resolved | Explain why no systemic fix is needed |
+
+   For each proposed action:
+   1. Read the file you'd change (skill, CLAUDE.md, doc)
+   2. Identify the specific section to edit
+   3. Draft the exact change (not a vague suggestion)
+
+   **4c. Merge CLAUDE.md review results.** When the subagent returns, incorporate its recommendations into your action proposals. Deduplicate with actions you've already proposed — if the subagent suggests something you've already covered, note it as reinforcement rather than listing it twice.
+
+   **Example — good:**
+   > Issue: Agent didn't check learnings.md before writing HTTP client code.
+   > Action type: Update CLAUDE.md
+   > File: CLAUDE.md → "Before Making Changes" section
+   > Change: Add "Check `docs/process/learnings.md` when writing code that touches external services"
+
+   **Example — bad:**
+   > Issue: Agent didn't check learnings.md before writing HTTP client code.
+   > Action: "We should remember to check learnings next time."
+
+5. **Approve and execute actions** (mode-dependent):
+
+   **Human-led mode:** Present all proposed actions (from 4b and 4c) to the user and ask which ones they'd like to take. Execute approved actions; skip declined ones.
+
+   **Autonomous mode:** Execute actions that are low-risk and reversible (doc updates, learnings additions, ticket creation). Do NOT execute actions that change skill behavior or CLAUDE.md without human review — log these as "proposed but deferred" in the retro entry.
+
+6. **Log to `docs/process/retrospective.md`** using this format:
+```markdown
+   ## YYYY-MM-DD - [Brief context of what we worked on]
+
+   ### Time Breakdown
+   | Started | Phase | 👤 Hands-On Time | 🤖 Agent Time | Problems |
+   |---------|-------|-----------------|---------------|----------|
+   | ... | ... | ... | ... | ... |
+
+   ### Metrics
+   | Metric | Duration |
+   |--------|----------|
+   | Total wall-clock | X hours |
+   | Hands-on | X hours (Y%) |
+   | Automated agent time | X hours (Y%) |
+   | Idle/testing/away | X hours (Y%) |
+   | Retro analysis time | X min |
+
+   ### Key Observations
+   - [Patterns identified from transcript]
+
+   ### Feedback
+   **What worked:** [User's feedback, or "N/A — autonomous session" if autonomous]
+   **What didn't:** [User's feedback, or "N/A — autonomous session" if autonomous]
+
+   ### Actions Taken
+   | Issue | Action Type | Change |
+   |-------|-------------|--------|
+   | [Issue description] | Skill / CLAUDE.md / Doc / Ticket | [Specific change made or ticket created] |
+```
+
+7. **Elevate to learnings**: Review the session for things worth adding to `docs/process/learnings.md`:
+  - Technical gotchas or surprises
+  - Patterns that worked well
+  - Mistakes to avoid repeating
+  - API quirks, environment issues, or tooling discoveries
+
+   **Propose specific additions**, e.g.:
+   > "Based on this session, I'd suggest adding to learnings.md:
+   > `## [Category]`
+   > `- [Specific learning]`
+   > Want me to add it?"
+
+   Don't just ask "anything to add?" - identify candidates yourself.
+
+8. **Commit** all retro changes (actions, retrospective log, learnings) with message: `docs: retro for [brief context]`
+
+9. **Confirm** what was logged and what actions were taken.