home / skills / zeeshan080 / ai-native-robotics / safety-checklist

safety-checklist skill

This skill helps validate robotics safety by applying a structured safety checklist to code, URDF, and configurations, highlighting gaps before deployment.

npx playbooks add skill zeeshan080/ai-native-robotics --skill safety-checklist

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.2 KB

---
name: safety-checklist
description: Robotics safety validation checklist for reviewing robot code and configurations. Use when reviewing URDF files, ROS 2 nodes, or any robotics content for safety issues.
allowed-tools: Read, Grep
---

# Safety Checklist

## Instructions

When reviewing robotics content for safety:

1. Check against the safety checklist
2. Flag any missing safety measures
3. Verify all limits are defined
4. Ensure warnings are present for dangerous operations

## Quick Safety Check

Before publishing any robotics content, verify:

- [ ] All joint limits are defined
- [ ] Emergency stop considerations mentioned
- [ ] Simulation-only content is marked
- [ ] No dangerous default values
- [ ] Proper units are used (SI units)

## Safety Categories

### Hardware Safety
- Joint limits and torque limits
- Collision avoidance
- Emergency stop handling

### Software Safety
- Error handling in nodes
- Watchdog timers
- State validation

### Educational Safety
- Clear warnings for real hardware
- Simulation vs real robot distinctions
- Supervised operation requirements

## Reference

See [checklist.md](checklist.md) for the complete safety checklist.

Overview

This skill provides a focused robotics safety validation checklist for reviewing robot code, URDF files, ROS 2 nodes, and configurations. It helps reviewers identify missing safety measures, verify limits, and ensure clear warnings for dangerous operations. The goal is to reduce risks when moving from simulation to real hardware.

How this skill works

The skill inspects robotics artifacts for common safety items: joint and torque limits in URDFs, node-level error handling and watchdogs, and configuration defaults that could be hazardous. It flags missing limits, absent emergency-stop handling, unspecified units, and simulation-only content that lacks real-hardware warnings. Reviewers get actionable findings to correct configuration, code, or documentation before deployment.

When to use it

Before publishing robotics tutorials or code that may be run on hardware
During PR reviews of URDF files, ROS 2 nodes, or launch/configuration files
When preparing simulation scenarios that could be run on real robots
Before demonstrations or student labs involving physical robots
When auditing safety posture of an educational robotics platform

Best practices

Always define joint position, velocity, and torque limits in URDF and controller configs
Include explicit emergency-stop handling and describe how to trigger it
Mark simulation-only examples clearly and provide safe real-hardware alternatives
Use SI units consistently and document units for every parameter
Add runtime checks: state validation, watchdog timers, and robust error handling
Provide clear warnings and supervision requirements for any operations that may be dangerous

Example use cases

Review a URDF to ensure all joints include position and effort limits before deployment
Audit ROS 2 nodes to confirm watchdog timers, exception handling, and safe defaults are implemented
Validate tutorial content to ensure simulation vs real-hardware distinctions are explicit
Check launch files and config parameters for dangerous default values or missing emergency-stop hooks
Assess educational lab exercises to ensure supervised operation and explicit warnings are present

FAQ

Does this checklist replace formal safety certification?

No. This checklist is for early detection of common safety issues and review guidance. It does not substitute formal risk assessments, safety standards compliance, or certification processes.

What if a parameter is intentionally unbounded for research?

Document the rationale clearly, mark the content as research-only or simulation-only, and include explicit operational warnings and required safeguards before any hardware execution.