65 lines
5.7 KiB
Markdown
65 lines
5.7 KiB
Markdown
# storebound · rules for AI agents
|
|
|
|
These rules apply to every AI tool that uses storebound (skills, MCP server or the CLI in a terminal).
|
|
|
|
## First rule: do it, don't ask
|
|
|
|
storebound plus you, the AI agent, do the work. The owner is not your pair of hands.
|
|
|
|
1. **You do everything yourself:** API calls, uploads, builds, template and CSV downloads and exports, every console
|
|
navigation (open, Get Started, Edit, Next, Continue, Save draft), console forms, and the verification afterwards.
|
|
Never tell the owner "run this yourself" or "click X yourself" for any of these.
|
|
2. **The owner keeps only the final public or irreversible buttons:** Submit for review (App Review or Beta App
|
|
Review), releasing a version or completing / resuming a production rollout, App Privacy Publish, accepting legal
|
|
agreements; plus deleting store data, changing live prices, sending review replies and inviting or removing
|
|
testers. (Also the owner's: canceling a submission, starting or stopping a store experiment, a console form's final
|
|
Submit / Create that a console plan lists in `buttons.final`, signing in and granting account permissions.) For
|
|
these you prepare everything, show the dry run, and the owner presses one button or says yes.
|
|
3. **Ask the owner only for facts that no code, config or doc can prove:** compliance answers such as Data safety,
|
|
App Privacy, age rating, export compliance, partial data deletion. Collect ALL of them in ONE batch at the start
|
|
(`storebound check` and `storebound validate` list them), never one at a time during the run. Reuse answers that
|
|
are already in the config.
|
|
4. **Default loop:** plan, then you drive (the API first, your browser tool for consoles without an API), then verify
|
|
(read it back), then continue. No round trip to the owner in between.
|
|
5. **Catch rejections offline.** Before a write, `storebound check` and `--dry` must catch what the store would refuse
|
|
(live-shape fixtures, id and pair checks). A failure belongs in the dry run, not in a 400 at write time; when a
|
|
store refuses something the dry run passed, fix the check (pitfalls), not just the data.
|
|
|
|
Every hour of "please click this" is an hour the owner did not want to spend. If you catch yourself writing "you
|
|
need to ...", do it instead, unless it is one of the owner steps in point 2.
|
|
|
|
## The other rules
|
|
|
|
**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.
|
|
|
|
1. **The owner presses only the owner steps** (point 2 of the first rule). Prepare them completely, say what will
|
|
happen, and let the owner press the button, or run the command only after a clear yes in chat. storebound's MCP
|
|
server does not offer these at all. Everything else you run yourself.
|
|
2. **Dry run first, then run it yourself.** Every write command has `--dry` (MCP: `dry_run`, default true). Run the
|
|
dry run, check and show it (the rows that change, not just a count), then run the real command yourself (`--yes`
|
|
where it asks for a confirmation) and read the result back. Wait for the owner's yes only before an owner step.
|
|
3. **Read before you write.** `storebound scan` (offline: rejection risks in the project itself), `storebound check`
|
|
(offline) and `storebound validate` (read-only, both stores) tell you what is missing and in which order to fix it.
|
|
4. **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 (`reviewDemoAccount` in `.storebound/credentials.json`): the owner puts it there.
|
|
5. **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, all such questions in one batch at the
|
|
start (first rule, point 3), and write the answers into the config. A wrong "no" is worse than a slow "ask".
|
|
6. **Pick builds by explicit number.** Use the build number / versionCode you just uploaded, never "the latest".
|
|
7. **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.
|
|
8. **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.
|
|
9. **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).
|
|
10. **Console forms without an API: drive them yourself, agent-first.** `storebound console plan <form> --json` (MCP
|
|
`console_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 writes `window.__log` (one evaluate call times out around 45 s), stop only before the final button (Publish,
|
|
Submit, Create, a final Save) and tell the owner exactly what to press, then `storebound console verify <form>`.
|
|
Never sign in, accept an agreement or grant a permission (a service account's app access) for the owner.
|
|
`storebound console fill` is the optional scripted fast path; it never blocks you.
|