Super AI Toolbox for Embedded Engineers

Inspiration: the question nobody could answer

Three board revisions into a prototype, someone on the team asked a simple question: which firmware did we actually test on board 7, and against which BOM?

Nobody could answer it. The firmware was on a laptop. The test log was in a NAS share under a folder named after a date. The BOM was an export from a spreadsheet that had since been edited twice. The bench photo that proved the harness setup was on someone's phone. Each artifact was fine on its own; together they proved nothing.

That gap is not a storage problem. A NAS already holds the bytes. The gap is provenance: the ability to say that this test round belongs to this firmware version, that this firmware was built against this BOM, and that nothing required is missing from the set.

We build JLC-integrated tooling for hardware teams — component lookup, tiered pricing, BOM costing, and PCB order records with Gerber and BOM attachments. The record side was already solved for us: a substantial in-house stack of Odoo 20 modules, running in production. What was missing was the file side: the messy, human, pre-structured pile of materials that exists before anyone fills in a form.

So we wrote a skill that operates on that pile.

What we learned

A capability contract is a better design brief than a feature list. Before writing a line of the skill, we read the platform's checker — 667 lines of validation rules — and treated it as the specification. The checker does not care about ambition. It cares that the name matches a regex, that the description carries a trigger phrase, that every delegation is a single quoted instruction, that nothing is fetched over the network. Designing to those constraints produced a smaller and more honest skill than our first outline.

Provenance is the product, not a feature. Every row the skill emits cites a source path and a content hash. That single decision cascades: it makes the test-round table auditable, it makes duplicate detection provable, and it makes the ledger useful six months later. We ended up describing completeness as a ratio rather than a feeling:

$$ \text{coverage} = \frac{\left|M_{\text{with provenance}}\right|}{\left|M_{\text{required by the round spec}}\right|} $$

A duplicate is exact only when $h(a) = h(b)$ and the bytes match — a hash claim without the bytes is a guess wearing a lab coat.

Empty results deserve their own vocabulary. Early drafts returned clean tables when folders were empty. That is a lie produced by formatting. The final version must say "empty", "not found", or "no match" explicitly, and must never substitute similar data or widen its own scope to find something to report.

An approval gate is architecture, not interface. Moving files and writing the ledger both change state on someone else's device. Both steps now stop and wait for an explicit answer. The skill presents; the engineer decides whether a test passed.

How we built it

The skill is an orchestration document, not code. It has no scripts, no network access, and no direct device calls. It delegates, in eight steps, to the platform's registered experts:

Inventory — list every material with path, type, size and time.
Fingerprint — group exact and near duplicates, propose which copy to keep.
Extract — logs and sheets to the document expert, bench photos to the photo expert.
Structure — align everything into a test-round table.
Reconcile — list missing records and BOM-versus-purchase differences.
Confirm — the engineer fills the verdict; the skill never does.
Archive — plan first, execute only after approval.
Ledger — write the entry, then read it back to verify.

Underneath, six public CLIs map to four agents (file-agent, document-agent, photo-agent, knowledge-agent). The package ships as five Markdown files, 21.9 KB unpacked, and passes the official checker with zero errors and zero warnings.

Alongside it sits the record layer we already run: a JLC component module with tiered pricing and BOM costing, and a PCB order module holding over 150 production orders with their Gerber files, BOMs and physical photos attached. We deliberately did not wire the skill to it.

The challenges

The capability boundary changed the architecture. Our first plan had the skill query Odoo for BOM prices and write back the archive record. Then we hit the platform rule: a skill can only delegate to registered experts; there is no general HTTP egress. The plan was not implementable as drawn.

We could have faked it with a note saying "call this API later". Instead we split the system along the seam the platform actually allows: the skill owns the file layer, Odoo owns the record layer, and they meet at a conventional folder layout and content hashes rather than at an API. That was the most useful hour of the project, and it made the proposal shorter.

Then the Odoo stack became a liability instead of a proof. It runs in production — but not on the NAS we were given, and the NAS cannot run these experts at all. So the honest sentence is "built, running elsewhere, not yet validated here". Every draft that claimed validation was weaker than the version that admitted the gap.

The authoring contract is unforgiving and mostly invisible. Forbidden verbs, banned paths, single-quoted delegations with exactly one target and one instruction, no dynamic references to a previous step. We iterated against the checker until it reported static-pass with nothing to say.

The 500-word proposal limit was its own engineering problem. Two pages, ten questions, 489 words. We removed every sentence that explained rather than asserted.

Where it stands

Built: the eight-step flow, the capability mapping, four reference documents, a checker-clean package.
Running elsewhere: the Odoo 20 BOM and pricing stack, in production on our own servers.
Not built: the coding-assistant prompt pack, and this stack on the NAS itself.
Still to validate: extraction accuracy on real logs, approval resume across a session, throughput on a large folder, photo legibility on the bench.

We are three engineers — one on skill design and orchestration, one on the Odoo record layer, one on the test-data pipeline. We used Codex (gpt-6.1-sol) for drafting and word-count checks; the design decisions, the business rules and the test criteria are ours.

The original question — which firmware, which BOM, which board — now has an answer that cites a path and a hash. That is a modest thing to have built, and it is the thing that was actually missing.neers