Quick recap​

In my previous post, I tore the thing apart and identified what's inside:

• An ESP-12S module (ESP8266 with 4MB flash and WiFi)
• A 1.54" 240x240 IPS LCD driven by an ST7789 controller over SPI
• A CH340K USB-to-serial chip for programming
• The board is helpfully labeled "ESP 1.54-LCD v1.0"

The pin mapping for the display (which I figured out by tracing the PCB) is:

Now let's actually make it do something.

Installing the driver​

The CH340K needs a driver on macOS. Download it from the WCH github and install it.

Here's the gotcha: after installing, macOS blocks the system extension until you manually approve it. It took me a while to figure out why I could not connect to my device until some googling gave me the answer. Go to System Settings > General > Login Items & Extensions > Driver Extensions and allow it. You can verify it's active with:

systemextensionsctl list

Once approved, plug the board in and check:

ls /dev/cu.wchusbserial*

You should see something like /dev/cu.wchusbserial21310.

Setting up PlatformIO​

I'm using PlatformIO to build and flash. Install it with:

brew install platformio

Create a new project:

mkdir hello-display && cd hello-display
pio init --board esp12e

Now replace the generated platformio.ini with this configuration:

[env:esp8266]
platform = espressif8266
board = esp12e
framework = arduino
monitor_speed = 115200
monitor_rts = 0
monitor_dtr = 0
upload_port = /dev/cu.wchusbserial*
monitor_port = /dev/cu.wchusbserial*
lib_deps =
    TFT_eSPI
build_flags =
    -DUSER_SETUP_LOADED=1
    -DST7789_DRIVER=1
    -DTFT_WIDTH=240
    -DTFT_HEIGHT=240
    -DTFT_MISO=-1
    -DTFT_MOSI=13
    -DTFT_SCLK=14
    -DTFT_CS=15
    -DTFT_DC=2
    -DTFT_RST=0
    -DLOAD_GLCD=1
    -DLOAD_FONT2=1
    -DLOAD_FONT4=1
    -DSPI_FREQUENCY=40000000

A few things to note:

• USER_SETUP_LOADED=1 tells TFT_eSPI to skip its own config file and use our build flags instead. This is way cleaner than editing the library's User_Setup.h.
• monitor_rts = 0 and monitor_dtr = 0 prevent the serial monitor from resetting the board every time you connect. The CH340K's DTR/RTS lines trigger a reset by default, which is super annoying when you're just trying to watch logs.
• The pin numbers match the board's SPI wiring to the ST7789 display.

The firmware​

Create src/main.cpp:

#include <Arduino.h>
#include <TFT_eSPI.h>

TFT_eSPI tft = TFT_eSPI();

void setup() {
    Serial.begin(115200);
    Serial.println("Hello World!");

    tft.init();
    tft.setRotation(0);
    tft.fillScreen(TFT_BLACK);
    tft.setTextColor(TFT_WHITE, TFT_BLACK);
    tft.setTextSize(2);
    tft.setCursor(40, 100);
    tft.println("Hello World!");
}

void loop() {
}

Flash it​

pio run -t upload

PlatformIO will download the ESP8266 toolchain and the TFT_eSPI library automatically on the first run. After that, it compiles and flashes over USB.

If the upload fails with a serial port error, make sure:

1. The serial monitor isn't running (it holds the port)
2. The USB cable is plugged in (not just charging — some cables are power-only)
3. The CH340K driver is actually approved (check System Settings)

It works!​

You should see "Hello World!" on the screen. Now, the sky is the limit.

After some research, I found that many versions of that kind of device exist, for a similar price tag. Some of them are using an ESP-32 and a touch button on top. They sell for about $25 (canadian dollars) right now. I am considering getting one to get bluetooth and at least some way to turn on/off the screen or have some controls. Maybe I'll create a small solar panel and battery level monitor for our camper van since there's an open API I can use to get readings with a bluetooth connection.

I just received a cute display. I don't know yet what I'm going to do with it. The listing did not say much, and I did not research it a lot. I just impulsively pressed the "add to cart" button and let future (now present) Sophie the pleasure to discover what's inside.

So, today I'm opening it up to document what's inside. Maybe some ideas will come soon. So far, the best idea I have is to code a custom and cute desk pet/robot/companion that does nothing useful other than being a cute companion.

The outside​

The display from the front, a cute yellow cube with a small dark screen recessed into the top face

The back of the device showing ventilation slits, a button, and a USB-C port for power

Opening it up​

It slides open, and I immediately notice that there is plenty of room to cram some stuff in there if I want to. Maybe I'll add a battery?

The PCB​

The main PCB slid out of the case, revealing an ESP-12S WiFi module and the board labeled "ESP 1.54 LCD V1.0" by ZJYUNJIE

