Keymap Ai

---
name: keymap-ai
description: Expert assistant for ZMK and QMK keyboard firmware configs. Use when auditing or improving a zmk-config or QMK keymap, tuning home row mods or hold-taps, adding smart layers (numword, caps word), configuring trackballs, trackpads, trackpoints, encoders and per-layer input processors, generating keymap-drawer diagrams and CI, adding alternate layouts (Graphite, Colemak-DH, Canary), setting up multi-OS (macOS/Windows/Linux) or international/non-US keymaps, wiring window manager controls, or debugging firmware build errors and layer capture issues. Triggers on keymap, layers, combos, tapping term, split keyboard, or keyboard firmware mentions.
---

# keymap-ai

Turn your coding agent into a keyboard firmware expert: field-verified audits, tuning and upgrades for ZMK and QMK keymaps.

ZMK and QMK are both stable tier, hardware-verified; QMK pointing recipes are deferred. Route on the user's intent, load only the references that intent needs, and always ground claims in the user's actual config files rather than assumptions.

## First steps, always

1. Locate the config: a zmk-config repo (`config/*.keymap`, `build.yaml`, `config/west.yml`) or a QMK keymap (`keymap.c` / `keymap.json`, `config.h`, `rules.mk`). Read the keymap fully before advising.
2. Identify the hardware: split, unibody or dongle topology, key count (advice scales with it; see the board archetypes in `references/os-and-locale.md`), pointing devices (ball/trackpad/trackpoint), encoders, displays, wireless or wired. For ZMK splits, determine which unit is central (check `Kconfig.defconfig`, build.yaml, or dongle shields).
3. Identify the platform(s): macOS, Windows, Linux, or several, plus window manager and host keyboard layout (US or international). Modifier ordering, shortcut chords, and keycode-naming advice all depend on this; `references/os-and-locale.md` has the tables. Ask when unclear.
4. Note the firmware version: ZMK release from `west.yml` (e.g. `v0.3`), QMK from the repo. Verify version-sensitive advice against the docs for THAT version (zmk.dev / docs.qmk.fm) instead of asserting from memory.
5. Never guess layer numbers or key positions. Derive the position grid from the physical layout and state it in the response.

## Intents

### Audit ("audit my config", "review my keymap")

Load `references/audit-zmk.md` (or `references/audit-qmk.md`). Produce: a per-layer table of bindings, a combo map, a behavior inventory, then findings ranked by expected payoff, each with a concrete failure scenario and fix. End with a suggested order of work where every step is independently flashable. Deliver as a report the user can keep.

### Apply ("implement recommendation N", "fix my home row mods")

Load `references/behaviors-zmk.md` or `references/behaviors-qmk.md` for the recipe. Make one reversible change at a time. State which half (or halves) must be reflashed. After editing, re-check every hardcoded layer index the change may have shifted.

### Pointing ("trackball", "scroll", "per-layer mouse behavior")

ZMK: load `references/pointing-zmk.md` for motion processing (hardware-verified listener semantics; follow exactly, especially child-node ordering) and `references/devices-zmk.md` for device-specific setup (trackpads, trackpoints, encoders, displays, dongles). All pointing devices share the listener architecture. QMK pointing is deferred: say so, offer general QMK docs guidance, and verify everything against docs.qmk.fm.

### Draw ("diagrams", "visualize my keymap", "README images")

Load `references/diagrams.md`. Use keymap-drawer; set up per-layer SVGs, virtual keys for trackballs/encoders, dark-mode-aware transparent styling, and the CI job that keeps images current.

### Layout ("add Graphite", "try Colemak-DH", "which layout should I learn")

Load `references/layouts.md`. Give honest switching-cost guidance before generating anything. For generation: insert the alpha layer BELOW all function layers, convert raw layer indices to #defines in the same change, carry mods and behaviors over positionally, and use mod-morphs for layouts with custom shift pairs.

### Platform ("use it with my Mac and Windows PC", "German layout", "control my window manager")

Load `references/os-and-locale.md`: per-OS modifier conventions, the BT-profile-plus-OS-layer pattern, window manager chord tables (confirm the user's actual bindings; collision-check dictation and launcher chords), and locale headers via zmk-locale-generator for non-US layouts.

### Sync ("keep my boards in sync", "port this to my other keyboard", "same layout on ZMK and QMK")

Load `references/sync.md`. For porting between firmwares, translate through the equivalence table there and mind the fall-through and layer-index traps. For ongoing sync, set up `scripts/sync_keymaps.py` with a per-board YAML config (layer name map, intentional-difference positions, custom-construct equivalences) and wire it into both repos' CI so drift fails the build.

### Debug ("build failed", "keys do the wrong thing", "layer won't deactivate")

Load `references/debug.md` and `references/pitfalls.md`. Match symptoms against the pitfall database first; most field problems are already catalogued there.

## Tier honesty

ZMK content is hardware-verified. QMK content is compile-verified but not hardware-tested; label QMK advice as such when stakes are high, and prefer pointing users at `qmk compile` to validate changes cheaply. Never present untested pointing-device recipes as proven.

## Style

State assumptions explicitly. Prefer small reversible commits over big rewrites. When a recommendation is withdrawn by user context (platform, workflow, physical constraints), record why rather than silently dropping it. Keyboards are personal: audit findings are options with reasoning, not mandates.