Add AI use policy page; recommend KiCad for board design

- Add an AI use policy (adapted from napari's, itself from Zulip's), tailored to
  BeeHive contributions (boards, recipes, MicroPython, docs). Nest Contributing
  into a section (Overview + AI use policy) and link it from the Contributing page.
- "Build your own board": recommend KiCad (FOSS, and what BeeHive's boards use —
  open the existing .kicad_pcb files as references) plus FreeCAD for mechanical
  parts.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: roaldarbol

docs/ai-use-policy.md

@@ -0,0 +1,62 @@
+---
+title: AI use policy
+description: How to use AI tools when contributing to BeeHive — you are accountable for what you submit.
+---
+
+# AI use policy
+
+BeeHive welcomes contributions made with the help of AI tools — but **you are
+responsible for everything you submit**. This page sets out how to use them well.
+
+## The core principle
+
+We are humans who enjoy working with other humans. Use whatever tools help you,
+but you are ultimately accountable for the boards, code, and documentation you
+contribute. If you would not be comfortable explaining a change and standing
+behind it, it is not ready to submit.
+
+## Please don't
+
+- Let an AI agent open pull requests on your behalf.
+- Submit a board design, recipe, code, or docs change you have not personally
+  understood and tested.
+- Let a chatbot carry on a conversation (an issue thread, a PR review) for you.
+
+Pull requests that appear to ignore these guidelines may be closed without
+review — checking un-vetted machine output costs maintainers more time than it
+saves.
+
+## Using AI to build and code
+
+- **Get familiar with what you are changing first.** Understanding the board,
+  the [design rules](introduction/design-rules.md), or the code you are touching
+  lets you write better prompts *and* judge whether the output is right.
+- **Don't trust an assistant's claims about how BeeHive works.** LLMs are often
+  confidently wrong, even about things the docs answer directly. Check against
+  the design rules, the board's schematics, or a real device.
+- **Test on hardware.** A recipe or snippet that looks plausible is not a
+  contribution until it actually runs on the boards it claims to.
+- **Keep pull requests small and focused,** even if a tool generated everything
+  in one go. One board, one recipe, or one fix per PR is far easier to review.
+- **Edit AI-written comments and prose.** Prefer clarity and brevity over
+  exhaustive, generic text; delete comments that just restate the code.
+
+## Using AI to communicate
+
+- **Say why, not what.** A PR description that merely restates the diff adds
+  nothing — explain your reasoning and what you tested.
+- **Fill in the templates yourself.** Issue and PR templates exist to save
+  everyone time; complete them rather than having a tool do it.
+- **Verify anything you post.** Don't paste unchecked AI output into an issue or
+  a pull request.
+- **Link, don't quote.** Pointing to the primary source — a datasheet, the docs,
+  a repo file — beats quoting an LLM. If you must quote one, put it in a
+  `>` blockquote so it is clearly machine output, not your own words.
+- **Clarity over polish.** A clear, slightly imperfect message beats a
+  perfectly-worded one that hides the point.
+
+## Attribution
+
+This policy is adapted from the
+[napari AI use policy](https://napari.org/dev/developers/contributing/ai.html),
+which was itself adapted from Zulip's AI usage guidelines.

docs/contributing.md

@@ -8,6 +8,10 @@ description: How to contribute boards, recipes, and fixes to BeeHive.
 BeeHive is open source and community-driven. Contributions aren't confined to
 one institution — anyone can add a board, share a recipe, or improve the docs.
 
+!!! note "Using AI tools?"
+    That's fine — but you're accountable for what you submit. Please read the
+    [AI use policy](ai-use-policy.md) first.
+
 ## Ways to contribute
 
 - 🧩 **A new board (ingredient).** Design a daughter board that follows the

docs/techniques/build-your-own-board.md

@@ -9,6 +9,21 @@ Every BeeHive board is either a **mainboard** (carries a microcontroller) or a *
 
 The workflow is simple: pick a function, design to the rules, then submit via the repo.
 
+## What to design it in
+
+Use **[KiCad](https://www.kicad.org/)** — a free, open-source, cross-platform
+EDA suite for schematic capture and PCB layout. It's the standard FOSS tool for
+this, and it's what BeeHive's own boards are drawn in, so you can open any
+existing board's `.kicad_pcb` from the [ingredients catalogue](../ingredients/index.md)
+(each board links its KiCad files) as a starting point or reference. KiCad also
+exports the gerbers and bill of materials the fab houses and
+[Kitspace](https://kitspace.org/) need.
+
+!!! tip "Mechanical parts"
+    If your board needs a 3D-printed frame, mount or enclosure, design those in
+    **[FreeCAD](https://www.freecad.org/)** (open-source parametric CAD). KiCad
+    can hand off the board outline and 3D model to it.
+
 ## 1. Pick a function
 
 A daughter board does **one thing** — drive an actuator or read a sensor. If you find yourself putting two unrelated functions on one board, that's two boards. Keeping boards single-function is what lets them mix and match across recipes.

zensical.toml

@@ -63,7 +63,10 @@ nav = [
       { "Glossary" = "courses/intro-to-electronics/glossary.md" },
     ] },
   ] },
-  { "Contributing" = "contributing.md" },
+  { "Contributing" = [
+    { "Overview" = "contributing.md" },
+    { "AI use policy" = "ai-use-policy.md" },
+  ] },
 ]
 
 [project.theme]