Close-up of the ESP-12S module with its FCC ID (2AHMRESP12S), CE marking, and the PCB antenna.

There's also a 4-pin JST-style connector labeled VG54 on the board. The traces appear to route toward the right side of the ESP-12S, possibly to GPIO14 (SCL) and GPIO12 (SDA) — which would make it an I2C expansion port. A continuity test with a multimeter would confirm it.

I noticed that some listings are mentioning a capacitive touch on the top of the device, but the one I bought does not have that. This is probably where it would be plugged in.

The other side of the PCB showing the display flex cable connector and several surface-mount ICs

The ribbon cable is marked "FP-154HSC04B" with "JY" underneath. No separate touch controller or extra FPC is present, so this is likely a display-only panel without touch input.

The U3 IC turns out to be a CH340K by WCH — a USB-to-serial converter. This means the USB-C port isn't just for power, it's for programming the ESP-12S directly over USB. That is going to make projects easy to flash! :D

Notes for future self​

The ESP-12S​

I used the ESP8266 and ESP32 in many projects in the past, and attempted to do something useful with the tiny but very limited ESP-01. It's the first time I get to play with an ESP-12S, which is actually an ESP8266 in a specific module packaging with a built-in PCB antenna and 4MB flash.

As opposed to the good ol' ESP32 I know pretty well now, the ESP-12S has

• No bluetooth
• Less powerful CPU
• A lot less RAM
• Fewer GPIO
• A lot cheaper
• Consumes a lot less current

So it makes a good low power and cheap alternative for simple projects.

The display module​

Based on the board label "ESP 1.54 LCD" and the ribbon cable marked "FP-154HSC04B", this is a 1.54" IPS TFT LCD with a 240x240 resolution and 65K RGB colors. These panels are almost always driven by an ST7789 controller over SPI. No touch capability.

The Discovery​

I found rspec-github first and my mind was blown. Failed specs show up as annotations directly on your PR files. No more clicking through to Actions, no more scrolling through walls of output. The failures come to you, right where you're already looking.

Then I searched for rubocop-github-annotations-formatter. Same magic, but for linting violations. That missing frozen string literal? Annotated. That line that's too long? Right there in your diff.

And to complete the trilogy: cucumber_github_formatter. Your acceptance test failures, also annotated.

Why This Changes Everything​

Before: push code → something fails → click through to Actions → expand the right job → scroll forever → find the problem → context switch back to code.

Now: push code → failures appear as comments exactly where they happened.

It's wild how something this simple—just formatting output differently—completely transforms the CI experience. Your test suite, linter, and acceptance tests all become part of the PR conversation instead of separate reports hidden three clicks away.

These aren't making your tests run faster or your code better. They're just putting information where you need it, when you need it. And honestly? After discovering all three in one day, I'm questioning every other tool in my stack. What else have I been doing the hard way?

If you're running Ruby tests in GitHub Actions without these formatters, you're living in the past. Your future self will thank you.

Working on my OctoPrint gem, Claude was inconsistent about running RuboCop after making changes. Sometimes it would run, sometimes it wouldn't, and it often decided to manually fix style violations instead of using the autocorrections.

While reading the Claude Code hooks documentation, I realized I could automate this completely. Hooks execute shell commands in response to events like file edits, tool usage, or when Claude finishes responding.

Example​

I added this hook to my ~/.claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|MultiEdit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "file_path=$(echo '$TOOL_PARAMETERS' | jq -r '.file_path // empty'); if [[ $file_path == *.rb ]] && [[ -f $file_path ]]; then rubocop \"$file_path\" -a; fi"
          }
        ]
      }
    ]
  }
}

The Feature​

According to the Claude Code documentation, you can prefix bash commands with ! in your slash command templates to execute them and include their output.

Example: Smart Git Commits​

This is the example they provide in the documentation so you can try it now:

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
description: Create a git commit
---

## Context

- Current git status: !`git status`
- Current git diff (staged and unstaged changes): !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

## Your task

Based on the above changes, create a single git commit.

Simple, but incredibly boring.

The work was pure drudgery: read an API endpoint's documentation, create classes for models and errors, write tests, document everything, repeat. I implemented just what I needed and then... let it sit. For years. Untouched except for the occasional Dependabot update.

Fast forward to last month when I realized this project was perfect for experimenting with AI-assisted development. The patterns were already established, the tests were in place, and I even had a checklist of what was done versus what remained. Each endpoint implementation was basically identical—ideal for testing different approaches to vibecoding.

So I started handing off endpoints to Claude Code, one by one.

The result? The gem is now about 50% complete, and I'm confident I can release a first version within the month. Not because I changed my approach or found new motivation—because AI took over the repetitive parts I was dreading.

There are no more big decisions to make. No architectural puzzles to solve. Just implementation work that AI handles while I focus on the parts that actually interest me.

