---
name: meegle-plugin-create
version: 1.0.0
description: |
  Meegle 插件工程创建（原子 skill）：最小化创建插件工程骨架（plugin.config.json + 工程目录）。
  当用户明确只想创建空壳工程（"创建一个空的插件工程"、"初始化插件项目骨架"）时触发，或由 workflow phase 内部调用。
  若用户说"我需要一个 xxx 插件" / "从零做一个 xxx"，应由 workflow phase 统一编排（含 create + feature + polish + publish），而非直接调用此 skill。
  前提：用户已执行 `lpm login`（见接入文档）；未登录时 CLI 会 stderr 提示，由用户自行登录后重试。
metadata:
  requires:
    bins: ["npx"]
  cliHelp: "lpm create --help"
---

# create phase — overview

> **入口守卫执行权已由 router 接管(合并后)**:本 phase 是 `meegle-plugin` skill 的 create 子阶段。
> router(`../SKILL.md`) 的 §1 入口 SOP **已先验过**当前目录的 `plugin.config.json` 存在性(Step 1.2)、
> 并据此 + 用户意图路由到本 phase(Step 1.3)——`create phase` 只在两种情况进入:
> (a) `NOT_EXIST` + 用户要"空壳工程"(包括被 workflow 编排进入)
> (b) 显式 `phase=create` 入口
>
> 情况 (a) 下,plugin.config.json 不存在,下方 EXIST 拦截天然不触发。
> 情况 (b) 下,本 phase 仍按下方 EXIST 守卫保护(用户可能在已有工程目录里误选 phase=create)。
>
> **简言之**:在合并路径下,你 Read 到本文件时 router 已做过等价或更上层的 gate;
> 下方守卫保留作**显式 phase=create + EXIST 兜底**和**独立读者(人类参考)**的语义注解,
> 合并执行路径上不会重复触发。

## 入口守卫(仅在显式 `phase=create` + cwd 存在 plugin.config.json 时触发)

```bash
test -f ./plugin.config.json && echo "EXIST" || echo "NOT_EXIST"
```

| 检查结果 | 处理 |
|---------|------|
| `NOT_EXIST` | ✅ 继续下方"最少 Read 清单" → 按 mode 走流程 |
| `EXIST` | ⛔ **立即停下**,不得 Read 任何 mode reference。告知用户:"检测到当前目录已有插件工程(`plugin.config.json` 存在)。`create phase` 会破坏既有工程。如果要在此插件上加功能请走 `feature phase`;如果确认要创建新插件请先切到空目录或删除 `plugin.config.json` 后重试。"等用户决策,不得继续 |

## 本 skill 的最少 Read 清单（守卫通过后再读）

- mode=setup → Read [`create-setup.md`](create-setup.md)
- mode=plan → Read [`create-plan.md`](create-plan.md)
- mode=apply → Read [`create-apply.md`](create-apply.md)
- mode=verify → Read [`create-verify.md`](create-verify.md)
- 不要预加载 4 个 mode reference；按当前 mode 按需 Read

## 核心理念

**用户的出发点是功能需求，不是插件元信息。**

用户说"我需要一个在看板上显示燃尽图的功能"，而不是"帮我创建一个名叫工时统计助手、分类为效率工具的插件"。因此：
- 创建阶段只需要一个**工作名称**和 siteDomain
- 名称/描述/分类等展示信息在**发布前**由 AI 自动总结（polish phase）
- 让用户尽快进入点位配置和代码开发

## 核心流程

```
mode=setup   → 获取 siteDomain（auth 未通过时 CLI 会直接 stderr 提示登录）
mode=plan    → 从功能需求提取工作名称 + 决定 app_type（normal / ai_node / ai_field）+ 用户确认
mode=apply   → lpm create --app-type <从 plan 决策> （仅 name，无需描述/分类）
mode=verify  → 检查 plugin.config.json 完整性（含 app_type）+ 工程目录就绪
mode=pipeline（默认）→ setup → plan → apply → verify
```

> **app_type 是不可逆决定**：`lpm create --app-type` 在 Meegle 后台写定后任何命令都不能转——选错就要 `lpm workspace clean` 删工程从头来。详细决策树见 [`create-plan.md`](create-plan.md) 的 P1.5。

## 使用方式

本 phase 通常由 meegle-plugin 的 router 自动路由进入(见上层 [`../SKILL.md`](../SKILL.md) §1 入口 SOP)。触发本 skill 时用自然语言描述意图即可——比如"创建一个空的插件工程"——router 会按 cwd context + 意图路由到 create phase。

**显式入口**(高级用法 / 调试 / 断点续跑):触发本 skill 时显式说 `phase=create` 或 `phase=create mode=<modename>`,可跳过 router 的 phase 选择,直接进入指定 step。

可用 mode:
- `mode=pipeline`(默认)— 端到端全流程
- `mode=plan` — 仅确认信息
- `mode=apply` — 执行创建
- `mode=verify` — 验证工程就绪

> workflow phase 编排进入本 phase 时,通过 Read create-*.md 序列推进——守卫执行权已由 router 接管(见上方"入口守卫执行权"段),无需 mode 之外的入参。

## 各模式详细流程

- `mode=setup`  → 读取 `create-setup.md`
- `mode=plan`   → 读取 `create-plan.md`
- `mode=apply`  → 读取 `create-apply.md`
- `mode=verify` → 读取 `create-verify.md`

## 输出产物

| 产物 | 说明 |
|------|------|
| `plugin.config.json` | 含 pluginId、pluginSecret、siteDomain、name、resources: []、`app_type`（normal / ai_node / ai_field 之一） |
| `node_modules/` | 插件工程依赖，由 init 自动安装 |
| `src/` | 工程模板目录结构 |

## 后续流程

```
create phase → feature phase（Stage Config 点位配置 + Stage Code 代码）→ polish phase → publish phase
                                                                                  ↑ AI 总结已实现功能
                                                                                    生成名称/描述/分类
```

> 前置依赖链由 `workflow phase` 统一维护（`lpm login` 由用户自备 → create phase → ...）。

> 创建完成后告诉用户工程的绝对路径（用 `pwd`）+ 推荐 git 管理（`plugin.config.json` 含 `pluginSecret` 风险见 [`publish-verify.md`](publish-verify.md) V3 输出段）——便于多个插件场景下用户回找。完整文案落地建议下沉到 `lpm create` CLI stderr，详 backlog。被 workflow 编排时不输出此段，由 publish 终态统一收尾。