Build a Capacitor text-to-speech mobile library from a spec with Kiro

Michael de Guzman had Kiro build a Capacitor text-to-speech library for OutSystems ODC. The first build passed 39 tests but was the wrong asset type; the final one passed 7 of 7 checks on an iPhone.

Done withKiro· Oct 17, 2026

What they did

Michael de Guzman wanted a native text-to-speech wrapper for OutSystems Developer Cloud (ODC) mobile apps, built on the community Capacitor plugin, and wanted to see if Kiro could build it with spec-driven development. He handed Kiro a spec and let it work in spec mode with autopilot and parallel subagents, using the OutSystems MCP to drive Mentor, OutSystems' own asset-building agent. After the first build went wrong he rewrote the spec, switched model per phase (Opus 5.5 for the spec and reviews, Sonnet for the build), and had Kiro write a click-by-click build sheet for the parts he had to do by hand in ODC Studio. He also had Kiro record every lesson in always-loaded steering files.

How it went

The first build reported complete with 39 green tests, but Mentor had made a Reactive library, not a Mobile one, because the reused spec just said library. Kiro had checked completion by counting element names, not wiring, and some work vanished when subagent sessions closed without publishing. The rebuild hit an untested sentence in the spec, which Kiro flagged as a false premise, and Mentor refused to load Mobile assets at all. De Guzman built both assets by hand from the build sheet, correcting several wrong instructions along the way. Both shipped to the Forge and all 7 on-device scenarios passed on a physical iPhone.

Worth knowing

As of mid-October 2026 Mentor through the OutSystems MCP cannot create or load Mobile libraries or Mobile apps, so the agent can only do read-only checks there. Green tests against a mock plugin said nothing about the platform. Unpublished Mentor edits are lost when a session closes, so parallel subagents need a publish step per task.

Try it

With Kiro· 6 parts to fill in

Build [component] for [platform] from the spec in [spec file]. Before writing any code, read the spec line by line and list every claim about the platform, such as asset types, where actions can be called from and what converts automatically. Mark each claim as verified against [docs or tool] or unverified, and stop to show me the unverified ones. Name the exact asset type you will create. Do not report a task complete because tests pass or names exist: check that each element is wired and published, and tell me what you could not inspect. Write each platform rule you learn into [steering file]. Stop when [acceptance tests on a real device] pass.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related