Coding agents write barcode scanning code that compiles and passes review, then falls apart on a damaged label. Here's how we taught them to get it right.
I'm Ilber, an Android developer at Scandit. I work on the SDK these skills install, so treat this as a build note from someone close to it, not a neutral review. I've tried to keep it honest about where Scandit Agent Skills help and where they don't.
Ask a coding agent to add barcode scanning to your Android app and you'll get something back in minutes. It compiles. It might even pass review. Then a warehouse worker points it at a creased label in bad light and … nothing happens.
That gap, between code that looks correct and code that works in the field, is the whole problem with letting a coding agent integrate a barcode scanning SDK on its own.
The agent picks the wrong API for the use case. It leaves the default camera and resolution settings in place, so single-barcode performance is fine but a dense shelf of barcodes crawls. It skips the configuration that handles low light, motion blur, and damaged codes, because none of that shows up in a happy-path demo. And it writes against an API shape from its training data that we changed two releases ago.
None of this is the agent being dumb. It's the agent not having the context. (Honestly, most human developers get this wrong on the first pass too.) Tuning a barcode scanner for real conditions is domain knowledge, and you only get it by shipping to a lot of devices.
What we built
Scandit developers have been shipping barcode scanning code for 15 years. We’ve written all that knowledge down in a form a coding agent can actually use. Scandit Agent Skills are a set of instructions that teach a coding agent how to integrate barcode scanning the way someone who's done it a hundred times would.
They follow the Agent Skills Open Standard, so they work in Cursor, Claude Code, GitHub Copilot, OpenAI Codex, Gemini, OpenCode, and 40-odd other agents. Install is one line.
The skills also track every SDK release. So instead of the agent reconstructing an API from whatever it memorized during training, it checks the current docs and starts from our maintained sample code.
In this demo, an agent uses a skill to wire in Smart Label Capture, which is one of the fiddlier products to set up by hand. Start to finish it took a bit over 20 minutes, and the coder was at the keyboard for maybe 2 of them. First scan worked.
Install
Run this in your project directory and follow the prompt to pick your agent:
npx skills add https://github.com/scandit/skills
Claude Code as a plugin, one line at a time:
/plugin marketplace add scandit/skills
/plugin install scandit-sdk@scandit-plugins
Cursor users get a one-click install from the marketplace: → Install in Cursor
How it actually works
You describe the use case in plain language inside your agent. Something like "scan barcodes in a warehouse picking app on Android." A photo of the use case helps even more. If the agent is missing something it needs, it asks instead of guessing.
The product-picker skill (data-capture-sdk) takes that and recommends the right product and framework. This step is one agents often get wrong on their own, because the choice between, say, single Barcode Capture and MatrixScan Batch depends on the workflow, not the syntax.
From there the matching skill writes the integration into your codebase: SDK setup, license activation, the camera and scanning configuration, the UI wiring, the performance defaults, the edge cases. On Android that means it isn't just dropping in a view and calling it done. It sets the bits that decide whether the thing survives a real device.
Then you iterate in plain language:
- Restyle SparkScan to match your app's theme? Ask.
- Not sure single scanning is the right call? Tell it to try MatrixScan Batch instead of Barcode Capture and compare.
- Want a real comparison against your current open-source scanner? Ask it to swap the library for Scandit and you get a working test app from one prompt.
How we know Scandit Agent Skills help
A skill that confidently produces worse code is worse than no skill. So we test for that directly, following Anthropic's methodology: run the same model on the same task twice, once with the skill and once without, and compare the output.
We're at roughly 500 evaluation cases across 44 skills, pulled from the real snags and dead ends we've watched developers hit across thousands of integrations. We keep adding cases as the models change.
The scenarios are the messy ones, not Hello World. Version migrations. Swapping in from another library. Hardware trigger support for warehouse staff wearing gloves. Rejecting specific barcodes with custom error feedback. Continuous scanning for high-volume apps. Every case also checks that the agent left your existing code alone.
Try it and tell us where it breaks
npx skills add https://github.com/scandit/skills
If you hit a bug, an outdated SDK pattern, or guidance that's just wrong, file it in the issue tracker. If a product, framework, or workflow you need isn't covered yet, open a feature request. I'd rather hear about the rough edges than not.
Top comments (0)