deploy-microfeed

name	deploy-microfeed
description	Deploy and administer microfeed from a local repository clone using the project-owned yarn manage CLI. Use when a user asks a coding agent to operate a local or Cloudflare instance, including accounts, initialization, connection, development, deployment, themes, snapshots, status, destruction, Pages migration, domains, Access, built-in authentication, configuration, or instance selection.

Deploy microfeed

Use yarn manage as the only interface that changes Cloudflare. Do not replace the CLI workflow with raw Wrangler commands, Cloudflare API calls, an MCP server, a plugin, or dashboard-created Worker, D1, or R2 resources.

Read the relevant command section in the canonical yarn manage reference before using an unfamiliar command or option. Treat that document as the complete capability and side-effect contract; keep this skill focused on agent sequencing and safety.

microfeed supports one deployment engine: yarn manage from a local repository clone. A person may run it directly or ask a local agent to operate it, but do not offer Cloudflare repository imports, Workers Builds, deploy buttons, GitHub Actions, raw Wrangler deploys, or API-token deployment as alternatives. If a user asks for a dashboard-only or hosted deployment, explain that it is not supported and guide them to the local yarn manage workflow. Never request their Cloudflare email, password, private password-setup link, or token in chat.

Guardrails

• Use this workflow only from a local interactive coding-agent session whose environment can complete Wrangler's localhost browser OAuth callback. Do not attempt it from a hosted or headless agent session.
• Never request a password or Cloudflare token in chat. Never use --admin-password; that deliberately unsafe option exists only for unattended automation whose operator accepts shell-history, process-list, transcript, and CI-log exposure.
• Relay the one-time password-creation URL printed by yarn manage exactly once so the user can open it. Treat it as private: never ask the user to paste it back, write it to a file, reuse it in another command, or expose it after it has served its handoff.
• Stop before deployment when the Wrangler browser OAuth callback is unavailable.
• Inspect git status --short before deploying. If the working tree is dirty, identify that the current files will be built and obtain explicit approval to deploy them. Do not modify, discard, or stash the changes.
• Treat changes to package.json, yarn.lock, .yarn/, manage-cli/, wrangler.jsonc, wrangler.template.jsonc, astro.config.ts, or this skill as security-sensitive because deployment executes or trusts them. Inspect their diffs and any untracked files, name them to the user, and recommend a clean trusted checkout. Continue only when the user explicitly trusts those exact changes; a generic approval of a dirty tree is insufficient.
• Explain the external changes before starting: fresh initialization can create a Worker, D1 database, R2 bucket, Worker secrets, and, only when selected, a Worker Custom Domain with Cloudflare-managed DNS and certificates.
• Keep never-provisioned webhooks off unless the user explicitly asks to enable them for an exact production or preview site. Preserve an existing enabled or disabled lifecycle state during ordinary deployment; never change it without an explicit request. First opt-in creates a dedicated Queue, producer and consumer bindings, an hourly maintenance trigger, and an endpoint-secret encryption key, so it requires its own approval and exact --enable-webhooks command.
• Delete a deployment only through yarn manage destroy, after its dry run and explicit approval of the exact resource list. Never delete reused data, bypass identity or replacement-resource checks, pass --yes, or improvise lower-level deletion commands. Never reuse an existing D1 database or R2 bucket unless the CLI identifies it and the user explicitly approves that exact resource.

User-facing language

• Assume the user does not know Cloudflare terminology. Ask for a site name, not an "instance" or "Worker name." Explain that it is a short name for the new microfeed and helps form its web address.
• Before asking for the site name, recommend choosing a globally unique, distinctive name even though Cloudflare technically scopes Worker names to an account. If the user plans to use a custom web address, recommend replacing its dots with hyphens: for my.domainname.com, suggest my-domainname-com.
• Ask for the email used to sign in as administrator, not an "owner email." Explain that this creates the first protected dashboard login.
• Do not ask the user to name D1 or R2 resources unless they request advanced customization. Derive their names from the site name using the documented defaults.
• Ask about a custom web address in plain language and make clear it is optional and can be added later.
• Keep terms such as Worker, D1, R2, instance, binding, and OAuth out of the initial questions. Introduce them only when needed for an approval or error, and immediately explain what each resource does in plain language.
• Never ask for all configuration fields at once. Start with: "Choose a globally unique site name. If you plan to use a custom web address, replace its dots with hyphens—for example, my.domainname.com becomes my-domainname-com. What would you like to call your site, and what email would you like to use to sign in as administrator?" State separately that the user must not send a password in chat. After receiving those answers, always ask: "Would you like to use your own web address (for example, feed.example.com), or start with the free Cloudflare address? You can add your own address later." Do not start initialization until this choice is explicit, unless the user already supplied it.

