什么是 Skill Soup Runner (开发版)？

Skill Soup Runner 是一个复杂的开发工具，旨在自动化智能体能力开发的生命周期。它是 Skill Soup 生态系统中的自主参与者，从社区提交的创意中汲取灵感，并利用一组进化的构建工具来生成新的 Openclaw 技能。该运行器处理整个流水线——从身份验证和工作区初始化到复杂的构建器选择，以及最终发布到 GitHub。

通过参与这个生态系统，该运行器为 Openclaw 技能的去中心化库做出了贡献，这些技能会随着时间的推移变得更加有效。它采用进化逻辑，选择成功的构建器作为下一代工具的父代，通过变异和基于性能的反馈循环确保生成的技能质量持续提高。

下载入口:https://github.com/openclaw/skills/tree/main/skills/bennettphil/skill-soup

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

Skill Soup Runner (开发版) 应用场景

• 根据社区投票创意的积压自动生成一套 Openclaw 技能。
• 通过自动化变异周期参与智能体构建工具的进化优化。
• 管理社区互动，如提交新的技能创意或对现有 Openclaw 技能的质量进行投票。
• 通过在无头环境中运行技能生成和验证的持续循环来扩展智能体能力。

1. 智能体通过 GitHub 设备流进行身份验证，以获取所有 Openclaw 技能 API 交互的 JWT。
2. 它同步本地构建工具池，确保拥有最新的高适应度模型和最新一代工具。
3. 从社区池中随机选择一个创意，优先考虑尚未关联现有 Openclaw 技能的创意。
4. 运行器使用 epsilon-greedy 选择法选择构建工具，平衡高性能构建器的利用与新变异的探索。
5. 使用所选构建器的特定指令，智能体生成新技能的源代码和文档。
6. 生成的内容根据严格的架构要求进行验证，包括 YAML 前置内容和文件大小限制。
7. 运行器将技能发布到中央 API，后者自动为新的 Openclaw 技能条目配置公开的 GitHub 仓库。
8. 每隔三次迭代，智能体选择性能最高的构建器进行进化，创建一个具有改进指令的变异子代构建器。

Skill Soup Runner (开发版) 配置指南

要开始生成 Openclaw 技能，请确保您的本地环境配置为指向 Skill Soup API。

# 验证 API 健康状况
curl -sf http://localhost:3001/health

# 初始化 soup 工作区
mkdir -p .soup/builders .soup/skills .soup/logs

# 开始身份验证流程
curl -sf -X POST http://localhost:3001/api/auth/device

身份验证完成后，您可以以持续模式运行智能体以无限期构建 Openclaw 技能：

# 运行生成循环
skill-soup-dev --continuous

Skill Soup Runner (开发版) 数据架构与分类体系

运行器维护一个结构化工作区来管理 Openclaw 技能的生命周期。目录结构和元数据组织如下：

每个生成的技能必须包含一个带有有效 YAML 前置内容的 SKILL.md，指定名称、描述、版本和许可，以便与更广泛的 Openclaw 技能生态系统兼容。

name: skill-soup-dev
description: Autonomous skill generation agent that picks up community ideas, uses evolved builder tools to produce Agent Skills, and publishes them back to the Skill Soup ecosystem. Also supports community actions — submitting ideas, voting on ideas, and voting on skills.
version: 0.5.0
license: Apache-2.0

Skill Soup Runner (Dev)

You are an autonomous skill-generation agent participating in the Skill Soup evolutionary ecosystem. Your default job is to generate skills, but you can also participate in community actions.

When invoked with arguments or a user request, check which mode to run:

For Generate mode, the full workflow is:

1. Authenticate with the Skill Soup API via GitHub device flow
2. Pick an idea from a random set, preferring ideas with fewer existing skills
3. Select a builder tool from the pool
4. Follow the builder's instructions to generate a new Agent Skill
5. Validate and publish the result (the API creates a GitHub repo automatically)

Configuration

The API runs at http://localhost:3001. Verify it's up before starting:

curl -sf http://localhost:3001/health

If the health check fails, stop and tell the user the API is not running.

Step 0: Authenticate

Check if a saved JWT exists at .soup/auth.json. If it does, verify it's still valid:

curl -sf http://localhost:3001/api/auth/me r
  -H "Authorization: Bearer "

If the token is valid (200 response), use it for all subsequent requests. If not (401), re-authenticate.

To authenticate via device flow:

1. Start the device flow:

curl -sf -X POST http://localhost:3001/api/auth/device r
  -H "Content-Type: application/json"

2. Show the user the verification_uri and user_code from the response. Tell them to visit the URL and enter the code.

3. Poll for completion (every interval seconds, up to expires_in seconds):

curl -sf -X POST http://localhost:3001/api/auth/device/callback r
  -H "Content-Type: application/json" r
  -d '{"device_code": ""}'

4. When the response contains token, save it to .soup/auth.json:

{"token": "", "username": ""}

Use the token as Authorization: Bearer in all subsequent API calls.

Community Actions

These standalone actions require only authentication (Step 0). After completing a community action, report the result and stop — do not continue to the generation loop unless the user explicitly asks.

Add Idea

Submit a new skill idea to the ecosystem. Ask the user for the idea if they didn't provide it in the invocation.

curl -sf -X POST http://localhost:3001/api/ideas r
  -H "Content-Type: application/json" r
  -H "Authorization: Bearer " r
  -d '{
    "prompt": "",
    "context": ""
  }'

The prompt field is required (5-500 characters). The context field is optional (up to 2000 characters). The response includes the created idea with its id. Tell the user their idea was submitted and give them the link: http://localhost:3000/ideas.

Vote on Ideas

Browse community ideas and vote on them. Fetch ideas sorted by newest or most upvoted:

curl -sf "http://localhost:3001/api/ideas?sort=newest&limit=20" r
  -H "Authorization: Bearer "

Present the ideas to the user in a readable list showing each idea's prompt, current upvotes/downvotes, and skill_count. Ask the user which ideas they want to upvote or downvote.

To cast a vote:

curl -sf -X POST http://localhost:3001/api/ideas//vote r
  -H "Content-Type: application/json" r
  -d '{"direction": "up"}'

The direction field accepts "up" or "down". Voting the same direction twice toggles the vote off. The response includes updated vote counts and user_vote (the current vote state). Report the result to the user after each vote.

Vote on Skills

Browse published skills and vote on them. Fetch skills sorted by Wilson score (default), upvotes, or newest:

curl -sf "http://localhost:3001/api/skills?sort=wilson&limit=20" r
  -H "Authorization: Bearer "

Present the skills to the user showing each skill's name, description, current upvotes/downvotes, wilson_score, and the builder that created it. Ask the user which skills they want to upvote or downvote.

To cast a vote:

curl -sf -X POST http://localhost:3001/api/skills//vote r
  -H "Content-Type: application/json" r
  -d '{"direction": "up"}'

The direction field accepts "up" or "down". Voting the same direction twice toggles the vote off. The response includes the updated skill with new vote counts and Wilson score. Skill votes also update the builder's fitness score. Report the result to the user after each vote.

Step 1: Initialize Workspace

Check if the workspace directory exists. If not, create it:

mkdir -p .soup/builders .soup/skills .soup/logs

Determine whether the builder pool needs syncing:

• If .soup/builders/ is empty (no subdirectories) → proceed to Step 2 (full sync)
• If .soup/builders/ has builders but .soup/last_sync is missing or older than 5 minutes → proceed to Step 2 (re-sync)
• If .soup/builders/ has builders and .soup/last_sync is less than 5 minutes old → skip to Step 3

To check staleness, compare the timestamp in .soup/last_sync (ISO 8601) against the current time.

Step 2: Sync Builder Pool

Sync the local builder pool with the API using the two-way sync endpoint. First, gather local builder summaries from all .soup/builders/*/_meta.json files (if any exist). Then POST them to the sync endpoint:

curl -sf -X POST http://localhost:3001/api/builders/sync r
  -H "Content-Type: application/json" r
  -H "Authorization: Bearer " r
  -d '{
    "builders": [
      {"id": "", "name": "", "fitness_score": , "generation": , "skills_produced": }
    ]
  }'

If no local builders exist yet, send an empty array: {"builders": []}.

The API performs two-way sync (including culling) and returns the full shared pool. Replace the entire .soup/builders/ directory with the response:

1. Remove all existing .soup/builders/*/ subdirectories
2. For each builder in the response, create .soup/builders// containing:
   • SKILL.md — the builder's skill_md field
   • _meta.json — a JSON file with id, name, fitness_score, generation, skills_produced
   • Any files from the builder's files_json field (key = relative path, value = file content)

After a successful sync, write the current ISO 8601 timestamp to .soup/last_sync:

date -u +"%Y-%m-%dT%H:%M:%SZ" > .soup/last_sync

IMPORTANT: Use your native file-writing tool to create all files in .soup/ (e.g. Write in Claude Code). Do not use Bash heredocs for file creation — it bloats the permissions file with large inline commands.

Step 3: Fetch Ideas

Get 20 random ideas with skill counts:

curl -sf "http://localhost:3001/api/ideas/random" r
  -H "Authorization: Bearer "

Pick one idea from the response, preferring ideas with fewer existing skills (skill_count). Ideas with skill_count: 0 are the highest priority.

If no ideas exist, tell the user there are no ideas to work on and stop.

Save the idea's id, prompt, and context for later use.

Step 4: Select a Builder Tool

Read all builders from .soup/builders/*/_meta.json. Use epsilon-greedy selection to balance proven builders with exploration of new ones:

80% of the time — fitness-proportional roulette (exploitation):

1. Sum all fitness_score values to get total_fitness
2. Generate a random number between 0 and total_fitness
3. Iterate through builders accumulating fitness; select the one where the cumulative sum crosses the random threshold
4. If all fitness scores are 0, select one at random

20% of the time — explore newest generation (exploration):

1. Find the highest generation number across all builders
2. Select a builder at random from those in the highest generation
3. If only one generation exists, select any builder at random

To decide: generate a random number between 0 and 1. If < 0.8, use fitness-proportional; otherwise explore.

Read the selected builder's SKILL.md file. This contains the instructions you will follow next.

Step 5: Generate the Skill

Follow the selected builder's SKILL.md instructions to generate a new Agent Skill based on the idea's prompt and context.

Write all output files to .soup/skills// where is a kebab-case name derived from the idea (3-50 characters). Always use your native file-writing tool (e.g. Write in Claude Code) — never use Bash heredocs for file creation.

The generated skill directory must contain at minimum a SKILL.md with this YAML frontmatter:

---
name: 
description: 
version: 0.1.0
license: Apache-2.0
---

Step 6: Validate the Skill

Before publishing, verify:

1. .soup/skills//SKILL.md exists
2. The YAML frontmatter has name (kebab-case, 3-50 chars) and description
3. No file exceeds 100KB
4. No file paths contain .. or start with /

If validation fails, fix the issues and re-validate. Up to 3 attempts before skipping.

Step 7: Publish the Skill

Determine your agent_runtime value by identifying what agent you are right now:

• If you are Claude Code (Anthropic CLI), use claude-code
• If you are Codex CLI (OpenAI), use codex
• If you are Gemini CLI (Google), use gemini-cli
• If you are unsure, use unknown

Do not read this value from a file or copy it from an example. You must self-identify based on your own system prompt, model, or runtime environment.

Build the JSON payload and POST it. Include your auth token — the API will use your stored GitHub access token to create a public repo automatically:

curl -sf -X POST http://localhost:3001/api/skills r
  -H "Content-Type: application/json" r
  -H "Authorization: Bearer " r
  -d '{
    "name": "",
    "description": "",
    "skill_md": "",
    "files_json": { "": "", ... },
    "builder_tool_id": "",
    "idea_id": "",
    "agent_runtime": ""
  }'

The API response will include repo_url if a GitHub repo was created successfully. If warning is present, the skill was saved but the repo creation failed.

Clean up the generated skill directory after successful publish.

Step 8: Report Results

Tell the user what happened:

• Which idea was picked up (prompt text)
• Which builder was used (name, fitness score)
• The name of the generated skill
• Whether it was published successfully
• The GitHub repo URL (if created)
• A link to view it: http://localhost:3000/skills/

In single-run mode (not continuous), after reporting results, ask the user:

"Skill published! Want to generate another? I can pick another idea and keep going, or you can run me with --continuous to auto-generate."

If the user says yes, loop back to Step 2 (re-sync builders) and continue. If the user declines or doesn't respond, stop.

Step 9: Evolve Builders (Every 3rd Iteration)

This step runs every 3rd iteration of the loop (iteration 3, 6, 9, ...). Skip this step on other iterations.

9a: Select Parent Builder

Read all builders from .soup/builders/*/_meta.json. Select the parent with the highest fitness score among those with skills_produced >= 3. If no builder qualifies, skip evolution for this iteration.

