Workshop Rules Luban polishes a tool through five steps. Material Inspection: First judge if the "material" is worth polishing—rotten wood cannot be carved; if it's not worth it, say so directly and suggest directions for replacement. Peer Research: Look at all similar works on the market to understand where this tool stands in the industry; good tools can't be created behind closed doors. Dimension Measurement: Evaluate using three metrics - structure, actual testing, and live verification. Every score must have evidence, no relying on feel—live verification measures real running outputs; silent failures are more fatal than poor documentation. Iterative Refinement: Seal the original as a baseline first; after polishing, measure again with the metrics—keep it if it passes, revert if it doesn't. Never polish extra just to seem like you've done work. Post-Release Iteration: Delivery is not the end; peers are still evolving, users will come back, and the next iteration starts with real feedback.

1. Shopkeeper (Product Manager): Judge who this tool solves problems for and what problems it solves, and why it's worth installing.
2. Traveler (Ecosystem Researcher): Search for similar Skills in ecosystems like GitHub, ClawHub, skills.sh, Tessl, and analyze why they are understood, collected, installed, and shared.
3. Measurer (Auditor): Use dual-track evaluation of structure scoring + actual performance to identify the most critical aspects to polish first.
4. Planer (Optimizer): Make bounded candidate edits, only accepting changes that pass the verification gate.
5. Display Director (README & Showcase Director): Package the Skill into a public asset that others are willing to stop and look at, and want to install after seeing it.

1. Target Skill: Local Skill directory path / GitHub repository link / ClawHub page / A segment of SKILL.md content / An unformed Skill idea
2. Target Release Platform (optional): GitHub / ClawHub / skills.sh / Tessl / Private use
3. User Priority (optional): Shareability / Actual performance / Installation rate / Cross-runtime compatibility / README expression / Showcase intensity

examples/ai-news-radar-case.md

• SKILL.md

  ,

  README.md

• references/

  ,

  scripts/

  ,

  assets/

  ,

  examples/

• test-prompts.json

  or equivalent test samples
• Installation instructions, demo/showcase screenshots, GIFs, output samples
• GitHub repository structure and public signals like commit/issue/star
• Display methods on ClawHub/skills.sh/Tessl pages

references/birth-checklist.md

• Inspect material first, then act. Don't start rewriting copy immediately.
• Research peers first, then discuss differences. Don't do closed-door upgrades.
• Measure first, then decide to retain. Don't think it's better just because it's longer.
• Silent failures are more fatal than poor documentation. A green CI can lie—always reconcile with real running outputs, don't just trust the status light.
• Polish only one aspect per round; upgrade granularity after building trust. Strictly single aspect in the first round to build trust; after the user explicitly authorizes batch changes ("Do all" "Fix everything"), switch to "single aspect per commit"—each commit passes the verification gate independently and is pushed immediately, reducing the attribution unit from round to commit.
• No empty words. Prohibit unexecutable phrases like "Suggest considering", "Can be flexibly adjusted", "Optimize according to circumstances".
• Don't complicate for the sake of being advanced. The more public a Skill is, the more it needs to be quickly understood by first-time viewers.
• Don't leak privacy or credentials. No API keys, tokens, cookies, private paths, or real account privacy in READMEs, examples, scripts, or test data.
• Default to cross-Agent ecosystem compatibility. Try to be compatible with Skill-compatible runtimes like Claude Code, Codex, OpenCode, OpenClaw, Hermes, unless the user explicitly requires a single runtime.

• Push immediately after commit. Don't hoard local commits; push every verified commit immediately.
• Don't run long tasks in the background. Wait for long commands like cloning large repositories or running pipelines in the foreground; never reuse the directory operated by a background task until the task ends.
• Do heartbeat checks for background sub-Agents. No growth in output files for a long time = suspected stuck (mostly stuck on invisible permission pop-ups); actively stop, retrieve existing clues, and switch to a foreground solution.
• Showcases must be reproducible. Recording scripts (e.g., vhs tape), data scripts, and outputs for demos are stored together in the repository, so anyone can re-record at any time.

