agentleFS
Sign inStart free
thoitiettxl-cyberthoitiettxl-cyber/Claw-II/skills/skill-creator/SKILL.md

skill-creator

Skill2 starsChanged 7 months agoMITView on GitHub

Create or refactor internal Agent Skills according to the canonical core design spec, including KB self-contained mode, coverage matrix, indexed refs, semantic self-audit, and parseable compliance verdict.

189 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use taskflow-inbox-triage, mermaid-diagram-generator and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AtomicBot-aiSkill

    taskflow-inbox-triage

    Also in 6 projects that use this

  • shalombSkill

    mermaid-diagram-generator

    Guide on creating and editing Mermaid charts safely. Use when asked to draw a diagram, flowchart, or architecture chart. Triggers on: 'mermaid', 'diagram', 'flowchart', 'visualize'.

    Also in 5 projects that use this

  • naman10parikhSkill

    ecosystem-reference

    Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.

    Also in 5 projects that use this

  • naman10parikhSkill

    fractal-delegation

    Also in 5 projects that use this

  • Liang-MHSkill

    stock_analysis

    获取 A 股、基金和港股的实时行情和技术分析数据

    Also in 5 projects that use this

  • nicepkgSkill

    community-led-growth

    Expert in community-led growth (CLG) - leveraging user communities to drive acquisition, retention, and expansion. Covers building developer communities, user groups, ambassador programs, and turning customers into advocates. Knows the difference between community as a feature vs community as a growth engine, and how to measure community ROI. Use when "community-led, CLG, ambassador program, champion program, user community, developer community, word of mouth, user group, " mentioned.

    Also in 5 projects that use this

  • +6 more from naman10parikh

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 14 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 185 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create new skills according to the core standard.

    line 37
  2. Distinctive:

    Run self-audit with additional semantic drift checks.

    line 41
  3. Distinctive:

    When there is conflict:

    line 57
  4. Very specific:

    Every spec change must re-run scripts/self_audit.sh to avoid drift between scaffold/template/audit.

    line 60
  5. Distinctive:

    if KB-style: reading order + coverage matrix + portability note

    line 74
  6. Very specific:

    Use references/template-skill-md-v1.md to create/edit SKILL.md.

    line 75
  7. Distinctive:

    If KB self-contained, scaffold/verify the minimum doc-set:

    line 79
  8. Very specific:

    Do not leave python3, pip3, bare pip, or PATH-dependent shebangs like #!/usr/bin/env python3 if the skill is expected to run on the current …

    line 91
  9. Very specific:

    Only keep python3 when it is descriptive data/real runtime path (/data/adb/openclaw/python/bin/python3) or an error/diagnostic example that …

    line 93
  10. Distinctive:

    If self-audit warns about semantic drift or stale legacy claims:

    line 97
  11. Very specific:

    If editing any canonical/shared file (e.g.

    line 101
  12. Distinctive:

    Do not hardcode secrets.

    line 120
  13. Distinctive:

    Do not fabricate line ranges.

    line 121
  14. Distinctive:

    Do not create directives that conflict with system/developer policy.

    line 122
  15. Distinctive:

    If the workflow has external/network write: add an approval checkpoint.

    line 123
  16. Distinctive:

    If missing input/permissions: report what is missing and request it clearly.

    line 133
  17. Distinctive:

    If runtime/tool error: return a short error + likely cause + proposed remediation.

    line 134
  18. Distinctive:

    If self-audit is only WARN: clearly state which WARNs are acceptable and which WARNs must be fixed before real-world PASS.

    line 135
  19. Distinctive:

    If there is policy/safety risk: stop and escalate via approval checkpoint.

    line 136
  20. Very specific:

    When the skill is already relatively stable and needs benchmark/review/package artifact, hand off to skill-bench.

    line 140

“Common” is measured: kept by at least 6 in 10 of the 185 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill Creator (Core-Governed)

This skill is the standard toolchain to create/refactor internal skills under the same rulebook.

Indexed Reference Map

  • @[SKILL.md#L1-L108] Frontmatter
  • @[SKILL.md#L32-L108] Purpose + capability expansion
  • @[SKILL.md#L40-L108] Reading order
  • @[SKILL.md#L48-L108] Standard SOP
  • @[SKILL.md#L79-L108] Output contract
  • @[SKILL.md#L92-L108] Guardrails
  • @[references/design-spec-core-v1.md#L1-L137] Canonical core design spec v2
  • @[references/template-skill-md-v1.md#L1-L64] Canonical SKILL.md template v2
  • @[references/audit-checklist-v1.md#L1-L44] Canonical audit checklist v2
  • @[references/specification.md#L1-L102] Local spec constraints
  • @[references/refactor-pattern.md#L1-L51] Indexed refactor + KB mode patterns
  • @[scripts/init_skill.sh#L1-L204] Scaffold helper with KB-mode support
  • @[scripts/build_index_refs.sh#L1-L43] Index map helper
  • @[scripts/self_audit.sh#L1-L200] Compliance + semantic validator
  • @[scripts/batch_audit.sh#L1-L51] Batch audit helper for skills/*

Scope

  • In-scope: create/refactor/audit internal Agent Skills according to the canonical design spec, indexed refs, kb_mode governance, semantic self-audit.
  • Out-of-scope: benchmark/package/review workflow after the skill is already stable; hand off to skill-bench.

Purpose

  1. Create new skills according to the core standard.
  2. Refactor old skills to the core standard.
  3. Upgrade technical skills to Knowledge Base self-contained form when needed.
  4. Audit completeness according to a coverage matrix rather than intuition alone.
  5. Run self-audit with additional semantic drift checks.
  6. Output a parseable compliance report (PASS/FAIL + findings).

Reading Order

  1. references/specification.md (merged upstream+local SSoT)
  2. references/design-spec-core-v1.md
  3. references/template-skill-md-v1.md
  4. references/audit-checklist-v1.md
  5. references/refactor-pattern.md
  6. scripts/self_audit.sh

Merge Policy (Upstream + Local)

  • references/specification.md is the single source of truth for validation semantics.
  • Rules apply in this order:
    1. Upstream constraints (Agent Skills canonical format)
    2. OpenClaw local governance extensions (kb_mode, self-contained doc-set, indexed refs, semantic checks)
  • When there is conflict:
    • prioritize keeping it upstream-valid first,
    • then apply local policy if it does not violate upstream.
  • Every spec change must re-run scripts/self_audit.sh to avoid drift between scaffold/template/audit.

Standard SOP

  1. Determine the target skill <skill-dir> and mode (create|refactor).
  2. Classify style:
    • regular skill
    • KB thin
    • KB hybrid
    • KB self-contained
  3. Standardize according to references/design-spec-core-v1.md:
    • folder structure
    • frontmatter constraints
    • trigger rules
    • SOP + error handling + output contract
    • if KB-style: reading order + coverage matrix + portability note
  4. Use references/template-skill-md-v1.md to create/edit SKILL.md.
  5. Build indexed refs:
    • scripts/build_index_refs.sh <file.md>
    • validate line ranges with nl -ba <file> when needed.
  6. If KB self-contained, scaffold/verify the minimum doc-set:
    • references/INDEX.md
    • references/QUICK_REFERENCE.md
    • core doc (CORE_API.md/CONCEPTS.md)
    • references/PATTERNS.md
    • references/EXAMPLES.md
    • references/AI_WORKFLOW.md
  7. Python Env / Local Wrapper Repair (mandatory for future skills):
    • Audit all docs/scripts/examples in <skill-dir> to detect drift from the local runtime contract.
    • Standardize execution examples to the absolute local wrapper when appropriate:
      • /data/adb/openclaw/node/bin/python
      • /data/adb/openclaw/node/bin/pip
    • Do not leave python3, pip3, bare pip, or PATH-dependent shebangs like #!/usr/bin/env python3 if the skill is expected to run on the current Android OpenClaw host.
    • With shell helpers, prefer python -m pip via the absolute wrapper instead of depending on PATH.
    • Only keep python3 when it is descriptive data/real runtime path (/data/adb/openclaw/python/bin/python3) or an error/diagnostic example that must preserve the original text.
  8. Run self-audit:
    • scripts/self_audit.sh <skill-dir>
  9. Cross-check references/audit-checklist-v1.md and output verdict.
  10. If self-audit warns about semantic drift or stale legacy claims:
  • patch related references
  • rerun audit
  1. Reference Drift Prevention (mandatory):
  • If editing any canonical/shared file (e.g. a heavily cross-referenced skill like glibc-prebuilt-bundle, skill-creator, or a shared spec/checklist/template), run a full-sweep audit across all skills/* before reporting done.
  • Standard command:
    • for d in skills/*; do [ -f "$d/SKILL.md" ] && sh skills/skill-creator/scripts/self_audit.sh "$d" || true; done
  • You may only conclude when ref line range out of bounds no longer appears.

Output Contract

  • Self-Audit Report
    • structure/frontmatter/name/description/line-count/reference existence
    • KB mode checks
    • semantic warnings/errors
  • Indexed Reference Map
    • list of @[path#Lx-Ly] + purpose
  • Final Code
    • full content of the main files created/edited
    • at minimum must include the file map + full content of the main controlling files (SKILL.md, validator script, spec/checklist/template if edited)
  • Compliance Verdict
    • PASS when there is no critical fail, otherwise FAIL

Guardrails

  • Do not hardcode secrets.
  • Do not fabricate line ranges.
  • Do not create directives that conflict with system/developer policy.
  • If the workflow has external/network write: add an approval checkpoint.
  • For skills running on the Android OpenClaw host, do not leave a Python execution contract dependent on PATH when the absolute wrapper is required by the local runtime.
  • Semantic audit is heuristic; do not claim it proves absolute correctness.

Trigger Rules

  • Positive: Trigger when the user request matches skill-creator per the description: Create or refactor internal Agent Skills according to the canonical core design spec. Use when needing to standardize structure/frontmatter/triggers/SOP, add indexed refs, run self-audit, package self-contained KB, or output compliance verdict.
  • Negative: Do not trigger for requests outside scope or that do not need the workflow/expertise of this skill.
  • Escalation: If there is external action/network write or sensitive operation, add an approval checkpoint before execution.

Error Handling

  • If missing input/permissions: report what is missing and request it clearly.
  • If runtime/tool error: return a short error + likely cause + proposed remediation.
  • If self-audit is only WARN: clearly state which WARNs are acceptable and which WARNs must be fixed before real-world PASS.
  • If there is policy/safety risk: stop and escalate via approval checkpoint.

Relationship to skill-bench

  • skill-creator is responsible for canonical authoring/governance.
  • When the skill is already relatively stable and needs benchmark/review/package artifact, hand off to skill-bench.
  • skill-bench must not override the schema authority of skill-creator.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free