Blinky

MakerAI

MakerAI is an AI-native hardware runtime and manufacturing platform. The board design path turns reviewed, structured engineering inputs into auditable KiCad schematics and PCBs; it does not treat a rendered image or an autorouter return code as proof that hardware is ready to build.

Current Board-Design Route

The sole active EDA implementation is skills/makerai-board-design. It targets low-voltage, low-power, low-speed, module-based embedded boards and provides:

• typed board specifications as the electrical source of truth;
• critical-part evidence and explicit engineering assumptions;
• versioned, source-linked circuit-block templates;
• deterministic multi-page KiCad schematic generation;
• exact specification/KiCad netlist equivalence checks;
• KiCad ERC/DRC plus independent semantic, SKiDL, geometry, render, connectivity, reference-plane, and manufacturing gates; and
• explicit separation between automated review candidates and human-approved releases.

The fixed smart-pot MVP and the earlier Hardware-DSL/KiCad script experiment are archived under legacy/. They are not current design backends.

Repository Layout

skills/
  makerai-board-design/       Current schematic, PCB, routing, and review skill.
    assets/                   Schemas, examples, evidence, profiles, and templates.
    references/               Engineering policies and workflow documentation.
    scripts/                  Deterministic generators, checkers, and exporters.
    tests/                    Fast workflow and policy regression tests.

legacy/
  pcb-mvp/                    Archived fixed smart-pot manufacturing MVP.
  kicad-script-demo/          Archived natural-language/Hardware-DSL EDA prototype.
  lab/                        Archived tool evaluations and experiment evidence.
  reports/                    Archived project reports and presentations.
  research/                   Archived market, module, and ecosystem research.

docs/                         White papers, proposals, and design discussions.
reports/                      Reports produced by the current skill route.

Generated skill environments, downloaded tools, and scratch runs live below the skill as .venv/, .tools/, and .runs/; they are intentionally ignored by Git. Reproducible inputs, lock files, source code, and policies are versioned.

Engineering Source of Truth

The current route keeps concerns separate:

1. design.json owns components, exact pins, nets, footprints, and constraints.
2. design.evidence.json owns primary-source evidence, assumptions, waivers, and mandatory human-review boundaries.
3. Schematic and PCB layout profiles own presentation and physical intent, not electrical connectivity.
4. Versioned block templates own qualified local presentation and source links.
5. Deterministic generators emit KiCad files from those inputs.
6. Independent checkers compare the emitted artifacts back to the original specification and fail closed when a required gate does not pass.

See the skill instructions, architecture, and professional schematic workflow for the authoritative process.

Quick Start

Bootstrap and verify the isolated EDA environment:

SKILL_DIR="$PWD/skills/makerai-board-design"
"$SKILL_DIR/scripts/bootstrap.sh"
"$SKILL_DIR/scripts/doctor.py" --strict
"$SKILL_DIR/.venv/bin/python" -m pytest -q "$SKILL_DIR/tests"

Generate and review the reference ESP32-S3 schematic in a fresh output directory:

SKILL_DIR="$PWD/skills/makerai-board-design"

"$SKILL_DIR/scripts/run_professional_schematic.py" \
  "$SKILL_DIR/assets/examples/esp32-s3-sensor-hub.json" \
  --profile "$SKILL_DIR/assets/schematic-layouts/esp32-s3-sensor-hub-professional-v1.json" \
  --evidence "$SKILL_DIR/assets/examples/esp32-s3-sensor-hub.evidence.json" \
  --template-dir "$SKILL_DIR/assets/schematic-templates/blocks" \
  --source-catalog "$SKILL_DIR/assets/template-sources.lock.json" \
  --output build/esp32-s3-sensor-hub-schematic

The command refuses to overwrite a non-empty output directory. A passing result is SCHEMATIC_AUTOMATED_REVIEW_PASSED: an engineering-review candidate that still requires the documented human checks. PCB placement, routing, and release commands are documented in the skill instructions.

Safety Boundary

The automated route does not cover mains, high-energy batteries, medical or automotive safety functions, motor power stages, discrete RF, DDR, PCIe, Ethernet PHY layout, isolation barriers, or certification sign-off. Those cases require a qualified engineer and a design-specific review plan.

Never describe an automatically generated design as production-ready. Use these states consistently:

• generated: files exist, but required gates have not all passed;
• review-candidate: automated gates pass and human review remains;
• release-approved: a named human reviewer completed the release checklist;
• blocked: at least one required gate failed or the design is outside scope.

Historical Material

The archived implementations and their selected outputs remain in legacy/ so earlier results can be inspected and reproduced. New features, board families, validation rules, and release decisions must use the current skill route.

The broader product direction remains documented under docs/, while historical tool evaluations, reports, and research evidence remain under legacy/.

License and Dependencies

The board-design skill source is MIT licensed. Optional upstream tools are kept at process boundaries and retain their own licenses. Review upstream licenses before redistributing tool binaries or copied material.