Forem: Tony Loehr

The 55.6% problem: why frontier LLMs fail at embedded code

Tony Loehr — Thu, 07 May 2026 02:57:12 +0000

55.6%.

That's DeepSeek-R1's pass@1 on EmbedBench when it gets a circuit schematic alongside the task description. 50.0% without the schematic. Best score from the best reasoning model on the first comprehensive benchmark for LLMs in embedded systems development. Cross-platform migration to ESP-IDF tops out at 29.4%, set by Claude 3.7 Sonnet (Thinking).

Take a second with that. The same models that one-shot a Next.js app are coin-flipping firmware. And the benchmark only tested three boards.

That 1,553 number is the live count from pio boards --json-output against PlatformIO Core 6.1.18 on the day this post was written, and PlatformIO-MCP wraps that catalog directly. So when we say "1,553 boards," we mean an MCP server you can npx-install today that knows how to build, flash, and monitor against any of them.

What EmbedBench actually measures

EmbedAgent (Wang et al., 2025) is the paper. EmbedBench is the benchmark. 126 cases, nine electronic components, three hardware platforms -- Arduino Uno, ESP32, Raspberry Pi Pico. The authors evaluate LLMs across three roles a real embedded engineer plays: Programmer (write code given a schematic), Architect (design the circuit and the code from a task description), Integrator (port working code from one platform to another). Scoring is pass@1 against the Wokwi virtual circuit simulator. Either the test passes or it doesn't.

The methodology is sound; the simulator is deterministic, the harness automated, and the metric leaves no wiggle room for graded partial credit. So while the numbers are real, they're also incomplete.

What the harness can't see

EmbedBench is single-shot in a simulator. The model gets the task once and writes the answer once. There is no compiler error fed back, no error: 'GPIO_NUM_45' was not declared in this scope for the model to read and react to. There is no flash to a real board and no serial monitor to confirm the LED actually blinked at the rate it was supposed to. The Architect role can hand back a circuit with the wrong pin mapping and never find out until the test fails.

That isn't how anyone writes firmware. Embedded development is iterative.

You compile, you read the toolchain noise, you fix the missing include, you flash, you watch the serial log, you change the baud rate, you fix the off-by-one in the timer ISR, you flash again. The benchmark measures the cold-start guess and reports it as if it were the whole loop.

The paper's own failure modes back this up. LLMs flunked 7-segment displays because they got voltage levels and segment mappings wrong. They flunked push buttons because they didn't handle debounce. They flunked ESP-IDF migration because they hallucinated syntax for a framework they've barely seen in training. Every one of those failures is the kind of thing a build, a flash, and a serial print would catch on the second or third iteration.

What changes with a real loop

This is the part of the story PlatformIO-MCP fills in. The MCP server gives an agent the four tools that make iteration possible: it can build a project, push the binary onto a board, watch the serial line, and ask which boards are even connected. None of those tools fixes the underlying knowledge gap in ESP-IDF or 7-segment voltage tables; what they fix is the absence of a feedback signal. A model that ships on the third try beats a model that gets it perfect on the first try, every time. The loop is the difference.

A note for the secure-customer crowd

The teams writing firmware for these platforms tend to be the same teams with stingent security requirements: defense, aerospace, medical, industrial. MCP plus local inference plus an open source agent plus the on-prem PlatformIO toolchain is a stack that clears the bar for these environments. The benchmark numbers and the deployment story end up being the same conversation.

Try the loop

npx pio-mcp dashboard

platformio-mcp is on npm, repo at github.com/jl-codes/platformio-mcp. One command, real boards, the whole feedback loop the benchmark didn't measure. If you've run an agent against an ESP32 or an STM32 and have data to share, DM me on X

I built an MCP server so AI agents can flash 1,000+ embedded boards

Tony Loehr — Tue, 05 May 2026 23:13:31 +0000

npx pio-mcp dashboard

That's the install. Open a terminal anywhere — your laptop, a fresh VM, a coworker's machine — type one line, and you get a React dashboard wired to PlatformIO Core. From there an LLM can compile firmware, flash it to a real board, and stream serial back to the same browser tab.

platformio-mcp v2.0.0 shipped to npm. Here's why and how.

The gap

LLMs are stupidly good at writing firmware. Hand Claude a datasheet and it'll spit out C++ that compiles. Hand it the FreeRTOS docs and it'll wire up a queue without breaking a sweat.

The next step always falls apart.

