rolecraft-sh/rolecraft

Part 3 of 4 — single-source-of-truth registry refactor Evidence: #251. Parts so far: #253 (completions), #254 (registry merge). This issue fixes the dead doc-generation pipeline. Problem scripts/generate-readme.js was introduced in #188 with a token system ({{AGENT_COUNT}}, {{VERIFIED_COUNT}}, {{PACKAGE_SIZE}}, ...). But the same PR committed the files with tokens already resolved to literals. Today: grep -r '{{' README.md docs/comparison.md benchmark/RESULTS.md → 0 matches The generator reads each file as its own template, finds no tokens, and writes the file back unchanged — a no-op The "sync" tests in src/agents/manifest.test.js (README.md matches generated content from manifest tokens) therefore compare a file against a token-replacement of itself and can never fail Net effect: when the agent count changed 86 → 87 in #251, ~11 documentation files had to be hand-edited, which is exactly what #188 was built to prevent. Suggested approach Re-introduce {{AGENT_COUNT}}, {{VER

Part 2 of 4 — single-source-of-truth registry refactor Evidence for the cost of the current split: #251 (adding one agent touched 18 files). Part 1: #253 (completions). This issue merges the two data sources. Problem Today an agent's data lives in two files that must be kept consistent by hand: File Holds Keyed by src/agents.js (AGENTS_DATA) flag, name, skill dir resolver, label array entry src/agents/manifest.js (MANIFEST_DATA) support level, MCP format/path, instruction format, docUrl, lastVerified, notes, aliasFor agent name manifest.js already imports and iterates AGENTS_DATA, so nothing conceptually separates them — it is purely a historical split. Consequences: Adding/verifying an agent means editing both files with matching keys; a typo in the name key silently falls back to EXPERIMENTAL defaults (there is no cross-validation) MCP_SUPPORTED is a third place listing flags, duplicating what MANIFEST_DATA[*].mcpSupport.supported already expresses The manifest fallb

Part 1 of 4 — single-source-of-truth registry refactor Adding oh-my-pi (omp) support in #251 required touching 18 files for what is conceptually one data row. This issue is the first, lowest-risk step of eliminating that duplication. Companion issues cover the registry merge, the token pipeline, and doc count literals (links added as they are filed). Problem src/commands/completions.js hardcodes every agent flag in three places: SCOPE_FLAGS array (~87 entries) used by the bash completion The zsh script template: one '--flag[Also install to <dir>]' \\ line per agent The fish script template: one complete ... -l flag -d 'Install to <dir>' line per agent Every new agent requires editing all of these by hand. In #251 we added omp and had to touch zsh + fish blocks manually; bash got the flag automatically via SCOPE_FLAGS (also manual). Meanwhile bin/rolecraft.js already derives flags dynamically: agents.map((a) => `--${a.flag}`) // help text so the CLI itself does NOT need edits when a

Problem rolecraft remove <skill> only deletes the skill from ~/.agents/skills/ and ./.agents/skills/, regardless of which agent directories the skill was actually installed to. When a skill is installed with a per-agent flag (--claude, --pi, --omp, --cursor, ...), the lockfile entry is removed but the files stay on disk in that agent's skills directory. Steps to reproduce # 1. Install a skill targeting omp rolecraft install ./my-skill --omp ls ~/.omp/agent/skills/my-skill # exists ✓ # 2. Remove it rolecraft remove my-skill # reports success # 3. Files are still there ls ~/.omp/agent/skills/my-skill # still exists ✗ Same happens with any non-default target: --pi (~/.pi/agent/skills/), --claude (~/.claude/skills/), --tabnine (~/.tabnine/agent/skills/), etc. Expected behavior After remove, every directory recorded for the skill in the lockfile should be cleaned up. The lockfile already stores the target flags per skill: { "my-skill": { "agents": ["omp"], ...

Summary The public completionApi from src/api/completions.js has zero test coverage. The existing test file src/commands/completions.test.js only exercises the CLI wrapper (completionsCommand), which keeps its own duplicate copy of the shell scripts. Since src/api/completions.js and src/commands/completions.js each maintain separate bash/zsh/fish templates, they can silently drift apart — the API is exported publicly via src/index.js:50 (completionApi as completions) but nothing verifies its output. Location src/api/completions.js — completionApi (line 266), bashScript (136), zshScript (186), fishScript (239) src/index.js:50 — public export: export { completionApi as completions } src/commands/completions.js — duplicate script templates used by the CLI wrapper Expected behavior completionApi(bash | zsh | fish) returns a script for each supported shell (mirroring the assertions in src/commands/completions.test.js) completionApi(tcsh) rejects with Unknown shell (matching the C