Explore capture and portability for agent tools and skills

Goal

Investigate whether Context Service should manage agent-generated tools and skills in addition to state, memory, knowledge, workspaces, and artifacts.

Agent harnesses increasingly create reusable scripts, tools, skills, plugins, and related configuration while users work. These capabilities may be valuable beyond one laptop or session. Context Service could potentially capture them locally and provide the same revisioning, lineage, synchronization, backup, access, and lifecycle features already used for context.

This is exploratory work. The outcome may be a prototype, a narrower transport feature, integration with another system, or a decision that executable capabilities do not belong in Context Service.

Questions to answer

• What counts as a tool or skill across Claude Code, Codex, OpenCode, and Pi?
• Which assets are project-local, user-global, generated, installed, or externally managed?
• Should tools and skills become new Context Service types, artifact subtypes, or references to another registry?
• Can contextctl discover generated capabilities without capturing unrelated personal configuration?
• What metadata is required for dependencies, harness compatibility, runtime requirements, and installation paths?
• How should local capture, export/import, PVC sync, S3 sync, background backup, revisions, and lineage apply?
• How are conflicts handled when restoring into a machine or cloud runtime that already has a tool or skill?
• How do we prevent secrets, credentials, unsafe code, or untrusted instructions from being captured and executed?
• What provenance, review, signing, policy, or user confirmation is required before installation or activation?

Investigation

1. Inventory the tool and skill formats and storage locations used by the supported harnesses.
2. Select one simple project-local example and one harness-specific example.
3. Prototype discovery and packaging without automatically activating executable content.
4. Sync the package from a local harness to S3 or a Context Service PVC.
5. Restore it into a clean local or cloud environment and verify its contents and dependencies.
6. Compare this approach with established package, plugin, artifact, and OCI registries.

Desired UX to explore

The exact commands are not decided, but evaluate whether a flow this simple is possible:

contextctl capability capture
contextctl capability list
contextctl capability sync push NAME
contextctl capability restore NAME

Command names and resource types should follow from the investigation rather than being assumed.

Deliverables

• A short inventory of harness formats and portability constraints.
• A threat and trust-boundary analysis for executable assets.
• A small proof of concept if a safe representative workflow is viable.
• A recommendation: add first-class support, reuse artifacts, integrate with another registry, or do not pursue.
• Follow-up implementation issues only after the design is validated.

Acceptance criteria

• The distinction between context data and executable capabilities is explicit.
• At least one realistic local-to-remote-to-clean-environment workflow is evaluated.
• Security, dependency, compatibility, and ownership risks are documented.
• A clear go/no-go and proposed resource model are recorded.

Start at the contextctl entry point and inventory tool and skill formats and storage locations for Claude Code, Codex, OpenCode, and Pi. Select one project-local and one harness-specific example, then evaluate discovery, packaging, S3 or Context Service PVC sync, and restoration into a clean environment without activation. Document portability, dependencies, trust boundaries, and a clear go/no-go recommendation.