"Great, now flash it to the ESP32 sitting on my desk."

You get back a markdown wall of "first install pyenv, then bootstrap a venv, then pip install platformio, then check your USB-C cable supports data, then make sure the right udev rule is in place on Linux, then..." It's a setup-doc generator. The agent has read every PlatformIO tutorial ever written. It still can't push bytes to flash memory because it has no hands.

MCP is the hands. The agent calls a tool, the tool runs on your machine, the result comes back. PlatformIO Core is already a CLI that knows how to talk to ~1,000 boards across 30+ platforms (ESP32-S3, RP2040, STM32H7, nRF52840, ATmega328P, Teensy 4.1, SAMD21, ATtiny85, and so on). I exposed it through MCP. That's the whole product.

What v2.0.0 actually does

Nine MCP tools. Each one is a thin wrapper around a pio subcommand:

list_boards        → pio boards <filter>
init_project       → pio project init
build_project      → pio run                       (background mode + status polling)
upload_firmware    → pio run --target upload       (optional start_monitor)
list_devices       → pio device list
serial_monitor     → pio device monitor            (non-blocking, streamed)
search_libraries   → pio pkg search
install_library    → pio pkg install
list_libraries     → pio pkg list
get_dashboard_url  → returns localhost URL with bound auth token

Plus init_project, the unsung hero. PlatformIO project scaffolding is the thing agents got wrong every single time before this — they'd hand-write a platformio.ini with three subtle bugs in the board_build section. The MCP tool just shells out to pio project init and the bugs vanish.

The demo that closes the deal

Real prompt, real ESP32, real flash:

> Initialize a new Arduino project for an ESP32 Dev Board in /tmp/esp32-blink.
  Build it, flash it, and start the serial monitor.

The agent's tool calls, in order:

list_boards          { filter: "esp32" }                                 → esp32dev
init_project         { board: "esp32dev", framework: "arduino",
                       projectDir: "/tmp/esp32-blink" }
build_project        { projectDir: "/tmp/esp32-blink" }                  → SUCCESS
upload_firmware      { projectDir: "/tmp/esp32-blink",
                       start_monitor: true }                             → flashed

End-to-end on a clean machine: ~90 seconds. Most of that is the PlatformIO toolchain pulling esptool and the Espressif SDK on first run. Subsequent flashes are sub-10s.

Install in one command

We make it easy to integrate PIO MCP into your choice of coding agent. v2.0.0 ships a one-shot installer:

npx platformio-mcp install --cline       # Cline (VS Code extension or CLI)
npx platformio-mcp install --claude      # Claude Desktop
npx platformio-mcp install --vscode      # VS Code native MCP support
npx platformio-mcp install --antigravity # Google Antigravity

Each installer:

Resolves the host's config path per OS. macOS goes to ~/Library/Application Support, Windows reads %APPDATA%, Linux falls back to ~/.config. There's a 9-line appDataDir() helper that does the dispatch.
Reads the existing config if one's already there.
If the JSON is corrupted, copies it to <path>.bak before rewriting. I learned this the hard way.
Idempotently merges an mcpServers.platformio block. Re-running the installer is a no-op.
Prints the path it touched so you can grep for it later.

For any other MCP host, this is the manual config block:

{
  "mcpServers": {
    "platformio": {
      "command": "npx",
      "args": ["-y", "platformio-mcp", "--open-dashboard-on-start"]
    }
  }
}

The dashboard

The dashboard is the part nobody asks for and everybody uses once they have it.

Reason: build output is the worst possible thing to feed back to an LLM. A clean pio run for an ESP32 project is 40+ kilobytes of toolchain noise — arm-none-eabi-gcc flags, linker incantations, every single .o file. Pour that into the agent's context and you've spent a third of your token budget on text the agent doesn't need.

So the MCP tools return short, structured summaries to the LLM. The full output streams over Socket.io to a React dashboard the human can watch:

A per-process random UUID is injected as PORTAL_AUTH_TOKEN at boot. Every HTTP request and every Socket.io connection requires it. The dashboard URL looks like http://localhost:8080?token=<uuid> and that token isn't in any config file or env var the LLM has access to. If you launch the dashboard, only you (and the agent that spawned it) can hit the API.

The auto-launch is gated behind --open-dashboard-on-start (or the PIO_MCP_OPEN_DASH_ON_START=true env var). Browser launch goes through the open package, so the same call works on macOS, Linux, and Windows. The previous version had a hardcoded exec('open ...') that only fired on macOS — patched in v2.0.0.

