Deploy Microfeed

Prepared-workspace workflow

1. When the published launcher handed off this skill, use its printed cached repository and reference paths and keep using the public npx command prefix. The launcher has already verified the bundled release source and run yarn install --immutable with its pinned Yarn runtime; do not edit the cached source or run a second checkout. In a user-managed clone, confirm the repository root contains package.json, yarn.lock, and manage-cli/index.ts.

2. Require Node.js 22.12 or newer with npm for the public npx invocation. Ordinary deployment through the published launcher does not require Git or Corepack. Git is command-specific for installing or updating a theme from GitHub, initializing a theme repository unless --no-git is passed, and theme export --git. In a user-managed clone, check its normal development tools directly and obtain approval before a command writes outside the workspace.

3. In a user-managed clone, before any command receives OAuth input, obtain network approval and run yarn install --immutable --check-cache. This must revalidate the locked packages and relink local dependencies even when node_modules already exists, unless the same trusted session just completed that exact command. The launcher-owned workspace has already completed its locked installation.

4. Do not assume the user needs a new site. Discover their Cloudflare access before collecting new-site choices or making any deployment mutation:

   yarn manage accounts --json

   Explain that Wrangler may open Cloudflare in the browser and stores the resulting OAuth credentials through its OS keyring support. Explain that a profile is a saved Cloudflare login, while an account is a Cloudflare workspace that owns sites and data. The output lists every stored profile, marks the one active for this repository, shows only that login's accounts, and prints commands for switching to other named profiles. If authorization is required, pause for the user to finish it, then resume the command. If no usable account appears, offer yarn manage accounts --reauthorize. If the user wants to preserve the current login and add another, use yarn manage accounts --profile <name> --reauthorize instead. Do not work around OAuth with a token.

5. When exactly one account is returned, use its full ID. When several are returned, show each plain-language account name and the last eight ID characters, then ask the user which one owns the site. Duplicate names are expected; use the selected full ID. Never select the first account, and never begin initialization before this choice is resolved.

6. Run yarn manage instances --account-id <account-id> --json. Use the selected saved instance when one exists. Otherwise show every exact compatible Worker candidate. Ask the user to choose when more than one is available, then use the ready-to-run read-only connect command for the chosen Worker and continue with Existing installations. Continue below only when no compatible Worker is selected and the user wants a new site. Collect the new site's non-secret choices in plain language. Ask only for the site name and administrator sign-in email initially. Then require an explicit choice between a custom web address and the free Cloudflare address; do not silently assume either. If the user wants a custom address, collect its exact hostname. Map those answers to the internal values and recommend the documented defaults:

   • site name, internally used as the instance and Worker name: the user's globally distinctive name
   • content database (D1): <worker-name>-db
   • media storage (R2): <worker-name>-media
   • dashboard path (--admin-path): admin
   • authentication: built-in email/password
   • administrator sign-in email, internally passed as owner email: supplied by the user
   • custom domain: optional; collect an exact hostname when selected

7. Summarize the selected site and the services Cloudflare will create in plain language: the hosted application (Worker), content database (D1), optional media storage (R2), protected dashboard path and administrator login, and optional custom web address. Show the exact technical resource names in parentheses for an auditable approval. Obtain approval for the browser Cloudflare sign-in and exact Cloudflare changes before starting the initialization command.

8. Start initialization with every known non-secret choice and the exact account ID so the user is not asked twice:

   yarn manage init --instance <instance> --project-name <worker> \
     --account-id <account-id> \
     --d1-name <database> --r2-name <bucket> --admin-path <path> \
     --admin-auth built-in --owner-email <email> --yes

   Omit --owner-email when built-in authentication is not selected. Never add --admin-password. If --yes is inappropriate because the user asked for interactive customization, still supply --account-id and every answer already known.

   Add --no-r2 only after the user deliberately opts out. If Cloudflare instead returns 10042 / NotEntitled, accept the CLI's verified content-only completion. Relay its account-specific R2 dashboard link and explain that activation and any payment method or billing consent must be completed by the user in Cloudflare; never attempt that consent yourself.

9. If initialization is interrupted, rerun the identical command. Rely on the CLI's saved state and resource checks; do not bypass a collision or add a reuse flag unless the user approves the exact resource. When Wrangler says a workers.dev subdomain must be registered during a newly created account's first Worker deployment, treat it as temporary account preparation and do not relay Wrangler's onboarding link. For an agent-driven run, wait about 60 seconds and rerun the identical init command once. If it persists, relay the CLI's guidance so the user can wait a few minutes before trying again.

10. Honor the recorded web-address choice. If the user selected a custom web address, run:

    yarn manage domain --instance <instance> --hostname <hostname> \
      --account-id <account-id> --yes

    A hostname change while password setup is pending rotates the one-time token. Discard the earlier URL and relay only the new final-hostname URL. If the user selected the free Cloudflare address, mark that checklist item complete without creating DNS or a custom domain. If the choice was never recorded, stop and ask before continuing.

