Meta Llama is a model family and ecosystem, not one universal desktop agent with a documented local SKILL.md directory. Skill behavior therefore depends on the harness running the model. Llama Stack supplies interfaces for agentic applications, tool use, retrieval, safety, and deployment, but the application still decides how procedural packages are discovered and loaded.
Separate the model from the host
A portable skill contains metadata, instructions, and optional resources. A host needs to scan the available packages, advertise their descriptions, select one for the task, load its body, expose allowed files, and connect the necessary tools. Claude Code, Codex, Gemini CLI, and Grok ship versions of that lifecycle. With Llama, you may need to implement it in your own agent service or use a third-party harness that already does.
A minimal adapter
- Scan a trusted skills directory for folders containing
SKILL.md. - Parse only the metadata fields your application supports and reject invalid files.
- Expose concise names and descriptions to the routing step.
- Load the selected body and resource manifest only after a match.
- Map requested tools to your Llama Stack tool provider or application functions.
- Keep file and network permissions outside the Markdown package.
- Record which skill version shaped each result.
Do not execute a package because it parses
Markdown can instruct a model to run scripts, read files, call remote services, or reveal secrets. Treat public skills as untrusted input. Review scripts, restrict paths, require approval for consequential tools, and keep credentials in the host. Meta’s broader Llama system includes safety components such as prompt-injection and guard models, but those controls do not replace application-level permissions.
Port the workflow before the extensions
Start with the skill’s outcome, inputs, steps, and finish checks. Ignore Claude-, Codex-, Gemini-, or Grok-specific fields unless your harness implements them. If the package depends on dynamic context or an MCP server, make that dependency explicit and add it to the host as a separate capability.
Measure behavior across models
A skill that works with one hosted model may need clearer decision boundaries with another. Run the same test set, fixed inputs, and acceptance checks. Compare evidence use and artifacts, not whether the prose sounds identical. Keep model-specific advice in a reference file when it is genuinely required rather than forking the entire skill.
Where SkillForge fits
SkillForge produces the human-readable package and keeps the editing process visual. For Llama deployment, export the SKILL.md, place it in the trusted source used by your harness, and implement the discovery and permission boundary around it. Claim “Llama compatible” only after that exact harness has loaded and exercised the workflow.