~/lovstudio/coding/skills/
├── index/                     ← central catalog (lovstudio/skills repo)
│   ├── skills.yaml            ← machine-readable manifest (paid flag lives here)
│   └── README.md              ← human-readable catalog
├── {name}-skill/              ← each skill is an independent repo
│   ├── SKILL.md
│   ├── README.md
│   ├── CHANGELOG.md           ← managed by skill-optimizer
│   ├── scripts/               ← standalone Python CLI scripts
│   └── references/            ← optional progressive-disclosure docs
└── ...

~/.claude/skills/lovstudio-{name}  ← symlink → ~/.agents/skills/lovstudio-{name}
                                                 → ~/lovstudio/coding/skills/{name}-skill/

• GitHub repo name:

  lovstudio/{name}-skill

  (with

  -skill

  suffix)
• Local source path:

  ~/lovstudio/coding/skills/{name}-skill/

  (no

  lovstudio-

  prefix)
• Claude Code reads:

  ~/.claude/skills/lovstudio-{name}/

  (with

  lovstudio-

  prefix, via symlink)
• Frontmatter

  name

  :

  lovstudio:{name}

  (with

  :

  separator)

• paid: true/false

  lives only in

  index/skills.yaml

  , never in SKILL.md

这个 skill 的分发定位?

1. Free (public) — 任何人 git clone 就能用。适合引流、通用工具、开源贡献。
2. Paid, 普通 IP — 核心逻辑是流程/模板/prompt 编排,用户 grep 出来不心疼。用加密分发 + license 鉴权。
3. Paid, 敏感 IP — 含算法参数/业务规则/调好的 prompt/API 密钥,用户反编译会心疼。用 cloud-split:核心逻辑放云端,本地只有瘦客户端。

提示:不确定 → 选 2。未来升级到 3 比降级容易。

• 选 1 → 走标准公开 repo 流程
• 选 2 → 走 encrypted skill 流程(README 里坦诚说明 "加密 = 鉴权闸门,不保证反提取")
• 选 3 → 停下来读

  references/cloud-split.md

  ,然后走 cloud-split 流程

• 解决什么问题?输入 → 输出是什么?
• 2-3 个具体使用示例
• 触发短语(中文 + English)

我先拆解一下这个 skill 的结构:

公开层(瘦客户端 SKILL.md 会暴露这些):

• [具体列出:对话流、输入解析、输出渲染、错误处理]

保护层(需要藏起来的):

• [具体列出:算法/阈值/规则/prompt 工程/密钥/数据]
• 或明确写 "无 — 这个 skill 没有需要保护的核心逻辑"

按这个拆解,你选的 [Q1 答案] [合理 / 不合理,建议改成 X]。确认继续?

• 纯指令 SKILL.md,还是需要 Python CLI 脚本?
• (如果 Q1 选了 3:这一问跳过。cloud-split 的"实现"就是云端 handler,不是本地脚本。)

1. Scripts — deterministic operations →

   scripts/

2. References — domain knowledge Claude needs while working →

   references/

3. Assets — files used in output (templates, fonts, etc.) →

   assets/

• Python scripts must be standalone single-file CLIs with

  argparse

• No package structure, no

  setup.py

  , no

  __init__.py

• CJK text handling is a core concern if the skill deals with documents

python3 ~/.claude/skills/lovstudio-skill-creator/scripts/init_skill.py <name>

~/lovstudio/coding/skills/{name}-skill/

{name}-skill/
├── SKILL.md          ← frontmatter + TODO workflow
├── README.md         ← human-readable docs with version badge
└── scripts/          ← empty, ready for implementation

--paid

scripts/

1. Read

   references/cloud-split.md

   end-to-end before writing any code (this is not optional — the rules for non-leaky payloads are there, not here)
2. Start from

   threshold-check

   as the reference pattern, NOT

   paid-add

   .

   paid-add

   is an architecture demo with an intentionally leaky payload (for teaching). Copying its return shape into a real skill defeats the whole point of cloud-split.
3. Write the handler at

   ~/lovstudio/coding/web/supabase/functions/skill_call/handlers/<name>.ts

   — return a minimal symbolic payload (

   {verdict: "A" | "B"}

   style), not descriptive strings or narrative

   display

   fields
4. Write the thin SKILL.md per the

   threshold-check

   template — rendering via a symbol → text table, never via a computed algorithm
5. MANDATORY pre-flight audit — before registering the handler in the dispatcher, before deploying, before telling the user "done": run the checklist in

   references/cloud-split.md

   → "MANDATORY pre-flight audit" section. Report each item's result to the user. If any item fails, rewrite before moving on.
6. Skip the normal Step 4 "write scripts" — there usually aren't any for cloud-split skills (unless you need client-side rendering of server output)

{score, verdict: "below", display: "2+6=8 (below 10)"}

1. Write scripts in

   scripts/

   — test by running directly
2. Write SKILL.md — instructions for AI assistants:
   • Frontmatter

     description

     is the trigger mechanism — cover what + when + concrete trigger phrases (中文 + English)
   • Body contains workflow steps, CLI reference, field mappings
   • Use

     AskUserQuestion

     for interactive prompts before running scripts
   • Keep SKILL.md under 500 lines; split to

     references/

     if longer
3. Write README.md — docs for humans on GitHub:
   • Version badge (source of truth for version)
   • Install command:

     git clone https://github.com/lovstudio/{name}-skill ~/.claude/skills/lovstudio-{name}

   • Dependencies
   • Usage examples, options table
   • ASCII diagrams if useful

references/templates.md

skills.yaml

/agent

if [ -n "$LOVSTUDIO_REVALIDATE_SECRET" ]; then
  curl -sfX POST https://lovstudio.ai/api/revalidate \
    -H "x-revalidate-secret: $LOVSTUDIO_REVALIDATE_SECRET" \
    -H "content-type: application/json" \
    -d '{"tags":["skills-index"]}' \
    && echo "✓ cache refreshed" \
    || echo "⚠ revalidate failed (will appear within 1h)"
fi

lovstudio/web:src/data/skills.ts

• skills-index

  — the yaml index (invalidates all list pages)

• skill:<id>

  — detail for a single skill

• skill-cases:<id>

  — cases.json for a skill

1. In a new conversation, invoke

   /lovstudio:<name>

   — confirm it triggers
2. Notice struggles → edit SKILL.md / scripts in the source repo
3. Commit & push (the symlink chain means no local copy to sync)

• Multiple themes/variants →

  references/themes.md

• Complex API docs →

  references/api.md

• Large examples →

  references/examples.md

references/themes.md

1. Check user memory and conversation context first
2. Pre-fill what you can
3. Only ask for fields you truly don't know

• INSTALLATION_GUIDE.md

  — clutter; install instructions go in README.md
• Test files — scripts are tested by running, not with test frameworks

• __pycache__/

  ,

  *.pyc

  ,

  .DS_Store

  — add to

  .gitignore

• paid

  field in frontmatter — it lives only in

  index/skills.yaml