用途：把含多个可部署组件的仓库转成统一的 OpenDeploy 项目计划，覆盖 monorepo、workspace、docker-compose、web+worker、cron 及多服务项目。通常由 /opendeploy 内部调用，用户无需切换命令。
主要能力与做法： 一、预检与命令。直接调用时先执行 OpenDeploy 门禁： npm list -g @opendeploydev/cli --depth=0 --json；npm view @opendeploydev/cli version --json；opendeploy update check --json；opendeploy preflight . --json；opendeploy deploy plan . --review --json。仅用全局 opendeploy 二进制，不要用 npx。 二、建立服务图而非猜测清单。为每个候选项确定 service_kind（web、worker、cron、internal 或托管依赖）、源码根、构建与启动命令、公开 HTTP 端口、依赖与环境别名、持久化需求。仅当公开入口、用户自有密钥、破坏性存储选择或源码编辑无法安全推断时才停止。 三、仓库形态区分。孤立 monorepo（子应用不共享本地包）以子目录为源码根，如 apps/api；共享 workspace（pnpm-workspace.yaml、workspaces、turbo.json、nx.json 或共享 packages/*）应保留仓库根并使用过滤命令，如 pnpm --filter <pkg> build、pnpm --filter <pkg> start 或 turbo run build --filter=<pkg>。不确定时优先仓库根加过滤命令。 四、候选评分。强应用信号（源码根或服务内 Dockerfile、Procfile web、start/serve 脚本、框架入口、compose build 加 HTTP 端口、文档标注 web/API/app）；worker 信号（worker、queue、sidekiq、celery、scheduler、clock、beat、consumer、cron）；依赖信号（postgres、mysql、mariadb、mongo、redis、valkey、meilisearch、elasticsearch、qdrant、minio、clickhouse、rabbitmq、kafka、mailpit、smtp 或存储镜像）；忽略信号（仅配置包、示例、文档、storybook、playground、基准、测试、仅初始化容器、.devcontainer、本地代理/垫片包、dev/test profile 服务）。默认部署得分最高的公开 web/API 服务及其必需 worker 与托管 DB/缓存；仅当两个以上真实公开入口同等合理时才询问。 五、Compose/Procfile。从 compose 构建服务图，不照搬每个条目；仅构建有 build 或仓库内 Dockerfile/context 且具 web/worker/scheduler 角色的服务；image-only 条目视为预构建 sidecar。不要以 Docker Compose 为运行时单元部署，应转换为 OpenDeploy 服务、托管依赖、环境链接、端口、域名与卷。postgres、mysql、mongo、redis、valkey 在受支持时映射为托管依赖。depends_on 仅转为顺序与环境接线，不保证就绪。ports 容器侧为候选 HTTP 端口；volumes 转为存储决策。Procfile 中 web 为公开 HTTP 服务，worker、queue、sidekiq、celery、scheduler、clock 为无公开域名的 worker 或 cron。 六、多服务规则。除用户明确要多公开入口外只选一个公开入口；worker 保持内部、无域名；前后端都需要时两者都建并在域名就绪后接线；先写部署顺序（托管依赖、核心 API/web、websocket/实时、前端/仪表盘、worker/cron），一次部署一个直至核心公开路径健康；创建前写资源预算；同镜像不同模式可复用 Dockerfile 配不同启动命令/env；wrapper Dockerfile 的 source_path 保持上传根、dockerfile_path 指向归档内存在文件，运行 opendeploy archive create . --json 验证包含且不含 .secrets/.env/token；共享 workspace 中命令可能需 cd 进包目录；JS workspace 优先用包管理器过滤命令；记录 watch 路径类证据；首次流量前规划迁移/初始化并验证；扫描所有 DB URL 别名（如 DIRECT_URL、DATABASE_DIRECT_URL、MIGRATE_DATABASE_URL、SHADOW_DATABASE_URL）；先建托管依赖并等就绪、取环境，再建应用服务；启动关键 URL 型环境须有有效值；晚期绑定的服务间/公开 URL 需显式处理；本地持久数据尽量在首次部署前加卷并回读 opendeploy volumes list --service <id> --json；worker 优先 service type: worker 与 internal_only: true；用最小 service-create body 并回读验证；每个服务保存 ID，重部署必须传既有 ID，否则可能重复；失败恢复按日志与回读、修补同服务配置、deployments retry、再为同服务创建一次新部署的顺序，不创建替代服务、不停无关健康服务；依赖版本不同须给简要说明与冒烟测试计划。 七、用户提问与输出计划。仅在服务图无法由源码证明或出现新同意门时提问；推荐选项标签须含 (Recommended) 且排首位且不把推荐藏在说明里。变更前保留精简计划表：Service、Kind、Source、Build、Start、Port、Dependencies，随后进入主 opendeploy 首次部署流程。
限制：以上为技能文档所述规则，未提供具体定价、配额数值、支持平台清单或未提及功能，均暂未提供；具体命令与步骤以文档为准。