Things I'm proud of that nobody will notice

The tarball is 499 kB. 114 files. build/ + web/dist/ + scripts/installers/ + LICENSE + README. No node_modules, no tests, no web/src/. The minified UI bundle is 921 kB / 291 kB gzip on its own; everything else is rounding error.
prepublishOnly runs the full TypeScript build, the Vite UI build, and a smoke check that asserts build/index.js, web/dist/index.html, and scripts/installers/index.js exist before npm allows the publish to proceed. Hard to ship a broken artifact.
Workspace state is mediated through proper-lockfile. Two agent processes can't race each other on the same project. If you've ever had two MCP servers fight over the same serial port, you know why this matters.
The pio-mcp alias package is 842 bytes. Three files: a 283-byte bin.js that does import("platformio-mcp"), a package.json with one dependency, a README. Same binary, shorter to type.
The default npx platformio-mcp (no subcommand) still boots the MCP stdio server. Existing configs that point at build/index.js keep working unchanged. v2 is additive.

Get started in five seconds

# Open the dashboard right now. No clone, no build, no install.
npx pio-mcp dashboard

# Wire it into your AI agent of choice.
npx platformio-mcp install --cline
npx platformio-mcp install --claude
npx platformio-mcp install --vscode
npx platformio-mcp install --antigravity

Repo: github.com/jl-codes/platformio-mcp
npm: platformio-mcp · pio-mcp
Release notes: v2.0.0

I'm @forkbombETH on X. Issues and PRs welcome on GitHub. If you build something cool with this, lmk.

npx pio-mcp dashboard

A huge warm thank you to Matt Mcneill for being an amazing collaborator and pushing for the features that make v2 amazing!

20 one-shot prompts that turn Kanban into an autonomous coding machine

Tony Loehr — Mon, 06 Apr 2026 16:30:00 +0000

Most people look at Cline Kanban and see a board. Cards, columns, drag and drop. But Kanban isn't a project management tool. It's an orchestration layer for coding agents, one with a particularly robust feature: the Kanban Agent in sidebar chat is where the real leverage lives.

One prompt in the Kanban Agent can decompose a complex project into linked task cards, fan them out for parallel execution across multiple agents, and chain them so one finishing triggers the next. The result is end-to-end autonomous workflows that go from a single sentence to committed code across your entire codebase.

We put together 20 starter prompts across five categories. Each one is copy-paste ready for the Kanban sidebar chat. They create linked dependency chains, maximize parallel agent execution, and produce real, working code. Install with npm i -g cline, run cline in any project directory, and try them.

Kanban sidebar agent creating linked task cards from a single prompt

Greenfield app scaffolding

These prompts build new projects from scratch. The key pattern: set up the foundation first, then fan out parallel tasks for features that don't depend on each other.

1. Express API from scratch

Build a production-ready Express API for this project. Break it into 
tasks: 1) Set up Express with TypeScript, tsconfig, and a dev script 
with nodemon 2) Add a health check endpoint at GET /health returning 
{ status: "ok", timestamp } 3) Add structured JSON logging with pino 
4) Add global error handling middleware with proper error response 
format 5) Add CORS and helmet security middleware. Link them 
sequentially -- each builds on the last. Start task 1.

2. React + Vite frontend

Scaffold a React frontend with Vite for this project. Tasks: 1) 
Initialize Vite with React and TypeScript template, add path aliases 
in tsconfig and vite.config 2) Set up React Router with a layout 
component, home page, and 404 page 3) Add a reusable component 
library -- Button, Card, Input, Modal -- in src/components/ui with 
basic styling 4) Add a dark/light theme provider using CSS variables 
and React context. Link 1 → 2 → 3, and 1 → 4 so theming and 
components run in parallel after routing is set up. Start task 1.

3. CLI tool

Build a Node.js CLI tool in this repo. Tasks: 1) Set up the project 
with TypeScript, a bin entry in package.json, and commander.js for 
argument parsing 2) Add a "init" command that scaffolds a config file 
interactively using prompts 3) Add a "run" command that reads the 
config and executes the main logic with a progress spinner using ora 
4) Add colorized output with chalk and a --verbose flag for debug 
logging. Link 1 → 2, 1 → 3, and 1 → 4 so all three commands build in 
parallel after setup. Start task 1.

