- `storebound console plan <form> [--json] [--lookup]`: read-only plan for an AI agent that drives the browser itself: start URL (deep links), ordered steps, answer sheet with the console's exact labels (certain / ask owner, curly quotes noted), never-press list, verified UI facts, driving guidance (in-page async loop + window.__log), verify instructions. All six forms. - `storebound console verify <form> [--from-text <file|->]`: App Privacy per-type summaries from page text, Play Create app from input states, content rating / target audience summaries, App Store record and age rating from the API; exit 1 on a mismatch. - MCP: console_plan, console_verify (read-only); console fill stays off MCP. - App Privacy (verified 2026-10-12): two information steps, unlabeled purpose checkboxes (nearest parent text), "Definitions and Examples" never pressed; fixture and engine follow. - Play Create app (verified 2026-10-12): /developers/<id>/create-new-app, App package name + read-only Check availability, material-radio inner [role=radio] click, app dashboard URL and play.appId, service account "Add app" as an owner step. - console-autofill skill rewritten agent-first; agents-core rule 10; README; pitfalls 12, 18 (confirmed sign-out), 19; CHANGELOG; play-first-release.
3.5 KiB
3.5 KiB
storebound · rules for AI agents
These rules apply to every AI tool that uses storebound (skills, MCP server or the CLI in a terminal).
Read skills/store-pitfalls/SKILL.md before any store task. It lists the mistakes already made in real releases
(store lists that lag after a create, dry runs without a plan, taken App Store names, byte limits, ...) and what to do.
- The owner decides public and irreversible steps. Submitting for review (App Review or Beta App Review), releasing a version, resuming or completing a rollout, canceling a submission, deleting products or listings, accepting agreements, sending review replies, inviting or removing testers, changing prices, starting or stopping a store experiment: explain what will happen and let the owner do it (or run the command only after a clear yes in chat). storebound's MCP server does not offer these at all.
- Dry run first. Every write command has
--dry(MCP:dry_run, default true). Show the dry run (the rows that change, not just a count), then run it for real only after the owner agrees. - Read before you write.
storebound scan(offline: rejection risks in the project itself),storebound check(offline) andstorebound validate(read-only, both stores) tell you what is missing and in which order to fix it. - Credentials only from the environment,
.storebound/in the project (gitignored) or a credential profile (~/.storebound/credentials/<profile>.json, named by--account <profile>or a workspace). Never ask for keys, passwords or tokens in chat, never print them, never write them into the config, docs or commits. The same goes for the App Review demo account (reviewDemoAccountin.storebound/credentials.json): the owner puts it there. - Never answer a compliance question you cannot know. Export compliance, Data safety, App Privacy, age rating, target audience: ask the owner when the code does not prove the answer. A wrong "no" is worse than a slow "ask".
- Pick builds by explicit number. Use the build number / versionCode you just uploaded, never "the latest".
- Long uploads run in the background with a log (
storebound play images > .storebound/images.log 2>&1 &) and you report the progress lines, not guesses. - No manipulative tactics with reviewers, players or store policies: no fake reviews, no incentives for ratings, no hidden features, no misleading screenshots, no keyword stuffing.
- Personal data stays local. Tester lists, review reply drafts, health reports and analytics snapshots live in
.storebound/(gitignored). Never put tester emails, reviewer names or crash logs into issues, docs or commits, and never ask for tester emails in chat (storebound masks them in its output). - Console forms without an API: drive them yourself, agent-first.
storebound console plan <form> --json(MCPconsole_plan) gives the start URL, steps, the answer sheet, the buttons you must never press and the verified UI facts. Drive the page with your own browser tool, adapt to what it shows, run long flows as an in-page async loop that writeswindow.__log(one evaluate call times out around 45 s), stop before the final button (Publish, Submit, Create, a final Save) and tell the owner exactly what to press, thenstorebound console verify <form>. Never sign in, accept an agreement or grant a permission (a service account's app access) for the owner.storebound console fillis the optional scripted fast path; it never blocks you.