菜单
End-to-end IoT product development orchestration for TuyaOpen projects. Guides from requirements gathering → Tuya Platform product/DP creation → complete embedded firmware generation. State-machine: detects project state and picks up from wherever development currently stands.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/tuya/tuyaopen-ide-manifests --skill smart-product-dev命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Build and compile TuyaOpen projects, select build configurations, edit Kconfig options, clean artifacts, and run Linux ELF binaries. Use when the user mentions compiling, building, tos.py build, config choice, menuconfig, Kconfig, build error, or running a project. 项目编译、构建、编译配置、清理编译、编译错误、menuconfig、Kconfig。
Agent-friendly non-blocking serial log capture for TuyaOpen devices. Runs tos.py monitor in the background, writes logs to file, and lets the agent tail or stop it at any time. Use when the agent needs to capture device logs without blocking, run a debug session, or monitor UART output during a build-flash-analyze loop. 后台串口日志、非阻塞监控、设备日志捕获、agent日志分析。
Automated build-flash-monitor-analyze development loop for TuyaOpen devices. Covers log analysis, error patterns, CLI testing, and iterative debugging. Use when the user mentions dev loop, automated testing, log analysis, debug cycle, iterative development, or CI loop. 开发闭环、自动化测试、日志分析、调试循环、迭代开发。
基于 SOC 职业分类
正在显示 SKILL.md
| name | smart-product-dev |
| description | End-to-end IoT product development orchestration for TuyaOpen projects. Guides from requirements gathering → Tuya Platform product/DP creation → complete embedded firmware generation. State-machine: detects project state and picks up from wherever development currently stands. |
| when_to_use | Use when the developer says "I want to make a [device]", "帮我做一个XX", "what's next?", "下一步该干什么", or describes product features and expects end-to-end guidance. Do NOT use for pure platform ops (→ tuya-iot-platform), pure build/debug (→ tuyaopen/dev-loop), or project creation only (→ tuyaopen/project-config). |
| id | smart-product-dev |
| surface | embedded |
| tags | ["product","dp","pid","embedded","iot","workflow","orchestration"] |
| license | Apache-2.0 |
| defaultEnabled | true |
| related | ["tuya-iot-platform","tuyaopen/dev-loop","tuyaopen/project-config","tuyaopen/env-setup"] |
| command | tuyaopen.skill.smartProductDev |
End-to-end orchestration: requirements → Tuya Platform product/DP → embedded firmware.
Disambiguation: If only doing one sub-task, use the dedicated skill:
tuya-iot-platformtuyaopen/dev-looptuyaopen/project-configtuya-iot-platformAlways unwrap before any DP access — dpSchema may be a { ok, data } wrapper:
dpSchema = snapshot.dpSchema?.data ?? snapshot.dpSchema
dps = dpSchema?.dps ?? []
selectedDps = dps.filter(dp => dp.selected === true)
Never access snapshot.dpSchema.dps directly.
Run in order. Stop on first failure.
| Check | How | If failing |
|---|---|---|
| CLI binary | .tuyaopen/ide/bin/tuya-devplat-cli exists | "Please open this project in TuyaOpen IDE first — the IDE writes the CLI wrapper on project open." |
| Platform auth | tuya-devplat-cli auth status --format json → exit 0 AND authenticated: true | "Please sign in via TuyaOpen IDE → Developer Platform sidebar." Never run auth login. Timeout >10 s → report network issue. |
| SDK env | $OPEN_SDK_ROOT set and dir contains export.sh/export.bat/export.ps1 | SDK present but not activated → delegate to tuyaopen/env-setup. SDK absent → "Please clone the SDK via TuyaOpen IDE → Library." |
Read ALL files fresh on every entry including re-entry. Never carry state from prior conversation.
| File | What to extract |
|---|---|
tuyaopen.project.ini | [product] pid, [platform] target |
.tuyaopen/project.json | ai.intent, ai.expectedDps, ai.productCategory |
.tuyaopen/platform/product-<pid>.json | full snapshot (apply unwrap), fetchError |
.tuyaopen/ide/platform.json | peripherals, connectivity, pinout, flashAndDebug |
.tuyaopen/ide/board.json | peripheralPatterns |
.tuyaopen/ide/demo.json | cloud.pid.* — PID firmware location (IDE-owned; do not hand-edit firmware PID, see Step 6). Absent → not created from a demo |
.tuyaopen/architecture.json | surfaces.embedded.peripherals |
source/embedded/src/tuya_app_main.c | #include lines (text grep only) |
source/embedded/src/ listing | all .c filenames present |
If .tuyaopen/ does not exist → state is no-project.
Evaluate top-to-bottom. First match wins.
no-project .tuyaopen/ does not exist
bare [product] pid is empty or missing
has-pid pid non-empty AND any of:
· product-<pid>.json missing
· product-<pid>.json has fetchError
· selectedDps (after unwrap) count === 0
has-dps pid non-empty
AND product-<pid>.json exists, no fetchError
AND selectedDps count ≥ 1
AND architecture.json surfaces.embedded.peripherals is empty/absent
AND source/embedded/src/ has only scaffold files*
in-progress pid non-empty
AND product-<pid>.json exists, no fetchError
AND selectedDps count ≥ 1
AND at least one of:
· architecture.json surfaces.embedded.peripherals has any entry ← authoritative
· source/embedded/src/ has non-scaffold .c files
*Scaffold files: at time of writing, only tuya_app_main.c. When architecture.json.surfaces.embedded.peripherals has entries, that is the definitive in-progress signal regardless of file listing. Do not rely on header scanning alone — the scaffold may include umbrella headers (e.g., tal_api.h) that reference hardware headers transitively.
Delegate to tuyaopen/project-config to create the project. After creation re-run from Context Reading.
Goal: requirements → create product + DPs on platform → bind PID.
Ask developer to describe the product freely. Extract:
dj (灯具), kt (空调), qt (通用), etc. Affects DP numbering and standard templates.Communication type: Infer from [platform] target + platform.json.connectivity. Do not ask.
Wi-Fi-only path: If platform.json.connectivity.ble.enabled === false — still run Steps 2 and 3. After Step 3, tell developer: "Your board is Wi-Fi-only. tuya-iot-platform only supports Wi-Fi+BT product creation. Please create the product manually on platform.tuya.com and give me the PID." Then jump to Step 6 (skip Steps 4–5 — product was created manually).
Do not ask about GPIO/hardware here — that belongs in has-dps.
Map features to DP codes + types. For known categories, use standard codes. Present for confirmation:
I'll create these DPs:
switch_led (bool) — on/off
bright_value (integer, 10–1000) — brightness
temp_value (integer, 0–1000) — color temperature
Does this look right? Any additions or changes?
Wait for explicit confirmation before proceeding.
Merge/update .tuyaopen/project.json. Preserve all existing top-level fields and all ai.* fields not listed below. Only set:
{
"ai": {
"intent": "<developer description verbatim>",
"expectedDps": ["switch_led", "bright_value", "temp_value"],
"productCategory": "dj"
}
}
Delegate to tuya-iot-platform → ops/product.md. Show dry-run preview + riskLevel. Require explicit developer approval before --confirm. On failure: do not write PID to ini, stop.
Delegate to tuya-iot-platform → ops/manage-dp.md. Dry-run → developer approves → confirm. On partial failure: report which DPs failed, stop.
Edit tuyaopen.project.ini → [product] pid = <pid>. This is the only file you write for binding.
Do NOT hand-edit the firmware PID (the Kconfig CONFIG_TUYA_PRODUCT_ID in source/embedded/app_default.config / config/*.config, or a TUYA_PRODUCT_ID macro). The IDE owns the firmware rewrite: it reads the demo's PID-location spec from .tuyaopen/ide/demo.json (cloud.pid.via / kconfigKey / macro / file) and writes the PID to the exact location that demo declares — which is often NOT the default symbol. Editing it yourself will likely target the wrong key/macro/file and bind the wrong PID.
Binding is a two-step handshake and is NOT complete after you write the ini. You write [product] pid; the IDE writes the firmware. Until the developer clicks Update (更新), the firmware still holds the previous PID (or the demo's placeholder) — the new PID is NOT in the build yet. You MUST NOT end a bind turn without the Update call-to-action below; it is the required final message of every bind, even when you also did other work (DP creation, snapshots, cleanup).
Required closing message: "I've set the PID <pid> in tuyaopen.project.ini. ⚠️ The firmware still has the old PID — to land the new one, open TuyaOpen IDE → Project Details and click the Update (更新) button. Tell me when done." (On the Cloud IoT info row the same action is labelled Refresh (刷新).)
When developer says done: re-run full state detection from Context Reading. Trust the file, not the claim. If still has-pid, tell developer and wait again.
Do NOT invent IDE buttons or pages. The only button the developer ever clicks for product data is Update (更新) (a.k.a. Refresh (刷新) on the Cloud IoT row). There is no "Sync" button for product or panel data. The panel snapshot (panel-<pid>.json) is auto-managed by the IDE — it syncs on its own when Project Details opens and on bind; never ask the developer to "Sync" it.
Rollback: If writing ini fails after product was created: "Product created, PID <pid>. Please add manually: [product] pid = <pid> in tuyaopen.project.ini, then click Update (更新) in Project Details."
Goal: Diagnose and fix missing/incomplete DPs.
| Condition | Action |
|---|---|
product-<pid>.json missing | "Please click Update (更新) in TuyaOpen IDE → Project Details (or Refresh (刷新) on the Cloud IoT row)." Re-run state detection after developer confirms. Trust the file. |
fetchError in snapshot | Show error text. Ask developer to check credentials/network, then click Update (更新) again. |
selectedDps count === 0, ai.expectedDps exists | Run DP creation (bare Step 5). Ask developer to click Update (更新). Re-run state detection. |
selectedDps count === 0, no ai.expectedDps | Ask developer what DPs are needed. Write to project.json ai.expectedDps (merge/update, preserve other fields). Run DP creation. Ask developer to click Update (更新). |
DP completeness (when selectedDps ≥ 1 and ai.expectedDps exists):
ai.expectedDps but not in selectedDps → add via tuya-iot-platform → ops/manage-dp.md (dry-run → approve → confirm)selectedDps but not in ai.expectedDps → ask developer if intentional. If yes: add to ai.expectedDps (merge/update project.json)After any fix: ask developer to click Update (更新) in Project Details, re-run state detection.
Goal: Hardware wiring + complete firmware generation.
Collect from ALL sources:
board.json peripheralPatterns[*].pins[*][*].gpioplatform.json flashAndDebug.flash.pinsplatform.json flashAndDebug.debug port → look up TX/RX via pinout[]platform.json peripherals.uart[*] where role === "log" → look up TX/RX via pinout[]Available after subtracting reserved:
peripherals.pwm.spec.channels[] — each channel lists valid pin options; exclude options whose GPIO is reservedperipherals.i2c.spec.buses[] — each bus needs SDA + SCL (2 GPIO); exclude buses with no free pin pairperipherals.gpio.spec.pins[] minus all reserved numbersRead architecture.json surfaces.embedded.peripherals — skip Step 3 inquiry for peripherals already wired there.
GPIO demand per interface:
| Interface | GPIO pins |
|---|---|
| PWM channel | 1 |
| I2C bus | 2 (SDA + SCL) |
| SPI bus | 4 (MOSI + MISO + CLK + CS) |
| GPIO output/input | 1 |
If demand > available: tell developer. Suggest alternatives (different board, I2C expander, fewer channels). Do not continue until resolved.
For each DP needing hardware (not already in architecture.json), present available options then ask:
Brightness control (warm + cool LED) via PWM:
PWM0 → valid pins: 6, 18 (pin 4 reserved: board STATUS_LED)
PWM1 → valid pins: 7, 19
PWM2 → valid pins: 8, 20
Which channel + pin for warm-white LED?
Which channel + pin for cool-white LED?
Active-high or active-low?
Never assume a pin. If developer picks a reserved GPIO: "GPIO X is already used by [board.json component]. Please choose from the options above."
Present plan including Kconfig changes. Wait for approval.
Implementation plan:
Warm LED: PWM0 / pin 6 / active-high
Cool LED: PWM1 / pin 7 / active-high
DP handlers: switch_led (id 1), bright_value (id 2), temp_value (id 3)
Kconfig: CONFIG_ENABLE_PWM
Headers: tuya_iot_dp.h, tal_pwm.h
Cloud: solution type from product snapshot
Does this look right?
Update source/embedded/app_default.config:
peripherals.<name>.enableMacro (skip if null)connectivity.<radio>.enableMacro (skip if null)Run tos.py check. If it fails, fix Kconfig and re-check. Do not generate code until tos.py check passes.
Use TAL APIs (tal_*). Do not call tkl_* (platform layer) directly.
Look up from platform.json:
peripherals.<name>.tklHeader → #include header pathperipherals.<name>.idPrefix → prefix for port/pin C enumsGenerate:
selectedDps IDs(snapshot.detail?.data ?? snapshot.detail)?.protocolType
Entry point: tuya_app_main() in source/embedded/src/tuya_app_main.c.
Debug output: PR_DEBUG(fmt, ...).
Write new peripherals and modules to architecture.json surfaces.embedded. This is the authoritative in-progress signal. Write only after Step 6 completes.
Delegate to tuyaopen/dev-loop. If build fails, diagnose and fix in place. If Kconfig is root cause, go to Step 5 and rebuild.
Goal: Gap analysis → complete code.
Cross-reference source files, architecture.json, ai.expectedDps, and selectedDps:
ai.expectedDps with no handler in source → missingarchitecture.json surfaces.embedded.peripherals not initialized in code → missing initselectedDps not in ai.expectedDps → ask developer if they should be handledReading existing code...
Handled: switch_led ✓
Missing: bright_value — no PWM init or handler
Missing: temp_value — no PWM handler
Completing now...
Run has-dps Step 3 hardware inquiry only for missing parts. Read architecture.json first — do not re-ask for already-wired peripherals.
After completing, update architecture.json (has-dps Step 7).
Delegate to tuyaopen/dev-loop.
| Trigger | Action |
|---|---|
DP found missing vs ai.expectedDps | → has-pid (add DP), return to current state |
| Developer adds new feature | Update ai.expectedDps. → has-pid (add DP). Return to in-progress. |
| Build fails: missing Kconfig | → has-dps Step 5 |
| Developer wants different PID | Clear [product] pid from ini. Delete product-<old-pid>.json. Keep ai.*. → bare Step 3 (persist intent) then Step 6 (bind the new PID). Skip Steps 4–5 — the product already exists on the platform. |
| Change product category | Clear ai.productCategory + ai.expectedDps from project.json. → bare Step 1. |
Always:
preview + riskLevel before any --confirmai.intent / ai.expectedDps before re-asking requirementsNever:
tuya-devplat-cli auth loginarchitecture.jsontkl_* APIs in generated code| Failure | Recovery |
|---|---|
| Product created, write ini fails | Report PID. Ask developer to add [product] pid = <pid> manually. |
| DP creation partially fails | Report which failed. Re-enter has-pid on next run — ai.expectedDps comparison catches the gap. |
| Update (更新) not clicked | Re-run state detection after each "done" claim. Trust the file. |
Kconfig / tos.py check fails | Fix before generating code. |
| Build fails | Stay in in-progress. Debug via dev-loop. |
| Wi-Fi-only board | Run Steps 1–3, ask developer to create product manually, continue from Step 6. |