agentleFS
B-M-Capital-ResearchB-M-Capital-Research/honeclaw/skills/skill_manager/SKILL.md

Skill Management

Skill748 starsChanged 3 months agoMITView on GitHub

Design, inspect, create, update, and validate Hone skills, including Codex-native discovery through workspace .agents/skills and compatibility with legacy Hone runners.

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 7 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not copy skill bodies into each Codex user turn and do not call Hone MCP skill-loading tools merely to activate a skill.

    line 21
  2. Distinctive:

    Prefer this frontmatter schema:

    line 26
  3. Distinctive:

    Keep the Markdown body task-oriented and ready to inject as prompt text.

    line 55
  4. Distinctive:

    Use the native skill list already supplied by Codex.

    line 61
  5. Very specific:

    Read the selected skill's SKILL.md from its disclosed path.

    line 63
  6. Distinctive:

    Read bundled scripts or references only when the task needs them.

    line 64
  7. Very specific:

    Use discover_skills(query="...") to select the skill.

    line 68
  8. Very specific:

    Use skill_tool(skill_name="<skill id>") to load its full prompt.

    line 69
  9. Very specific:

    Write or update the source SKILL.md.

    line 74
  10. Distinctive:

    Keep the body concrete: trigger rules, required steps, tool usage expectations, and refusal/verification constraints.

    line 75
  11. Very specific:

    Do not teach the deprecated skill_tool(action="add" | "update" | "remove") CRUD workflow.

    line 82
  12. Very specific:

    Do not rely on load_skill as the main user-facing path.

    line 83
  13. Distinctive:

    If a skill is path-gated, mention that it may stay hidden until matching files are involved.

    line 84
  14. Very specific:

    If runtime enforcement is not implemented for a field such as hooks or strict tool scoping, say so plainly instead of pretending it is …

    line 85

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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 Management (skill_manager)

Manage the source skill, not a generated projection of it.

Runtime Contract

  1. Built-in sources live in skills/<id>/SKILL.md; custom sources live in data/custom_skills/<id>/SKILL.md; legacy project-local sources may live in a closer .hone/skills/<id>/SKILL.md.
  2. Trusted persistent Codex ACP workspaces expose enabled Hone skills as individual symlinks under <actor workspace>/.agents/skills/.
  3. Codex performs native progressive disclosure: it starts with each skill's name, description, and path, then reads the complete SKILL.md only when the task activates that skill.
  4. Do not copy skill bodies into each Codex user turn and do not call Hone MCP skill-loading tools merely to activate a skill.
  5. Non-Codex and strict legacy runners retain Hone's discover_skills / skill_tool bridge. load_skill remains a compatibility shim only.

Frontmatter Contract

Prefer this frontmatter schema:

---
name: Human readable name
description: One-line description
when_to_use: Brief trigger guidance
allowed-tools:
  - skill_tool
user-invocable: true
model: optional model override
effort: optional effort override
context: inline
agent: optional agent hint
paths:
  - src/**/*.rs
hooks: {}
arguments: []
script: optional default script path like scripts/run.sh
shell: optional shell hint
---

Notes:

  • allowed-tools replaces legacy tools as the main runtime field.
  • context should usually be inline; use fork only when the skill should run in an isolated child runner.
  • paths hides the skill from the default listing until the active task touches matching files.
  • script declares the default executable entrypoint inside the skill directory. Native Codex may run a trusted bundled script directly; legacy Hone runners may use skill_tool(..., execute_script=true).
  • Keep the Markdown body task-oriented and ready to inject as prompt text.

How To Inspect Skills

On native Codex:

  1. Use the native skill list already supplied by Codex.
  2. Match from name and description.
  3. Read the selected skill's SKILL.md from its disclosed path.
  4. Read bundled scripts or references only when the task needs them.

On a legacy Hone runner without native skill discovery:

  1. Use discover_skills(query="...") to select the skill.
  2. Use skill_tool(skill_name="<skill id>") to load its full prompt.

How To Create Or Update Skills

  1. Collect the intended skill id, description, trigger conditions, and whether users should be able to invoke it directly with /<skill-name>.
  2. Write or update the source SKILL.md; never edit the actor-workspace symlink as if it were an independent copy.
  3. Keep the body concrete: trigger rules, required steps, tool usage expectations, and refusal/verification constraints.
  4. Validate native discovery with Codex skills/list or a real Codex ACP turn. Validate the legacy bridge separately only when that runner remains in scope.

Strict Rules

  • On native Codex, do not call discover_skills, load_skill, or skill_tool just to discover or load a skill.
  • Preserve actor-owned entries in .agents/skills; Hone only owns its hone__* links.
  • Do not teach the deprecated skill_tool(action="add" | "update" | "remove") CRUD workflow.
  • Do not rely on load_skill as the main user-facing path.
  • If a skill is path-gated, mention that it may stay hidden until matching files are involved.
  • If runtime enforcement is not implemented for a field such as hooks or strict tool scoping, say so plainly instead of pretending it is active.

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.