Problem
System skills (skills in .system/) are only loaded implicitly via topic detection in the skill-hint block. They cannot be invoked directly via /skill-name and have no mechanism for declaring dependencies on other skills.
This creates two gaps:
-
No explicit access — The user cannot type /netclaw-operations to reference the ops manual, or /netclaw-memory to understand memory behavior. These are invisible unless topic detection happens to fire.
-
No transitive loading — When a skill is loaded, it cannot declare that it also needs other skills. This means context is silently missed when working on compound tasks.
Examples Where This Matters
Example 1: Subagent authoring
When the user starts creating a subagent, subagent-authoring loads. But subagent creation touches audience gating, approval scoping, and daemon configuration — all documented in netclaw-operations. Without transitive loading, the agent may miss critical context about how approvals and audience policies affect subagents.
Ideal behavior: subagent-authoring declares requires: [netclaw-operations] and both load.
Example 2: Skill authoring
When creating a new skill, skill-authoring loads. But the skill may need to understand how skills are discovered, how external sources work, or how MCP tool routing interacts with skills — all in netclaw-operations/skills.md.
Ideal behavior: skill-authoring declares requires: [netclaw-operations] and both load.
Example 3: Memory troubleshooting
When debugging memory issues, netclaw-memory loads. But the user may also need diagnostics info from netclaw-operations/diagnostics.md to check embedding status, daemon health, or audience gating.
Ideal behavior: netclaw-memory declares requires: [netclaw-operations] for the diagnostics reference.
Example 4: Explicit reference
The user types /netclaw-operations to review how scheduling works before setting up a reminder. Currently this is a no-op because system skills are not slash-invokable.
Ideal behavior: The skill loads and the agent summarizes the relevant section.
Proposed Solution
1. Make system skills discoverable and invokable
Allow skills in .system/ to appear in slash command completion and be invocable via /skill-name. This gives explicit access to foundational documentation.
2. Add skill dependency metadata
Support a metadata.requires field in skill frontmatter:
---
name: subagent-authoring
description: "How to create and troubleshoot file-defined subagents..."
metadata:
requires:
- netclaw-operations
author: netclaw
version: "1.3.2"
---When a skill loads, the daemon automatically loads all requires dependencies first (cycle detection included). Dependencies are loaded in topological order.
3. (Optional) Make dependencies transitive
If skill A requires skill B, and skill B requires skill C, loading A loads B and C. This keeps the dependency graph simple — each skill only declares its direct needs.
Implementation Notes
- Cycle detection: Reject circular dependencies at load time with a clear error.
- Performance: Dependencies load once per session and are cached. No repeated fetches.
- Backwards compatibility: Skills without
requires work exactly as today. This is purely additive.
- System vs user skills: The same mechanism applies to both — a user skill can require a system skill and vice versa.
Why This Matters
Right now the agent has to "guess" which system skills are relevant to a task. If it forgets to load one, it works with incomplete context. Explicit dependencies make the knowledge graph deterministic and auditable — the user can see exactly what context the agent is working with and why.
Problem
System skills (skills in
.system/) are only loaded implicitly via topic detection in theskill-hintblock. They cannot be invoked directly via/skill-nameand have no mechanism for declaring dependencies on other skills.This creates two gaps:
No explicit access — The user cannot type
/netclaw-operationsto reference the ops manual, or/netclaw-memoryto understand memory behavior. These are invisible unless topic detection happens to fire.No transitive loading — When a skill is loaded, it cannot declare that it also needs other skills. This means context is silently missed when working on compound tasks.
Examples Where This Matters
Example 1: Subagent authoring
When the user starts creating a subagent,
subagent-authoringloads. But subagent creation touches audience gating, approval scoping, and daemon configuration — all documented innetclaw-operations. Without transitive loading, the agent may miss critical context about how approvals and audience policies affect subagents.Ideal behavior:
subagent-authoringdeclaresrequires: [netclaw-operations]and both load.Example 2: Skill authoring
When creating a new skill,
skill-authoringloads. But the skill may need to understand how skills are discovered, how external sources work, or how MCP tool routing interacts with skills — all innetclaw-operations/skills.md.Ideal behavior:
skill-authoringdeclaresrequires: [netclaw-operations]and both load.Example 3: Memory troubleshooting
When debugging memory issues,
netclaw-memoryloads. But the user may also need diagnostics info fromnetclaw-operations/diagnostics.mdto check embedding status, daemon health, or audience gating.Ideal behavior:
netclaw-memorydeclaresrequires: [netclaw-operations]for the diagnostics reference.Example 4: Explicit reference
The user types
/netclaw-operationsto review how scheduling works before setting up a reminder. Currently this is a no-op because system skills are not slash-invokable.Ideal behavior: The skill loads and the agent summarizes the relevant section.
Proposed Solution
1. Make system skills discoverable and invokable
Allow skills in
.system/to appear in slash command completion and be invocable via/skill-name. This gives explicit access to foundational documentation.2. Add skill dependency metadata
Support a
metadata.requiresfield in skill frontmatter:When a skill loads, the daemon automatically loads all
requiresdependencies first (cycle detection included). Dependencies are loaded in topological order.3. (Optional) Make dependencies transitive
If skill A requires skill B, and skill B requires skill C, loading A loads B and C. This keeps the dependency graph simple — each skill only declares its direct needs.
Implementation Notes
requireswork exactly as today. This is purely additive.Why This Matters
Right now the agent has to "guess" which system skills are relevant to a task. If it forgets to load one, it works with incomplete context. Explicit dependencies make the knowledge graph deterministic and auditable — the user can see exactly what context the agent is working with and why.