reTerminal Sticky agent skill

Teaches your coding agent how the Seeed Studio reTerminal Sticky actually works. The Sticky is an ESP32-S3 board with a 3.97 inch 800x480 e-ink panel, capacitive touch, and a 750 mAh battery, sold as a magnetic fridge note device.

Built to the Agent Skills standard, so it runs in Claude Code, Codex, OpenCode, pi, Cursor, Gemini CLI and anything else that implements the format. The agent pulls it in on its own when you ask about Sticky firmware, pin assignments, display refresh, touch handling, ESPHome configs, or submitting to the Playground registry.

Why I built it

Ask any model about this board and it will invent a pin map with total confidence.

There is no Seeed wiki page for the Sticky. Both wiki.seeedstudio.com/reterminal_sticky/ and /sticky/ return 404. The official docs at seeedstudio.com/sticky/docs went up recently and Seeed says they are still being written. Meanwhile the only public code known to run on production hardware sits inside the Playground registry, in a community 2048 game whose author shipped complete ESP-IDF source.

So I read both. The device guide supplied the pin tables. The registry source supplied what the docs leave out, like the exact power latch sequence and the way the touch transform has to mirror whatever display rotation you chose. Where the two disagree, the skill says so rather than picking a winner.

Install

The quickest route covers every agent at once. Run this in your project, or add -g for a global install:

npx skills add varo6/reTerminal-sticky-skill

That writes the skill to .agents/skills/sticky-device, which Codex, OpenCode and pi all read natively, then symlinks it into .claude/skills/ for Claude Code. Pass -a to choose targets, for example -a codex -a opencode.

As a Claude Code plugin

Claude Code can install it as a versioned plugin instead, which means updates arrive through the plugin manager:

/plugin marketplace add varo6/reTerminal-sticky-skill
/plugin install sticky-device@reterminal-sticky

By hand

Copy skills/sticky-device/ into whichever directory your agent scans.

Agent Project Global
Codex .agents/skills/ ~/.agents/skills/
OpenCode .opencode/skills/, .agents/skills/ ~/.config/opencode/skills/, ~/.agents/skills/
pi .pi/skills/, .agents/skills/ ~/.pi/agent/skills/, ~/.agents/skills/
Claude Code .claude/skills/ ~/.claude/skills/

.agents/skills/ is the shared path, so a single copy there covers Codex, OpenCode and pi together:

git clone https://github.com/varo6/reTerminal-sticky-skill
mkdir -p ~/.agents/skills
cp -r reTerminal-sticky-skill/skills/sticky-device ~/.agents/skills/

Invoking it

Most agents pick the skill up on their own from its description. To force it, Codex uses $sticky-device, pi uses /skill:sticky-device, and OpenCode exposes it through its built-in skill tool.

What it knows that the datasheet won't tell you

Two mistakes will eat your first evening with this board.

Firmware latches the power rail. Drive GPIO 45 high and pulse GPIO 46 in the first moments of app_main(), or the rail drops the instant you let go of the power button. The device looks bricked. It isn't.

The panel is 800x480 landscape in hardware, and the two public reference implementations disagree about what to do with that. Seeed's dashboard demo draws landscape and rotates 180 degrees. The registry's 2048 game draws portrait and rotates 270 with mirror_x set. Neither is wrong. Pick one, rotate in exactly one function, then make the touch layer match. Mix them and you get a screen that looks perfect above a touch layer rotated 90 degrees, which is a genuinely miserable afternoon.

Smaller things it gets right. sticky_display_refresh_partial() submits a whole frame instead of a rectangle, so you have to white-fill the area you are replacing or the old glyphs sit underneath the new ones. GPIO 7 is documented as the IMU interrupt in one place and the fuel gauge interrupt in another, and the skill flags the conflict instead of guessing.

Layout

SKILL.md is short on purpose. It routes. Asking about the pin map should not drag the registry schema into context, so the detail lives in files the agent reads only when it needs them.

File Covers
references/hardware.md Full GPIO map, bus topology, power subsystem, known ambiguities
references/esp-idf-dev.md Toolchain, project skeleton, working sdkconfig.defaults, the power latch, deep sleep, failure table
references/display.md seeed_epaper API, framebuffer layout, rotation, refresh modes, ghosting
references/peripherals.md Touch transform and gesture thresholds, buttons, sensors, mic, SD
references/playground-registry.md Full integration.json schema, both contribution paths, validation, CI
references/ecosystem-and-docs.md Every doc URL, the wiki situation, existing firmware projects, ESPHome

There is also a script that pulls the working drivers out of the registry, seeed_epaper, gt911 and bq27220, using a sparse checkout. About 500 KB instead of cloning the full 104 MB.

skills/sticky-device/scripts/fetch_sticky_sources.sh ./vendor

Scope

This is a documentation skill. It does not flash your device, generate firmware, or talk to hardware over serial. All it does is stop your agent from guessing.

It is also a snapshot. Seeed's docs are moving and the registry schema is versioned, so check anything time sensitive against the source before trusting it. Items marked unverified are marked that way for a reason.

Not affiliated with Seeed Studio.

Contributing

Measurements from real hardware are worth more than anything else you could send. If you settle one of the unverified items, meaning the GPIO 7 interrupt owner, microSD timing, or PDM mic configuration, open a PR or an issue and say what you measured and how.

If you add material, keep SKILL.md short. Detail belongs in references/, and those files stay one level deep so agents read them whole instead of skimming.

License

MIT. The reference material is distilled from Seeed's public documentation and from MIT-licensed registry sources by their respective authors.