cloudflare-app-bootstrap

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Cloudflare App Bootstrap

Cloudflare 应用引导

Take the project from its current state to a working local request that exercises the requested application behavior. Preserve the user's framework, package manager, CLI, and existing services. Read the relevant current documentation before choosing configuration or commands, and check support against installed versions with local CLI help and schemas.
将项目从当前状态推进到能够成功处理本地请求,并验证所请求的应用行为。保留用户选用的框架、包管理器、CLI 和现有服务。在选择配置或命令之前,阅读相关的当前文档,并通过本地 CLI 帮助和 schema 检查已安装版本的支持情况。

Start from the project

从现有项目开始

Inspect the app directory, lockfile, scripts, framework and adapter versions, Cloudflare configuration (
cloudflare.config.ts
, or a Wrangler configuration file), and existing setup instructions. In a monorepo, identify the application root before installing or generating files. Install from the existing lockfile and reuse the project's dependency and configuration conventions.
If the project has no Cloudflare configuration yet, set it up first with the
frameworks-on-cloudflare
skill for a framework app, or the
cf-cli
skill otherwise. Identify the source of any framework-generated configuration and edit that source. Do not replace a working app with a starter to resolve a configuration problem.
检查应用目录、lockfile、scripts、框架和 adapter 版本、Cloudflare 配置(
cloudflare.config.ts
或 Wrangler 配置文件)以及现有的设置说明。在 monorepo 中,先确定应用根目录,再安装依赖或生成文件。应基于现有 lockfile 安装依赖,并复用项目的依赖和配置约定。
如果项目尚无 Cloudflare 配置,先使用
frameworks-on-cloudflare
skill 设置框架应用,否则使用
cf-cli
skill。确定框架生成的配置来源,并直接编辑该来源。不要用 starter 替换可正常工作的应用来解决配置问题。

Connect only the resources the app needs

仅连接应用所需的资源

Identify each binding used by application code and map it to an existing resource or a new local resource. Keep names consistent across code and configuration. Keep existing resource identifiers: a binding without one is treated as a new resource to provision on the next deploy.
Read automatic provisioning before manually creating supported resources, and check which resource types it covers. Provisioning differs by CLI:
  • Wrangler:
    wrangler dev
    creates local resources that persist between runs, and
    wrangler deploy
    creates remote resources and writes their identifiers back to the configuration file.
  • cf
    :
    cf deploy
    provisions missing resources but does not write identifiers back to
    cloudflare.config.ts
    (Develop, build, and deploy). Record the identifiers it reports in the configuration.
Establish the account, environment, and resource before any required remote creation.
Choose the dev command from the app's scripts and the local development guide. A local Worker can use remote bindings: identify which resources are simulated and which calls reach real services before exercising writes. Use the framework's supported Workers dev integration; a frontend-only dev server does not establish that server bindings work.
For data-backed features, initialize only the state needed for the first meaningful request. Preserve existing migration tooling. For D1, follow migrations and pass
--local
or
--remote
to
d1 migrations apply
explicitly.
--local
initializes only the simulated database; apply remote migrations only when the requested setup includes that database change. For Durable Objects, check the current class migration configuration rather than treating it as a D1 SQL migration.
确定应用代码使用的每个 binding,并将其映射到现有资源或新的本地资源。确保代码与配置中的名称一致。保留现有资源标识符:如果某个 binding 没有标识符,则将其视为需要在下一次部署时创建的新资源。
在手动创建受支持资源之前,阅读自动预配文档,并确认其涵盖的资源类型。不同 CLI 的预配方式有所不同:
  • Wrangler:
    wrangler dev
    创建可在多次运行之间保留的本地资源;
    wrangler deploy
    创建远程资源,并将资源标识符写回配置文件。
  • cf
    :
    cf deploy
    会预配缺失的资源,但不会将标识符写回
    cloudflare.config.ts
    (开发、构建和部署)。应将其报告的标识符记录到配置中。
