Skip to main content

skill-creator

Create or update focused, CAMEL-compatible agent skills with only the instructions and resources their workflows need. Use when designing, scaffolding, validating, testing, or packaging a reusable skill for SkillToolkit; do not use for ordinary code or documentation that does not need a skill.

Datos de origen

Repositorio
camel-ai/camel
Última actividad en el origen
31 de agosto de 2026 a las 09:24
Idioma detectado de SKILL.md
inglés
Estrellas
17.812
Forks
2106

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
6 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
skill-creator
description
Create or update focused, CAMEL-compatible agent skills with only the instructions and resources their workflows need. Use when designing, scaffolding, validating, testing, or packaging a reusable skill for SkillToolkit; do not use for ordinary code or documentation that does not need a skill.
# Skill Creator Create skills that give CAMEL agents useful, non-obvious guidance without constraining unrelated work. ## Core principles - **Assume the agent is capable.** Include only context that changes its decisions or makes repeated work more reliable. Remove generic advice, duplicated explanations, and speculative edge cases. - **Preserve user intent and authority.** A skill supports the requested task; it does not broaden the task, select a different product, or grant permission for external or destructive actions. - **Match specificity to risk.** Use flexible instructions when several approaches are valid. Use exact sequences or deterministic scripts when an operation is fragile, safety-sensitive, or must be repeatable. - **Keep discovery precise.** The `description` is visible before the body and is the primary trigger. State the job, likely trigger terms, and any boundary needed to prevent common false matches. - **Disclose details progressively.** Keep the shared workflow in `SKILL.md`. Put conditional details in directly linked references and load only the resources needed for the current request. - **Prefer the smallest useful bundle.** Start instruction-only. Add a script, reference, or asset only when it has a concrete, recurring purpose. ## CAMEL skill contract A skill is a directory with one required file and optional resources: ```text skill-name/ |-- SKILL.md Required frontmatter and instructions |-- scripts/ Optional deterministic helpers |-- references/ Optional guidance loaded only when relevant `-- assets/ Optional templates or files used in output ``` For repository-scoped CAMEL skills, prefer `<repo-root>/.camel/skills/<skill-name>/`. `SkillToolkit` also discovers repository skills under `.agents/skills`, user skills under `~/.camel/skills` and `~/.config/camel/skills`, and system skills under `/etc/camel/skills`. Design for these runtime behaviors: - `SkillToolkit` initially exposes each skill's `name`, `description`, path, scope, and direct child entries. It loads the body only after the agent calls `load_skill`. - Loaded content includes the skill's base directory. Use paths relative to that directory when referring to bundled resources. - Repository skills take precedence over user and system skills with the same name. Keep names unique and make the directory name match the frontmatter `name`. - Skill discovery is cached. Call `clear_cache()` or recreate the toolkit when testing changes in a running process. - `SkillToolkit` loads instructions but does not execute scripts. Give the agent `TerminalToolkit` or another appropriate execution tool when a skill requires runnable helpers. - Product-specific metadata is optional. Do not add files such as `agents/openai.yaml` unless a target host actually consumes them; CAMEL's `SkillToolkit` does not require them. ## Create or update a skill Adapt the workflow to the request. Skip steps that add no value, but verify the finished skill against realistic use. ### 1. Define the job and trigger boundary Identify: - the outcome the skill should help produce; - two or three realistic requests that should trigger it; - nearby requests that should not trigger it; - non-obvious constraints, tools, data, or output requirements. Ask the user only for missing information that would materially change the skill. For an existing skill, inspect its current files and callers before removing or renaming anything. ### 2. Plan the minimum bundle Use `SKILL.md` alone when instructions are sufficient. Add resources only for these reasons: - `scripts/`: logic that would otherwise be rewritten, or operations needing deterministic behavior; - `references/`: maintained schemas, policies, APIs, or substantial guidance needed only in some modes; - `assets/`: templates, fonts, images, boilerplate, or other files copied or adapted into the result. Do not add placeholder directories, README files, changelogs, installation guides, or duplicated quick references without a concrete requirement. ### 3. Initialize or edit For a new skill, either create the directory and `SKILL.md` directly or use the bundled initializer when its scaffold is useful: ```bash python <skill-creator-base>/scripts/init_skill.py \ <skill-name> --path <repo-root>/.camel/skills ``` The current initializer creates example resource directories. Delete every placeholder and directory the finished skill does not need. Do not initialize an existing skill again. Use lowercase letters, digits, and single hyphens for names, with a maximum of 64 characters. ### 4. Write for progressive disclosure In frontmatter: - Keep `name` equal to the skill directory name. - Write a concise, discriminating `description` that says what the skill does and when it applies. Front-load the main use case because hosts may shorten long descriptions. - Keep required metadata to `name` and `description`. Add supported optional fields only when the target environment needs them. In the body: - Use direct instructions and decision criteria, not background the agent already knows. - State inputs, outputs, important invariants, and stopping conditions where they affect correctness. - Link every supporting reference where it becomes relevant and explain when to read it. Avoid deep chains of references. - Reuse scripts and assets explicitly rather than asking the agent to recreate them. - Preserve real compatibility and authorization boundaries. Do not turn one observed failure into a universal rule without evidence. For conditional patterns, read only the applicable bundled guide: - For sequential or branching procedures, read [references/workflows.md](references/workflows.md). - For strict output structures or examples, read [references/output-patterns.md](references/output-patterns.md). ### 5. Validate implementation Run the bundled validator from any working directory: ```bash python <skill-creator-base>/scripts/quick_validate.py <skill-directory> ``` Then verify the behavior that validation cannot prove: - Run every new or changed helper script with representative inputs. - Instantiate `SkillToolkit` with the intended repository root as `working_directory` and confirm the skill appears in `list_skills()`. - Confirm `list_skill_files()` exposes the intended resources and `load_skill()` returns the body with the correct base directory. - If scripts are required, test the agent with both `SkillToolkit` and the execution toolkit the workflow expects. ### 6. Evaluate and iterate Test trigger quality and execution quality separately: 1. Try the realistic should-trigger and should-not-trigger requests from step 1. Include paraphrases rather than matching only the description's wording. 2. Run a small set of representative tasks with the skill loaded. When useful, compare against the same tasks without the skill to check that it adds value. 3. Inspect the actual decisions and outputs, collect user feedback when output quality is subjective, and identify the smallest supported correction. 4. Re-run the affected cases and retain changes only when they improve the intended behavior without broadening false triggers. Use the CAMEL model and agent configuration already chosen for the task. Do not introduce a provider-specific CLI merely to evaluate a CAMEL skill. Independent or parallel agent evaluation is optional when available and justified; it is not a prerequisite for creating a useful skill. ### 7. Package only when needed If the user needs a distributable `.skill` archive, run: ```bash python <skill-creator-base>/scripts/package_skill.py \ <skill-directory> [output-directory] ``` The packager validates first and excludes common local, credential, cache, and build artifacts. Inspect the archive contents before delivery. Do not package an intermediate skill when repository-local use is the requested outcome. ## Completion criteria A skill is complete when: - its trigger boundary is clear and tested with positive and negative cases; - its instructions preserve task scope and contain only useful guidance; - every bundled resource is necessary, discoverable, and verified; - CAMEL can discover and load it from the intended root; - no scaffold placeholders or local artifacts remain; - packaging succeeds when distribution was requested.
Ver en GitHub