{"slug":"architect-12","title":"architect","summary":"Entry-point skill for designing robotics applications with AI agents. Turns requirements (robot type, task, hardware, sim-vs-real, GPU/budget) into a full stack decision — middleware, simulation, data, visualization, training frameworks — plus a scaffold plan and a written archit","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-09-20T17:07:57.463573Z","repo":{"url":"https://github.com/robium-ai/robium","stars":14,"forks":0,"license":"MIT","updatedAt":"2026-09-19T21:00:59Z"},"bodyHtml":"<hr>\n<h2>name: architect\nversion: 1.6.1\ndescription: &gt;\nEntry-point skill for designing robotics applications with AI agents. Turns requirements (robot type, task, hardware, sim-vs-real, GPU/budget) into a full stack decision — middleware, simulation, data, visualization, training frameworks — plus a scaffold plan and a written architecture brief. Use when: starting any new robotics app; 'build a robot app', 'which robotics stack', 'scaffold a robotics project', 'mobile robot', 'robot arm', 'manipulation policy', 'navigation stack', backlog-driven kickoffs like 'let's do demo 1', 'do demo N', 'build the next demo'; or when requirements exist but the stack is unchosen. This is the entry-point skill of the robium plugin: load it first; it routes to every other robium skill per build phase. Not for: debugging an existing stack (use the matching tool skill) or authoring robium skills (skill-author).</h2>\n<h1>architect</h1>\n<p>The entry point to robium. Given a robotics application idea, this skill turns\nrequirements into a concrete stack decision — middleware, simulation, data,\nvisualization, and training frameworks — plus a scaffold plan and a written\n<strong>architecture brief</strong>. It is the only skill that knows the whole robium\ncatalog; everything else is reached by routing from here. Load it first on any\nnew robotics app, then hand off to the domain skills for the actual build.</p>\n<h2>When to use this skill</h2>\n<ul>\n<li>Starting a brand-new robotics application from a rough idea (\"build a mobile\nrobot that navigates a warehouse\", \"train a manipulation policy on an arm\").</li>\n<li>The requirements exist but the stack is unchosen, or half-chosen and you want\na sanity check before committing.</li>\n<li>You need a durable, written architecture record the whole project builds from.</li>\n<li>You want the routing map: \"which robium skill do I load for phase X?\"</li>\n<li>Open-ended or backlog-driven kickoffs (\"let's do demo 1\", a vague feature\nidea) start with <code>brainstorming@superpowers</code> — it owns requirements-gathering.\nArchitect takes over once requirements are settled (robot type, task,\nhardware, sim-vs-real, GPU) to make the stack decision itself, rather than\nbrainstorming's own research improvising it.</li>\n<li>Cross-references — go straight to the tool skill, skipping architect, when the\nstack is already chosen and the question is narrow:\n<ul>\n<li>Debugging or configuring an existing stack → the matching tool skill\n(<code>nav2</code>, <code>ros2</code>, <code>gazebo</code>, <code>lerobot</code>, …). \"My costmap isn't updating\" is a\n<code>nav2</code> question, not an architect question.</li>\n<li>Authoring or improving robium skills themselves → <code>skill-author</code>.</li>\n<li>Deep-diving one decision (uv vs Docker, which visualizer) → the umbrella\nthat owns it (<code>environments</code>, <code>visualization</code>); architect points you there.</li>\n</ul>\n</li>\n</ul>\n<h2>Key directives</h2>\n<ul>\n<li><strong>Delegation posture: route + embed the decision logic.</strong> The <em>decisions</em>\n(which stack, why) live here; the <em>how-to</em> lives in the skill each decision\nroutes to. Never duplicate a tool skill's content — link to it.</li>\n<li><strong>Always produce or update <code>docs/architecture-brief.md</code> in the app repo.</strong>  It\nis the living architecture contract — every later build step reads from it,\nand refinements edit it in place. No brief, not done. Use\n<code>references/brief-template.md</code> for its required sections.</li>\n<li><strong>Virtual-environment-first.</strong>  Reproducibility is decided before code: route\nthe env question to the <code>environments</code> skill (uv/venv vs Docker) and record\nthe choice in the brief. Do not let a project start with an ad-hoc setup.</li>\n<li><strong>Never invent syntax or tools.</strong>  Recommend only real, current tools at\nversions you have verified — robium ships curation, not a framework. When a\nversion fact matters (ROS 2 distro, Gazebo pairing, GPU floor), confirm it\nagainst current docs (e.g. <a href=\"https://docs.ros.org/\">docs.ros.org</a> for ROS 2\ndistro/EOL status) rather than memory. See <code>references/stack-selection.md</code>\nfor the verified defaults this skill ships with.</li>\n<li><strong>State open risks explicitly in the brief.</strong>  Unverified assumptions (GPU\navailability, hardware you can't see, sim-to-real gaps) go in the brief's\nopen-risks section, not silently into a decision.</li>\n</ul>\n<h2>Quick start</h2>\n<p><strong>1. Collect the requirement checklist</strong> (ask for anything missing; if a\ncritical item is still unknown, record the assumption in the brief rather than\nguessing silently):</p>\n<ul>\n<li><strong>Robot type</strong> — mobile base, arm/manipulator, humanoid, drone, custom?</li>\n<li><strong>Task</strong> — navigate, manipulate/grasp, inspect, learn a policy, teleop?</li>\n<li><strong>Hardware</strong> — real robot (which?), sim only, or sim-first then real?</li>\n<li><strong>Sim vs real</strong> — where does the MVP need to run?</li>\n<li><strong>GPU</strong> — is an NVIDIA RTX GPU available? VRAM? (gates Isaac Sim / Lab.)</li>\n<li><strong>Local vs remote</strong> — laptop, workstation, or headless remote server?\n(drives the visualization choice — remote favors <code>foxglove</code>.)</li>\n</ul>\n<p><strong>2. Pick a golden path.</strong> The two MVP verticals:</p>\n<ul>\n<li><p><strong>Navigation</strong>  (mobile robot, autonomous nav in sim):\n<code>ros2</code> + <code>nav2</code> + <code>gazebo</code> + <code>visualization</code>\n→ ROS 2 Jazzy (LTS) middleware, Nav2 for the nav stack, Gazebo Harmonic as\nthe paired simulator, an RViz2 or Foxglove view. Dockerized env via\n<code>environments</code>. This is the classic, well-supported path — favor it when the\ntask is \"get from A to B autonomously.\"</p>\n</li>\n<li><p><strong>Manipulation</strong>  (arm, learned policy):\n<code>lerobot</code> (+ <code>isaac-sim</code> / <code>isaac-lab</code> <em>if a capable GPU is available</em>) +\n<code>huggingface</code> + <code>data</code>\n→ LeRobot for policy training/eval (ACT, Diffusion, SmolVLA, π0), datasets\nand models sourced through the <code>huggingface</code> delegation, <code>data</code> for the\nsourcing strategy. Add <code>isaac-sim</code>/<code>isaac-lab</code> only when the GPU floor is\nmet (see Platform gotchas); otherwise stay in LeRobot's own sim/eval tools\nand a CPU/uv env. Favor this when the task is \"learn to grasp / manipulate.\"</p>\n</li>\n</ul>\n<p><strong>3. Write the brief.</strong> Fill <code>docs/architecture-brief.md</code> from\n<code>references/brief-template.md</code> — chosen stack + reasoning, module breakdown,\ncomms plan, env strategy, data plan, robium skills per phase, open risks.</p>\n<p><strong>4. Scaffold — bootstrap-first.</strong>  Before laying anything out from scratch,\ncheck the battle-tested sample registry: <code>REGISTRY.md</code> at the root of the\ncompanion robium-applications repo\n(<a href=\"https://github.com/robium-ai/robium-applications\">github.com/robium-ai/robium-applications</a>;\nlocally a sibling checkout when present). Each card names the stack an app\nproves, what it can bootstrap, and its encoded battle scars. If an existing\napp resembles the target (same vertical, overlapping stack), <strong>bootstrap\nfrom it</strong> — copy its structure, env shape, and test shape, then diverge —\nand note the donor app in the brief. Only when no card is close, lay out\nthe repo fresh per <code>references/scaffold-patterns.md</code> (ROS 2 app layout or\nLeRobot app layout). Then hand each phase to its skill.</p>\n<p>For the heavy version of step 2 (a full stack-comparison research burst that\nkeeps the noise out of the main conversation), launch the <code>robium-architect</code>\nsubagent; it runs this skill as its playbook and writes the brief.</p>\n<h2>Decision guidance</h2>\n<p>The routing map. Architect is the only skill that sees the whole catalog; it\nhands each build phase to the skill below. Grouped by phase.</p>\n<h3>Design / architecture</h3>\n<table>\n<thead>\n<tr>\n<th>Skill</th>\n<th>Hand off when…</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>architect</code></td>\n<td>You are here — requirements → stack → brief → scaffold, and routing to everything below.</td>\n</tr>\n<tr>\n<td><code>integration</code></td>\n<td>Module boundaries and comms are the question: topics/services vs zenoh/gRPC, Dockerfiles, compose wiring across nodes.</td>\n</tr>\n<tr>\n<td><code>environments</code></td>\n<td>Deciding reproducibility: uv/venv vs Docker, identical local/remote repro, GPU passthrough. Resolve this early, per the env-first directive.</td>\n</tr>\n</tbody>\n</table>\n<h3>Middleware &amp; motion</h3>\n<table>\n<thead>\n<tr>\n<th>Skill</th>\n<th>Hand off when…</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>ros2</code></td>\n<td>The app uses ROS 2 — core usage, packages, nodes, launch files, message/topic wiring. The substrate for the nav vertical.</td>\n</tr>\n<tr>\n<td><code>nav2</code></td>\n<td>Autonomous navigation for a mobile base — costmaps, planners, controllers, behavior trees, localization.</td>\n</tr>\n</tbody>\n</table>\n<h3>Simulation</h3>\n<table>\n<thead>\n<tr>\n<th>Skill</th>\n<th>Hand off when…</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>simulation</code></td>\n<td>Choosing a simulator or getting sensor simulation right, before committing to a specific engine.</td>\n</tr>\n<tr>\n<td><code>gazebo</code></td>\n<td>Simulating a ROS 2 robot — the paired sim for the nav vertical (Gazebo Harmonic ↔ ROS 2 Jazzy).</td>\n</tr>\n<tr>\n<td><code>isaac-sim</code></td>\n<td>Photoreal / GPU-accelerated sim or synthetic data — <strong>only when the NVIDIA RTX GPU floor is met</strong>.</td>\n</tr>\n<tr>\n<td><code>isaac-lab</code></td>\n<td>GPU-parallel reinforcement-learning environments on top of Isaac Sim — same GPU gate.</td>\n</tr>\n<tr>\n<td><code>mujoco</code></td>\n<td>Lightweight, contact-rich manipulation sim <strong>without ROS</strong> — a single-arm grasp / pick-and-place task (e.g. the SO-101), headless offscreen render, hand-rolled IK. The non-ROS, non-GPU-photoreal alternative to gazebo/isaac-sim; runs natively on Apple Silicon.</td>\n</tr>\n</tbody>\n</table>\n<h3>Learning &amp; data</h3>\n<table>\n<thead>\n<tr>\n<th>Skill</th>\n<th>Hand off when…</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>lerobot</code></td>\n<td>Training or running a manipulation/imitation policy — the substrate for the manipulation vertical.</td>\n</tr>\n<tr>\n<td><code>huggingface</code></td>\n<td>Pulling datasets/models or pushing artifacts to the Hub — <strong>delegate</strong> to <code>hf-cli@huggingface-skills</code>; robium adds only the robotics glue.</td>\n</tr>\n<tr>\n<td><code>data</code></td>\n<td>Deciding where data comes from: offline datasets vs sim generation vs teleop collection.</td>\n</tr>\n</tbody>\n</table>\n<h3>Visualization</h3>\n<table>\n<thead>\n<tr>\n<th>Skill</th>\n<th>Hand off when…</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>visualization</code></td>\n<td>Choosing a viz tool or applying viz best practices, before picking a specific one.</td>\n</tr>\n<tr>\n<td><code>rviz2</code></td>\n<td>Classic ROS 2 visualization on a local Linux machine with a display.</td>\n</tr>\n<tr>\n<td><code>foxglove</code></td>\n<td>Web-based viz — the go-to for a <strong>headless remote server</strong> or cross-platform team viewing.</td>\n</tr>\n<tr>\n<td><code>rerun</code></td>\n<td>Timeline/multimodal logging for ML and perception debugging (heavy pointer to Rerun's own docs).</td>\n</tr>\n</tbody>\n</table>\n<h3>Verification &amp; meta</h3>\n<table>\n<thead>\n<tr>\n<th>Skill</th>\n<th>Hand off when…</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>testing</code></td>\n<td>Standing up smoke tests, sim-based regression, or launch testing — plan this into the brief, don't bolt it on later.</td>\n</tr>\n<tr>\n<td><code>test-assets</code></td>\n<td>Sourcing the data tests run against — canonical worlds/models/datasets, fixture layout, goldens. Load with <code>testing</code> when planning the test setup.</td>\n</tr>\n<tr>\n<td><code>live-demo</code></td>\n<td>Publishing a finished app as a public interactive web demo — mission-control demo page, per-visitor Cloud Run sim instances, viewer handoff. Entry bar: the app's smoke test is green.</td>\n</tr>\n<tr>\n<td><code>cloud-run</code></td>\n<td>Deploying a headless robotics/sim/demo container to Google Cloud Run — build → Artifact Registry → <code>gcloud run deploy</code>, and the sim-on-Cloud-Run gotchas (no multicast, CPU-on-request, session affinity, ws timeout). The CPU deploy target live-demo builds on.</td>\n</tr>\n<tr>\n<td><code>skill-author</code></td>\n<td>Editing robium's own skills (fresh authoring, mining, hardening from learnings). Not an app-building skill.</td>\n</tr>\n<tr>\n<td><code>skill-updater</code></td>\n<td>End-of-session absorption: folding the current session's gotchas back into the robium skills. Not an app-building skill.</td>\n</tr>\n</tbody>\n</table>\n<p>See <code>references/stack-selection.md</code> for the decision trees behind these\nhand-offs (middleware yes/no, simulator gazebo-vs-isaac, training framework).</p>\n<h2>Platform gotchas</h2>\n<ul>\n<li><strong>Isaac Sim / Isaac Lab are GPU-gated.</strong>  Per NVIDIA's current requirements\n(<a href=\"https://docs.isaacsim.omniverse.nvidia.com/latest/installation/requirements.html\">docs.isaacsim.omniverse.nvidia.com</a>),\nthe floor is an <strong>RTX 4080 with 16 GB VRAM</strong> (minimum), an RTX 5080 or\nbetter recommended (16 GB+ VRAM), and 32 GB+ system RAM (64 GB recommended;\nIsaac Lab RL training wants more of both). Linux (Ubuntu) is the primary\ntarget; <strong>there is no macOS support</strong>. If the GPU floor isn't met, do not\nroute to Isaac — keep the manipulation path in LeRobot's own sim/eval\ntooling. Verify the current floor in <code>isaac-sim</code> before committing; treat\nGPU availability as an open risk if unconfirmed.</li>\n<li><strong>macOS / Apple Silicon</strong>  cannot run the native ROS 2 + Gazebo desktop stack\ncleanly — plan for Docker (route to <code>environments</code>) or a Linux remote.</li>\n<li><strong>Remote / headless servers</strong>  have no display for RViz2 — default the viz\nchoice to <code>foxglove</code> (web UI) in that case, and note it in the brief.</li>\n<li><strong>ROS 2 distro choice:</strong>  <strong>Lyrical Luth</strong> (LTS, GA 2026-05-22, supported to\nMay 2031) is the current newest LTS — default new apps to it unless a\ndependency forces otherwise. Exception: the ROS 2 + Nav2 + Gazebo navigation\nvertical still defaults to <strong>Jazzy Jalisco</strong> (LTS, supported to May 2029) for\nnow, because Nav2 has not yet shipped binary packages for Lyrical (tracked in\n<code>ros-navigation/navigation2#6123</code> as of 2026-07) — re-check before picking\nLyrical for that path. Kilted Kaiju is non-LTS and nearing its own EOL\n(~Dec 2026); don't pick it as a new default. Record the chosen distro in the\nbrief.</li>\n</ul>\n<h2>Customization</h2>\n<ul>\n<li><strong>Different robot/task:</strong> re-run the requirement checklist and the decision\ntrees in <code>references/stack-selection.md</code>. The two golden paths are starting\npoints, not the only shapes — a drone-inspection app is still ROS 2 + a sim +\nviz, just with different nodes; a real-hardware manipulation app is LeRobot\nwith the sim swapped for a hardware driver.</li>\n<li><strong>Adapt the scaffold:</strong> <code>references/scaffold-patterns.md</code> gives a ROS 2 layout\nand a LeRobot layout; rename packages and prune directories your app doesn't\nneed, but keep the <code>docs/architecture-brief.md</code> location fixed — tooling and\nevery later phase expect it there.</li>\n<li><strong>Adapt the brief:</strong> every section in <code>references/brief-template.md</code> is\nrequired, but its depth scales with the project — a one-robot sim demo needs a\nshort comms plan; a multi-robot fleet needs a real one.</li>\n</ul>\n<h2>References</h2>\n<ul>\n<li><code>references/stack-selection.md</code> — the decision trees: middleware (ROS 2\nyes/no), simulator (Gazebo vs Isaac), and training framework, with the\nverified version defaults this skill ships.</li>\n<li><code>references/scaffold-patterns.md</code> — repo layouts for a ROS 2 app and a\nLeRobot app: directory trees plus what each directory holds.</li>\n<li><code>references/brief-template.md</code> — the required sections of\n<code>docs/architecture-brief.md</code> (chosen stack + reasoning, module breakdown,\ncomms plan, env strategy, data plan, robium skills per phase, open risks).</li>\n<li><code>examples/architecture-brief-example.md</code> — a filled brief for a hypothetical\ndiff-drive warehouse robot (status: unverified).</li>\n<li>Battle-tested sample apps + registry:\n<a href=\"https://github.com/robium-ai/robium-applications\">robium-applications</a> —\n<code>REGISTRY.md</code> indexes every app (stack, pass bar, bootstrap-for, battle\nscars); the bootstrap-first source for Quick start step 4.</li>\n<li>Upstream: <a href=\"https://docs.ros.org/\">ROS 2 docs</a>, <a href=\"https://docs.nav2.org/\">Nav2 docs</a>,\n<a href=\"https://gazebosim.org/docs/\">Gazebo docs</a>, <a href=\"https://github.com/huggingface/lerobot\">LeRobot</a>,\n<a href=\"https://docs.isaacsim.omniverse.nvidia.com/\">Isaac Sim</a>,\n<a href=\"https://isaac-sim.github.io/IsaacLab/\">Isaac Lab</a>. The <code>robium-architect</code>\nsubagent (<code>agents/robium-architect.md</code>) runs this skill as its playbook.</li>\n</ul>\n<h2>Changelog</h2>\n\n<ul>\n<li><p>1.6.1 (2026-08-01): anchor IDs added to claim-bearing items (learning-engine Phase 1); no content changes.</p>\n</li>\n<li><p>1.6.0 (2026-08-01): routing table (Verification &amp; meta) gains the new\ncloud-run skill — the Cloud Run deploy target for headless robotics/demo\ncontainers that live-demo builds on (issue #67).</p>\n</li>\n<li><p>1.5.0 (2026-07-31): route MuJoCo / non-ROS manipulation-sim tasks to the new mujoco skill.</p>\n</li>\n<li><p>1.4.0 (2026-07-18): routing table gains the new test-assets skill\n(test-data sourcing, paired with testing).</p>\n</li>\n<li><p>1.3.1 (2026-07-18): stale-fact refresh — robium-applications GitHub links\nrepointed to the robium-ai org after the repo transfer (two occurrences;\nold URLs redirect).</p>\n</li>\n<li><p>1.3.0 (2026-07-15): description gains backlog-driven kickoff phrasing\n('let's do demo 1', 'do demo N', 'build the next demo') after a real session\nmissed the trigger; added a brainstorming↔architect handoff bullet to When\nto use this skill (brainstorming owns requirements-gathering, architect takes\nover for stack selection) after the two collided on being 'the' entry point\nand stack-selection research got duplicated by hand.</p>\n</li>\n<li><p>1.2.0 (2026-07-13): routing map gains the new <code>live-demo</code> skill\n(publish a finished app as a public web demo — born from the nav-trial\ndemo deployment).</p>\n</li>\n<li><p>1.1.1 (2026-07-12): skill-refiner run 1 — present-tense 'this session' phrasing reworded (no meaning change) so the refiner's undated-provenance warning stays noise-free.</p>\n</li>\n<li><p>1.1.0 (2026-07-12): scaffold step made bootstrap-first — check\nrobium-applications' REGISTRY.md for a resembling battle-tested app\nbefore scaffolding fresh; registry link added to References.</p>\n</li>\n</ul>\n","files":[{"path":"evals.yaml","sizeBytes":270,"isText":true},{"path":"examples/architecture-brief-example.md","sizeBytes":5739,"isText":true},{"path":"references/brief-template.md","sizeBytes":4080,"isText":true},{"path":"references/scaffold-patterns.md","sizeBytes":5619,"isText":true},{"path":"references/stack-selection.md","sizeBytes":5199,"isText":true},{"path":"SKILL.md","sizeBytes":17079,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-20T17:08:56.913168Z","sha256":"4CF7BB00EBEE95E715A65D9444046DD35A3B8110CCD645B103804CBD0452A793","sizeBytes":17383},"review":null,"source":{"repositoryUrl":"https://github.com/robium-ai/robium","path":"archive/architect/1.6.1","license":"MIT","commit":"498ea4e4beab472e999287e9d628d892c206a8a1","subtreeSha":"607A8330172C421420A637E20F17326F38473454BC58D13746168542F72E9ED7","lastSyncedAt":"2026-09-20T17:07:51.565883Z"},"reviewedAt":"2026-09-20T17:10:30.387793Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/robium-ai/robium/tree/main/archive/architect/1.6.1"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install robium-ai-robium@llmmart"},{"target":"git","command":"git clone https://github.com/robium-ai/robium.git"}]}