agent rules: first rule "Do it, don't ask" (agents-core and every adapter, README, store-pitfalls lead, first-release, declarations and console skills); the agent runs the real command after the dry run, the owner presses only final public or irreversible buttons and answers compliance facts in one batch; handoff text removed from skills; tests/do-it-dont-ask.test.ts. Pitfall 26

skills/play-first-release/SKILL.md

@@ -10,10 +10,12 @@ or `bun <toolchain>/cli/index.ts`; agents can also use the `storebound mcp` tool
 It reads `storebound.config.ts` in the project (create with `storebound init`) and credentials from env or
 `.storebound/credentials.json` (gitignored). Every write command has `--dry`. Run `storebound check` first.
 
-**Ask the owner before anything public or irreversible**: production releases, "Send for review", publishing,
-deleting products. Sending a first release for review is the owner's action in the Console, not yours.
+**Do it, don't ask** (first rule in AGENTS.md / `docs/agents-core.md`): you run every step below yourself, API steps
+with storebound and UI steps in Play Console with your browser tool, and verify each. The owner only presses the
+public or irreversible buttons (Send changes for review, production release or rollout, agreements, deleting
+products) and answers the compliance facts no file proves, all in one batch at the start.
 
-## Steps (API = storebound does it, UI = Play Console by hand)
+## Steps (API = storebound, UI = Play Console, driven by you with your browser tool)
 
 1. **UI · Create the app.** `storebound console plan play-app-record` (then drive the form with your browser tool,
    or the scripted `storebound console fill play-app-record`). The form is
@@ -25,10 +27,11 @@ deleting products. Sending a first release for review is the owner's action in t
    `/console/u/0/developers/<developerId>/app/<appId>/app-dashboard`: put that app id in `play.appId` (the App
    content forms deep-link from it).
    **Owner step after every Create app:** a service account's app-level permissions do NOT cover apps created later.
-   The owner opens Users and permissions > the service account > Add app > the new app > Admin (or at least: view app
-   information, manage store presence, release to testing tracks, manage testing tracks, manage production releases,
-   manage policy declarations, manage orders and subscriptions) > Apply > Save changes. Never do this yourself: it is
-   a permission grant (agents in auto mode are blocked from it too). Then `storebound apps check --store play`.
+   Granting them is the owner's (a permission grant; agents in auto mode are blocked from it too): give the exact
+   path in the same message as the Create app button, Users and permissions > the service account > Add app > the new
+   app > Admin (or at least: view app information, manage store presence, release to testing tracks, manage testing
+   tracks, manage production releases, manage policy declarations, manage orders and subscriptions) > Apply > Save
+   changes. Then run `storebound apps check --store play` yourself.
 2. **UI · API access.** Google Cloud project (any) > enable "Google Play Android Developer API" > create a service
    account > JSON key (keep it outside the repo). Play Console > Users and permissions > Invite new users > the
    service account email > app permissions: view app information, manage store presence, release to testing tracks,
@@ -52,7 +55,7 @@ deleting products. Sending a first release for review is the owner's action in t
 6. **API · Listing text.** Fill `store/listing.md` (one section per language), then `storebound play listing`.
    It also sets contact email + website (website = the domain serving app-ads.txt). Run `--dry` first and show the
    owner the plan (details and per language old -> new per field; draft languages skipped until `listing reviewed`,
-   `--include-drafts` only on the owner's word); the real run asks in a terminal and PUTs only what changes.
+   `--include-drafts` only on the owner's word); then run it yourself with `--yes`: it PUTs only what changes.
 7. **API · Graphics.** Render (`store-screenshots` skill), `storebound shots jpeg`, then
    `storebound play images > .storebound/play-images.log 2>&1 &` and follow the log (it is slow: one edit per language).
    Required: the 512 x 512 icon, the 1024 x 500 feature graphic and at least 2 phone screenshots (Play Console Help
@@ -68,7 +71,8 @@ deleting products. Sending a first release for review is the owner's action in t
     with the demo account (`review-access`); with accounts: the delete-account URL (`account-deletion`); subscriptions:
     `storebound play subscriptions` (`store-subscriptions`).
 11. **UI · Store settings.** Category + tags, contact details.
-12. **API + UI · Production.** `storebound play release --version-code N --production draft`, then in the Console:
+12. **API + UI · Production.** `storebound play release --version-code N --production draft`, then in the Console
+    (you, with your browser tool):
     Production > Countries/regions > Add countries > select all > Save; Production > the draft release > Edit >
     Next > Save; Publishing overview > **Send changes for review** (owner).
 13. **Verify.** `storebound validate --play` (no blockers), `storebound play status` (tracks, listings, products), Console dashboard has no open tasks,