Skip to content

Emit a machine-readable skills sync manifest for CI/audit #8

Description

@caioribeiroclw-pixel

Portkey's Skills Registry docs describe a nice team workflow: published Prompt Partials are synced into agent-specific skill directories (.claude/skills/, .cursor/skills/, .codex/skills/, etc.), and setup can also configure MCP/gateway pieces.

One small auditability gap: after portkey skills sync --yes --agent ..., a team or CI job has a human-readable success message, but not a durable machine-readable record of what became visible to each agent.

Would you consider adding a JSON sync manifest, either as --json, --manifest <path>, or a sidecar file?

Useful fields could be:

{
  "run_id": "...",
  "generated_at": "2026-06-14T16:00:00Z",
  "source": {
    "workspace": "...",
    "gateway": "https://api.portkey.ai",
    "published_only": true
  },
  "targets": [
    {
      "agent": "claude",
      "scope": "project",
      "skills_dir": ".claude/skills",
      "written": [
        {
          "skill_id": "code-reviewer",
          "name": "code-reviewer",
          "version": "12",
          "path": ".claude/skills/code-reviewer/SKILL.md",
          "content_sha256": "..."
        }
      ],
      "skipped": [
        {
          "skill_id": "security-patterns",
          "reason": "not selected"
        }
      ],
      "errors": []
    }
  ],
  "writes_started": true,
  "restart_required": true
}

Why this seems useful:

  • CI can diff the manifest and fail if a required skill did not sync to a target agent.
  • Teams can review "published in Portkey" vs "visible on disk" without reading local directories manually.
  • It gives a clean boundary between install success and runtime activation. The manifest does not need to prove that an agent later used the skill; it only proves what the sync made available.
  • For security-sensitive skills, the content_sha256 lets teams verify drift without logging the full SKILL.md body.

I noticed --dry-run already previews target paths, so this might be a small extension of the existing planning/writing path rather than a new concept.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions