Produces a complete SKILL.md packaged as a .skill file ready for CAS distribution. Use when: 'create a new skill', 'write a skill', 'build a skill for this workflow', 'turn this into a skill', 'upgrade this to a skill'.
Instrucciones de origen · Vista previa de solo lectura
name
skill-creation
model
sonnet
description
Produces a complete SKILL.md packaged as a .skill file ready for CAS distribution. Use when: 'create a new skill', 'write a skill', 'build a skill for this workflow', 'turn this into a skill', 'upgrade this to a skill'.
license
Complete terms in LICENSE.txt
category
skill-forge
triggers
["create a new skill","write a skill","build a skill for this workflow","turn this into a skill","upgrade this to a skill"]
tier
1
agents
["primary"]
tool_dependencies
["file_system"]
inputs
[{"name":"skill_description","type":"string","description":"Description of the workflow or domain to formalize into a skill","required":true},{"name":"usage_examples","type":"string[]","description":"Concrete usage scenarios for the skill (1-3 examples)","required":false}]
outputs
[{"name":"skill_package","type":"ref","format":"cas-ref","description":"Complete SKILL.md packaged as a .skill file ready for CAS distribution"}]
Skill Creator
Purpose
Use this skill to formalize a workflow or domain into a reusable, installable skill package. The output is a .skill file ready to be added to any agent that needs the capability.
Invoke when:
A user asks to "create a skill", "write a skill", "build a skill for this workflow", or "turn this into a skill"
A workflow is executed repeatedly and would benefit from formalization
A domain requires knowledge the agent lacks by default (schemas, APIs, business rules)
An existing skill needs iteration or quality improvement to meet A+ standards
Inputs
Before starting, gather:
Concrete examples — at least 1–3 real usage scenarios
Target agent — who will use this skill (same agent, different instance, a partner agent)
Skill name — short, lowercase, hyphenated (e.g., bigquery-queries, pdf-rotation)
Ask one targeted question at a time. Do not front-load a list of questions.
Skill Anatomy
Every skill consists of a required SKILL.md file and optional bundled resources:
skill-name/
├── SKILL.md (required)
│ ├── YAML frontmatter metadata (required)
│ │ ├── name: (required)
│ │ └── description: (required)
│ └── Markdown instructions (required)
└── Bundled Resources (optional)
├── scripts/ - Executable code (Python/Bash/etc.)
├── references/ - Documentation intended to be loaded into context as needed
└── templates/ - Files used in output (templates, icons, fonts, etc.)
SKILL.md (required)
Every SKILL.md consists of:
Frontmatter (YAML): Contains name and description fields. These are the only fields that the agent reads to determine when the skill gets used; make the description clear and specific about what the skill produces and when to use it.
Body (Markdown): Instructions and guidance for using the skill. Only loaded AFTER the skill triggers (if at all).
Bundled Resources (optional)
scripts/ - Executable code for repetitive or deterministic tasks (e.g., rotate_pdf.py). Token efficient, can run without loading into context.
references/ - Documentation loaded as needed (schemas, API docs, policies). Keeps SKILL.md lean. For large files (>10k words), include grep patterns in SKILL.md.
templates/ - Output assets not loaded into context (logos, fonts, boilerplate code).
Avoid duplication: Information lives in SKILL.md OR references, not both.
Do NOT include: README.md, CHANGELOG.md, or other auxiliary documentation. Skills are for AI agents, not users.
Progressive Disclosure
Three-level loading system:
Metadata - Always in context (~100 words)
SKILL.md body - When skill triggers (<500 lines)
Bundled resources - As needed
Keep SKILL.md under 500 lines. When splitting content to references, clearly describe when to read them.
Key principle: Keep core workflow in SKILL.md; move variant-specific details to reference files.
Match the level of specificity to the task's fragility and variability:
High freedom (text-based instructions): Use when multiple approaches are valid, decisions depend on context, or heuristics guide the approach.
Medium freedom (pseudocode or scripts with parameters): Use when a preferred pattern exists, some variation is acceptable, or configuration affects behavior.
Low freedom (specific scripts, few parameters): Use when operations are fragile and error-prone, consistency is critical, or a specific sequence must be followed.
Skill Creation Process
Skill creation involves these steps:
Understand the skill with concrete examples
Plan reusable skill contents (scripts, references, templates)
Initialize the skill (run init_skill.py)
Edit the skill (implement resources and write SKILL.md)
Deliver the skill (send SKILL.md path via notify_user)
Iterate based on real usage
Follow these steps in order, skipping only if there is a clear reason why they are not applicable.
Step 1: Understanding the Skill with Concrete Examples
Skip this step only when the skill's usage patterns are already clearly understood.
Gather concrete examples of how the skill will be used. Ask questions like:
"What functionality should this skill support?"
"Can you give examples of how it would be used?"
Avoid asking too many questions at once. Conclude when you have a clear sense of the functionality.
Step 2: Planning the Reusable Skill Contents
For each example, identify reusable resources:
Resource Type
When to Use
Example
scripts/
Code rewritten repeatedly
rotate_pdf.py for PDF rotation
templates/
Same boilerplate each time
HTML/React starter for webapp builder
references/
Documentation needed repeatedly
Database schemas for BigQuery skill
Step 3: Initializing the Skill
At this point, it is time to actually create the skill.
Skip this step only if the skill being developed already exists, and iteration or packaging is needed. In this case, continue to the next step.
When creating a new skill from scratch, always run the init_skill.py script. The script conveniently generates a new template skill directory that automatically includes everything a skill requires, making the skill creation process much more efficient and reliable.
Creates the skill directory at /home/ubuntu/skills/<skill-name>/
Generates a SKILL.md template with proper frontmatter and TODO placeholders
Creates example resource directories: scripts/, references/, and templates/
Adds example files in each directory that can be customized or deleted
After initialization, customize or remove the generated SKILL.md and example files as needed.
Step 4: Edit the Skill
When editing the (newly-generated or existing) skill, remember that the skill is being created for another instance of Manus to use. Include information that would be beneficial and non-obvious to Manus. Consider what procedural knowledge, domain-specific details, or reusable assets would help another Manus instance execute these tasks more effectively.
Learn Proven Design Patterns
Consult these helpful guides based on your skill's needs:
Multi-step processes: See /home/ubuntu/skills/skill-creation/references/workflows.md for sequential workflows and conditional logic
Output formats or quality standards: See /home/ubuntu/skills/skill-creation/references/output-patterns.md for template and example patterns
Progressive Disclosure Patterns: See /home/ubuntu/skills/skill-creation/references/progressive-disclosure-patterns.md for splitting content across files.
These files contain established best practices for effective skill design.
Start with Reusable Skill Contents
Begin with the scripts/, references/, and templates/ files identified in Step 2. This may require user input (e.g., brand assets for templates/, documentation for references/).
Test added scripts by running them to ensure they work correctly. For many similar scripts, test a representative sample.
Delete any unused example files from initialization.
Update SKILL.md
Writing Guidelines: Always use imperative/infinitive form.
Frontmatter
Write the YAML frontmatter with name and description:
name: The skill name
description: Primary trigger mechanism. Must include what the skill does AND when to use it (body only loads after triggering).
Example: "Document creation and editing with tracked changes. Use for: creating .docx files, modifying content, working with tracked changes."
Body
Write instructions for using the skill and its bundled resources.
Step 5: Delivering the Skill
Once development of the skill is complete, validate and deliver it to the user.
Validate the Skill
Run the validation script to ensure the skill meets all requirements:
If validation fails, fix the errors and run validation again.
Deliver to User
Use message tool to send the SKILL.md file as attachment:
/home/ubuntu/skills/{skill-name}/SKILL.md
The system will automatically:
Detect the path pattern /home/ubuntu/skills/*/SKILL.md
Package the skill directory into a .skill file
Send to frontend as a special card with options:
Add to My Skills
Download
Preview
Step 6: Iterate
After testing the skill, users may request improvements. Often this happens right after using the skill, with fresh context of how the skill performed.
Iteration workflow:
Use the skill on real tasks
Notice struggles or inefficiencies
Identify how SKILL.md or bundled resources should be updated
Implement changes and test again
Output
A completed skill package containing:
SKILL.md — valid YAML frontmatter + body with at least 8 ## sections (A+ standard)
Move verbose prose from ## Steps to references/detailed-steps.md if over 150 lines
Rewrite ## Notes as ## Anti-patterns with concrete failure modes
Validate and re-deliver
Edge Cases
Requested skill is really a seed or note, not a workflow — ask for 2–3 concrete usage scenarios before starting; if the user cannot provide them, suggest capturing a seed first
Existing skill directory already has a SKILL.md — treat this as iteration (Step 4), not creation from scratch; read the current file before proposing any changes
User wants a skill that wraps another skill — infer tier 3, add meta_skill to tool_dependencies, and link the referenced skill in the body's Related Skills section
Skill body exceeds 400 lines during drafting — pause, identify which sections contain variant or example detail, and move them to references/ before continuing
Anti-Patterns
Over-explaining what the agent already knows. Don't include basic API documentation the agent has in training. Only add domain-specific, proprietary, or procedural knowledge the agent cannot infer.
Vague description field. A skill with a vague description will never fire. The description is the only field read before loading the skill body — be explicit about when to use it.
Monolithic SKILL.md. A 600-line body defeats progressive disclosure. When the body exceeds ~400 lines, split variant details into references/.
README.md in the skill directory. Skills are for agents, not humans. Do not include README.md, CHANGELOG.md, or any auxiliary documentation.
Skipping validation.quick_validate.py catches structural errors before delivery. Running it only when something feels wrong means shipping broken skills.
Designing for one example. A skill built for exactly one known scenario fails on edge cases. Gather multiple examples in Step 1 to expose variation and plan for it.
High freedom where low freedom is needed. If a script must run in a specific sequence (e.g., database migration), do not leave it as a narrative description — use a script with enforced order.
