Question: Skill Loading Strategy in the claude-code Adapter
Hi, I've been studying the gitagent codebase in detail and noticed an interesting design tension worth discussing.
What I observed
skill-loader.ts already implements a clean two-tier progressive disclosure pattern:
loadSkillMetadata() — lightweight, ~100 tokens, returns only name + description from the YAML frontmatter
-
loadSkillFull() / loadAllSkills() — full parse, returns frontmatter + complete Markdown instructions body
The gitagent skills list command correctly uses the lightweight path via discoverSkills(). The openclaw adapter also takes a different approach — passing through raw SKILL.md files as standalone workspace files, letting the OpenClaw runtime handle them natively.
However, the claude-code adapter calls loadAllSkills(), eagerly inlining every skill's full instruction body directly into CLAUDE.md.
My question
Was this a deliberate trade-off, or a placeholder for a future improvement?
I'm curious about the reasoning behind not adopting one of these alternatives for the claude-code adapter:
- Metadata-only initial load — Inline only
name, description, and allowed-tools from each skill's frontmatter into CLAUDE.md, then let Claude read the full SKILL.md file on-demand when it needs to execute that capability. This mirrors how knowledge/ already works with always_load.
- File passthrough — Instead of inlining skill content at all, reference the skill files by path (e.g.,
@skills/code-review/SKILL.md) and rely on Claude Code's native file-reading capability to pull them in when needed.
Why this matters
With agents that have many skills, eager full-text inlining could significantly inflate the context window on every invocation — even for skills that are rarely or never triggered. The progressive disclosure infrastructure is already built; it just isn't wired up to the export path.
Is there a plan to align the claude-code (and system-prompt) adapters with a smarter loading strategy?
Question: Skill Loading Strategy in the
claude-codeAdapterHi, I've been studying the gitagent codebase in detail and noticed an interesting design tension worth discussing.
What I observed
skill-loader.tsalready implements a clean two-tier progressive disclosure pattern:loadSkillMetadata()— lightweight, ~100 tokens, returns onlyname+descriptionfrom the YAML frontmatterloadSkillFull()/loadAllSkills()— full parse, returns frontmatter + complete Markdown instructions bodyThe
gitagent skills listcommand correctly uses the lightweight path viadiscoverSkills(). Theopenclawadapter also takes a different approach — passing through rawSKILL.mdfiles as standalone workspace files, letting the OpenClaw runtime handle them natively.However, the
claude-codeadapter callsloadAllSkills(), eagerly inlining every skill's full instruction body directly intoCLAUDE.md.My question
Was this a deliberate trade-off, or a placeholder for a future improvement?
I'm curious about the reasoning behind not adopting one of these alternatives for the
claude-codeadapter:name,description, andallowed-toolsfrom each skill's frontmatter intoCLAUDE.md, then let Claude read the fullSKILL.mdfile on-demand when it needs to execute that capability. This mirrors howknowledge/already works withalways_load.@skills/code-review/SKILL.md) and rely on Claude Code's native file-reading capability to pull them in when needed.Why this matters
With agents that have many skills, eager full-text inlining could significantly inflate the context window on every invocation — even for skills that are rarely or never triggered. The progressive disclosure infrastructure is already built; it just isn't wired up to the export path.
Is there a plan to align the
claude-code(andsystem-prompt) adapters with a smarter loading strategy?