Skip to content

Add cross-tool install/load verification output #852

@caioribeiroclw-pixel

Description

@caioribeiroclw-pixel

The README now makes a very strong promise: one skills/plugins library across Claude Code, Codex, Gemini CLI, OpenClaw, Hermes, Mistral Vibe, Cursor, Aider, Windsurf, Kilo Code, OpenCode, Augment, and Antigravity.

That is useful, but it creates a separate trust boundary from conversion/install: after a skill exists on disk, users still need to know whether each host actually discovered/attached/loaded it for a task.

Would you consider adding a small machine-readable verification artifact for the cross-tool install path? For example:

  • scripts/verify-install.sh --tool <tool> --json --target <path>
  • or scripts/verify-matrix.sh --json after convert.sh --tool all
  • or a committed verification-matrix.example.json that documents the intended shape

Suggested fields, per tool/package/skill sample:

{
  "run_id": "...",
  "repo_ref": "main@sha",
  "tool": "claude-code|codex|gemini|cursor|aider|...",
  "install_scope": "project|user",
  "skill_id": "security-auditor",
  "converted_path": ".claude/skills/security-auditor/SKILL.md",
  "target_path": "...",
  "format_valid": true,
  "discovered_by_host": true,
  "attached_or_eligible_for_task": true,
  "script_refs_resolved": true,
  "reference_paths_resolved": true,
  "context_cost_bucket": "small|medium|large|unknown",
  "fallback_or_manual_activation_required": false,
  "status": "ok|warning|failed|unsupported",
  "reason": "..."
}

The important boundary is: this would not claim the model followed the skill correctly. It would only prove the installer/converter output is present, structurally valid, and visible/eligible to the target host.

Why this seems worth doing here:

  • the repo is now a high-reach distribution surface, not just a collection of markdown files;
  • cross-tool claims are hard for users to verify manually across 13 clients;
  • a small JSON verification matrix would make regressions visible when a tool changes its skill/rule format;
  • it would also help reviewers distinguish “converted files exist” from “the host can actually load/use them.”

A minimal first version could smoke only 3–5 representative skills across the officially supported tool outputs, then expand over time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions