architect

architect

The entry point to robium. Given a robotics application idea, this skill turns requirements into a concrete stack decision — middleware, simulation, data, visualization, and training frameworks — plus a scaffold plan and a written architecture brief. It is the only skill that knows the whole robium catalog; everything else is reached by routing from here. Load it first on any new robotics app, then hand off to the domain skills for the actual build.

When to use this skill

• Starting a brand-new robotics application from a rough idea ("build a mobile robot that navigates a warehouse", "train a manipulation policy on an arm").
• The requirements exist but the stack is unchosen, or half-chosen and you want a sanity check before committing.
• You need a durable, written architecture record the whole project builds from.
• You want the routing map: "which robium skill do I load for phase X?"
• Cross-references — go straight to the tool skill, skipping architect, when the stack is already chosen and the question is narrow:
  • Debugging or configuring an existing stack → the matching tool skill (nav2, ros2, gazebo, lerobot, …). "My costmap isn't updating" is a nav2 question, not an architect question.
  • Authoring or improving robium skills themselves → skill-author.
  • Deep-diving one decision (uv vs Docker, which visualizer) → the umbrella that owns it (environments, visualization); architect points you there.

Key directives

• Delegation posture: route + embed the decision logic. The decisions (which stack, why) live here; the how-to lives in the skill each decision routes to. Never duplicate a tool skill's content — link to it.
• Always produce or update docs/architecture-brief.md in the app repo. It is the living architecture contract — every later build step reads from it, and refinements edit it in place. No brief, not done. Use references/brief-template.md for its required sections.
• Virtual-environment-first. Reproducibility is decided before code: route the env question to the environments skill (uv/venv vs Docker) and record the choice in the brief. Do not let a project start with an ad-hoc setup.
• Never invent syntax or tools. Recommend only real, current tools at versions you have verified — robium ships curation, not a framework. When a version fact matters (ROS 2 distro, Gazebo pairing, GPU floor), confirm it against current docs (e.g. docs.ros.org for ROS 2 distro/EOL status) rather than memory. See references/stack-selection.md for the verified defaults this skill ships with.
• State open risks explicitly in the brief. Unverified assumptions (GPU availability, hardware you can't see, sim-to-real gaps) go in the brief's open-risks section, not silently into a decision.