11. Find the final one-time URL in the management command's output. Explain that the dashboard deliberately returns HTTP 403 until the user opens this private link and chooses a 12–128 character password in the browser. Relay the URL, wait for the user to say browser setup succeeded, and never handle the password yourself.

12. Verify the finished installation:

    yarn manage status --instance <instance> --account-id <account-id>

    If status reports a healthy deployment with password setup still pending, do not call the deployment failed. Relay the newest link if this run has one, wait for browser completion, and rerun status. If the link expired or is missing, run yarn manage auth setup with the same instance and account ID to rotate it.

13. Report the verified public URL, dashboard URL, site name, Worker, D1 database, R2 bucket and setup state, authentication mode, and custom domain status. Include the completed readiness checklist. Warn and stop if the status command says the admin dashboard is public.

Existing installations

With published-launcher state, start with accounts --json; when several accounts are available, show their names and ID suffixes and ask the user to select one. Then run instances --account-id <account-id> --json. Use the selected saved instance when one exists. Otherwise show every exact compatible Worker candidate, ask the user to choose when more than one is available, and run the listed read-only connect command for the selected Worker. Obtain deployment approval before deploy. Run init only when the user chooses a new site rather than a discovered installation.

Before updating, show the selected instance with yarn manage instances and confirm the target. Run yarn manage accounts --json, verify that the saved full account ID is still available, then run yarn manage deploy --instance <instance> --account-id <account-id> and yarn manage status --instance <instance> --account-id <account-id>. Use --preview consistently when the user selected the isolated preview environment.

If instances or status reports automatic pending media, a non-interactive agent deployment leaves it content-only and prints the deterministic enable command. Ask whether the user wants to activate media storage. After the user has enabled R2 and accepted any Cloudflare billing terms in the dashboard, run yarn manage deploy --enable-r2 --instance <instance> --account-id <account-id>. A same-named bucket still needs approval for that exact reuse; add --reuse-r2 only after receiving it. If media is recorded as disabled, ordinary deploys stay quiet and the same explicit enable command is the opt-in.

For a local-only instance, use yarn manage deploy --local --instance <instance> to apply local migrations and run checks/build without starting a server. Add --enable-r2 only when the user wants to permanently add the simulated local media binding.

Treat an authentication, permission, name-collision, Pages-domain, or verification failure as actionable. Preserve the CLI's error, explain the next safe step, and rerun the same management command after the user resolves it. Do not work around the failure with lower-level Cloudflare tooling.

Webhook lifecycle commands perform retried, read-only D1 and Queue access preflight before changing infrastructure. If Cloudflare returns authentication code 10000, use the exact fresh-process command printed by yarn manage. Never substitute a raw Wrangler command. A failure before the preflight leaves the Queue untouched; a later failure leaves a recorded transition that the same command resumes safely.

Destruction workflow

1. Treat requests to delete, destroy, remove, uninstall, or tear down a site as destructive authorization only after the target is unambiguous. Do not infer permission to delete from a request that merely asks how deletion works.

2. Inspect the working tree under the same security-sensitive rules used for deployment. Select the saved site and verify its saved Cloudflare account is available.

3. Always begin with the read-only plan:

   yarn manage destroy --instance <instance-name> --account-id <account-id> --dry-run

   Add --preview only when the user selected the preview. Never destroy production while its preview exists; remove preview first as instructed by the CLI.

4. Relay the complete plan in plain language, including the site and account, public address, hosted application, database ID and name, media bucket, webhook Queue name, Queue ID, state, ownership, exact consumer, backlog, Cron schedules, custom address, reused/preserved status, local instance folder, and every dashboard inspection URL. Explain that confirmed destruction verifies and detaches only the saved Worker's Queue consumer, then deletes the instance-specific Queue even with --keep-data, while D1 and R2 may be preserved. Owned Cloudflare data deletion is permanent and that the local folder includes a separate development database and media sandbox. Ask whether the user wants to keep Cloudflare data; add --keep-data only when they explicitly choose it.

5. Obtain explicit approval for that exact plan. Then run:

   yarn manage destroy --instance <instance-name> --account-id <account-id> \
     --confirm <instance-name>

   Preserve --preview or --keep-data from the approved plan. Do not use --yes; do not substitute the confirmation value.

6. Show a destruction checklist through the handoff:

   • dry-run inventory reviewed;
   • exact deletion approved;
   • hosted application and custom address absent;
   • owned database absent or explicitly preserved;
   • owned media storage absent or explicitly preserved;
   • webhook Queue absent and Cron schedules removed;
   • local instance folder and development sandbox removed;
   • final Workers & Pages, D1, R2, and Queues list checks reported.

7. If interrupted, rerun the identical confirmed command. Rely on the CLI's recorded steps, identity checks, and replacement-resource refusal. Never clear its progress markers or delete a same-named replacement manually.

8. Report automatic deletion and preserved resources separately. Do not inspect or change Zero Trust or SSL settings. Relay the final account-specific Workers & Pages, D1, R2, and Queues dashboard links, the exact name to find on each page, and whether it should be absent or preserved. Ask the user to refresh the lists if Cloudflare has not reflected the change yet.