在执行任何必需的远程资源创建之前,先确定账户、环境和资源。
根据应用的 scripts 和本地开发指南选择开发命令。本地 Worker 可以使用远程 bindings:执行写操作前,应确定哪些资源会被模拟,以及哪些调用会访问真实服务。使用框架支持的 Workers 开发集成;仅运行前端开发服务器无法证明服务端 bindings 能够正常工作。
对于依赖数据的功能,仅初始化首次有意义请求所需的状态。保留现有的 migration 工具。对于 D1,请遵循migrations指南,并明确向
d1 migrations apply
传入
--local
或
--remote
。
--local
仅初始化模拟数据库;仅当所请求的设置包含该数据库变更时,才应用远程 migrations。对于 Durable Objects,应检查当前的类迁移配置,不要将其视为 D1 SQL migration。

Resolve configuration and secrets

解决配置和 Secrets 问题

Classify required values by consumer: build process, browser bundle, or Worker runtime. Keep private runtime credentials out of public client configuration. Use Workers secrets for runtime secrets, and configure values the build needs in its build environment.
In Wrangler and Vite projects, follow local secret loading for file names, environment precedence, and required-secret declarations. In a
cf
project, find the equivalent with
cf cli search
rather than assuming the Wrangler behavior. Reuse the project's chosen local secret file, make sure files with real values are ignored by Git, and provide names and safe placeholders for missing values. Local secrets are not installed on a deployed Worker. Authenticate only when the selected workflow needs account access; do not make login or deployment a blanket prerequisite for local setup.
按使用者对必需值进行分类:构建进程、浏览器 bundle 或 Worker runtime。将私有运行时凭据与公开客户端配置分离。运行时 secrets 应使用 Workers secrets,构建所需的值则应在构建环境中配置。
在 Wrangler 和 Vite 项目中,应遵循本地 secret 加载指南,了解文件名、环境变量优先级和必需 secret 声明。在
cf
项目中,使用
cf cli search
查找等效方式,不要直接假定 Wrangler 的行为。复用项目选定的本地 secret 文件,确保包含真实值的文件被 Git 忽略,并为缺失值提供名称和安全占位符。本地 secrets 不会安装到已部署的 Worker。仅当所选工作流需要访问账户时才进行身份验证;不要将登录或部署作为本地设置的统一前提条件。

Verify the first application request

验证首次应用请求

After changing configuration, regenerate binding and runtime types with the project's script:
wrangler types
in a Wrangler project, or
cf workers types
in a
cf
project. Do not hand-edit generated declarations. Run the relevant existing build and type checks.
Start the actual development workflow and exercise a representative route or UI action, including its binding access when applicable. Check the response and the intended state change, not just that a server started. For missing credentials or unsupported local services, report exactly what remains unverified instead of claiming the app works.
Leave reproducible install, initialization, and dev commands in the project's setup documentation. Report the tested URL or action, which resources are local or remote, required values still missing, and any remaining remote setup. Continue to deployment only when it is part of the user's task.
修改配置后,使用项目的 script 重新生成 binding 和 runtime types:Wrangler 项目运行
wrangler types
,
cf
项目运行
cf workers types
。不要手动编辑生成的声明。运行项目中相关的现有 build 和 type checks。
启动实际的开发工作流,并测试一条有代表性的路由或 UI 操作;在适用时,还应执行其 binding 访问。检查响应和预期的状态变更,而不只是确认服务器已启动。对于缺失凭据或本地服务不受支持的情况,应准确报告仍未验证的内容,不要声称应用能够正常工作。
在项目的设置文档中保留可复现的安装、初始化和开发命令。报告已测试的 URL 或操作、哪些资源位于本地或远程、仍缺少哪些必需值,以及尚未完成的远程设置。仅当部署属于用户任务的一部分时,才继续进行部署。

Skill feedback

Skill 反馈

If the user reports that this skill gave incorrect or outdated guidance, or is missing information, read references/skill-feedback.md.
如果用户报告此 skill 提供了错误或过时的指引,或者信息不完整,请阅读 references/skill-feedback.md。