Skip to main content

Module skills

Module skills 

Source
Expand description

ORCH-11 (observed tier): read-only enumeration of the skill packages each harness has installed.

supercode never installs, removes, or edits a skill here — it opens the directories the harness’s own loader opens and reports what is there. The roots below are transcribed from each harness’s documented/primary source:

  • Claude Code — enterprise (managed) > personal ~/.claude/skills/ > project .claude/skills/, nested .claude/skills/ in subdirectories, plugin skills namespaced plugin:skill (docs/composable-harness/inventory/claude-code.md “Skill locations & precedence”; docs:skills#where-skills-live).
  • Codex — repo .agents/skills from cwd to the repo root, user ~/.agents/skills (plus the deprecated $CODEX_HOME/skills), admin /etc/codex/skills, and the bundled cache $CODEX_HOME/skills/.system (inventory/codex.md §7 Skills; codex-rs/core-skills/src/loader.rs). [skills] in $CODEX_HOME/config.toml is an enable/disable overlay (SkillConfig { path, name, enabled }), not an extra root, so it is read for enabled only (codex-rs/config/src/skills_config.rs:12-36 at the pinned commit 1f0566d3).
  • opencode — {skill,skills}/**/SKILL.md under every .opencode dir plus the global config dir (inventory/opencode.md §7 Skills, packages/opencode/src/skill/index.ts:23-25).
  • pi — ~/.pi/agent/skills/, ~/.agents/skills/, project .pi/skills/ and .agents/skills/ in cwd and its ancestors (inventory/pi.md §2 Skills, src:core/skills.ts).
  • Hermes 0.21.0 — HERMES_HOME/skills (get_skills_dir() = get_hermes_home() / "skills", hermes_constants.py:1195-1197), and because profile mode sets HERMES_HOME to <root>/profiles/<name> (hermes_constants.py:160-190), <root>/profiles/<name>/skills too. Hermes groups skills by category, so a root is walked, not listed.
  • OpenClaw 2026.7.1-2 — managed <config>/skills, plugin <config>/plugin-skills, workspace <workspace>/skills and <workspace>/.agents/skills, personal ~/.agents/skills (src/skills/loading/workspace.ts:1155-1215 at tag v2026.7.1-2).

enabled is None wherever the harness’s own source does not say; only Codex’s [skills] overlay and a skill’s own frontmatter produce a bool.

Structs§

LoopSkill
One SKILL.md package the supercode loop itself will load.
ShellInjection
The authorization a !`cmd` expansion runs under — built from a resolved crate::Config, never assembled ad hoc at a call site.
SkillHomes
Config homes the skill roots hang off. Defaults follow each harness’s own environment contract; a caller may override any of them (tests, probes).
SkillRow
One installed skill package, as one harness holds it.
SkillsQuery
harness.v1.skills.list request.

Enums§

SkillScope
Where a skill package was found, in the vocabulary shared by all six harnesses.

Constants§

MAX_SKILL_BODY_BYTES
Ceiling on the bytes of a skill body handed to the model in one load.
SKILL_HARNESSES
Every harness that has a skills root, in product order.

Functions§

declared_skill_name
A skill package’s own declared name: SKILL.md frontmatter name, else the directory’s own name — exactly the rule list_skills applies, so a row installed here is found again by the name the loader will report.
find_skill
Resolve one invocation name against a discovered set: exact, then case-insensitively, then the unqualified leaf of a dir:skill / plugin:skill name when exactly one skill owns that leaf. A leading / or $ sigil is stripped first, so the same resolver serves the slash command, the mention, and the skill tool — one name, one answer.
implicit_skill_match
BP-6 (cx§7 “implicit (description-matched) invocation”): the single best skill a message DESCRIBES, or None.
list_skills
List every installed skill package the query selects.
load_for_config
The loop’s skill set for a resolved crate::Config — empty unless [core.skills] enabled is on AND the config names a harness whose root table to read, so a config that says nothing about skills discovers nothing (byte-identical to the pre-BP-6 loop).
load_loop_skills
Discover every SKILL.md package the loop will load, in PRECEDENCE order: the config’s own extra roots first (a root a config names is more specific than a discovered one), then the named harness’s own documented root table in its own order, then — for Claude Code — nested <subdir>/.claude/skills packages under cwd, qualified dir:skill.
render_skill
The envelope a loaded body arrives in, identical whichever door invoked it (skill tool result, /name expansion, $slug mention), so a transcript reads the same way in all three.
skill_roots
Every (scope, root) a harness’s own loader would consult, restricted to the roots that exist right now.
writable_skill_roots
The roots supercode may WRITE a skill package into, in the harness’s own precedence order — the same table skill_roots reads, narrowed to the two scopes a client may address and NOT filtered by existence (an install creates the root the harness’s loader would then read).