feat(api_server): enrich /api/skills response for Hermes Workspace UI

[easyvibecoding]

Problem

The /api/skills endpoint in gateway/platforms/api_server.py currently returns only {name, description, category} for each skill, delegating to tools.skills_tool.skills_list().

But the outsourc-e/hermes-workspace UI (as of v1.0.0+) expects a much richer shape for its Skills Browser → Installed tab:

type SkillSummary = {
  id, slug, name, description,
  author, triggers, tags, homepage,
  category, icon, content, fileCount,
  sourcePath, installed, enabled,
  builtin?, security,
}

In particular, the frontend filters by installed === true — since the backend never sets this flag, the Installed tab renders empty ("No skills found") even when 78 skills are actually available locally.

Users hit this as soon as they connect hermes-workspace to a hermes gateway (upstream or this fork), and there's currently no combination of hermes gateway + hermes-workspace in which the Installed tab works out of the box.

Change

This PR enriches the /api/skills handler to return the shape hermes-workspace UI expects. It re-scans SKILL.md frontmatter using existing helpers (_parse_frontmatter, _parse_tags, _get_category_from_path — already exported from tools.skills_tool), so there's no new parsing logic, just a richer mapping.

It also adds stub routes so the Marketplace/install/uninstall buttons don't 404:

• GET /api/skills/hub-search → empty list with explanatory hint (real marketplace would require clawhub CLI, separate change)
• POST /api/skills/install → 501 with message
• POST /api/skills/uninstall → 501 with message

New fields exposed

Each skill in the skills[] array now includes:

Field	Source	Purpose
installed: true	presence in SKILLS_DIR	lets UI's tab=installed filter work
source	"builtin" or "hub" (path-based)	provenance label in UI
trust_level	"builtin" / "verified" / "local"	security badge
tags	frontmatter metadata.hermes.tags + tags	filter chips
triggers	frontmatter triggers	searchable
author	frontmatter author	card subtitle
version, license	frontmatter	metadata display
path	relative to $HOME	details link
identifier	"<source>:<name>"	stable key for install/uninstall
related_skills	frontmatter metadata.hermes.related_skills	cross-linking
repo, homepage, extra	frontmatter	optional

New query params

• ?tab=installed — filters to installed=true (all local skills)
• ?tab=marketplace — returns empty; real marketplace goes through /api/skills/hub-search
• ?q=<term> — free-text search across name / description / tags
• ?limit=N — page size (total count remains in count field)

Back-compat

• Existing callers asking for ?category=X still work (same behavior)
• Existing shape keys (success, skills, categories, count) preserved
• Added tab and hint fields to response (additive, ignored by old clients)
• /api/skills/categories and /api/skills/{name} endpoints untouched

How it was verified

Tested locally on macOS with:

• Fork HEAD: cd742aa8 + this patch
• outsourc-e/hermes-workspace at main (includes Advanced Notion Intelligence (Smart Search & Schema Awareness) NousResearch/hermes-agent#52 Authorization fix)
• Browser: Safari on iOS + desktop Chrome

Before: "No skills found" on Installed tab.
After: 78 skills render with categories, author badges (Hermes Agent, Orchestra Research, etc.), security pills, enable toggle, uninstall button (button returns 501 per stub).

Direct curl:

curl -H "Authorization: Bearer $API_SERVER_KEY" \
  "http://localhost:8642/api/skills?tab=installed&limit=2" | jq
# Returns: total=78, first skill includes installed:true, source, trust_level, tags, author...

Related

• outsourc-e/hermes-workspace#50 (open): "Memory & Skills panels not available — how to connect enhanced Hermes gateway" — this is the server-side half of that story; hermes-workspace#52 (merged) handled the client-side auth header.
• Real clawhub marketplace integration is explicitly out of scope; stubs return clear hints.

Notes

• No tests added — tests/gateway/test_api_server.py (if it exists) would be the right place if you want me to add them in a follow-up.
• I've been running this patch for the past few hours and haven't hit issues, but obviously a second pair of eyes would help.