sylo-skill-author

name	sylo-skill-author
description	Meta-skill to scaffold a new Pi Agent Skill with Sylo-friendly frontmatter and optional widget or route surfaces.
metadata	{"sylo":{"category":"authoring","icon":"edit"}}

Skill author (Sylo)

When invoked:

1. Interview (required) — Before creating files:

   • Transient widget vs persistent route: Does the operator need UI the agent opens mid-turn (widget, Discussion #317 — show_widget) or UI the operator opens from the sidebar any time route?
   • If route, which nav_section should the sidebar use: domain, tools, library, or dev? (Default mentally: domain for everyday product surfaces; tools for utilities; library for references; dev for authoring/diagnostics-aligned panels. Unknown strings fall back to domain per host.)

2. Copy templates — do not hand-roll from memory

   Canonical scaffolds live in @sylo/skill-builder:

   Surface	Template path
   Widget	Copy templates/widgets/starter/ into the skill tree as assets/widgets/<widget-id>/ (replace <widget-id> with a kebab-case name that matches widgets: in SKILL.md).
   Route	Copy templates/routes/starter/ into the skill tree as routes/<route-id>/ (same id as the routes: item entry in frontmatter).

   After copy: rename starter placeholders — set manifest.json id to the real widget/route id (must match folder + frontmatter).

3. Write SKILL.md under ~/.pi/agent/skills/<skill-name>/ (or project .pi/skills/) including YAML frontmatter:

   • name, description, optional metadata.sylo (category, icon, …).
   • If using a widget: top-level widgets: listing each widget folder id + widget_protocol_version: 1.
   • If using a route: top-level routes: (each item has id, title, nav_section as chosen, entry, fallback, required_capabilities as needed) + route_protocol_version: 0.

   Every widget directory must keep fallback.md; every route directory must keep fallback.md (Sylo refusal rule).

4. Offer params.schema.json / metadata.sylo.paramsSchema only when the skill needs operator-editable configuration (unchanged convention).

5. Surface styling: Use classes from @sylo/skill-builder assets/sylo-surface.css (sylo-surface-lead, sylo-surface-btn, …). Sylo injects this CSS into iframes; starter templates already use it.

6. Companion-ready UI (phone): Sylo can expose skill routes on a phone via the desktop Companion server (Settings → Companion). Skill route HTML should:

   • Include <meta name="viewport" content="width=device-width, initial-scale=1" /> (starter templates do).
   • Use responsive layout (stack on narrow widths, touch-friendly controls).
   • Test at ~390px width, not only desktop sidebar width.
   • Reuse one HTML surface for desktop iframe + phone iframe unless the operator explicitly needs a separate mobile layout.

After writing, remind the operator to /reload (and restart the host when route discovery caches apply).

For brownfield attach (operator already has a folder / HTML UI), prefer /skill:sylo-attach-ui instead of this skill.