start

开始

新产品。 从 flow-next 或 flow-mono 初始化一个新应用，同时让 explore 在同一轮中梳理产品。这相当于 flow 技能中的“在此处设置 Flow”加上模板引导（决策 0026）：使用相同的 Flow 块和指令文件布局、相同的交付方式问题，以及相同的目标。

确定性的重命名、目标位置安全检查、基线文档和提交门控规则都位于此技能的 lib/ 模块中。请使用这些规则，而不要盲目全局替换或执行破坏性 Git 命令。

收集输入

先采纳调用中已经说明的信息，再提问。lib/identity.mjs 中的 inferTemplateFromRequest 会根据请求中指定的模板选择模板，并使用 lib/constants.mjs 中的 TEMPLATE_HINTS。请求中指定的项目名称，或当前目录的名称，就是建议使用的名称。

只针对仍缺少的信息，在一轮中提问：

1. 项目名称（产品标识；决定软件包名称和 Portless 主机名）。
2. 本地目标目录。 当 assessDestination 接受当前工作目录时，默认使用该目录；只有在用户提出要求或当前目录不符合条件时，才建议使用嵌套目录或同级目录。
3. 模板——仅在无法推断时询问。单个 Next.js 应用推荐使用 flow-next，Turborepo（apps/web、packages/ui）推荐使用 flow-mono。
4. 可选的 GitHub 远程仓库——仅当用户想要创建或关联新仓库时询问；绝不假定用户有推送权限。
5. 交付方式——仅在用户未说明时询问：本地或拉取请求，定义见 build 的“交付方式”部分。如果不创建 GitHub 仓库，建议选择本地；如果创建，则建议选择拉取请求。此依据仅适用于 start，因为仓库正在创建中。

如果没有收到答复，就再次询问；不要擅自改用用户未确认的目标目录。

在确认之前解决所有引导问题，包括需要保留哪些文件；引导流程会报告阻塞项，而不是提问。

使用 lib/identity.mjs 中的 deriveProjectIdentity 推导标识：slug、package.json 名称、Portless 名称，以及 <slug>.localhost 主机名。显示标题仍使用用户提供的名称。

写入前确认

口头请求可能会听错，因此在用户同意之前不要写入任何内容。说明模板、项目名称（包括 slug 和主机名）、目标目录、要创建的任何 GitHub 仓库及其可见性、交付方式、将写入的 Flow 块，以及交接给 explore 的安排，然后等待用户明确答复“是”。其他任何答复都不算同意；请更正信息并重新说明。

并行运行两个流程

用户同意后：

• 引导流程。 工作进程按“引导顺序”所列顺序，执行下方从“获取模板”到“初始提交”的所有部分，并报告完成情况。
• Explore 流程。 主会话以新产品运行的方式将对话交给 explore，并将用户的描述作为首条输入。Explore 在对话中起草内容，在引导流程报告初始提交之前不写入任何内容。

如果宿主没有独立工作进程，先运行引导流程，再运行 explore，并说明执行顺序。如果未安装 explore，请完成引导流程，并建议接下来进行探索。

引导失败不会中止探索：报告阻塞项并继续探索；待仓库创建后再整理简报。

获取模板（与上游历史记录无关）

获得授权时，优先使用 GitHub Use this template：

gh repo create <owner>/<repo> --template gaboesquivel/<template> --clone <destination>

否则，将模板克隆到临时目录，然后使用 lib/git-safety.mjs 中的 copyTemplateInto 将其复制到目标目录。该函数会跳过模板的 .git，且不会覆盖现有文件。如果目标目录中没有 .git，请在其中运行 git init，并在用户授权前不添加任何远程仓库。

• 切勿让 origin 指向 gaboesquivel/flow-next 或 gaboesquivel/flow-mono。
• 只有在用户明确提供并授权后，才添加用户的远程仓库。
• 写入文件前，使用 lib/git-safety.mjs 中的 assessDestination 和 assertNoTemplateOrigin。

在现有目录中引导项目。 仅包含 Agent 设置项（AGENT_SETUP_ENTRY_NAMES，lib/constants.mjs 中的条目）的目标目录视为空目录。在该根目录引导项目，而不是在嵌套文件夹中。保留这些文件，只添加 Flow 区块和 @AGENTS.md 导入：如果模板自带某个已保留文件的副本，请在 skipped 中报告，并保留采用者的版本。对于其他文件（例如提示词日志），assessDestination 会列出它们；请在收集输入时确定是否保留，然后将其传入 preserve。

如果目标目录中存在未经授权的意外文件，或路径中已有 Git 提交记录，请停止。切勿对现有项目执行 reset、clean 或删除其历史记录。

重命名模板标识符

使用 lib/rename.mjs 中的 renameAllowlistForTemplate、applyRenamesInTree 和 scanTreeForStaleIdentifiers。允许列表用于指定要重命名的文件；不要将其扩展为全局替换。

