Problem

feeds/skills/.system/files/netclaw-operations/SKILL.md has grown past
the "single-file useful for an agent's working set" threshold. Current
sections: Route by Intent, Project Directory, Scheduling, Background
Jobs, Tool Discovery, Approval Prompts, Skill Management, Webhook
Management, Inbound Attachments, LLM Providers (new in #1075),
Search Providers, Diagnostics, Feature Kill Switches, Identity,
Self-Maintenance, Device Pairing. That's ~850 lines and growing every
time we add a feature area.

The whole point of skills is "load only the operational guidance the
agent needs right now." A monolithic SKILL.md defeats that.

What the skill feed actually supports

SystemSkillSyncService.cs:217-262 reads entry.Files from the
manifest and downloads sibling files alongside SKILL.md. So
multi-file skills are already a supported feed shape — what we don't
have today is:

1. A convention for how SKILL.md references siblings (markdown link?
   YAML frontmatter pointer?).
2. Runtime logic that surfaces sibling files to the agent lazily (load
   provider-types.md only when the user intent matches the LLM
   Providers row), rather than all-up-front.

Proposed split

Reorganize netclaw-operations/ from:

netclaw-operations/SKILL.md   (everything)

to:

netclaw-operations/SKILL.md             (Route by Intent + cross-cutting)
netclaw-operations/providers.md         (LLM Providers, Search Providers)
netclaw-operations/scheduling.md        (Scheduling, Background Jobs)
netclaw-operations/diagnostics.md       (Diagnostics, Feature Kill Switches)
netclaw-operations/skills.md            (Skill Management)
netclaw-operations/identity.md          (Identity, Self-Maintenance)
netclaw-operations/devices.md           (Device Pairing)
netclaw-operations/approvals.md         (Approval Prompts)
netclaw-operations/webhooks.md          (Webhook Management, Inbound Attachments)
netclaw-operations/tools.md             (Tool Discovery)

SKILL.md keeps the Route by Intent table but each row links to the
sibling file instead of an anchor on the same page.

Open questions

• How does the runtime decide which sibling to load? Match the user
  intent against the route-by-intent row, then fetch only that sibling?
• Do we need a subskills: field in the YAML frontmatter, or is
  scanning SKILL.md's links sufficient?
• How does the manifest publishing pipeline (generate-skill-manifest.sh,
  CI release workflow) need to change to emit entry.Files?

Why this is worth doing

The agent's context window is finite and shared with the current
session's actual work. Loading 850 lines of operational text to answer
"how do I add an LLM provider?" wastes ~5K tokens of the working set on
content that's irrelevant to that question. Progressive disclosure
restores the linear cost-per-feature-area property that skills are
supposed to have.

Not in scope

This issue tracks netclaw-operations specifically. Other skills
(netclaw-memory, netclaw-projects, search-citation, etc.) are
small enough that they don't need the same treatment yet.

Surfaced by

PR #1075 (GitHub Copilot provider) — adding the LLM Providers section
pushed the file past 850 lines and made the size-vs-utility tradeoff
visible.