⭐ 4. Full-stack with database – A single prompt gives you a typed Express API backed by SQLite with full CRUD, input validation, and seed data. Five linked tasks, two parallel branches.

Set up a full-stack app with Express backend and SQLite database. 
Tasks: 1) Initialize Express with TypeScript and install better-
sqlite3 2) Create a database module in src/db.ts that initializes 
SQLite, creates a "users" table with id, name, email, created_at 3) 
Add CRUD API routes: GET /users, GET /users/:id, POST /users, PUT 
/users/:id, DELETE /users/:id 4) Add input validation middleware 
using zod schemas for the POST and PUT routes 5) Add seed script that 
populates 10 sample users. Link 1 → 2 → 3 → 4, and 2 → 5 so seeding 
runs in parallel with route development. Start task 1.

Codebase modernization and migration

Legacy code is where Kanban's parallel execution really shines. These prompts audit first, then fan out multiple refactoring tasks simultaneously.

5. JavaScript to TypeScript migration

Migrate this JavaScript project to TypeScript. Tasks: 1) Add 
tsconfig.json with strict mode, install typescript and ts-node, 
rename entry point to .ts 2) Rename all .js files in src/ to .ts and 
fix immediate type errors with explicit type annotations 3) Add type 
definitions for all function parameters and return types across the 
codebase 4) Replace any require() calls with ES module imports and 
update package.json with "type": "module" if needed 5) Add a build 
script using tsc and verify the compiled output runs correctly. Link 
sequentially 1 → 2 → 3 → 4 → 5. Start task 1.

6. Dependency audit and upgrade

Audit and upgrade dependencies in this project. Tasks: 1) Run npm 
outdated, identify all packages with major version bumps, and create 
a report as UPGRADE_PLAN.md listing each package, current version, 
target version, and known breaking changes 2) Upgrade all non-
breaking minor and patch versions across the project 3) Upgrade major 
version packages one at a time, fixing breaking changes in the code 
after each upgrade 4) Remove any unused dependencies identified by 
depcheck. Link 1 → 2, 1 → 3, and 1 → 4 so cleanup and upgrades run in 
parallel after the audit. Start task 1.

⭐ 7. Add ESLint and Prettier -- This prompt runs two completely independent tooling setups in parallel, then applies each tool's auto-fixes in separate worktrees. Zero conflicts because each agent works in isolation.

Add code quality tooling to this project. Tasks: 1) Install and 
configure ESLint with a flat config file using @eslint/js and 
typescript-eslint, with rules for no-unused-vars, consistent-return, 
and no-console as warnings 2) Install and configure Prettier with a 
.prettierrc that uses single quotes, no semicolons, and 2-space tabs 
3) Run eslint --fix across the entire codebase and commit the auto-
fixed changes 4) Run prettier --write across the entire codebase and 
commit the formatted changes. Link 1 → 3 and 2 → 4 so linting and 
formatting run in parallel. Start tasks 1 and 2.

8. Extract shared utilities

Refactor this codebase to extract duplicated logic. Tasks: 1) Scan 
the codebase for duplicated patterns -- repeated validation logic, 
string formatting, date handling, error construction -- and list them 
in a REFACTOR_PLAN.md 2) Create a src/utils/ directory with modules 
for each identified pattern: validation.ts, format.ts, dates.ts, 
errors.ts 3) Replace all duplicated code across the codebase with 
imports from the new utility modules 4) Add unit tests for each 
utility module using the existing test framework. Link 1 → 2 → 3, and 
2 → 4 so tests and refactoring run in parallel. Start task 1.

Testing and quality

Testing is one of the highest-value uses for Kanban because unit tests, integration tests, and documentation are naturally independent -- they fan out perfectly.

⭐ 9. Comprehensive test suite -- Four tasks, but the real magic is the linking pattern: unit tests and integration tests build simultaneously after the test framework is configured, then converge on the CI coverage gate.

Add a test suite to this project. Tasks: 1) Install and configure 
vitest with TypeScript support, add test and test:coverage scripts to 
package.json 2) Write unit tests for all utility functions and helper 
modules in src/utils or src/lib, aiming for 100% coverage on those 
files 3) Write integration tests for all API routes using supertest, 
covering success cases and error cases 4) Add a test:ci script that 
runs tests with coverage and fails if coverage drops below 80%. Link 
1 → 2 and 1 → 3 so unit and integration tests build in parallel, then 
2 → 4 and 3 → 4 so the CI script comes last. Start task 1.

10. API documentation

Document all APIs in this project. Tasks: 1) Install swagger-jsdoc 
and swagger-ui-express, configure them to serve docs at /api-docs 2) 
Add JSDoc annotations with @swagger tags to every route handler 
documenting the method, path, parameters, request body schema, and 
response schema 3) Add example request/response payloads for each 
endpoint in the swagger annotations 4) Add a README section 
documenting how to access the API docs locally and listing all 
available endpoints with brief descriptions. Link 1 → 2 → 3, and run 
4 in parallel after 1. Start task 1.

11. Error handling hardening

Harden error handling across this codebase. Tasks: 1) Create a custom 
AppError class in src/errors.ts that extends Error with statusCode, 
isOperational, and context fields, plus factory functions for 
notFound, badRequest, unauthorized, and internal errors 2) Add an 
Express error-handling middleware that catches AppError instances and 
returns structured JSON error responses with appropriate status codes 
3) Audit every route handler and replace raw throw/try-catch patterns 
with the new AppError classes 4) Add a process-level uncaught 
exception and unhandled rejection handler that logs and gracefully 
shuts down. Link 1 → 2 → 3, and 1 → 4 in parallel. Start task 1.

12. Add logging and observability

Add structured logging to this application. Tasks: 1) Install pino 
and pino-http, create a logger module in src/logger.ts that outputs 
JSON logs with configurable log levels via LOG_LEVEL env var 2) Add 
request logging middleware using pino-http that logs method, url, 
status code, and response time for every request 3) Add contextual 
logging to all existing route handlers and service functions -- log 
on entry, on error, and on completion with relevant context like user 
IDs or resource IDs 4) Add a correlation ID middleware that generates 
a UUID per request and attaches it to all log lines for that request. 
Link 1 → 2 and 1 → 4 in parallel, then 2 → 3 and 4 → 3 so the route 
logging comes last. Start task 1.

Feature development

These prompts add real product features. The linking patterns here are more complex because features have more interdependencies -- but Kanban handles the orchestration.

⭐ 13. Authentication system -- This is the most complex single prompt in the collection. Five tasks, three parallel branches, a convergence point. One sidebar message gives you a complete auth system with registration, login, JWT middleware, and route protection.

Add JWT authentication to this Express app. Tasks: 1) Install 
jsonwebtoken and bcryptjs, create a src/auth/ directory with modules 
for password hashing and JWT token generation/verification with 
configurable secret and expiry via env vars 2) Add POST 
/auth/register endpoint that validates email/password, hashes the 
password, stores the user, and returns a JWT 3) Add POST /auth/login 
endpoint that validates credentials, compares the password hash, and 
returns a JWT 4) Add an auth middleware that extracts the JWT from 
the Authorization header, verifies it, and attaches the user to 
req.user 5) Protect all existing routes except /health and /auth/* 
with the auth middleware. Link 1 → 2, 1 → 3, 1 → 4 so register, 
login, and middleware build in parallel, then 2 → 5, 3 → 5, 4 → 5 so 
route protection comes last. Start task 1.

14. Search and filtering

Add search and filtering to the existing list endpoints in this API. 
Tasks: 1) Create a query parser utility in src/utils/query.ts that 
extracts page, limit, sort, order, and arbitrary filter fields from 
req.query with sensible defaults and validation 2) Update the GET 
list endpoints to accept ?search= parameter that does a case-
insensitive partial match across text fields 3) Add pagination 
support -- return results with { data, total, page, limit, totalPages 
} response format 4) Add sort support with ?
sort=field&order=asc|desc. Link 1 → 2, 1 → 3, 1 → 4 so search, 
pagination, and sorting build in parallel after the query parser. 
Start task 1.

15. File upload endpoint

Add file upload capability to this Express app. Tasks: 1) Install 
multer and configure it with disk storage in an uploads/ directory, 
10MB file size limit, and allowed extensions for images (jpg, png, 
gif, webp) 2) Add POST /upload endpoint that accepts a single file, 
validates it, stores it, and returns { filename, originalName, size, 
mimetype, url } 3) Add GET /uploads/:filename endpoint that serves 
the uploaded file with proper content-type headers and 404 handling 
4) Add a cleanup utility that deletes uploaded files older than 30 
days, callable via a DELETE /uploads/cleanup endpoint. Link 1 → 2 → 
3, and 1 → 4 in parallel. Start task 1.

16. WebSocket real-time updates

Add WebSocket support to this Express app for real-time updates. 
Tasks: 1) Install ws, integrate a WebSocket server with the existing 
HTTP server, and create a connection manager in src/ws.ts that tracks 
connected clients by ID 2) Add a broadcast utility that sends a JSON 
message to all connected clients or to specific client IDs 3) Modify 
the existing POST, PUT, and DELETE route handlers to emit WebSocket 
events after successful mutations -- e.g., { event: "user:created", 
data: user } 4) Add a heartbeat ping/pong mechanism that detects and 
cleans up stale connections every 30 seconds. Link 1 → 2 → 3, and 1 → 
4 in parallel. Start task 1.

DevOps and infrastructure

Infrastructure tasks are often tedious and repetitive. They're also perfectly suited for parallel execution because a Dockerfile, a CI config, and a .dockerignore don't depend on each other.

17. Dockerize the application

Dockerize this application. Tasks: 1) Create a multi-stage Dockerfile 
with a builder stage that installs deps and compiles TypeScript, 
production stage that copies only compiled output and production 
deps, runs as non-root user on port 3000 2) Create a docker-
compose.yml with the app service, health check, environment variables 
from .env, and a volume mount for uploads if applicable 3) Add a 
.dockerignore file excluding node_modules, .git, .env, dist, and test 
files 4) Add npm scripts: docker:build, docker:run, docker:stop and 
document them in the README. Link 1 → 3 in parallel (both are 
independent files), then 1 → 2 → 4 for the compose and docs. Start 
tasks 1 and 3.

⭐ 18. GitHub Actions CI/CD -- Four tasks, three running in parallel from the start. CI workflow, release workflow, and contributing docs all build simultaneously, then converge on adding README badges. This is the kind of infrastructure setup that normally takes an afternoon -- Kanban does it in minutes.

Add GitHub Actions CI/CD to this project. Tasks: 1) Create 
.github/workflows/ci.yml that runs on push and PR to main -- checks 
out code, installs deps, runs linting, runs tests with coverage, and 
fails if coverage is below threshold 2) Create 
.github/workflows/release.yml that runs on tags matching v* -- builds 
the project, creates a GitHub release with auto-generated notes 3) 
Add a branch protection rules recommendation in CONTRIBUTING.md 
documenting that main requires CI to pass 4) Add status badges for CI 
workflow to the top of README.md. Link 1 → 4 and 2 → 4 so badges come 
after both workflows exist. Run 1, 2, and 3 in parallel. Start all 
tasks.

19. Environment configuration

Add proper environment configuration to this project. Tasks: 1) 
Install dotenv, create a src/config.ts module that loads and 
validates all environment variables with defaults, exports a typed 
config object -- include PORT, NODE_ENV, LOG_LEVEL, DATABASE_URL, 
JWT_SECRET 2) Create .env.example with all required variables and 
placeholder values, add .env to .gitignore 3) Replace all process.env 
references scattered across the codebase with imports from the config 
module 4) Add a startup validation that checks all required env vars 
are present and logs which are missing with a clear error message 
before the app exits. Link 1 → 2 and 1 → 3 in parallel, then 3 → 4. 
Start task 1.

20. Monorepo setup

Convert this project into a monorepo. Tasks: 1) Install and configure 
Turborepo with a root turbo.json, move the existing app code into 
packages/api, update all paths and imports accordingly 2) Create 
packages/shared with common TypeScript types, utility functions, and 
constants that will be shared across packages 3) Create packages/web 
as a minimal React + Vite frontend that imports types from 
packages/shared 4) Configure the root package.json with workspace 
scripts: dev (runs all packages), build (builds all), test (tests 
all), and lint (lints all). Link 1 → 2, 1 → 3 in parallel (both 
depend on the monorepo structure), then 2 → 4 and 3 → 4 so workspace 
scripts come after all packages exist. Start task 1.

Now show us yours

These 20 prompts are starting points. The real creative potential is in the workflows you build for your own projects -- the migration scripts nobody else has thought of, the testing patterns specific to your stack, the infrastructure recipes that save your team hours every week.

We want to see what you come up with. Share your best one-shot Kanban prompts with #OneShotShip on Twitter/X, or post them in our Discord and Reddit. Tag us at Cline so we can find them. The most creative and effective prompts will get featured in future Cline content.

And if you're building open source tools, workflows, or integrations on top of Kanban, our $1M open source grant program is accepting applications. Build something great and get funded to keep going.

Get started:

npm i -g cline
cline