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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions