ST1S14PHR 3V3 3A

KiCad

Table of Contents

• KiCad
  • Table of Contents
  • About
  • Setup
    • Required Tools
    • Setup Instructions
      • 1. Install the Tools
      • 2. Clone the Repository
      • 3. Set the KICAD_LIBRARY Environment Variable
      • 4. Authenticate Git and the GitHub CLI
      • 5. Configure VS Code and GitHub Copilot
    • Project Initialization Script
      • What the Script Does
      • Usage
      • Non-Interactive Usage
  • Directories
  • PCB Template Structure
    • Template Naming Convention
    • Available Templates
    • Template Selection
    • Adding Custom Templates
  • CI/CD Pipelines
    • PCB
    • Changelog Check
    • Documentation
    • Code Style Check
    • PlatformIO Firmware
    • ESP-IDF Component
    • Component Release
  • Release Workflow
    • Version Scheme
    • create-dev-branch Skill
    • create-release Skill
      • Prerequisites
      • Usage of the Skill
      • What the Skill Does
      • Files Changed by the Skill
  • GitHub Secrets Configuration
  • GitLab CI/CD Variables
  • How to Obtain API Keys
  • Part-DB
    • Part Links with a Hostname
    • Resolve the Hostname on Windows
    • create-partdb-part Skill
  • Resources
  • Maintainer

About

My private KiCad repository with symbols, 3D models (most of the models are delivered by the part manufacturer, GrabCAD, 3D ContentCentral or SnapEDA), and footprints for different projects.

Please write an e-mail to DanielKampert@kampis-elektroecke.de if you have any questions.

Setup

Required Tools

Setup Instructions

1. Install the Tools

Linux (Debian/Ubuntu):

sudo apt update
sudo apt install git python3 curl

Install KiCad from the KiCad download page and the GitHub CLI by following the official installation instructions. The distribution packages of both tools are often outdated.

Windows (PowerShell):

winget install --id KiCad.KiCad
winget install --id Git.Git
winget install --id Python.Python.3.12
winget install --id GitHub.cli
winget install --id Microsoft.VisualStudioCode

Add the bin directory of KiCad (e.g. C:\Program Files\KiCad\10.0\bin) to the PATH, so that kicad-cli can be found.

Verify the installation:

git --version
python3 --version
kicad-cli version
gh --version

2. Clone the Repository

The template and the plugins are included as Git submodules, so clone the repository recursively:

git clone --recurse-submodules https://github.com/Kampi/KiCad

For an existing clone, fetch the submodules with git submodule update --init --recursive.

3. Set the KICAD_LIBRARY Environment Variable

Create an environment variable with the name KICAD_LIBRARY and set it to the location of the repository.

Linux/macOS:

echo 'export KICAD_LIBRARY="$HOME/Projects/KiCad"' >> ~/.bashrc
source ~/.bashrc

Windows (PowerShell):

[Environment]::SetEnvironmentVariable("KICAD_LIBRARY", "C:\KiCad", "User")

Restart KiCad and all terminals afterwards.

4. Authenticate Git and the GitHub CLI

git config --global user.name "John Doe"
git config --global user.email "john.doe@example.com"
gh auth login --hostname github.com --git-protocol https --web
gh auth setup-git
gh auth status

gh auth setup-git makes Git use the credentials of the active GitHub CLI account, so git push and gh always use the same account. With several accounts, add them with gh auth login and switch with gh auth switch --user <username>.

5. Configure VS Code and GitHub Copilot

1. Install the GitHub Copilot extension and sign in with your GitHub account

2. Open the generated project folder (not the KiCad repository) in VS Code, so that the skills in .github/skills/ are found

3. Make sure agent skills are enabled (chat.useAgentSkills, enabled by default)

4. Windows only: The skill uses Bash commands. Set Git Bash as the terminal profile for agent commands:

   "chat.tools.terminal.terminalProfile.windows": {
       "path": "C:\\Program Files\\Git\\bin\\bash.exe"
   }

