用途
lov-dev-to-prod 面向已有项目需要从开发态过渡到生产态的情况，例如 Tauri、Electron、原生桌面或 Web 项目。它把项目整理成可复查的生产制品，并对配置、构建、签名、安装和发布交接边界做检查，直到用真实构建、签名或安装证据确认结果。外部公开发布始终是显式下一步，不会默认执行。
主要能力
技能区分三类范围：本地生产安装、已签名可分发制品、外部公开发布，并强调不能从前两类推断第三类。它会读取目标仓库的说明、构建配置、版本来源、包管理器和当前工作树，保留无关改动；只确认会影响结果的用户选择，例如平台、目标目的地或是否授权外发。开始修改前会先声明验收条件，例如 macOS 的 .app 通过签名与 Gatekeeper 检查、Windows 安装程序具有已签名可执行文件、Web 构建由生产命令生成且部署不在范围内。
使用方式
工作流要求按顺序执行：先解析技能根目录、依赖与运行时上下文，读取 skill.yaml 和共享用户画像，并确认本地资源可用；再冻结生产目标与授权范围，映射开发与生产边界，运行确定性基线脚本：
python3 "$SKILL_DIR/scripts/production_audit.py" --root . --format markdown
该报告仅作为审计辅助，不能单独证明产品已就绪。随后进行最小必要的源码与配置改动，保持开发命令可用，运行仓库既有的质量门禁，并用真实生产命令构建。验证阶段按平台检查，例如 macOS 下验证 bundle identifier 与版本、codesign --verify --deep --strict、spctl -a -vv -t exec，以及声明已公证时的公证装订；本地安装则先暂存制品，在获得明确安装授权后把现有应用移到可恢复位置，再干净复制并比对已安装可执行文件摘要。测试或原生检查失败时报告 blocked 或 implemented_not_verified，不以开发服务器检查替代。
适用场景
适合用户说“把这个项目从 dev 转成 prod”“帮我做生产就绪检查”“打一个可安装的正式包”或“把开发态应用装到本机应用程序”等情况；也适合在交给发布流程前确认开发服务器、环境变量、构建命令、签名与安装边界。
限制
不适用于直接公开发布到 GitHub、官网、商店或 CI/CD，这类工作应交给 lov-app-release 或 lov-release-via-cicd；也不适用于普通功能错误诊断、单项 UI 修改、代码重构，或性能、内存、后台任务优化。没有真实构建和运行验证时不会称为“生产就绪”；未获明确授权时不会创建发布、标签、上传或商店提交，也不会编造凭据、端点值或发布通道。依赖 Python 3.8+ 标准库及目标项目自身的包管理器、编译器、签名与平台验证工具，本地就绪流程不需要云服务、凭据或外部同级技能。