feat(server): inject remote OpenWork Connect skills

[reachjalil]

Summary

• move remote-skill discovery prompt ownership into OpenWork Server
• expose the authenticated member's authorized skill catalog from Den as MCP resources at skill://index.json and skill://<name>/SKILL.md
• have OpenWork Server fetch, validate, cache, bound, and render the catalog into an Agent Skills-compatible <available_skills> discovery block
• keep the OpenCode plugin as a narrow engine adapter that only injects the server-produced instruction
• keep full skill bodies out of the system prompt; agents retrieve a selected body through the existing openwork-cloud_execute_capability / skill:<id> contract
• preserve the /mcp/agent surface at exactly two model-facing tools

Architecture

Den authorization + skill storage
  -> authenticated MCP skill resources
OpenWork Server
  -> normalized remote-skill catalog
  -> bounded discovery system instruction
Engine adapter (OpenCode plugin today)
  -> injects the OpenWork-owned instruction
Agent
  -> retrieves the selected SKILL.md with execute_capability

This keeps product behavior in OpenWork Server and confines engine-specific code to the adapter. A replacement engine can consume the same server endpoint without depending on OpenCode's treatment of MCP initialization instructions.

Agent Skills and skill://index.json

This PR builds on two stable foundations:

1. Agent Skills defines the SKILL.md format and progressive-disclosure lifecycle: expose name and description for discovery, then load the full SKILL.md only after the agent selects a relevant skill.
2. MCP Resources provide the authenticated remote transport and resources/read operation.

skill://index.json is an experimental Skills-over-MCP discovery convention layered on those foundations. It is being explored by the MCP Skills Over MCP Working Group, whose repository explicitly says that the work is exploratory and is not yet an official MCP specification or recommendation. This PR therefore treats the URI and discovery document as a versioned interoperability layer, not as a finalized universal standard.

Den publishes an authenticated index shaped like:

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "customer-briefing",
      "type": "skill-md",
      "description": "Prepare a customer briefing before meetings.",
      "url": "skill://customer-briefing/SKILL.md",
      "capability": "skill:skill_01..."
    }
  ]
}

The intended exchange is:

MCP initialize
  -> resources/read("skill://index.json")
  -> disclose only name + description to the model
  -> model selects a matching skill
  -> load the selected SKILL.md on demand

Each normalized SKILL.md is available as an MCP resource for compatible clients. OpenWork also includes the capability field as an extension to the discovery entry. Generic consumers can ignore that unknown field and use the url resource; OpenWork agents use it with the existing openwork-cloud_execute_capability transport. That preserves tenant-aware authorization, errors, policy enforcement, and the existing two-tool model-facing surface.

The <available_skills> XML is the server-rendered model disclosure format, not part of the MCP wire contract. Agent Skills guidance permits XML, JSON, or another structured catalog representation; the important invariant is progressive disclosure rather than one mandatory prompt syntax.

Validation

• pnpm --filter openwork-server typecheck — passed
• pnpm --dir ee/apps/den-api exec tsc -p tsconfig.json --noEmit — passed
• pnpm --filter openwork-server test -- src/connect-skill-catalog.test.ts src/opencode-plugins/openwork-extensions-preview.test.ts — 11 passed, 0 failed
• pnpm --dir ee/apps/den-api exec bun test test/mcp-agent-timeouts.test.ts — 13 passed, 0 failed
• pnpm --filter openwork-server build — passed
• pnpm --dir ee/apps/den-api build — passed
• GitHub Actions: OpenWork tests on Linux and macOS, Den API/web/inference builds, Helm validation, and i18n audit all passed
• rebased onto current upstream/dev (6bee537e7)

Focused tests cover authenticated MCP initialization and resources/read, index validation, prompt escaping and bounds, capability retrieval guidance, engine-adapter injection, unchanged initialize instructions, and the two-tool annotations/contracts.

Security and compatibility

• Den remains authoritative for organization, membership, sharing, and skill-hub access
• resources are registered only after the existing MCP authentication and active-membership checks
• metadata is schema-validated, normalized, escaped, and bounded before entering system context
• the prompt explicitly treats remote skill bodies as untrusted content subordinate to system and user instructions
• full skill bodies and credentials do not enter the discovery prompt
• malformed, unavailable, or unsupported catalogs fail closed to no injected skill catalog
• the server cache is scoped by workspace and a hash of the complete runtime MCP config, so token/config rotation invalidates it
• if the experimental remote-discovery convention changes, Den's resource adapter can evolve without changing OpenWork's normalized server catalog or agent-facing capability contract

Remaining gaps

• no live production OAuth provider was used
• no desktop UI evidence was produced because this has no UI surface
• the three Vercel fork statuses require Different AI team authorization and are not code failures

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 22, 2026 6:42am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
openwork-diagnostics	Skipped		Jul 22, 2026 6:42am

[vercel]

@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[benjaminshafii]

I think this should be done on openwork server part.

[reachjalil]

@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

yep I agree reviewing now

[reachjalil]

Agreed — I reworked this so OpenWork Server owns the remote-skill catalog and system-prompt behavior. Den now only exposes the authorized catalog as authenticated MCP resources, and the OpenCode plugin is a narrow adapter that injects the server-rendered instruction. The branch is rebased and the PR description includes the updated architecture and validation.