1. Real Problem: Is the real user problem solved by this Skill valid?
2. Unique Angle: Does its uniqueness come from methodology, script assets, private experience, data, workflow, or display effect? If there's no uniqueness, directly point out the risk of homogenization.
3. Installation Reason: Why should users install it instead of asking an Agent temporarily?
4. Public Shareability: Does it have a one-sentence sharing hook? Does it have results that can be screenshot, recorded, or displayed?

undefined

• Sub-Agent 1 — GitHub Peers: Search for

  <keyword> skill

  ,

  <keyword> agent skill

  ,

  <keyword> SKILL.md

  ,

  <keyword> Claude skill

  ,

  <keyword> OpenClaw skill

• Sub-Agent 2 — Skill Markets: Similar categories, popular Skills, and similar workflows in directories like ClawHub, skills.sh, Tessl
• Sub-Agent 3 (only needed when user specifies benchmarks): Deeply read the user-specified benchmark repository or Skill, analyze its README, installation path, and showcase practices

name

description

Prioritize using CLI tools like

curl

and

gh api

that are usually allowed; tools like WebFetch/WebSearch may trigger invisible permission pop-ups for users, causing you to hang silently. If one tool fails continuously or has no response, immediately switch to the CLI route, don't retry in place. Each candidate must provide a real URL; if not found, state it truthfully.

• Direct Peers: Solve the same problem.
• Indirect Peers: Solve adjacent problems, and users may choose between them.
• Craft Peers: Not the same function, but have excellent README, showcase, naming, and sharing practices worth learning.

undefined

• What specific pain point was it originally created to solve?
• Is it currently a tool, methodology, workflow, style migration, or automation system?
• What step is missing to turn it from "private use" to "publicly available"?
• Which path should the next version evolve along: stronger functions, better display, more stable installation, more universal adaptation, or higher verification?

• Naming Hook: Does the name have a memory point? Can people tell what it solves at a glance?
• One-Sentence Positioning: Is it explained in plain language?
• Installation Friction: Can it be installed with one command? Does it require complex prerequisites?
• First-Screen Trust: Does the README first screen have badges, GIFs, screenshots, result samples, or real data?
• Verifiable Outputs: Are there "visible" outputs after running, such as HTML, PDF, reports, cards, diffs, test results?
• Security Boundaries: Does it explain that it won't delete files randomly, leak data, or send external requests without permission?
• Ecosystem Compatibility: Does it explicitly support multiple Agent runtimes?
• Storytelling: Does it tell "why this Skill is needed now" instead of just listing functions?

• Freshness of Data Outputs: Are timestamps like

  generated_at

  in online/repository generated files actually up-to-date? How long have some files stopped updating?
• CI Reconciliation: The latest pipeline is green, but what did it actually submit/produce? Green light ≠ no problem—silent failure occurs when the status is successful but outputs are outdated.
• Real Rendering: If there are pages/outputs, open them in both desktop and mobile widths and take screenshots for evidence.
• Real Execution: Run each command in the document one by one; failure to run is evidence.

• ...

• ...

• ...

1. ...

1. ...

undefined

• Prioritize verification with real data replay: Run comparisons before and after changes using the project's current/historical real data, provide numbers (how many items were flipped, percentage change from X to Y); if no real data is available, fall back to dry-run with test prompts and mark it truthfully;
• At least 2 typical test prompts have better output than the frozen baseline;
• README first screen can explain value within 10 seconds;
• No obvious additional friction in the installation path;
• No secrets, private paths, or non-reproducible dependencies introduced;
• No making the Skill longer but harder to use;
• Differentiation from similar Skills is clearer.

• One-time comparison scripts →固化成 repository's backtest/verification tools (e.g.,

  scripts/backtest_*.py

  );
• One-time judgment criteria → established as explicit project rules (e.g., "Changing scores must be accompanied by ≥14-day replay report").

One-sentence hook: Don't talk about functions, talk about what pain it saves users from.

