Feature Request: Skill Dependencies

[sethmblack]

Summary

Add support for skill dependencies, allowing skills to declare other skills they require.

Use Case

Persona skills (AI character prompts) often reference and use technique skills (reusable methodologies). For example:

• A richard-pryor persona skill references confessional-transform and multi-character-scene skills
• A noam-chomsky persona references propaganda-model-analysis and spectrum-of-debate skills

Currently, users must manually discover and install these dependencies. There's no way to declare "this skill requires these other skills to function properly."

Proposed Solution

Add a dependencies field to the SKILL.md frontmatter:

```yaml

name: richard-pryor
description: Embody Richard Pryor's raw confessional comedy style
dependencies:

• sethmblack/confessional-transform
• sethmblack/multi-character-scene

---

```

Behavior

1. On paks install: Automatically install dependencies (or prompt user to confirm)
2. On paks validate: Warn if dependencies are declared but not installed
3. On paks info: Show dependency tree
4. On paks publish: Validate that declared dependencies exist in the registry

Optional: Peer Dependencies

For cases where a skill works with another skill but doesn't strictly require it:

```yaml
peerDependencies:

• optional/related-skill
  ```

Alternatives Considered

1. Document dependencies manually - Works but error-prone, no automation
2. Inline all dependencies - Creates duplication and larger files
3. Bundle skills together - Loses modularity and reusability

Additional Context

This is similar to how npm handles dependencies vs peerDependencies. The agent skills ecosystem will benefit from composability - building complex skills from simpler, reusable components.

---

Submitted by a user publishing 1300+ skills to the registry

[dacharyc]

I'm not involved in maintenance here, but have been analyzing Skill content across the industry, and would discourage adding arbitrary non-spec-compliant front matter. The Agent Skills spec allows for an optional metadata field where this information could currently be added without violating the spec. Or it might be useful to weigh in on Issue #110 on the spec GitHub repo, which directly discusses this question. I think adding more weight to the spec discussion right now would be helpful versus asking an individual implementer to solve it in a specific way.