- Status: Proposed
- Date: 2026-05-11
- Scope:
plugins/ruview(and the repo-root.claude-plugin/marketplace.jsonthat lists it)
RuView (WiFi-DensePose) is a large dual-codebase project (Rust v2/, Python archive/v1/, ESP32 firmware, 96 ADRs). Newcomers and operators repeatedly re-derive the same workflows: spin up the Docker demo, flash and provision an ESP32, run a sensing application, train a pose model, run the witness verification. We want those workflows packaged as a single discoverable Claude Code plugin (and mirrored for Codex), spanning practical → advanced.
-
One mega-plugin, marketplace-listed from the repo root. A single plugin
ruviewunderplugins/ruview/, listed by.claude-plugin/marketplace.jsonat the repo root (marketplace nameruview, pluginsource: "./plugins/ruview"). The manifest sits at the repo root soclaude plugin marketplace add ruvnet/RuView(and/plugin marketplace add ruvnet/RuViewin Claude Code) resolve it — Claude Code looks for.claude-plugin/marketplace.jsonat the cloned repo's root, not in subdirectories. No sub-plugins; the breadth is organized by skill instead. -
Directory contract.
.claude-plugin/marketplace.json # REPO ROOT — marketplace name `ruview`, plugin source ./plugins/ruview plugins/ruview/.claude-plugin/plugin.json # name, description, version, author, homepage, license, keywords — NO skills/commands/agents arrays plugins/ruview/skills/<name>/SKILL.md # frontmatter: name, description, allowed-tools plugins/ruview/commands/<name>.md # frontmatter: description (+ argument-hint) plugins/ruview/agents/<name>.md # frontmatter: name, description, model plugins/ruview/docs/adrs/0001-ruview-plugin-contract.md plugins/ruview/scripts/smoke.sh # structural contract plugins/ruview/codex/AGENTS.md + codex/README.md + codex/prompts/*.md # Codex mirror plugins/ruview/README.md # Compatibility + Namespace coordination + Verification + ADR sectionsSkills/commands/agents are auto-discovered from the directory tree — they are deliberately not enumerated in
plugin.json. -
Shell-first skills. Skills drive RuView's own tooling —
cargo,python,idf.py(via the Windows Python-subprocess pattern inCLAUDE.local.md),docker,nodescripts.allowed-toolsis limited to core tools (Bash Read Write Edit Glob Grep); nomcp__claude-flow__*dependency and no wildcard tools. The only external CLI referenced isnpx @claude-flow/cli@latest security scan, and only as an optional step for security changes. -
Namespace. The plugin claims the
ruview-*namespace for skills (ruview-quickstart,ruview-hardware-setup,ruview-configure,ruview-applications,ruview-model-training,ruview-advanced-sensing,ruview-cli-api,ruview-mmwave,ruview-verify), commands (/ruview-*), and agents (ruview-*). It writes to noclaude-flowmemory namespace. Coexists with theruflomarketplace with zero overlap (ruview-*vs.ruflo-*); if both are present, defer toruflo-agentdbADR-0001 §"Namespace convention". -
Codex mirror — full command parity. Every
/ruview-*command (ruview-start,ruview-flash,ruview-provision,ruview-app,ruview-train,ruview-advanced,ruview-verify) has a matchingcodex/prompts/<name>.md;codex/AGENTS.mdcarries the project rules andcodex/README.mddocuments installation. The mirror covers the operator-facing commands in full; the additional skills (ruview-quickstart,ruview-hardware-setup,ruview-configure,ruview-applications,ruview-model-training,ruview-advanced-sensing,ruview-cli-api,ruview-mmwave,ruview-verify) and agents have no Codex equivalent — their knowledge is folded intoAGENTS.mdand the prompt files. The smoke script enforces command↔prompt parity. -
Compatibility surface. Targets the
ruvnet/RuView/wifi-denseposerepo layout (v2/crates/,firmware/esp32-csi-node/,archive/v1/,scripts/,docs/adr/). Hardware docs default to ESP32 onCOM8and tell the reader to confirm the port. -
Smoke contract (
scripts/smoke.sh, ≥13 checks): repo-root.claude-plugin/marketplace.jsonexists + listsruview+ pointssourceat./plugins/ruview; plugin.json hasname/description/version/keywordsand does not containskills/commands/agentsarrays; everyskills/*/SKILL.mdhasname+description+allowed-tools; no wildcard (*) in anyallowed-tools; the expected skill set is present; everycommands/*.mdhas adescription; everyagents/*.mdhasname+description+model; README contains a## Compatibilitysection and aNamespace coordinationblock; this ADR exists withStatus: Proposed;codex/AGENTS.mdandcodex/prompts/*.mdexist and everycommands/<name>.mdhas a matchingcodex/prompts/<name>.md(command↔prompt parity); nothing is misplaced under.claude-plugin/.
- Good:
/plugin marketplace add ruvnet/RuView+/plugin install ruview@ruview(orclaude --plugin-dir ./plugins/ruviewfrom a clone) gives newcomers and operators the whole RuView workflow surface; no MCP-server prerequisite; Codex users get the same operator commands; the smoke script makes drift visible. - Cost: a mega-plugin means coarser install granularity (you get all 9 skills or none); the Codex mirror must be kept in sync by hand (the smoke script checks command↔prompt presence parity, not content parity); a skill stem (
ruview-verify) collides with a command stem — tolerated by Claude Code (both resolve), butclaude plugin detailslists it twice. - Follow-ups: if the skill set grows past comfortable browsing (it's at 9), revisit the "one mega-plugin" decision and split by lifecycle (
ruview-edge,ruview-train, …); add a content-parity lint between commands and Codex prompts; consider renaming/ruview-verifyto drop the skill/command stem collision; consider pinning a testedclaude-flowCLI minor for the security-scan step if that step becomes load-bearing; verify the underlying RuView command flags (sensing-server --help,gcloud-train.sh,provision.py) against the live tree rather than from README/scripts.