miaoda-coding

name	miaoda-coding
description	通过妙搭开发插件来创建简单网页，例如信息可视化展示（图表、看板、简报、报表等）、PPT/演示文稿、简单工具或应用原型。用户提到"妙搭"或"vibe coding"时也适用。注意：CRM/ERP/OA等管理系统（但用户明确说做"原型/demo/展示页"时仍适用本skill），AI对话/智能体/AI助手（核心功能是对话交互的）、定时任务/自动化/推送、AI智能能力、知识库等需求不适用本skill；纯创作类需求（写文章/脚本/文案/生成图片/视频等不是做一个应用的）、写个脚本（Python 等）及纯数据分析（用户只要分析结论、未要求做报告/看板/可视化）不要包装成应用。
user-invocable	false

妙搭

重要：创建或修改应用、网页、PPT 等制品的执行环节，必须通过 sessions_spawn 交给妙搭。绝对不要自己动手写代码。

首屏硬规则

1. 先做能力边界判断，再决定是派活给妙搭、引导去妙搭主站、还是本 skill 不处理。
2. 命中不适用场景（AI对话/智能体/助手、定时任务/自动化等）时，本 skill 不处理。
3. 命中复杂管理系统/复杂业务平台时，引导去妙搭主站（见「引导文案格式」）。但用户主动、明确说做”原型/demo/展示页”时，可以走妙搭生成原型。不要替用户决定降级为原型。
4. 不要解释能力边界、不要给替代方案、不要展开原因说明，也不要输出 HTML <a> 标签。

⚠️ 能力边界判断（必须首先执行）

妙搭开发插件可以做四类事情，收到用户请求后，必须先判断是否属于这四类，再决定是派活还是引导去妙搭主站。

支持的四类场景 → 派活给妙搭

1. 信息可视化展示（最核心的场景）：基于用户提供的数据做图表、看板、简报、报表、数据大屏、趋势分析图、对比展示等呈现。只要需求偏向"把信息/数据用可视化的方式展示出来"，都应该走妙搭。包括但不限于：行业简报、经营数据看板、项目进度展示、竞品对比、方案汇报页、数据报告展示页等
2. 简单应用原型：用于展示产品思路或交互方案的原型页面，不是一个真正投入使用的系统（如落地页、概念演示、方案展示）
3. PPT / 演示文稿：幻灯片、课件、汇报材料
4. 简单工具：有页面、也有一些基础的数据增删改查能力，但功能单一、不涉及复杂业务流程，重点是和 Agent 协同的工具，人和 Agent 都可以操作背后的数据

不适用的场景（本 skill 不处理）

以下需求不属于本 skill 的能力范围，不要派活给妙搭：

类别	识别关键词
AI 对话/智能体/助手	“AI对话/聊天/陪伴”、”AI助手/XX助手”（核心功能是 AI 对话交互的助手）、”智能体/Agent”、”智能客服”、”AI工作台”、”配置智能体/搭建智能体”、”机器人配置/Bot配置”
定时任务/自动化/推送	“每日/每天/每周/每月”、”定时/定期执行”、”自动采集/抓取/同步/更新”、”实时监控/监测/预警”、”爬虫/爬取”、”推送通知/实时推送/按需推送/订阅推送”、”聚合订阅”
AI 智能能力	“AI分析/生成/推荐/预测/识别”、”AI辅助/AI驱动/AI赋能”、”智能匹配/评分/批改”、”预测分析/预测报告”
知识库/智能问答	“知识库”、”文档问答”、”智能搜索”、”知识图谱”
纯文字创作	“写文章/脚本/文案/小说/诗歌/演讲稿/邮件”、”撰写/创作/润色/改写/翻译”、”初稿写作/大纲生成/选题推荐”。只要用户要的是纯文字产出，就直接以文字回复，不要做成网页/应用/PPT
纯数据分析	“分析这份数据”、”帮我看看这些数字”、”算一下/统计一下”、”得出结论/给出建议”等——用户只要分析结论、没有明确要求”做个报告/看板/页面/可视化”时。直接用文字或表格回答分析结果即可，不要自作主张包装成应用
复杂 PDF 生成	“生成 PDF”、”导出 PDF”、”转 PDF”、”思维导图 PDF”
需要外部数据源	“实时行情/价格/股价”、”获取最新数据”、”接入 API”、”全网搜索/新闻聚合”、”历史开奖数据/历史行情数据”
抢票/秒杀	“抢票”、”秒杀”、”自动抢/购”、”监控库存”
部署/运维	“部署实例/一键部署”、”运维/服务器管理”、”环境配置/实例管理”
数据对接/桥接	“数据源连接/桥接”、”API 对接”、”数据库连接”
AI 图片生成	“AI生成图片/一键生成图片”、”文生图/图生图”、”AI绘画/AI作画”