Project Initialization Script

The Scripts directory contains initialization scripts for creating new projects from the template:

• Scripts/init-project.ps1 - Windows PowerShell script
• Scripts/init-project.sh - Linux/macOS Bash script

The scripts find the template via the KICAD_LIBRARY environment variable or, if it is not set, relative to their own location.

Project Types

The scripts ask for the project type and keep only the directories, the firmware profile and the GitHub Actions workflows that belong to it:

• PlatformIO profile: ESP32 (esp32dev) with the ESP-IDF framework. The platform espressif32 @ 7.1.3 contains ESP-IDF v6.1. Hardware independent code in lib/ is tested on the host with the native environment
• ESP-IDF component profile: Component for ESP-IDF v6.1 or later with idf_component.yml, an example project in examples/basic and its own README.md and CHANGELOG.md. The sources are named after the repository (my-component becomes my_component.h)
• Project types without hardware get no KiCad project, no hw-* workflows and no release skills. The GitLab CI pipelines are not adapted to the project type yet
• A component cannot be combined with hardware in one repository, because the component release and the hardware release both use the tag x.y.z

What the Script Does

1. Project metadata: Prompts for project name, board name, designer, email, repository URL, company, main branch, target directory and the project type
2. PCB template selection (project types with hardware): Lists the PCB templates from Template-Project/hardware/ and applies the selected one
3. Project structure: Copies the complete template (hardware, firmware, CAD, 3D print, scripts, GitHub Actions workflows, GitLab CI pipelines and agent skills), removes template artifacts such as backups, VARIABLES.md and the Git data of the template, and applies the project type
4. Renaming: Renames the hardware directory to the lowercase board name and all Template.* files to <BoardName>.*
5. Metadata: Updates the text variables in the .kicad_pro file (PROJECT_NAME, BOARD_NAME, DESIGNER, COMPANY, release date and revision), the sheet title of the main schematic, kibot_main.yaml and the workflow settings
6. License: Prompts for an open source license (or no license) and downloads the license text
7. Placeholders: Replaces all ${...} placeholders in every text file of the project, including the GitLab CI pipelines and the agent skills
8. Documentation: Creates the AsciiDoc scaffolding in firmware/docs/ (not for the ESP-IDF component)
9. Git repository: Initializes the repository with the main branch, the remote origin, the commit message template .github/.commit-msg-template and an initial commit, and optionally pushes it

Usage

Windows (PowerShell):

cd C:\path\to\KiCad
.\Scripts\init-project.ps1

Linux/macOS (Bash):

cd /path/to/KiCad
./Scripts/init-project.sh

The script guides you through an interactive setup. Afterwards the target directory contains a fully configured KiCad project. The Bash script checks whether Python 3 is installed and prints installation instructions if it is missing.

Non-Interactive Usage

For automated or scripted usage, you can pipe all inputs to the initialization script using echo:

Windows (PowerShell):

"MyProject`nMyBoard`nJohn Doe`njohn.doe@example.com`nhttps://github.com/user/repo`nMyCompany`nmain`nC:\Projects`n1`n1`n1`nn" | .\Scripts\init-project.ps1

Linux/macOS (Bash):

echo -e "MyProject\nMyBoard\nJohn Doe\njohn.doe@example.com\nhttps://github.com/user/repo\nMyCompany\nmain\n/home/$(whoami)/projects\n1\n1\n1\nn" | ./Scripts/init-project.sh

Input Order:

