القائمة
插件化工作流版 analyze。读取用户自然语言和插件上下文，完成需求解析、器件确认、驱动搜索、替代推荐或冷门驱动标记，并以 phase_complete + manifest_content 把结果交给下游。触发：插件 start_phase(analyze)。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Analyze MicroPythonOS App ideas directly or when invoked by mpos-plan-app. Use to turn natural-language MPOS App requests into requirements, default app identity, manifest draft, Activity/Service plan, MPOS/LVGL API plan, dependency risk, test/deploy plan, mandatory MicroPythonOS resource links, and a JSON handoff before code generation.
Deploy or preview a MicroPythonOS app on desktop, web, device copy, MPK install, or installer/flash guidance paths. Use when Codex needs to launch a confirmed app for manual preview, copy it to a board with mpremote, validate an MPK on-device, or route firmware install and erase to install.micropythonos.com. Does not own app generation, static lint, packaging, or default smoke testing.
MicroPythonOS 基础开发知识库。提供代码架构、App/MPK 约束、LVGL 编程约定、MPY API reference、官方 docs 专题 reference、AGENTS 本地强约束。mpos-plan-app / mpos-analyze-app / mpos-prepare-deps / mpos-gen-app / mpos-test-app / mpos-package-app / mpos-deploy-app / mpos-publish-app 均依赖此 skill。
Generate, update, and repeatedly repair MicroPythonOS App code after requirements are confirmed. Use after mpos-analyze-app and optionally mpos-prepare-deps to create or modify an internal_filesystem/apps package directory with root MANIFEST.JSON, root icon_64x64.png, assets/*.py entrypoints/dependencies, dependency adapters, and validation results. Always defaults to a two-phase flow: first produce a generation plan and ask for confirmation, then write files only after explicit user confirmation. Supports repeated calls for user feature changes and test-failure repair loops. Does not analyze vague requirements, prepare external dependencies, package MPK files, deploy devices, flash firmware, publish to upystore, or rebuild lvgl_micropython.
Package and validate a single MicroPythonOS App as an MPK release artifact. Use when Codex needs to create a .mpk, validate an MPOS App manifest/icon/package structure, emit one app_index_entry.json fragment, run optional temporary install validation, or prepare AppStore/upystore publishing artifacts without uploading.
Orchestrate a MicroPythonOS App workflow across analyze, dependency preparation, generation, testing, packaging, deployment, and upystore publishing. Use when Codex needs to start from a natural-language app request, continue or resume an interrupted MPOS app task, decide the next mpos-* skill, maintain per-app plan_state.json and activity_log.jsonl under tmp/mpos-plan-app, handle user requirement changes with invalidation confirmation, or run the default path through mpos-publish-app. Does not implement code, download dependencies, test, package, deploy, flash, or upload directly.
| name | upy-analyze-plugin |
| description | 插件化工作流版 analyze。读取用户自然语言和插件上下文，完成需求解析、器件确认、驱动搜索、替代推荐或冷门驱动标记，并以 phase_complete + manifest_content 把结果交给下游。触发：插件 start_phase(analyze)。 |
这是 upy-analyze 的插件化工作流版本。
目标不是延续“本地多轮问答 + 直接写盘”的旧形态，而是改成：
用户自然语言 + 插件上下文
-> 意图拆解
-> 器件确认
-> 按工作流搜索驱动
-> 替代推荐或冷门驱动标记
-> 输出 manifest_content
-> phase_complete(next_phase=select-hw, next_skill=/upy-select-hw-plugin)
本 skill 不覆盖原版 G:\MicroPython_Skills\upy-analyze，用于独立演进插件化工作流。
custom 模式最多允许 1 张补充卡片beginner 模式如需补充场景/供电/性能/输出，也必须收敛成 1 张补充卡片system_recommended 且无驱动时允许替代推荐，最多 2 个候选user_specified 且无驱动时不自动替代，直接标记冷门驱动路径phase_complete，不是本地 manifest 写盘manifest_contentnext_phase 当前固定为 select-hwnext_skill 当前固定为 /upy-select-hw-pluginnext_phase 表示工作流阶段名，不能改成插件名；调用入口由 next_skill 表示phase_complete.manifest_content本 skill 的目标不是做多轮自由对话，而是产出一份稳定的入口阶段结果：
输入上下文
-> 意图拆解
-> 器件确认
-> 可选需求补充
-> 驱动搜索
-> 替代推荐或冷门驱动标记
-> manifest 校验
-> phase_complete(next_phase=select-hw, next_skill=/upy-select-hw-plugin)
本 skill 只接受以下输入字段：
user_descriptionpre_selected_boardpreferences.modepreferences.localeexisting_hardwareuser_description
pre_selected_board
preferences.mode
preferences.locale
existing_hardware
user_description 缺失或为空：
preferences 缺失：
mode = "beginner"locale = "zh"pre_selected_board 缺失：
nullexisting_hardware 缺失：
user_descriptionpre_selected_boardpreferences.modepreferences.localeexisting_hardware输出目标：
status_update(step_id="intent_extraction", level="info", message="正在分析需求...")user_specified / system_recommended必须完成的结构化产物：
project_namerequirements.descriptiondevices[]nametypeinterfacesource工作要求：
user_specifiedrequirements.description。例如“触摸按键用 TTP223，按下后为低电平”应输出 devices[].notes，并尽量结构化为 devices[].behavior.active_level="low"。system_recommendeddevices[].source 枚举；仍用 user_specified 或 system_recommended 表达需求来源，并可写 physical_source="board_onboard" 作为提示。正式的板载外设匹配、onboard_peripheral_ref 和引脚/BOM 去重由 select-hw 根据完整 board JSON 归一化。完成本步骤后，必须输出：
status_update(step_id="intent_done", level="success", message="提取到 N 个器件 ...")这是主流程唯一必经确认点。
确认后必须得到：
如果用户中途补充说明：
不得只做局部字符串拼补。
本步骤的协议目标：
approval_request(device_confirm)approval_response强停点规则：
device_confirm 后，必须停止并等待用户回复beginner 模式就自动视为“用户已确认器件清单”用途：
要求：
本步骤的协议目标：
approval_requestapproval_response强停点规则：
requirement_supplement，必须停止并等待用户选择driver 状态upy-pkg-guide skill，不得由 analyze 自己伪造 upypi 包名或安装命令pkg_guide_adapter 返回固定测试结果，但该 adapter 必须模拟 upy-pkg-guide 的输出语义强制证据要求：
driver.source = "upypi" | "awesome-micropython" | "github" 时，必须写入 driver.search_providerdriver.search_provider 必须是 upy-pkg-guidetest/ mock runner 只允许使用 pkg_guide_adapter，且必须同时写入 driver.search_mode = "mock" 和 driver.mock = truedriver.source = "none" | "cold-driver" 且该器件不是 builtin runtime only 时，也必须记录 driver.search_provider 和查询说明，证明不是未搜索就下结论driver.source = "builtin_runtime" 必须写入 driver.search_required = false，并用 driver.search_provider = "builtin_runtime_classifier" 标明这是内置能力分类，不是包搜索结果driver.source = "micropython_lib" 必须写入 driver.search_provider = "micropython_lib_classifier" 或 driver.search_provider = "upy-pkg-guide"test/ 目录只用于本地 JSON/protocol 演练；真实插件流程不得把 pkg_guide_adapter 当成真实驱动搜索来源。
Analyze 在做驱动搜索前，必须先区分两层：
builtin_runtime不要把“MCU/固件已提供底层外设 API”和“已经找到某个具体器件驱动包”混成同一种结果。
先回答两个问题：
若第 2 个问题涉及具体器件驱动包，必须对该器件调用 upy-pkg-guide：
for device in confirmed_devices:
if device is builtin runtime only:
mark builtin_runtime
else:
call upy-pkg-guide(device.name / aliases / chip model)
normalize result into devices[].driver
upy-pkg-guide 的职责边界：
upypiawesome-micropythonpackage_name、version、install_cmd、api_ref、repo_urlapi_ref 应优先写成结构化对象，例如 {"init": "...", "read": "...", "calibration": "..."}；不要只写一段不可解析的字符串。若来源资料只能确认一句摘要，可先写入 notes，不要伪装成完整 API。builtin_runtime 只表示：
典型例子：
machine.Pinmachine.ADCmachine.I2Cmachine.SPImachine.UARTmachine.I2Snetworkbluetoothneopixel这类情况不应该报成“无驱动”，而应标记为：
driver.source = "builtin_runtime"并建议补充：
driver.moduledriver.notes但要注意：
builtin_runtime 不等于“已经找到该具体器件的现成驱动包”I2C / SPI / UART 上的具体器件，Analyze 仍应继续优先检查 upypi若能力不属于固件内置，但属于 MicroPython 官方生态通用库/中间件，则应单独标记为：
driver.source = "micropython_lib"这类来源不是“内置固件自带”，也不应被混同为普通第三方 GitHub 库。
在 analyze 阶段，micropython_lib 的定位是：
典型例子：
aioble建议补充：
driver.package_namedriver.install_cmddriver.repo_url硬约束：
micropython_lib 不是温湿度、土壤、显示器、执行器等具体器件驱动的默认第一搜索源upypi若目标是“具体器件驱动”，而不是“官方生态通用库/中间件”，则按以下顺序检查外部驱动来源：
upypiawesome-micropythongithub执行要求：
package_name / install_cmddriver.source = "upypi"driver.source = "upypi" | "awesome-micropython" | "github" 必须来自 upy-pkg-guide 或等价 adapter 的结构化结果硬约束：
PyPI 当成 MicroPython 驱动包主搜索入口locallocalmachine.*、network、bluetooth、neopixel 这类能力，应统一写成 builtin_runtimemachine.ADC、machine.Pin、machine.I2S、network、bluetooth 等内置能力，却写成 driver.source = "none"，应视为 analyze 输出错误，而不是可接受的弱结果driver.source = "none" 只应用于以下两类情况：
upypi / awesome-micropython / github / micropython_lib 都没有可用现成驱动对于“不是单一型号，而是一大类实现方案”的器件，必须先拆实现族，再做驱动搜索。
例如“土壤温湿度传感器”，至少可能拆成：
ADC 电容式土壤湿度传感器UART/RS485/Modbus 土壤温湿度一体传感器I2C/SPI 数字土壤传感器规则：
只有在以下情况都不满足时，才进入“无现成驱动/冷门驱动”判断：
builtin_runtimeupypi 无可用结果awesome-micropython / github / 其他可信 MicroPython 驱动源 无可用结果micropython_lib 也无可用结果每个器件都必须得到以下结果之一：
driver.source = "builtin_runtime"driver.source = "micropython_lib"driver.source = "upypi"driver.source = "awesome-micropython"driver.source = "github"driver.source = "none"driver.source = "cold-driver"当前 analyze 阶段推荐的 driver.source 集合是：
builtin_runtimemicropython_libupypiawesome-micropythongithubnonecold-driver说明：
local 不是 analyze 阶段的默认常规选项local，必须能明确说明对应本地私有驱动资产来自哪里必须持续输出进度：
不得静默跑完整轮搜索后只给最终结论。
本步骤的协议目标：
status_update(step_id="driver_search", level="info", message="正在搜索驱动... (1/N)")driver_founddriver_fallbackdriver_nonedriver_cold补充说明：
builtin_runtime 归入“可支持”范畴，但应在 message 中写清：
OK INMP441 -> builtin_runtime (machine.I2S)OK 土壤湿度传感器 -> builtin_runtime (machine.ADC)system_recommended 无驱动 -> 可替代推荐user_specified 无驱动 -> 直接 cold-driver 标记只有以下条件同时成立时才允许替代推荐：
system_recommended替代候选也必须经过 upy-pkg-guide 验证：
upy-pkg-guideupy-pkg-guide 确认有可用 MicroPython 驱动的候选展示给用户替代推荐约束：
以下情况直接进入冷门路径标记：
user_specified 且无驱动system_recommended 且无驱动，用户拒绝替代并坚持原器件Analyze 在此仅做：
Analyze 不做：
本步骤的协议目标：
system_recommended 且无驱动时：
approval_request(alternative_device)approval_responseuser_specified 且无驱动时：
phase_completenext_phase 固定为 select-hwnext_skill 固定为 /upy-select-hw-plugin至少包含：
schema_versionphase = "analyze"project_namerequirementsdevices并保证：
requirements 字段完整devices[].source 明确devices[].driver.source 明确校验脚本职责是：
校验脚本不是 analyze 的完成标准。
Analyze 的完成标准是：
manifest_contentphase_completeAnalyze 最终必须把以下内容交给下游：
manifest_contentwarningserrorsnext_phase = "select-hw"next_skill = "/upy-select-hw-plugin"不要把“本地写盘成功”作为本 phase 唯一事实源。
本步骤的协议目标：
init_manifest.py 做校验phase_complete当没有真实插件宿主、也没有消息总线保存 phase_complete 时，Claude Code 直测很难从文件系统检查结果。因此允许额外写出调试产物。
触发条件：
G:\test\test 下测试本 skill推荐写入文件：
{project_dir}/manifest_draft.json
{project_dir}/manifest_validated.json
{project_dir}/phase_complete.analyze.json
{project_dir}/driver_search_log.md
写入内容：
manifest_draft.json
project_name、requirements、devicesmanifest_validated.json
init_manifest.py 校验和规范化后的 manifestphase_complete.manifest_content 保持一致schema_version、phase、created_at、updated_at、final_statusphase_complete.analyze.json
phase_complete 消息载荷manifest_contentartifacts 是数组，不允许写成 { "manifest_draft": "..." } 这类路径映射对象file_list artifact，例如：
{
"type": "file_list",
"title": "Claude Code 直测产物",
"files": [
{ "path": "manifest_draft.json", "status": "created" },
{ "path": "manifest_validated.json", "status": "created" },
{ "path": "phase_complete.analyze.json", "status": "created" },
{ "path": "driver_search_log.md", "status": "created" }
]
}
driver_search_log.md
upy-pkg-guide 的结果、最终 driver.source约束：
phase_complete.manifest_content 作为唯一阶段交接物phase_complete 决定phase_complete.analyze.json 后，必须用校验脚本的 phase_complete 模式验证：
python {skill_dir}/scripts/init_manifest.py --validate-phase-complete --input {project_dir}/phase_complete.analyze.json
phase_complete.analyze.json，不得宣称 analyze 阶段成功。当前 analyze 插件化版本应遵循以下消息顺序：
Step 1 输入上下文建立
-> status_update(intent_extraction)
Step 2 意图拆解完成
-> status_update(intent_done)
Step 3 器件确认
-> approval_request(device_confirm)
-> approval_response
Step 4 可选补充卡片（按需）
-> approval_request(requirement_supplement)
-> approval_response
Step 5 驱动搜索
-> status_update(driver_search)
-> status_update(driver_found / driver_fallback / driver_none / driver_cold)
Step 6 替代推荐（条件触发）
-> approval_request(alternative_device)
-> approval_response
Step 7 manifest 校验
-> script_run(init_manifest.py)
-> script_result
Step 8 阶段完成
-> phase_complete(result=success, next_phase=select-hw, next_skill=/upy-select-hw-plugin)
用途：
要求：
allow_add = trueallow_remove = truemulti_select = true建议载荷示例：
{
"type": "approval_request",
"payload": {
"approval_id": "device_confirm",
"header": "确认项目方案",
"question": "请确认以下器件是否正确",
"summary": {
"project_name": "植物助手",
"description": "读取土壤温湿度，支持触摸交互和语音对话",
"board": {
"status": "selected",
"display_name": "ESP32-S3-DevKitC-1",
"mcu": "ESP32-S3-WROOM-1"
}
},
"items": [
{
"id": "d1",
"name": "土壤湿度传感器",
"subtitle": "ADC 土壤湿度传感器",
"meta": "系统推荐",
"selected": true
},
{
"id": "d2",
"name": "I2S 麦克风",
"subtitle": "I2S 语音输入",
"meta": "系统推荐",
"selected": true
}
],
"allow_add": true,
"allow_remove": true,
"multi_select": true,
"actions": [
{
"label": "确认，开始搜索驱动",
"value": "confirm",
"primary": true
},
{
"label": "修改器件清单",
"value": "modify"
}
]
}
}
字段约束：
summary.project_name 必填summary.description 必填summary.board.status 只能是：
selectednoneitems[].id/name/subtitle/meta/selected 必填actions 至少包含 1 个主动作board.status = "none"，则不要求 display_name/mcu在无真实 UI 的对话环境中，展示本卡片后必须遵守：
用途：
要求：
建议载荷示例：
{
"type": "approval_request",
"payload": {
"approval_id": "requirement_supplement",
"header": "补充需求信息",
"question": "请补充场景、供电、性能和输出要求",
"summary": {
"project_name": "植物助手"
},
"items": [
{
"id": "scene_indoor",
"name": "室内桌面场景",
"subtitle": "默认推荐",
"meta": "scene=indoor",
"selected": true
},
{
"id": "power_usb",
"name": "USB 供电",
"subtitle": "默认推荐",
"meta": "power=usb",
"selected": true
},
{
"id": "perf_normal",
"name": "通用性能",
"subtitle": "1Hz / 常规精度 / 1秒响应",
"meta": "sample_rate=normal_1hz",
"selected": true
},
{
"id": "output_serial_oled",
"name": "串口 + OLED 输出",
"subtitle": "默认推荐",
"meta": "output=serial,display_oled,buzzer",
"selected": true
}
],
"allow_add": false,
"allow_remove": false,
"multi_select": true,
"actions": [
{
"label": "确认补充信息",
"value": "confirm",
"primary": true
}
]
}
}
用途：
system_recommended 器件无驱动时，给出最多 2 个替代器件建议载荷示例：
{
"type": "approval_request",
"payload": {
"approval_id": "alternative_device",
"header": "传感器：推荐替代器件",
"question": "当前器件无现成驱动，推荐以下替代器件",
"items": [
{
"id": "alt1",
"name": "HDC1080",
"subtitle": "精度较高，已有 upypi 驱动",
"meta": "推荐",
"selected": false
},
{
"id": "alt2",
"name": "AHT20",
"subtitle": "成本较低，已有 upypi 驱动",
"meta": "备选",
"selected": false
}
],
"allow_add": false,
"allow_remove": false,
"multi_select": false,
"actions": [
{
"label": "用 HDC1080（推荐）",
"value": "accept_alt1",
"primary": true
},
{
"label": "用 AHT20",
"value": "accept_alt2"
},
{
"label": "坚持原器件，走冷门驱动",
"value": "cold_driver"
}
]
}
}
Analyze 当前最少应定义以下进度消息：
intent_extractionintent_donedriver_searchdriver_founddriver_fallbackdriver_nonedriver_coldAnalyze 的 phase_complete 至少应包含：
phase = "analyze"resultsummarynext_phase = "select-hw"next_skill = "/upy-select-hw-plugin"manifest_contentartifacts：必须是数组。调试文件路径用 file_list artifact 表达，不允许用对象映射代替数组。warningserrors若 analyze 运行在没有真实插件卡片宿主的环境中，例如普通聊天式 skill 调用，则必须遵守以下规则：
approval_request(device_confirm) 出现后，回复必须结束，等待用户输入approval_request(requirement_supplement) 出现后，回复必须结束，等待用户输入approval_request(alternative_device) 出现后，回复必须结束，等待用户输入一句话要求：
先停，再等用户；没有用户确认，就不能往后跑。
Analyze 交给下游 select-hw 的 manifest_content 至少必须包含：
schema_versionphase = "analyze"project_namerequirements.descriptionrequirements.experiencerequirements.outputrequirements.existing_hardwarerequirements.mcu_specifieddevices其中每个 devices[] 至少必须包含：
nametypeinterfacesourcedriver.source可选但应保留的器件级字段：
notes：用户对该器件的自然语言补充，例如模块型号、触发方式、电平语义、安装方式behavior：可结构化的行为事实，例如 role、event、active_level、idle_level当用户明确描述器件行为时，优先同时写入 notes 和 behavior。例如 TTP223 触摸按键“按下后为低电平”应保留为器件级事实，供 select-hw 和 generate 决定 GPIO 输入、上拉/下拉和触发条件。
如 driver.source 属于现成驱动来源，后续应继续补全：
package_nameinstall_cmdversionapi_ref：优先为对象；字符串形式只可作为临时弱结果，并应在校验警告中暴露driver 还应保留搜索证据字段，供 analyze 校验和排查使用；下游 select-hw 可以忽略这些字段：
search_provider：upy-pkg-guide、pkg_guide_adapter、builtin_runtime_classifier 或 micropython_lib_classifiersearch_mode：real 或 mockmock：仅本地测试 adapter 结果允许为 truesearch_required：builtin runtime only 时应为 falsequery：传给 upy-pkg-guide 或 adapter 的关键词evidence：结构化来源证据，例如包名、仓库 URL、结果说明upy-analyze-plugin 应自带独立的 boards/ 目录资产。
用途：
pre_selected_board原则：
boards当前本地可用的测试入口包括：
python run_local_mock_session.py
python interactive_local_session.py
这是插件化 analyze 的第一版可演练工作流，并且当前已经具备：
script_run(init_manifest.py) 校验链路phase_complete(next_phase=select-hw, next_skill=/upy-select-hw-plugin) 交接链路后续增强重点不再是补“有没有工作流”，而是补：
workflow_session_root unless the user explicitly says it is only a diagnostic/log source.diagnostic_log_session is evidence only. Do not move manifest_content, project files, phase_complete files, or follow-up artifacts into it.workflow_session_root and reference the other path only in artifacts, warnings, or downstream error_context.start_phase.payload.runtime_context.session_root, source_phase_complete_path, or the explicit command argument.phase_complete.payload.runtime_context.session_root must point to the workflow session that owns the artifact chain.