”XX助手”的判断：看核心功能而非名称——核心是 AI 对话/问答/智能推荐的（如”AI写作助手””智能客服助手”）属于不适用；名字叫”助手”但本质是页面工具的（如”记账助手””配色助手”）按实际功能归类，可以走妙搭。

复杂管理系统 / 复杂业务平台 → 引导用户到妙搭主站

类别	识别关键词
复杂管理系统	“XX管理系统/平台”（客户管理、人力管理、财务管理、库存管理、生产管理、设备管理、物流管理、车队管理、物业管理、门店管理、医疗管理、安全管理等）、”CRM/ERP/OA/HRM/MES/WMS/进销存”、”全流程管理/一站式管理/端到端”、”多角色登录/权限管理/角色管理”、”工单/审批流/工作流”
复杂业务平台	“电商平台/交易平台/商城”、”教育/学习/培训/考试平台”、”医疗/健康管理平台”、”社交/社区平台”、”内容/直播运营平台”、”招聘平台”

遇到这两类需求时：

• 用户主动、明确说要做”原型/demo/展示页/概念验证”（如”做一个CRM的原型给老板看看”）→ 可以走妙搭，按「简单应用原型」场景生成
• 用户意图是做一个真正可用的系统 → 输出引导文案（见下方格式），引导去妙搭主站
• 不要替用户降级——用户说”做一个CRM”就是想做系统，不要自作主张改成做 CRM 原型

引导文案格式

这个需求比较复杂，你可以去妙搭搭建试试：

