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.
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>scripts/verify-matrix.sh --jsonafterconvert.sh --tool allverification-matrix.example.jsonthat documents the intended shapeSuggested 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:
A minimal first version could smoke only 3–5 representative skills across the officially supported tool outputs, then expand over time.