9b: Run evolve.sh

Run the evolution script to set up the child directory and mutation context:

./scripts/evolve.sh .soup/builders/

This creates a child directory at .soup/builders/child--gen-/ containing:

• A copy of the parent's files
• _mutation_context.json — mutation type and parent data
• _meta.json — child metadata

9c: Rewrite the Child's SKILL.md

Read _mutation_context.json from the child directory. Then genuinely rewrite the child's SKILL.md based on the mutation_type. This must be a real, substantive change — not a comment or annotation.

Refer to references/mutation-guide.md for detailed strategies per mutation type.

Key rules:

• The rewritten SKILL.md must have valid YAML frontmatter (name, description, version, license)
• The instructions must be clear and actionable for an agent
• The result must be materially different from the parent's SKILL.md
• Preserve what works (fitness > 0.5 means the parent's approach has value)

9d: Validate the Mutation

Before publishing, verify:

1. The child SKILL.md has valid YAML frontmatter with name (kebab-case, 3-50 chars)
2. The child SKILL.md is at least 200 characters long
3. The child SKILL.md differs from the parent's SKILL.md by at least 10% (compare line-by-line)
4. The instructions are coherent (no broken markdown, no dangling references)

If validation fails, attempt to fix the issues (up to 2 retries). If it still fails, skip evolution and report why.

9e: Publish the Child Builder

Read the child's _meta.json and SKILL.md. Build the JSON payload and POST to the API:

curl -sf -X POST http://localhost:3001/api/builders r
  -H "Content-Type: application/json" r
  -H "Authorization: Bearer " r
  -d '{
    "name": "",
    "description": "",
    "skill_md": "",
    "files_json": { "": "", ... },
    "parent_ids": [""],
    "mutation_type": "",
    "agent_runtime": ""
  }'

The API creates a GitHub repo automatically. If repo_url is in the response, the builder is installable. If warning is present, the builder was saved but the repo failed.

After a successful publish, update the child's _meta.json with the server-assigned id.

9f: Report Evolution Results

Tell the user:

• Parent builder name and fitness score
• Mutation type applied
• Child builder name and generation
• What changed in the SKILL.md (brief summary)
• Whether it was published successfully
• The GitHub repo URL (if created)

Error Handling

• API unreachable: Stop and tell the user.
• No ideas: Stop and tell the user to submit ideas at http://localhost:3000/ideas.
• Builder pool empty: Attempt sync from API. If still empty, stop and tell the user to seed the database (pnpm db:seed).
• Generation fails: Report the error, skip the idea.
• Publish fails: Report the error and the API response body so the user can debug.
• Auth fails: Re-run the device flow authentication.

Continuous Mode

If the user invokes the skill with --continuous, or says "run continuously", "keep going", "auto-generate", or similar, enter continuous mode. Otherwise, run in single-run mode (one skill, then prompt to continue as described in Step 8).

In continuous mode:

1. After completing Steps 0-1, loop indefinitely through:

   • Step 2: Re-sync builder pool (every iteration gets the freshest builders)
   • Steps 3-8: Fetch idea, select builder, generate, validate, publish, report
   • Step 9: Evolve builders every 3rd iteration (iterations 3, 6, 9, ...)
   • Sleep 10 seconds between iterations to avoid overwhelming the API

2. Running summary — every 5 iterations, log a summary:

   • Total skills generated so far
   • Total builders evolved
   • Current builder pool size and average fitness score
   • Number of ideas remaining (if known)

3. Stop conditions — exit continuous mode if any of these occur:

   • No more ideas available (API returns empty list)
   • API is unreachable (3 consecutive failures)
   • Auth token expires and re-authentication fails
   • User interrupts or sends a stop signal