[去妙搭创建<贴合需求的描述>](https://miaoda.feishu.cn/home?userInput=<URL编码后的需求摘要>&mode=application&open-from=openclaw)

规则：

• label 换成最贴合需求的一句话，例如”去妙搭创建电商平台””去妙搭创建客户管理系统”
• query 填需求摘要，尽量忠实保留用户需求，200 字以内（URL 编码前）
• 第一行固定用：这个需求比较复杂，你可以去妙搭搭建试试：
• 链接前后不要再补任何能力边界说明、替代方案、原因分析或额外格式修饰
• 不能输出 HTML <a> 标签
• 不要输出任何内部标记或 XML/HTML 风格包裹内容

正确示例：

这个需求比较复杂，你可以去妙搭搭建试试：

[去妙搭创建电商平台](https://miaoda.feishu.cn/home?userInput=%E5%B8%A6%E7%94%A8%E6%88%B7%E7%99%BB%E5%BD%95%E3%80%81%E6%94%AF%E4%BB%98%E3%80%81%E8%AE%A2%E5%8D%95%E7%AE%A1%E7%90%86%E3%80%81%E5%90%8E%E5%8F%B0%E5%AE%A1%E6%A0%B8%E5%92%8C%E6%95%B0%E6%8D%AE%E6%8A%A5%E8%A1%A8%E7%9A%84%E5%A4%A7%E5%9E%8B%E7%94%B5%E5%95%86%E5%B9%B3%E5%8F%B0&mode=application&open-from=openclaw)

这个需求比较复杂，你可以去妙搭搭建试试：

[去妙搭创建客户管理系统](https://miaoda.feishu.cn/home?userInput=%E5%AE%A2%E6%88%B7%E7%AE%A1%E7%90%86%E7%B3%BB%E7%BB%9F%EF%BC%8C%E6%94%AF%E6%8C%81%E5%AE%A2%E6%88%B7%E4%BF%A1%E6%81%AF%E7%AE%A1%E7%90%86%E3%80%81%E8%B7%9F%E8%BF%9B%E8%AE%B0%E5%BD%95%E5%92%8C%E6%95%B0%E6%8D%AE%E6%8A%A5%E8%A1%A8&mode=application&open-from=openclaw)

边界模糊时的判断原则

问自己三个问题（按顺序判断，第 1 条优先级最高）：

1. ”需求是否命中不适用场景表？” — 命中则本 skill 不处理
2. ”需求是复杂管理系统或复杂业务平台吗？” — 是的话，看用户是否主动明确说了要做原型/demo/展示页：说了 → 按「简单应用原型」场景走妙搭；没说 → 引导去妙搭主站
3. ”这是一个简单工具/原型/展示页，还是一个真正的业务系统？” — 如果用户期望的是一个可以真正投入日常使用、涉及多角色/多流程/复杂业务逻辑的系统，应该引导去妙搭主站

判断是否需要先做前置工作

妙搭开发插件只负责生成制品（网页、应用、PPT），不负责搜索、分析、总结等研究工作。

收到用户请求后，先判断：

• 纯建站/改站请求（如"做一个计算器"、"改一下颜色"）→ 直接派活给妙搭
• 对话中有需要传递给 code agent 的上下文（之前讨论的调研结果、用户偏好、素材等）→ 先调 miaoda_write_reference 写入参考资料，再派活
• 复合请求（如"先搜集 XX 资料，再生成网站"）→ 主 agent 先完成研究，整理为摘要+关键原文引用，调 miaoda_write_reference 写入，再派活

错误做法：把"先搜集再生成"的整个需求原样丢给妙搭——妙搭不会搜索，只会基于给定内容生成页面。

写入参考资料

用 miaoda_write_reference 将上下文写入项目的 reference 目录：

参数：

• project_id: 项目 ID
• category: "research"（调研结果）、"design"（设计要求）、"feedback"（用户反馈）
• content: Markdown 格式的参考资料（摘要+关键原文引用）
• filename: 可选，自定义文件名
• mode: "append"（默认，追加）或 "replace"（替换该 category 全部内容，用于用户反悔/调整）

整理原则：

• 结构化摘要：提炼对话中的关键结论、决策、需求
• 保留关键原文：用户的原话、重要数据、具体要求原样引用
• 不要把整段对话历史塞进去，提炼有价值的信息

调用者边界

Tool	谁调
miaoda_write_reference	主 agent（non-subagent 会话）
miaoda_coding	subagent
miaoda_check_progress	主 agent（non-subagent 会话）
list_projects	主 agent 或 subagent

派活

通过 sessions_spawn 派给 subagent。只传以下三个参数，不要传任何其他参数（不要传 streamTo、sandbox、stream 等）：

• runtime: "subagent"
• mode: "run"
• task: 按下面模板填写

如果 sessions_spawn 调用本身返回错误（如参数错误），去掉多余参数后重试，绝对不要 fallback 到自己写代码。

创建新项目：

1. 如有上下文需要传递，先调 miaoda_write_reference
2. 调 sessions_spawn，task 内容：

generation_request 编写原则：

• 忠实传递用户的功能需求，不要自行添加技术选型（如数据库方案、存储方式、第三方 API 等）
• code agent 运行在独立沙箱中，不具备你（openclaw）的插件和工具能力（如飞书多维表格、飞书文档等），不要推荐你自己的能力给它
• 技术方案由 code agent 根据平台内置能力自行决定

调用 miaoda_coding tool，参数：
- generation_request: "<生成指令>"
- project_id: "<project_id>"
- name: "<面向人类可读的应用名称>"
- description: "<根据用户需求整理的一句话简介，单行，80 字以内>"
- target:（**必填，不可省略**）根据消息来源判断——群聊中用 "chat:<chat_id>"（如 chat:oc_xxx），单聊中用 "user:<sender_id>"（如 user:ou_xxx），非飞书渠道传 "none"。缺少 target 会导致错误消息无法投递给用户。

如果 reference/ 目录已有参考资料，tool 会自动提示 code agent 查阅。

tool 会返回结构化 JSON（status/appId/finalText/output 等）。

tool 返回的 JSON 里如果有 `hint` 字段，严格按 hint 指示行事。

不要调 message tool（主 agent 会处理消息投递）。

修改已有项目：

1. 如有新反馈/调整，先调 miaoda_write_reference（category="feedback"，mode 按需选 append 或 replace）
2. 调 sessions_spawn，task 内容：

你只能调用以下两个 tool，按顺序执行，不得使用任何其他 tool（exec、ls、read 等均禁止）：

1. 调用 list_projects tool，无需任何参数。
2. 从返回的 projects 数组中找到与用户需求匹配的项目，取其 project_id。
3. 调用 miaoda_coding tool，参数：
   - generation_request: "<修改要求>"
   - project_id: "<上一步取到的 project_id>"
   - target:（**必填，不可省略**）根据消息来源判断——群聊中用 "chat:<chat_id>"（如 chat:oc_xxx），单聊中用 "user:<sender_id>"（如 user:ou_xxx），非飞书渠道传 "none"。缺少 target 会导致错误消息无法投递给用户。

tool 会返回结构化 JSON（status/appId/finalText/output 等）。

tool 返回的 JSON 里如果有 `hint` 字段，严格按 hint 指示行事。

不要调 message tool（主 agent 会处理消息投递）。

<sender_id> 从消息上下文的 sender_id 字段获取（格式如 ou_xxx）。 <chat_id> 从消息上下文的 chat_id / ChatType / To 字段判断：ChatType 为 "group" 时取 chat_id（格式如 oc_xxx）。

<project_id> 仅允许小写字母、数字和短横线，创建新项目时根据用户需求生成，例如：

• "帮我做一个 hello world 网页" → hello-world-webpage
• "做一个计算器" → calculator
• "做一个贪吃蛇游戏" → snake-game

你（主 agent）的行为

1. 读完这个 skill 后，首先执行能力边界判断。如果不在支持范围内，立即直接输出最终引导文案：第一行是“这个需求比较复杂，你可以去妙搭搭建试试：”，第二行是指向 https://miaoda.feishu.cn/home?userInput=<URL编码后的需求摘要>&mode=application&open-from=openclaw 的飞书 md 链接。不要自己补能力边界说明、替代方案或原因分析。
2. 确认在能力范围内后，判断是否需要写参考资料，需要则调 miaoda_write_reference
3. 调 sessions_spawn
4. 回复用户"交给妙搭了，稍等"
5. 不要 调 sessions_history、subagents、或任何 poll 操作
6. subagent announce 回来后，只发一条总结消息：简短总结做了什么，并附上预览链接
   • 预览链接获取方式：优先读 workspace/app/<project_id>/.spark/meta.json；如果不存在，再回退读 workspace/<project_id>/.spark/meta.json。从其中的 appUrl 字段拼上 ?mode=sidebar-semi（如已有 query 参数则用 &mode=sidebar-semi）
   • 如果 meta.json 中没有 appUrl，说明可能未部署成功，参考「查看执行详情」章节了解情况
   • 严禁发多条消息
   • 不要提系统、子任务、announce、subagent 等内部细节
7. miaoda_check_progress 用于两种场景：(a) 用户主动问进度时，(b) 任务失败且结果中有 hint 建议查进度时
8. 不要 调 message tool 自己推送消息，所有回复通过正常对话投递
9. 不要 自己写代码或用 exec/write 生成 HTML/JS/CSS 文件

处理失败和异常

subagent 返回的结果 JSON 中可能包含 status: "error" 或 status: "timeout"。按以下规则处理：

1. retryable: true + hint 字段存在：告诉用户遇到了问题（用通俗语言，不要说"网络连接中断"这种技术细节），然后按 hint 的建议执行（通常是先调 miaoda_check_progress 查看状态）
   • 如果 progress 显示已完成 → 正常回复结果
   • 如果 progress 显示仍在运行 → 告诉用户"还在处理中，稍后再查"
   • 如果 progress 显示失败 → 问用户是否要重试
   • 重试时：走修改已有项目流程，generation_request 填 "继续"。feida-ai 的 conversation 中已有完整上下文（需求 + 之前的代码 + 失败日志），发"继续"即可让 Agent 接着上次的进度工作。禁止用创建模板重复发送完整的原始需求——这会导致 Agent 看到重复的需求消息，浪费 token 并造成混乱
2. hint 包含"createSubApp 失败"：createSubApp 是创建应用的前置步骤，失败原因可能是用户额度不足、权限不够、或服务异常等。根据 error 字段的具体内容用通俗语言告诉用户（如"额度用完了"、"没有权限"、"服务暂时不可用"），不要重试，不要调 miaoda_check_progress
3. retryable: false 或无 retryable 字段：直接告诉用户失败了，附上错误信息，问用户怎么处理
4. 结果里没有预览链接（hint 提到"未检测到预览链接"）：调 miaoda_check_progress 查看最新状态，可能链接还没生成

禁止行为：

• 不要在用户不知情的情况下自动重试——先告诉用户情况，等用户确认
• 不要把 retryable、hint、logId 等内部字段暴露给用户
• 不要说"stream disconnected"、"reconnect exhausted"等技术术语

查看执行详情

项目执行信息默认位于 workspace/app/<project_id>/.spark/；如果该目录不存在，再回退到旧路径 workspace/<project_id>/.spark/。可直接读取：

• meta.json：应用元信息（appId、appUrl 等），用于获取预览链接
• progress.txt：关键节点进度日志（轻量，适合快速了解当前状态）

判定任务是否完成

subagent announce 后，优先读 workspace/app/<project_id>/.spark/progress.txt；如果不存在，再回退读 workspace/<project_id>/.spark/progress.txt 了解实际执行情况。

基于对实际情况的了解，自行判断下一步行动。