Does the skills have "progressive disclosure" for context management?

[TomLucidor]

A lot of skill-packs use flat structures, and that often is not helpful. There could be taxonomy that reduces the load.

[adunn08]

Good question, and yes, by construction rather than by folder taxonomy. The context load works in three tiers:

1. Trigger tier: until a skill fires, the only thing in context is its frontmatter description. We treat the 1024-character description limit as a hard budget and recently did a pass sharpening descriptions into explicit firing conditions and boundary clauses (which skill yields to which sibling), so the always-loaded surface stays small and precise.

2. Instruction tier: a skill's SKILL.md body loads only when it fires.

3. Reference tier: the heavy material (checklists, templates, matrices; there are around 490 reference files across the 103 skills) lives in per-skill reference files that load only when the instructions send the agent to them.

So the flat directory layout you are seeing is deliberate and orthogonal to context. Directories never load, descriptions do.

Where taxonomy does help is install surface, and that exists too. The subset repos (starter, seo, pm) are curated slices for anyone who does not want the full catalog installed.

Does that make sense?

[TomLucidor]

Here is my other Q: Can instruction become more granular and split between multiple skills that will reference each other? Or vague superskills usually made to have convoluted instructions being reducible to precise subskills with shorter delegation/subagent-ready instructions? If this is already done, what are the methods to coining/synthesizing other skills? https://github.com/aplaceforallmystuff/claude-agent-borg
The whole context-optimized SLM agents are getting mainstream now https://github.com/itayinbarr/little-coder

[adunn08]

Yes to the split. The skills never include or reference each other's bodies. A skill that loads another skill creates a load chain, and load chains defeat the tier model. Every skill stays independently loadable, which is also what makes one subagent-ready.

Composition happens one level up from the skill. Sibling collisions are handled at the trigger tier with boundary clauses in the descriptions (this skill defers to X when the task is Y). Multi-skill jobs are handled by the workflows tier.

Not sure about superskills. I use multiple skills to make a cogent workflow.

[TomLucidor]

Not sure about superskills. I use multiple skills to make a cogent workflow.

More like hierarchical indexing + disambiguation tactics to pick the right skills. And maybe workflow-as-skill (or workflow-plan-as-skill) thinking as an idea to sub-select skills to reduce context bloat similar to what people tried to do with subagents. Oh-My-Openagent has standardized subagents but MCP and skill bloat are still hard to manage

[adunn08]

Workflow-as-skill is roughly what the workflows tier is. A workflow ships in the same shape as a skill (a description that fires, a body that loads on fire). The body names the member skills, and each fires by its own trigger when its step arrives.

On hierarchical indexing, the descriptions are the index, one level deep on purpose. Disambiguation happens at selection time without loading any bodies. The bloat control today is install surface rather than hierarchy, which is what the subset repos are for.

Which skills are you most interested in? Would a new subset repo work for you? Let me know.