It's wild how a project that felt abandoned suddenly feels inevitable. Sometimes the barrier isn't complexity—it's just boredom.

So I handed it off to Claude with a simple request: "Can you document conventions and commonly agreed-on best practices for this Rails project?"

What came back surprised me. Claude didn't just reformat my scattered notes; it completely restructured them. My lazy bullet points became a comprehensive guide with clear sections, context, and actionable details. The output felt more... intentional. Like it was designed to actually help someone succeed, not just check a documentation box.

But then, I realized Claude had essentially shown me how to write for its own "neurons."

That moment got me thinking. If Claude could improve my documentation, could it improve my prompts?

The Question That Changed Everything​

Instead of guessing what would make my prompts better, I decided to ask directly. I developed what I now call my "improvement prompt" and it starts with this simple question:

"What information do you need from me to improve this prompt?"

Who's better positioned to answer that question than the AI itself?

The Process That Actually Works​

The key insight is that you don't start with a perfect prompt. You start by learning the workflow together, like pairing with a new colleague on an unfamiliar task. You experiment, take notes on what works, and gradually build up to something reliable.

My typical workflow looks like this:

1. Start simple: Create a basic prompt through conversation and feedback (like pairing with a new colleague)
2. Take notes: Track what works and what doesn't through multiple iterations
3. Ask for help: Use the improvement prompt template once I like the general workflow
4. Iterate together: Usually takes 4-5 rounds of questions and answers
5. Get the rewrite: Claude incorporates everything we've discussed into a polished, reusable prompt

The magic happens in step 4. Claude asks questions I wouldn't have thought to ask myself. Some feel irrelevant (like "How does this connect to your mentoring philosophy?"—which I ignore). But others reveal blind spots in my thinking or assumptions I didn't know I was making.

This approach works because you're not trying to guess what makes a good prompt from scratch. You're building understanding through actual use, then asking your AI collaborator to help you codify what you've learned together.

The Unexpected Side Effect​

Here's what I didn't see coming: this habit of asking "What do you need from me to succeed?" started bleeding into my human interactions.

I caught myself writing GitHub issues differently. Instead of assuming the next developer would have all the context I had, I started including more background. I explained the "why" behind requests, not just the "what."

Take this issue I recently wrote for an open-source project: instead of just saying "Add printer profiles support," I included acceptance criteria and implementation notes. It's written for both AI and human collaborators because good communication works for everyone.

My task definitions got clearer. My assumptions got smaller. I started realizing that some of the task definitions I'd written before were actually misleading. Not intentionally, but because I hadn't asked what information the reader needed to succeed.

The Real Insight​

The technique is useful, but the real revelation is bigger: Feedback is a gift, and the best feedback comes from the people you're directly working with.

Whether that's Claude helping me improve a prompt, or a junior developer telling me my GitHub issue lacks context, or a colleague pointing out an assumption I'm making—the pattern is the same. The people doing the work know what they need better than I do.

This simple question—"What do you need from me?"—has transformed how I approach every collaborative relationship. It shifts the dynamic from me guessing what others need to them telling me directly. It's more humble, more effective, and builds better working relationships.

Try It Yourself​

Next time you're working with AI on a repeated task, try asking "What information do you need from me to improve this prompt?" and see what happens. But more importantly, try the mindset shift. Instead of assuming you know what your collaborators (AI or human) need, ask them.

You might be surprised by what they tell you. And you might find yourself becoming a better collaborator in the process.

What would happen if you asked this question in your next code review, project kickoff, or one-on-one meeting?

The Improvement Prompt Template​

If you've made it this far and want to try this technique, here's the full template I use:

# Prompt Improvement Assistant

You are an expert prompt engineer helping me refine a prompt I've been developing. I've been working on this prompt through multiple iterations and now want to optimize it for better, more consistent results.

## Your Task

1. First, analyze the prompt I provide and identify its current strengths and potential areas for improvement
2. Ask me targeted questions to gather the information needed to enhance this prompt
3. Focus on understanding:
  - What specific outcomes I'm trying to achieve
  - What context or constraints are important
  - What common issues or inconsistencies I've encountered
  - What examples of good vs. poor outputs look like
  - What format or structure works best for my use case

## Your Questions Should Help Me Clarify

- Missing context that would improve results
- Ambiguous instructions that could be made clearer
- Additional examples or constraints that would be helpful
- Format specifications that would ensure consistency
- Any assumptions you're making that I should confirm or correct

## Next Steps

After our discussion, rewrite the prompt incorporating all the insights we've gathered. The improved prompt should be clear, specific, and designed for reliable reuse across similar tasks.

**Please follow this process:** My question to you is "What information do you need from me to improve this prompt?" Then analyze the prompt I share and ask your follow-up questions.