保留软件包导入（@repo/ui、web）以及对模板仓库的有效引用。扫描时保留的路径和跳过的目录分别由 lib/constants.mjs 中的 STALE_SCAN_PRESERVE_REL_PATHS 和 STALE_SCAN_SKIP_DIR_NAMES 指定。

重命名后，只要保留路径以外仍存在过时的模板标识符，身份验证就会失败。

依赖项和设置

在新项目根目录中运行模板的 pnpm setup（用于安装 .agents 中精选的技术类技能）。不要将 flow-skills 安装到新仓库中；如果用户已在此根目录安装了它们，请予以保留。除非用户提出要求，否则不要设置 FLOW_SETUP_SKIP_SKILLS。切勿提交机密信息；确保 .env.local 和构建产物不纳入 Git。

基线产品文档

使用 lib/baseline-docs.mjs 中的 buildBaselineDocs，为此产品编写 PRODUCT.md、DESIGN.md、ARCHITECTURE.md 和 GLOSSARY.md。记录模板名称、提交 SHA、派生的 slug/host，以及模板路由外壳。不要从 flow-skills 复制 Flow 的使命、标语或原则。如果 pnpm qa 报告这些文件存在格式问题，请运行项目的格式化工具（例如，在新根目录的文档上运行 pnpm exec oxfmt --write），然后重新运行检查。

引导顺序

所有步骤共用同一棵目录树，因此请将相互独立的步骤作为并发进程运行，而不是工作线程；分为五个阶段，每个阶段都要等待上一个阶段完成：

1. 身份重命名。
2. 同时运行 pnpm setup 并编写基线文档。
3. 运行 qa、eval、身份扫描和 build。
4. 启动开发服务器（portless_startup）。
5. 执行 HTTP 冒烟检查和 Operator fail-closed 检查。

在设置完成后的任一阶段运行 gitignore_artifacts。如果主机无法并发运行进程，则按相同顺序运行这些步骤，并说明这一情况。

验证（成功前必须完成）

将每项检查记录为 passed、failed 或 unavailable。仅构建通过或单元测试通过不足以作为成功依据。

检查	命令 / 操作
setup	pnpm setup
qa	pnpm qa
build	pnpm build
eval	pnpm eval（离线 GenUI + Eve 冒烟测试；断言失败 = failed）
portless_startup	pnpm setup:portless，然后运行 pnpm dev；记录 Portless 打印的 URL
http_home	对 Portless 源站执行 HTTP GET /
http_genui	执行 HTTP GET /genui
http_mcp	执行 HTTP GET /api/mcp 或 /.well-known/mcp.json
operator_fail_closed	未设置 OPERATOR_SECRET 时，Operator/MCP operator 必须安全关闭
identity_scan	scanTreeForStaleIdentifiers 不返回任何问题
gitignore_artifacts	对 .env.local、node_modules、.next 执行 git check-ignore

未配置密钥时，经过身份验证的 Operator 行为可能为 unavailable；这不算失败。依赖凭据的在线模型调用可能为 unavailable；请与必要的本地行为失败区分开来。

如果任何必要检查为 failed，请报告阻碍因素，且不要声称引导成功或创建误导性的成功提交。

Flow 块

所有必要检查通过后，使用 flow 技能的 lib/flow-block.mjs 编写项目的 Flow 块：传入项目的绝对路径以及已确认的交付方式（local 或 pull-request）。flow 技能的 Flow 块部分及其辅助工具负责指令文件布局；报告中保留辅助工具的输出，包括任何拒绝信息。除块的标记和导入行外，不要修改任何内容。未安装 flow 时，跳过此步骤并说明原因。

初始提交

仅当 lib/commit-gate.mjs 中的 canCreateInitialCommit 返回 ok，并且在写入块时，辅助工具报告其布局文件已被跟踪（若文件被忽略，块将不会纳入提交）时：

1. 检查暂存文件，确认其中没有密钥和构建产物。
2. 使用 chore: initialize <slug> 提交（参见 formatInitialCommitMessage）。
3. 确认 git status 干净、提交包含该块及任何导入、没有远程指向模板仓库，并报告提交 SHA。

不要使用 --no-verify。除非明确获准，否则不要推送或部署。

边界

• 仅可修改采用者的 AGENTS.md、CLAUDE.md、.cursorrules 或等效指令文件，以编写 Flow 块和 @AGENTS.md 导入。
• 不要自动调用 flow 或任何交付流水线；explore 是唯一的交接方式。
• 不要捆绑 Flow Factory 或工作流路由器。

完成

报告模板及模板提交 SHA、目标路径、保留和跳过的文件、重命名后的 slug 和 Portless 主机、创建或更新的文件、是否已写入 Flow 块及其交付方式、指令文件布局（块文件、是否已跟踪、导入）、每项验证检查、初始提交 SHA（如已创建）以及阻碍因素。引导流程结束时报告其通道，但不要打断尚未结束的探索问题。