odevio/odevio-cli/skill

Odevio — from a Flutter project to an iPhone

Odevio builds and signs iOS apps on remote Macs. The user needs no Mac and no iOS knowledge: certificates, provisioning profiles and app identifiers are already automated. This skill drives the whole path and asks as little as possible.

Read this file fully before acting. Then read a reference only when its situation arises:

Before anything — make sure Odevio is installed

This skill drives the odevio command; it does nothing without it. If you reached this skill through discovery rather than odevio skill install, the CLI may not be present yet. Step 1's odevio profile tells you: if the command is not found, offer pip install odevio (pipx install odevio if this machine's Python is externally managed) and let them run it. Then, so the commands below run without a permission prompt each time, register the skill for your agent once:

odevio skill install

It re-does nothing already done — safe to run when Odevio is already set up.

Say who is driving. End every odevio command you run with --agent <you> — claude, codex, gemini, grok, cursor, copilot, windsurf, or your own name if none fits — e.g. odevio screenshot listing ls --agent claude. It changes nothing in what the command does; it tells Odevio an agent ran it. Keep it last, after the command's own arguments. The one exception is odevio skill install, whose own --agent chooses where to install: leave yours out there. If the CLI answers "no such option: --agent", it is too old: say so and suggest pip install -U odevio, and leave the option out meanwhile. The commands quoted in these files omit it for readability; add it anyway.

How to talk to the user

This matters as much as the mechanics. The words never to use, when to stay silent, and how to ask a question live in references/voice.md. Read it before you act - it is not optional.

Step 0 — What do they actually want

Only App Store screenshots? When that is all they ask for — "make my App Store screenshots", marketing screenshots, with or without a build — this file's Steps 1 to 4 do not apply: no Flutter project, no Odevio app and no Apple account are needed. Run odevio profile for the session — and check the account it names is theirs, as below — then go straight to references/marketing-visuals.md (and design-directions.md when composing).

Their goal decides the kind of build, whether Apple's side needs setting up at all, and what "done" means. It is the one thing you cannot read from the project.

If the way they asked already says it — "get my app on my phone", "publish it", "does this even build" — take it and never ask again.

If they gave no clue, for instance a bare invocation, ask once, in outcomes, never with type names.

Offer these five, and all five, whatever form the question takes:

Publishing to the App Store is its own answer, and the one most easily lost. It shares a build with the testers option, which makes it tempting to fold the two together — do not. They lead to entirely different work: testers means the app is with Apple and you are finished, while the App Store means a page has to be written, pictures provided and a questionnaire answered. Someone who meant to publish and was offered only "send to testers" has no way of knowing the rest exists.

The wording of each option is what the user reads, so no build type ever appears in it — not in the heading, not in the explanatory line underneath. "Sends it to Apple and puts it in front of your testers" says what happens. "Build publication — envoi chez Apple" leaks the machinery and tells them nothing they can act on.

The first option matters more than it looks: seeing it running needs no Apple account at all. Everything else on that list requires a paid Apple developer account, so for someone who has not paid yet, that is the only thing you can offer today — and it is a real one, not a consolation prize.

Do not skip this and default to compiling. A silent assumption is worse than a question here: it spends a quarter of an hour producing something they did not ask for, and the App Store route needs a manual step that the others do not.

A local build is only conceivable on a Mac, so check the platform before the thought even forms. The host already tells you which system you are running on — no command needed. On Windows or Linux there is nothing to weigh: never mention building locally, never suggest they find a Mac, never frame Odevio as the fallback for something better. Building here is the answer, and a user without a Mac who is told about local builds has been handed a problem instead of an app.

On a Mac, still do not volunteer it. Someone with a Mac may be here precisely to avoid Xcode, certificates and provisioning profiles — which is most of what Odevio removes, and reason enough on its own. Offering to take the build away from us, unprompted, argues against the tool for no gain to them.

Read references/build-elsewhere-publish-here.md only when they bring it: an .ipa they already have, a CI that produces one, Xcode or fastlane in the conversation, or a direct question. Then the build is genuinely not the question, and offering one misreads their setup.

If they said the App Store, read the page before doing anything else. Not after building — before. Go to references/app-store-listing.md now and run odevio app store-status.

The reason is concrete: Apple may already hold a build. Building takes a quarter of an hour and occupies a machine someone else is waiting for, and there is no point spending either if what is needed is a description and three pictures. Only the page can say which of the two it is.

Then say what the whole thing involves, and what you are about to do first. Sending the app is the easy half; the page has to be filled in too, and two parts of it can only be done on Apple's own website:

Right — the App Store. Two things there that only you can do, about ten minutes in total: creating the

app's page, and answering Apple's questions about data. I will tell you exactly what to click.

Let me look at where your page stands before anything else — if your app is already with Apple there is no

need to build it again.

Only once the page has been read does building become a question, and then it is one to put to them rather than assume. references/app-store-listing.md covers the three cases.

Step 1 — Find out what is already there

Read the state before asking anything. Stop at the first blocking check.

Run as few commands as will do. Every one appears in front of the user as a block of shell and output, and a screenful of it before the first sentence makes a tool that promised to handle things look like it is rummaging. Two rules keep it short:

• Never inspect your own installation. Listing the skill's own directory, reading its own files to see

what is there, checking where it is installed — none of that tells you anything about their project and all of it is visible to them.

• One command per fact, and only facts you are about to use. odevio profile proves the CLI is

installed _and_ that there is a session, so odevio --version on top of it earns nothing. Their version is worth having only when something has already gone wrong. It also prints their account type and the teams they belong to — keep both: they decide whether a second Apple account is even permitted, and re-reading them later costs another command in front of the user.