1. GIF: Show from input to result within 30 seconds;
2. Screenshots: First-screen effect, final output, key diffs;
3. Sample Outputs: Real running outputs, don't just put fictional samples;
4. Comparison Charts: Before/after polishing;
5. Result Card: Score changes, main improvements, next step.

• ...

• ...

• ...

• ...

undefined

1. Maintain a benchmark observation list: Among the peers found during research, which ones' actions are worth continuous monitoring (their changelogs, new functions, user feedback channels). When users come back with "Look what XX did with YY", start from here, not from material inspection.
2. Establish iteration rules: Learn transparent iteration storytelling—release notes/changelogs are required for releases, explaining "why changes were made" instead of just "what was changed"; write the verification tools and explicit rules沉淀 in this round (see Verification Asset Institutionalization) into project documentation.
3. Mark the next iteration entry: Write down this round's "not done" list + known boundary losses (e.g., edge cases with recall issues), and start directly from here in the next round.

1. When material inspection concludes "Rotten wood, suggest replacing material and recarving";
2. When peer research finds serious homogenization in the current direction;
3. When preparing to upgrade from single Skill to Skill kit;
4. When preparing to add high-risk scripts, delete logic, or call external APIs;
5. When candidate rewrites will significantly change the Skill's positioning;
6. Merge to default branch, tag release, any deployment visible to real users—each of these three actions requires explicit authorization every time.

• Don't only modify SKILL.md without looking at README and showcase.
• Don't only look at format without running test prompts.
• Don't draw conclusions after finding only one peer.
• Don't equate "more functions" with "better".
• Don't pile up jargon to seem professional.
• Don't write private paths, private material libraries, or private accounts into public Skills.
• Don't write untrustworthy big words like "Supports everything" "Automatically solves all problems" in README.
• Don't hardcode the runtime to Claude Code unless it's an explicit positioning.
• Don't polish multiple aspects in one round without batch authorization; even after getting batch authorization, don't put multiple aspects into one commit.
• Don't trust CI status lights alone. Outputs may have stopped updating for days under a green light; must reconcile with real outputs.
• Don't treat users' questions as release authorization.
• Don't use

  git reset --hard

  as the default revert solution; if git is involved, prioritize auditable diff or revert ideas.
• Don't hold the planer and ruler in the same hand—the same perspective cannot be responsible for both "changing" and "evaluating".
• Don't copy peers' names, narratives, and structures just because their Skills are popular. Learn the craft, don't steal the appearance.
• Don't fabricate peers from memory. All similar Skills must have URLs; if not found, honestly mark "Not Found".

• Material inspection done? Conclusion given first, no skipping directly to rewriting?
• Peer research found at least 5 peers, covering direct/indirect/craft types, all with URLs? Sub-Agents followed tool discipline?
• Ecological niche judgment provided a "one-sentence new positioning", not a general summary?
• Live verification done? At least applicable items covered: data freshness, CI reconciliation, real rendering, document command execution?
• Nine-dimension scoring has evidence for each dimension? Prioritized real data replay, dry-run marked truthfully?
• Three polishing directions provided with a clear recommendation?
• Polishing granularity correct? First round single aspect; after batch authorization, single aspect per commit, commit immediately push?
• Candidate rewrites passed all verification gate clauses? Used independent inspector perspective?
• Verification assets institutionalized? Comparison scripts固化 into tools, judgment rules established as regulations, or explained why not worth retaining?
• README suggestions include one-sentence hook, visible output display, trigger methods, security boundaries? Showcase reproducible (recording scripts stored in repository)?
• "Post-polishing score" in graduation certificate marked as estimated/measured truthfully?
• Post-release iteration list maintained? Benchmark observation points, iteration rules, next iteration entry?
• No API keys, tokens, cookies, private paths, or real account privacy leaked?
• Mandatory stop points followed? Merge/release/deployment got imperative authorization every time?
• Questions needing user confirmation no more than 3, and all are direction-influencing?
• No violations of any workshop taboos?