1. Project name (e.g., "MyProject")
2. KiCad board name (e.g., "MyBoard", or press Enter to use project name)
3. Designer name (e.g., "John Doe")
4. Designer email (e.g., john.doe@example.com)
5. GitHub repository URL (e.g., https://github.com/user/repo) - username and repository name are extracted automatically
6. Company name (optional, or press Enter to skip)
7. Main branch name (default: "main")
8. Target directory (default: current directory)
9. Project type selection (1-4, default: "1" for hardware, see Project Types)
10. PCB template selection (number, e.g., "1" for first template). Only asked for project types with hardware, leave it out for the types 3 and 4
11. License selection (1-11, e.g., "1" for MIT)
12. Push to GitHub now (y/N, default: no)

Note: Empty values (just \n or backtick-n in PowerShell) will use the default value for that field.

Directories

The repository contains the following directories and files:

• 3D: 3D models in STEP format used by the library
• Applications: Additional applications, e.g. the Part-DB integration
• Design-Blocks: KiCad design blocks
• Drawings: Inventor projects for different 3D models
• Footprints: Part footprints
• GitHub: Third-party libraries as Git submodules (Espressif KiCad libraries)
• Layout: Drawing sheet templates
• Plugins: KiCad plugins as Git submodules (KiCad Project Initialization Plugin)
• Scripts: Project initialization scripts
• Symbols: Part symbols
• Template-Project: Project template (Git submodule)
• KiCad Workflow.md: Development workflow, version numbering and GitHub workflow
• AGENTS.md: Project guidelines for AI coding agents (GitHub Copilot, Claude Code, Codex, Cursor and others). .github/copilot-instructions.md and CLAUDE.md only point to it. Rules for single areas are in .github/instructions/

PCB Template Structure

The project template supports multiple PCB stackup configurations through template files. Templates must be placed in the Template-Project/hardware/ directory.

Template Naming Convention

PCB template files must follow this exact naming pattern:

Template - <manufacturer>_<thickness>_<layers>-layer.kicad_pcb

Components:

• Template - - Fixed prefix (required)
• <manufacturer> - PCB manufacturer name (e.g., pcbway, jlcpcb, oshpark)
• <thickness> - Board thickness with unit (e.g., 1.6mm, 0.8mm, 2.0mm)
• <layers> - Number of copper layers (e.g., 2, 4, 6)
• -layer.kicad_pcb - Fixed suffix (required)

Available Templates

• Template - pcbway_1.6mm_2-layer.kicad_pcb - PCBWay, 1.6mm thickness, 2 layers
• Template - pcbway_1.6mm_4-layer.kicad_pcb - PCBWay, 1.6mm thickness, 4 layers

Template Selection

During project initialization, the script will:

1. Scan the Template-Project/hardware/ directory for all template files
2. Parse the manufacturer, thickness, and layer count from each filename
3. Present an interactive menu with available templates
4. Copy the selected template as the base PCB file for the new project and remove the unused templates

Adding Custom Templates

To add a new PCB template:

1. Create a KiCad PCB file with your desired stackup and design rules
2. Name the file following the convention above
3. Place it in the Template-Project/hardware/ directory
4. The template will automatically appear in the selection menu

Template Requirements:

• Must be a valid .kicad_pcb file
• Should include appropriate design rules for the manufacturer
• Should contain stackup configuration matching the specified layer count
• Recommended to include manufacturer-specific constraints (trace width, spacing, etc.)

CI/CD Pipelines

The project template contains pipelines for GitHub Actions (Template-Project/.github/workflows/) and GitLab CI (Template-Project/.gitlab/ci/, included by Template-Project/.gitlab-ci.yml).

The GitHub Actions workflows are grouped by a prefix in the file name and in the workflow name, so they are listed together in the Actions view. The initialization script removes the workflows that do not belong to the project type.

PCB

Trigger: Push to dev or a development branch x.y.z_Dev / x.y_Dev, push of a version tag x.y.z, or manual start. The GitHub workflow only runs for branch pushes that change the hardware directory or hw-pcb.yaml. Tag pushes always start it

A push to main or master does not start the GitHub workflow. The main branch only receives releases, and a release is built by its tag. The GitLab pipeline still runs for main and master (except changes to *.md)

A branch x.y_Dev only triggers the build. Releases always use the three-part version scheme x.y.z

Generates the hardware outputs with KiBot in the kicad10_auto_full container:

• Variant-based builds: Uses the variant from kibot_variant. Tag pushes always use RELEASED
• Outputs: Schematic PDF, Gerbers, drill files, BoM, assembly documents, 3D renders and reports. The outputs are uploaded as workflow artifact (GitLab: job artifact) and not committed. Only the netlist XML is pushed back to the branch, because the next run reads the sheet titles from it
• ERC/DRC checks: Only for the CHECKED and RELEASED variants
• BoM check: scripts/python/check-bom.py compares the generated BoM (CSV and XLSX) with the schematic. The check fails when a fitted component is missing in the BoM, when the BoM lists a component that is not fitted or excluded from the BoM, or when the CSV and the XLSX BoM differ. A failed check is reported as error, but does not stop the pipeline or the release: GitHub shows an error annotation for the step Check BoM against schematic, GitLab marks the job pcb:check_bom as failed with a warning. The report lists the components that are not expected in the BoM by reason (DNP, test points, mounting holes, ...) and is shown in the job summary (GitLab: bom_check.md in the artifact of pcb:check_bom). The result is also stored as Markdown checklist <board>-bom_check.md next to the BoM, so it is part of the artifact and the release. The checklist contains the automatic checks and the components for the manual review
• Cost analysis: Runs KiCost with the distributor API keys. Missing keys do not fail the pipeline
• Release (tag pushes only): Updates CHANGELOG.md on the main branch, creates the GitHub/GitLab release with the outputs as ZIP file and publishes the outputs to GitHub/GitLab Pages. GitHub Pages is only updated by releases, so it always shows the state of the latest release

Variants:

• DRAFT: Schematic only, generates PDF, netlist and BoM (skips ERC/DRC)
• PRELIMINARY: Full outputs without ERC/DRC. Set by the create-dev-branch skill
• CHECKED: Full outputs with ERC/DRC. Set by the create-release skill
• RELEASED: Full outputs with ERC/DRC, automatically used for version tags

Enclosed components:

Components that are not assembled, but supplied loose with the board (e.g. jumpers, screws, spacers, cables), are marked with the value Enclosed in the symbol field assembly. The project template offers this field for every symbol. Leave it empty for all other components.

• BoM: Enclosed components stay in the BoM (CSV, HTML and XLSX) and are marked in the column Assembly. They get their own row, even when an assembled component has the same value and part number
• Position file: Enclosed components with a footprint are removed from the position file
• Assembly notes: A note tells the assembler that the components marked as Enclosed are not populated

Don't set DNP or Exclude from bill of materials for these components, otherwise they are removed from the BoM. A component without a footprint also needs Exclude from board. The field name and the value are set by ASSEMBLY_FIELD and ASSEMBLY_ENCLOSED in hardware/kibot_yaml/kibot_main.yaml

Changelog Check

Trigger: Pull/merge requests targeting main or master, push to main, master or dev

Validates the changelogs of the project. The GitHub workflow checks <board>/CHANGELOG.md, firmware/CHANGELOG.md and CHANGELOG.md (ESP-IDF component) and skips the files that do not exist. The GitLab pipeline checks <board>/CHANGELOG.md:

• The ## [Unreleased] section must exist
• Entries must be grouped under **Added:**, **Changed:**, **Fixed:** or **Removed:**
• Each entry must start with a dash and a space

Example:

## [Unreleased]

**Added:**

- New feature description (#12)

**Fixed:**

- Bug fix description (#13)

Documentation

Trigger: Push to main or master and pull/merge requests that change firmware/docs/** or the pipeline file, or manual start

• Converts all AsciiDoc files in firmware/docs/ to HTML and PDF and generates a landing page
• Publishes the result to GitHub/GitLab Pages

Code Style Check

Trigger: Pull/merge requests, push to main, master or dev, or manual start. The GitHub workflow only runs when C/C++ sources, scripts/ or the workflow file change

• Builds AStyle and runs scripts/bash/check-format.sh in dry-run mode. Style violations are reported, files are not changed
• The GitHub workflow checks the directories from source_dirs (firmware, for the ESP-IDF component src include examples). Without arguments the script checks src and include
• GitLab only: west-clang-format.gitlab-ci.yml checks Zephyr/West based firmware with clang-format instead of AStyle. It runs scripts/bash/check-clang-format.sh for the directories from SOURCE_DIRS (firmware). The job only exists in repositories with a West manifest (west.yml), a West workspace is not needed
• The style for Zephyr/West based firmware is stored in scripts/config/.clang-format: the rules of the Zephyr project with an indentation of 4 spaces instead of tabs. Copy the file as .clang-format to the root of the West application, then clangd and clang-format use it in the editor. It requires clang-format 16 or later
• A West based project is checked by both GitLab jobs. Remove astyle.gitlab-ci.yml from the include: list of .gitlab-ci.yml in such a project, because the AStyle rules differ from the clang-format rules

PlatformIO Firmware

Trigger: Pull requests and pushes to main, master, dev or a development branch that change firmware/ or the workflow file, or manual start

Builds, tests and checks the PlatformIO project in firmware/ (GitHub Actions only):

• Build: Reads the environments from platformio.ini and builds every environment except the ones with the native platform as a matrix. The firmware images (*.bin, *.elf) are uploaded as workflow artifact
• Unit tests: Runs pio test -e native on the host
• Static analysis: Runs pio check (cppcheck) for every target environment and fails on defects of medium or high severity

The firmware has no release pipeline. A version tag x.y.z starts the hardware release only.

ESP-IDF Component

Trigger: Pull requests and pushes to main, master, dev or a development branch (except changes to *.md), or manual start

Builds and validates the component in the repository root (GitHub Actions only):

• Build: Builds every example in examples/ in the espressif/idf Docker image for each combination of the matrix idf_version (default: v6.1) and target (default: esp32). Add versions or targets to the matrix to cover them
• Validation: Packs the component with compote component pack. This checks idf_component.yml without uploading anything

Component Release

Trigger: Push to main or master (merge of a development branch)

Releases an ESP-IDF component:

• Takes the version from the merge commit (Merge branch 'x.y.z_Dev') or the branch name
• Updates CHANGELOG.md, CMakeLists.txt and idf_component.yml, commits the changes and pushes the tag x.y.z
• Creates the GitHub/GitLab release. The GitHub workflow also uploads the component to the ESP Component Registry

Release Workflow

A hardware release follows the development cycle of the template:

1. Create a development branch x.y.z_Dev with the create-dev-branch skill. It branches off the main branch, sets the KiBot variant to PRELIMINARY and prepares the changelog variables for the release
2. Work on the design and document all changes in the ## [Unreleased] section of CHANGELOG.md
3. Create the release with the create-release skill. It merges the development branch into the main branch and pushes the tag x.y.z, which triggers the RELEASED build and the GitHub release

Version Scheme

Releases use exactly three numeric parts x.y.z (major, minor, patch), e.g. 1.2.0. A two-part version like 1.2 is not a valid release version, write it as 1.2.0.

The version is defined once by the name of the development branch. The tag, the commit message and the changelog variables are derived from it and are never entered separately.

The create-dev-branch skill extends a shorter input to this format (1.2 becomes 1.2.0). The create-release skill and the tag trigger of the PCB pipeline only accept this format. With a branch 1.2_Dev the skill stops, and a tag 1.2 or v1.2.0 does not start the release pipeline.

create-dev-branch Skill

The template contains the agent skill create-dev-branch in Template-Project/.github/skills/create-dev-branch/SKILL.md. GitHub Copilot finds it there, Claude Code finds it through the pointer in Template-Project/.claude/skills/create-dev-branch/SKILL.md. The initialization script copies it into every new project and replaces the placeholders (${BOARD_NAME}, ${BOARD_NAME_LOWER}, ${MASTER_BRANCH}) with the project values.

The skill prepares a development branch from any state of the main branch, so that only the design work and the changelog entries are missing before the create-release skill is started. It requires git, python3, an authenticated GitHub CLI and a clean working tree. The branch is pushed with the user that is logged in to the GitHub CLI. Start it in the Agent mode of the Chat view with /create-dev-branch.

1. Version: Asks for the version of the next release and extends it to x.y.z. Stops if the tag or the branch already exists
2. Main branch: Pulls the main branch (main or master, from master_branch in hw-pcb.yaml)
3. Branch: Creates the development branch x.y.z_Dev
4. Production data: Removes the production directory (kibot_output_path in hw-pcb.yaml) with the outputs of the previous release. The netlist XML is kept
5. Variant: Sets kibot_variant in .github/workflows/hw-pcb.yaml to PRELIMINARY
6. Changelog variables: Adds a free x.y.z entry for RELEASE_TITLE_<version> and RELEASE_BODY_<version> to the KiBot configuration and to the revision history sheet. It uses the unused column (${RELEASE_TITLE_...}) following the newest release. If all columns of the table are used, the column of the oldest release is replaced
7. Commit and push: Commits Prepare Development Branch for Release x.y.z and pushes the branch after a confirmation

The skill is based on the GitHub Actions workflow hw-pcb.yaml. It does not change the GitLab CI pipelines.

create-release Skill

The template contains the agent skill create-release in Template-Project/.github/skills/create-release/SKILL.md. GitHub Copilot finds it there, Claude Code finds it through the pointer in Template-Project/.claude/skills/create-release/SKILL.md. The initialization script copies it into every new project and replaces the placeholders (${BOARD_NAME}, ${BOARD_NAME_LOWER}, ${MASTER_BRANCH}) with the project values.

The skill is based on the GitHub Actions workflow hw-pcb.yaml and the GitHub CLI. It does not support GitLab CI.

Prerequisites

• All required tools for the skill are installed: git, python3, kicad-cli (KiCad 10 or later) and gh
• The GitHub CLI is authenticated with an account that can push to the repository (gh auth status). All pushes of the skill are done with this user
• The working tree is clean (git status --porcelain is empty)
• The current branch is the development branch x.y.z_Dev (three parts, see Version Scheme). The release version is always taken from the branch name
• The ## [Unreleased] section of CHANGELOG.md contains entries
• The tag x.y.z does not exist yet
• kibot_yaml/kibot_pre_set_text_variables.yaml and the revision history sheet contain a free x.y.z entry for the changelog variables, or already the entries for the release version

Usage of the Skill

1. Open the project in VS Code and check out the development branch, e.g. 1.2.0_Dev

2. Open the Chat view and select Agent mode

3. Start the skill with the slash command or a prompt:

   /create-release

   Create the release for the current development branch.

4. Confirm the summary (version, development branch, main branch) before the skill pushes anything

The skill stops at the first failing step and reports the error. It never deletes or moves a tag without asking.

What the Skill Does

1. Checks: Validates the branch name, the project files, the env section of hw-pcb.yaml, the changelog and the tag
2. ERC and DRC: Runs kicad-cli sch erc and kicad-cli pcb drc (with schematic parity). Errors abort the release, warnings do not
3. Changelog variables: Sets the free x.y.z entries for RELEASE_TITLE_<version> and RELEASE_BODY_<version> in the KiBot configuration and in the revision history sheet to the release version
4. Variant: Sets kibot_variant in .github/workflows/hw-pcb.yaml to CHECKED
5. Commit and push: Commits Prepare Release x.y.z and pushes it to the development branch
6. KiBot pipeline: Waits for the Hardware / PCB Data workflow of the commit with gh run watch
7. Merge: Pulls the netlist XML generated by the pipeline and merges the development branch into the main branch
8. Tag: Creates the tag x.y.z and pushes the main branch and the tag atomically
9. Release pipeline: Waits for the run of the tag, which builds the release, and reports the URL of the GitHub release. Only this run decides whether the release was successful. The push of the main branch starts no run
10. Pull: Pulls the main branch (main or master, from master_branch in hw-pcb.yaml) to get the released state with the updated CHANGELOG.md

Files Changed by the Skill

GitHub Secrets Configuration

Add the secrets in the repository settings under Settings > Secrets and variables > Actions.

GITHUB_TOKEN is provided automatically. The workflows use it to push the netlist and the changelog, to create releases and to deploy GitHub Pages. For the Pages deployment set Settings > Pages > Source to GitHub Actions.

GitLab CI/CD Variables

Add the variables in the project settings under Settings > CI/CD > Variables and mark them as masked.

How to Obtain API Keys

Only the Mouser API is enabled in kibot_yaml/kicost_config_local.yaml of the template. Enable further distributors there before you add their keys.

Mouser API Key:

1. Register at Mouser Electronics
2. Navigate to API Hub
3. Request access to the Search API and copy the key

DigiKey API Key:

1. Register at the DigiKey API Portal
2. Create an application and copy the client ID and the client secret

ESP Component Registry Token:

1. Log in to the ESP Component Registry
2. Navigate to your profile settings
3. Generate an API token for component uploads

Part-DB

Notes for using Part-DB as KiCad HTTP library. The examples use the hostname inventory.lan and the server address 192.168.178.103, replace them with your own values.

Part Links with a Hostname

Part-DB builds the links of a part (fields datasheet and Part-DB URL) from the host KiCad uses for the request. A library that calls Part-DB by its IP address gets links like http://192.168.178.103:8980/de/part/109/info.

Use the hostname in the root_url of the .kicad_httplib file to get links with the hostname:

"root_url": "https://inventory.lan/de/kicad-api/",

Symbols that are already placed keep the old link, because it is stored in the symbol. Update them in the schematic editor with Tools > Update Symbol Fields from Library.

Resolve the Hostname on Windows

KiCad can not load the library if Windows does not resolve the hostname. This happens when the router announces itself as additional DNS server via IPv6 and does not know the local name, even if the local DNS server does. Check it with:

Resolve-DnsName inventory.lan

If no address is returned, add the name to the hosts file. The file can only be written with administrator rights, the command starts an elevated PowerShell for it:

Start-Process powershell -Verb RunAs -ArgumentList '-NoProfile -Command "Add-Content $env:SystemRoot\System32\drivers\etc\hosts ''192.168.178.103 inventory.lan''"'

ping inventory.lan must show the address of the server afterwards. Restart KiCad to load the library again.

The entry is only valid for this computer. For all devices in the network, stop the router from announcing itself as DNSv6 server, so only the local DNS server is used.

create-partdb-part Skill

The agent skill create-partdb-part adds a component to Part-DB. It reads the existing parts of the same kind as schema, fetches the datasheet, the image and the prices through the Part-DB info providers and creates the part with parameters, attachments, order details and stock lot. It never deletes or changes existing parts.

The skill asks before it guesses:

• Info source: Always asks whether the data comes from an active info provider of Part-DB (e.g. Mouser) or from another source
• Part number: Checks that the info source knows exactly this number and that the values coded in it match. Asks when the number is not found, ambiguous or contradicting
• Assignment: Asks when the category, the footprint, the manufacturer or the storage location is not clear from the existing parts
• Symbol and footprint: Uses the symbol and the footprint of the own KiCad library when they exist there, and only falls back to the libraries shipped with KiCad for what is missing. Asks when several own symbols or footprints fit
• Label: Generates a label with the label profile of Part-DB that fits the kind of the part. Asks when no profile or several profiles fit
• Printer: Always asks on which installed printer the label is printed

Ask the agent for it in the chat, e.g. Add the part CR0805-JW-182ELF to Part-DB.

The skill reads the server and the token from the environment. Variables that are not set there are read from the file .partdb.env in the root of this repository. The file is ignored by Git and contains one NAME=value per line:

PARTDB_URL=https://inventory.lan
PARTDB_TOKEN=<API token>

Resources

• KiBot Template
• KiCad Project Template

Maintainer

• Daniel Kampert