Hardware Control Safety & Planning-First Development

A comprehensive development methodology for hardware projects that emphasizes safety, explicit user approval, and careful planning before implementation.

Core Principles

This skill enforces a disciplined development approach specifically designed for projects involving hardware control, embedded systems, or any work where mistakes can have physical consequences or data loss.

Mandatory Pre-Work Steps

Before responding to ANY request:

1. **Read Documentation First**: If a `development.md` or `.cursorrules` file exists in the project, read it completely before taking any action or making suggestions. These files contain critical project-specific guidelines.

2. **Verify Environment**: Always check that the virtual environment (venv) is activated before starting work or testing. If expected tools are missing, verify the virtual environment setup.

Planning-First Workflow

When to Stop at Planning

**Stop after presenting a plan** when the user uses phrases like:

These phrases indicate the user wants **discussion and options**, not immediate implementation.

When to Implement

**Only implement code** after explicit approval with phrases like:

The Planning Process

1. **Make a plan** based on requirements

2. **Double-check your plan** for completeness and safety

3. **Share the plan** for user approval

4. **Wait for explicit approval** before writing code

5. **When user shares feedback**, review and update the plan rather than immediately coding

Hardware Safety Protocols

Critical Hardware Rules

**NEVER perform hardware operations without confirmation:**

Hardware Safety Checklist

Before any hardware operation:

1. **Ask about current device state**: "What is the current state of the device?"

2. **Check bootloader configurations**: Read bootloader settings before destructive operations

3. **Read hardware documentation**: Review project-specific hardware docs before making suggestions

4. **Confirm the plan**: Present the exact steps and wait for explicit approval

5. **Verify twice**: Double-check device identifiers, port configurations, and operation parameters

Code and Implementation Standards

Application of Changes

Testing Approach

Code Quality

Documentation Standards

Markdown Style

Documentation Content

Scope Control

What NOT to Do

What TO Do

Example Workflows

Example 1: Planning Request

**User**: "How should we handle the air quality sensor data?"

**Correct Response**:

1. Read relevant documentation

2. Present 2-3 options with trade-offs

3. Stop and wait for user decision

4. Do NOT implement anything yet

Example 2: Hardware Operation

**User**: "Flash the new firmware to the device"

**Correct Response**:

1. Ask about current device state

2. Check bootloader configuration

3. Present the exact flash plan

4. Wait for explicit "go ahead"

5. Only then execute the operation

Example 3: Approved Plan

**User**: "Yes, that plan looks good"

**Correct Response**:

1. Implement the approved plan

2. Apply all changes yourself

3. Provide complete test scripts

4. Do NOT ask for approval again

Constraints

Notes

This skill is particularly valuable for:

The emphasis on explicit approval and planning prevents costly mistakes while maintaining development velocity once decisions are made.