Deployment readiness checklist

Show a short, plain-language checklist when deployment begins. Reprint the updated checklist after every completed milestone, before each user handoff, and in the final report. Use ✅ for complete, ⏳ for the current action, and ⬜ for pending. Never mark a skipped or unverified step complete.

Use these checks, adapting labels without exposing secrets:

• Local project and required software are ready
• Cloudflare sign-in is authorized
• Cloudflare account is selected
• Site choices are confirmed
• Site and content database are deployed
• Media storage is ready, explicitly disabled, or clearly marked as pending Cloudflare activation
• Public site is verified
• Administrator password is created and protected login is active
• Web address choice is complete: custom address verified, or free Cloudflare address explicitly accepted

Keep user handoffs next to the relevant pending item. A deployment is not fully ready until every applicable check is complete. If a step fails, show it as pending with a one-sentence recovery action; do not imply that earlier successful steps were undone.

Choose the management command

• Cloudflare authorization/account discovery: yarn manage accounts --json
• Separate named Cloudflare login: yarn manage accounts --profile <name>
• Fresh authorization for a named login: yarn manage accounts --profile <name> --reauthorize
• Fresh Cloudflare installation: yarn manage init
• Saved Cloudflare installation: yarn manage deploy
• Explicitly enable deferred media storage: yarn manage deploy --enable-r2
• Explicitly enable production webhooks: yarn manage deploy --enable-webhooks --instance <instance-name>
• Explicitly enable preview webhooks: yarn manage deploy --preview --enable-webhooks --instance <instance-name>
• Disable production webhook infrastructure while retaining its Queue and encryption secret: yarn manage deploy --disable-webhooks --instance <instance-name>
• Disable preview webhook infrastructure independently: yarn manage deploy --preview --disable-webhooks --instance <instance-name>
• Disable local Queue and Cron simulation for one run only: yarn dev --disable-webhooks --instance <instance-name>
• Prepare an init --local instance without starting it: yarn manage deploy --local
• Existing compatible Worker not saved in this clone: yarn manage connect; connecting is read-only, so ask again before a later deployment
• Isolated local development server: yarn manage dev
• Theme initialization and live version management: yarn manage theme; use export-microfeed-theme when creating or exporting a standalone authoring repository
• Portable backup or restore: yarn manage snapshot
• Diagnostics only: yarn manage status
• Destruction plan or removal: yarn manage destroy
• Side-by-side migration from Cloudflare Pages: yarn manage migrate-pages
• Production custom domain: yarn manage domain
• Optional user-managed Cloudflare Access: yarn manage access
• Administrator login or dashboard-path changes: yarn manage auth
• Generate and validate local configuration:

Use init --no-r2 only when the user explicitly wants a content-only or test installation. It works for Cloudflare and local initialization, saves the future bucket name, and must not be combined with preview or reuse approval. Preview and Cloudflare snapshot operations require production R2 to be ready.

Use --instance <name> whenever more than one saved instance exists or the user named a target. Do not deploy a local-only instance to Cloudflare.

When the user asks to enable webhooks, repeat the exact target environment. Explain that first enablement creates one dedicated Queue and encryption secret, while later enables verify and reuse their exact saved identities. An ordinary deployment preserves the saved state: enabled remains enabled, disabled remains detached, and unprovisioned remains off. Follow the normal dirty-checkout and Cloudflare authorization guardrails, run only the appropriate command above, then verify with yarn manage status --instance <instance-name> and report the Queue ID, producer binding, Worker consumer, delivery state, and Cron result. Do not infer preview from production or production from preview.

When the user asks to stop one webhook integration, guide them to Admin → Webhooks → Endpoints to disable or delete that endpoint. When they ask to stop webhook infrastructure or periodic Worker checks, use the exact production or preview --disable-webhooks command above after repeating the target. Explain that it cancels pending deliveries, purges queued messages, and removes the producer, consumer, and every Cron while retaining endpoint data, delivery history, the dedicated Queue, and the encryption secret. Events during the disabled interval are not replayed. Rerunning enable or disable is idempotent; never recreate, rename, adopt, purge, resume, or delete the Queue outside yarn manage.

Fresh-clone workflow

1. Confirm the repository root contains package.json, yarn.lock, and manage-cli/index.ts.

2. Check node --version and require Node.js 24. Check Corepack and enable it when Yarn is unavailable. Obtain approval before a command writes outside the workspace.

3. 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.

4. Collect non-secret choices in the plain language described above. 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

5. Discover the user's Cloudflare access before 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.

6. 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.

Existing installations

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.

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.