External Developer Agent Release Runbook
This is the one release prompt for an external BodyLink game developer. You do not need to program, choose a submission path, run commands, copy tokens, or interpret logs. Open the game repository in your coding agent and paste the block below unchanged.
A literally empty message cannot start an agent. The shortest usable request is “Release the BodyLink game in this folder for me.” A vague reply such as “go,” “yes,” or “approved” never authorizes a different upload or production action.
Copy everything inside this block as one prompt:
You are the lead for releasing the external BodyLink game in the currently open
folder. Assume I cannot program and may give you an empty, incomplete, incorrect,
misspelled, stale, or vague reply. Do all technical work yourself. Do not ask me
to run a command, edit a file, find an ID, inspect JSON/YAML, copy a token, choose
a release path, or interpret a log.
Goal
Prepare, test, export, and submit this external game through BodyLink's one-shot
OAuth agent flow. Produce exact validation/staging evidence, then prepare the
separate production submission only after a new exact human approval. A distinct
BodyLink human reviewer must play and approve that production submission.
Official Portal
https://bodylink-developer-portal.kiran-88f.workers.dev/
Human-input recovery
1. Treat “release it”, “ship it”, “go”, “do this”, or another vague initial
request as permission to INSPECT, TEST, BUILD, and PREPARE only. It is not
permission to authorize OAuth, upload, approve, publish, change access, or
modify production.
2. If my next reply is blank or unrelated, continue safe local preparation to the
first real human decision. Then repeat one compact decision and one exact reply
I can paste.
3. At an authority-changing decision, a blank, misspelled, partial, stale, or
different reply is NOT approval. Do nothing and show the same exact reply
again. STOP always cancels safely.
4. Derive repository, slug, version, artifact, bytes, digest, and source commit
from evidence. Never trust a value merely because I typed it.
5. “approved”, “lgtm”, “yes”, or “go” applies only when it exactly matches the
approval format immediately shown for the same artifact and effect.
6. If I paste a password, cookie, token, authorization code, or secret, do not
repeat or store it. Stop the affected flow and tell me which credential type
must be rotated.
Security and release boundaries
- Read every applicable AGENTS.md and repository release document. Preserve
unrelated work. Never push to main, force-push a protected branch, merge work
you authored, disable a test, weaken a gate, or commit a secret.
- I enter credentials only in the official Portal browser. Never read or export
browser cookies/storage. Never put credentials in commands, files, chat, or
evidence.
- Use the installed BodyLink CLI with OAuth Authorization Code + S256 PKCE. The
CLI opens a temporary 127.0.0.1 callback on the same computer as the browser.
Never copy, proxy, or replace the callback.
- A direct agent upload is validation/staging evidence only. Its response must say
source=agent-upload and productionEligible=false. Never call it approved,
published, production-ready, production-eligible, or live.
- Current external production is a separate authenticated Portal submission of a
new higher immutable version, followed by a distinct human reviewer. Exact-
digest confirmation for the direct upload is not reviewer approval.
- The BodyLink platform team currently provisions organization/game membership
and supplies the public OAuth client ID, organization ID, and game ID. These IDs
are not secrets. Never invent or scrape them.
- A slug@version is immutable. Never overwrite or reuse a submitted version. The
direct upload and later production submission therefore use different versions.
- The upload ZIP must not exceed 50 MiB (52,428,800 bytes).
A. Inspect without asking technical questions
- Confirm a game folder is open. If not, ask exactly:
HUMAN ACTION — OPEN THE GAME FOLDER
Open the game's repository folder in this agent, then reply READY.
- Read repository policy, git remote/branch/status, package.json,
bodylink.game.json, bodylink.project.json when present, lockfiles, and release
docs. Discover real scripts; do not invent commands.
- Report the verified repository, branch, dirty files, slug, current version,
source commit, Node/npm requirements, and available test/build/validate/export
commands.
- Find the Portal origin, public OAuth client ID, organization ID, and game ID in
the onboarding information already provided. If any are absent, finish safe
local checks and return exactly:
BLOCKED — BODYLINK PLATFORM ONBOARDING REQUIRED
missing: <client/org/game items>
completed evidence: <safe checks already completed>
next human action: Ask the BodyLink contact who granted Portal access to
register the account, organization, and game and provide the public IDs.
B. Build and verify
- Install dependencies through the repository lockfile when needed.
- Run repository-provided tests, build, submission validation, and ZIP export.
Prefer scripts such as test, build, validate, and export:zip only when they are
actually defined.
- Run the real local/hosted gameplay path, normally dev:hosted when available.
Exercise launch, first render, gameplay, available tracking/input, pause/back,
teardown, and relaunch. Label hardware-only checks honestly SKIPPED when the
required hardware is unavailable.
- Resolve ordinary technical failures when repository policy allows it, then
rerun affected gates. Never turn an untested item into PASS.
C. Freeze one immutable direct-upload candidate
- Verify the exact ZIP's slug/version against both manifests, PKZIP format, exact
bytes, <=52,428,800-byte limit, SHA-256 hex, and unpadded base64url SHA-256.
- Record the exact source commit and worktree state. If source changes are needed,
use a reviewable branch/PR and do not merge your own work.
- Present this and stop:
HUMAN ACTION — APPROVE OAUTH RELEASE FLOW
game: <slug>@<version>
file: <absolute ZIP path>
bytes: <exact bytes>
SHA-256 hex: <64-character digest>
SHA-256 base64url (Portal): <43-character digest>
source: <repository>@<full commit, or local-source limitation>
tests: <PASS/FAIL/SKIPPED summary>
effect: authorize and upload these exact bytes for validation/staging evidence
only; this does not authorize production.
Reply APPROVE OAUTH RELEASE <slug>@<version> or STOP.
- Do not start OAuth until I send that exact approval.
D. Run the one-shot CLI yourself
- Use the locally installed CLI. A normal invocation is:
npx --no-install bodylink release submit --portal <portal-origin> --client-id
<public-client-id> --org-id <org-id> --game-id <game-id> --version <version>
--bundle <absolute-zip-path> --source-repository <owner/repo> --source-commit
<full-lowercase-commit>
- Substitute only verified values. If repository and commit cannot both be
supplied truthfully, omit both. Never add a token or credential flag.
- Keep the command running while it owns the loopback listener. Credentials stay
in memory and are revoked/discarded when the command ends.
E. Walk me through browser authorization
- If Login/Register appears, show exactly one action:
HUMAN ACTION — SIGN IN
Verify the address starts with the official Portal origin. Register if needed
(password at least 12 characters), otherwise log in. Type credentials only in
the browser. Reply SIGNED IN when the consent page appears.
- Do not restart merely because sign-in was required. If the pending request does
not resume, stop the stale command and retry once with a fresh request. Never
reuse a callback, code, or token.
- On consent, verify the displayed client name, organization ID, game ID, device
label, release:read/release:submit permissions, expiry, and current 127.0.0.1
callback against onboarding evidence. On mismatch, deny and stop.
- If all displayed fields match, show:
HUMAN ACTION — AUTHORIZE AGENT
client: <displayed client name>
organization: <displayed org ID>
game: <displayed game ID>
device: <displayed device label>
permissions: release:read, release:submit
callback: <displayed 127.0.0.1 callback>
Reply AUTHORIZE AGENT <org-id> <game-id> or DENY.
- Only after that exact reply, click the visible approval action when browser
control is available. Otherwise ask me only to click that button. Never ask me
to copy a URL, code, or token.
F. Confirm the exact digest
- The same-origin confirmation page must show the expected slug, version, exact
bytes, base64url SHA-256, expiry, and that this authorizes validation upload
only. Compare every field with section C; deny on any mismatch.
- If all fields match, show:
HUMAN ACTION — CONFIRM EXACT RELEASE DIGEST
game: <slug>@<version>
bytes: <exact bytes>
SHA-256 base64url (Portal): <displayed digest>
effect: upload for validation/staging only; productionEligible=false
Reply CONFIRM EXACT RELEASE <slug>@<version> <base64url-digest> or DENY.
- Only after that exact reply, click “Approve this upload” when browser control is
available; otherwise ask me only to click it. Keep observing the same CLI while
it uploads, waits for validation, and discards its one-shot credentials.
G. Interpret direct evidence and prepare production
- A successful direct result must include submissionId, source=agent-upload,
state validated or staged, and productionEligible=false. Record safe IDs/state
and digest without credential material.
- State plainly:
DIRECT AGENT EVIDENCE COMPLETE — NOT PRODUCTION ELIGIBLE
These exact bytes passed validation/staging evidence. They cannot be promoted.
- Ask whether I want to prepare the current external production submission. If
yes, use the same slug and a new higher semantic version. Update both manifests,
rebuild, rerun every gate, export, and compute the new exact digest. Then stop:
HUMAN ACTION — APPROVE EXTERNAL PRODUCTION SUBMISSION
game: <slug>@<new-version>
file: <absolute ZIP path>
bytes: <exact bytes>
SHA-256 hex: <64-character digest>
SHA-256 base64url: <43-character digest>
effect: upload through my authenticated Portal session for validation/staging;
a distinct BodyLink human reviewer must still play and approve it.
Reply APPROVE EXTERNAL PRODUCTION <slug>@<new-version> or STOP.
- Only after that exact reply, drive the visible Portal /submit form. If browser
control cannot select the local file, ask me only to choose the named file and
click Upload. Save the resulting submission URL.
- Observe received -> validating -> staged or a fail-closed rejection. Then show:
HUMAN ACTION — DISTINCT PRODUCTION REVIEW
Send <submission URL> to a BodyLink reviewer. That person must play the staged
build and approve or reject it with their own Portal account.
Failure handling
- Sign-in does not resume: stop the stale CLI and retry once with a fresh request.
Never paste credentials or callback data.
- Loopback callback fails: confirm browser and CLI are on the same computer and
retry once. Remote/headless authorization is not supported by this flow.
- ZIP exceeds 50 MiB: stop before OAuth, reduce assets safely, rebuild, revalidate,
recompute the digest, and request approval again.
- Immutable conflict: bump both manifests to a new version, rebuild, revalidate,
recompute the digest, and request approval again.
- Service unavailable after bounded safe retry: preserve safe artifact evidence,
discard one-shot credentials, record timestamp/public code, and ask the
BodyLink platform team to restore service. Never work around the Portal.
- Any response missing source=agent-upload or productionEligible=false: fail
closed and escalate to the BodyLink platform team.
Final evidence
Return repository/branch/commit/worktree state; slug@version; ZIP name/path,
bytes, SHA-256 hex/base64url; every test/build/validation/gameplay PASS/FAIL/
SKIPPED; authorization and digest-confirmation timestamps without secrets;
confirmation/submission IDs; source/state/productionEligible; credential cleanup;
production submission ID/state when requested; and exactly one next human action.
Never say LIVE until the distinct reviewer approves and the production catalog
shows the exact production slug@version.
What this proves
The direct CLI step proves one-shot delegated authorization, exact-artifact confirmation, upload integrity, validation, and staging evidence. It does not create a production-eligible release. External production remains a separate authenticated Portal submission and a distinct BodyLink human review.