# EasyEDA API Skill: a WebSocket bridge that lets an AI agent drive the EDA client

> The easyeda-api-skill repository packages two things for AI coding tools: a built, indexed reference for the EasyEDA Pro API, and a Node.js bridge server that a companion EasyEDA extension connects to so the agent can execute code inside the running client. The documentation is thin in one place, where the package manifest and the README disagree about which npm scripts exist.

**easyeda/easyeda-api-skill** — 嘉立创EDA专业版AI SKILL，为AI编程工具提供完整的EasyEDA Pro API接口和WebSocket桥接能力。EasyEDA Pro AI SKILL provides a complete EasyEDA Pro API interface and WebSocket bridging capability for AI programming tools.

- Repository: https://github.com/easyeda/easyeda-api-skill
- Stars: 1,055 · Forks: 80
- Language: JavaScript
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/easyeda-easyeda-api-skill

## Two deliverables in one repository: references and a bridge

The package is described as an EasyEDA Pro API skill package for AI coding tools such as Claude Code, OpenCode, QwenCode, and any other tool that supports the Agent Skills standard. The point of the standard is that the tool reads a skill definition file and follows it, so the repository is written to be consumed by an agent rather than imported as a library.

Two use cases are described and they are not the same thing. The first is online debugging of EasyEDA Pro through AI, where the agent needs to call into a running editor. The second is extension development, where the agent needs API references, type information, usage examples and documentation about document source formats, so it can look up a signature, generate code and debug an integration. The second use case needs no running client. The README also offers a third path for people who would rather work on the underlying project, schematic and PCB source formats directly than go through the API at all.

For the audience that matters, an EasyEDA Pro extension developer working with an AI assistant, the package removes the two things that slow such work down: hunting for an API signature by hand, and guessing at code that cannot be run until the editor is open.

## The bridge binds a port in the 49620 range and waits for the client

The bridge is a Node.js server, and the connection scheme is designed around the fact that the EasyEDA client is a desktop application you launch yourself. The server picks an available port automatically inside the 49620 to 49629 range and then waits for the client to arrive. The client side is a separate extension, run-api-gateway.eext, which the README tells you to install into EasyEDA and download from a jlcext.com item page. Once loaded, that extension finds the server by scanning the port range and verifying the handshake, so you never type a port number into the extension yourself.

That design has a clear consequence for how the pieces sit in a workflow. The bridge is a local, developer-machine process, and the extension is the part that actually reaches the editor. The manifest is small, which is worth noting because the only runtime dependency declared is the WebSocket library:

```json
{
  "name": "easyeda-api",
  "version": "1.1.56",
  "type": "module",
  "scripts": {
    "server": "node scripts/bridge-server.mjs"
  },
  "dependencies": {
    "ws": "^8.21.3"
  }
}
```

Everything else the skill offers, the reference documentation, the format specifications, the guides and the packaging, is static text that the agent reads. The WebSocket layer is the only part that needs a running program on both ends.

## Five message types and a handshake that names the service

The protocol is small and it is worth reading closely, because the handshake is what makes the port scan safe. The documented message types are execute, sent from the AI side to the EDA side to run JavaScript code, result and error, which travel back to the AI side, handshake, sent from server to client for connection verification and carrying the field service: "easyeda-bridge", and ping/pong, a heartbeat in both directions.

Two properties follow from that list. The handshake field is what lets a client verify it has found the right service rather than an unrelated listener that happens to sit on a candidate port, which matters precisely because the range is scanned. And the heartbeat means a stalled editor session is detectable rather than a request that hangs indefinitely.

On the AI side the transport to the bridge is plain HTTP, and two endpoints are shown in the quick start. The health endpoint reports whether the service is connected, and the execute endpoint takes a JSON body with a code field that is evaluated in the client:

```bash
# Check EasyEDA connection status (assuming the service is on port 49620)
curl http://localhost:49620/health

# Execute EasyEDA code
curl -X POST http://localhost:49620/execute \
  -H "Content-Type: application/json" \
  -d '{"code": "return await eda.dmt_Project.getCurrentProjectInfo();"}'
```

That example calls a project information method through the eda namespace, which tells you the executed code runs against a live editor session with a real project loaded, not against a mock.

## Reference documents are compiled into an index the agent can search

The documentation side of the package is a build step rather than a pile of markdown. The README describes the API documentation as structured, built automatically by generating hierarchical indexes from reference documents so the agent can look things up quickly. The build reads the raw API documentation from the reference directory and writes structured documentation into the docs directory.

Both directories are marked as gitignored in the directory listing, which is an important detail for anyone cloning the repository. reference/ holds the raw API reference docs and is gitignored, and docs/ holds the built output and is gitignored as well. What is tracked in the repository root is README.md, the Simplified Chinese README, SKILL.md, package.json, package-lock.json, and the format/, guide/, references/, scripts/ and user-guide/ directories. So the docs you consume are produced locally by a build, and the source of truth for the API lives in files the clone does not bring with it.

Alongside that, three content areas support the work: format/ for the document source format specifications covering project, schematic and PCB formats, guide/ for API development guides, and user-guide/ for user-facing guides. The user-guide/ directory is unusual for a developer package and is worth a look before you assume every file in the repository is aimed at an agent.

## The README names five npm scripts and the manifest declares one

Here is the gap in the project. The quick start tells you to install dependencies with npm install, then build the documentation with npm run build:docs, then start the bridge with npm run server, and later to package with npm run pack or npm run pack:fast. The manifest shown above declares only one script, server, pointing at scripts/bridge-server.mjs. The scripts for building docs and packing are therefore not declared in the version of package.json included here, even though the scripts/ directory in the tree does contain build-docs.mjs and pack.mjs.

This matters more than a documentation nit, because a fresh clone plus the documented commands is exactly the path a new user takes. The documented flow also shows a directory split that the manifest does not match: the directory listing places the bridge at server/index.mjs while the npm script runs scripts/bridge-server.mjs. Both of these differences are visible in the repository as it stands, and neither is explained anywhere in the text.

The safe approach for an adopter is to check what your checkout actually declares before trusting the quick start, and to read scripts/ directly if a documented command fails. This is exactly the kind of drift that the automated index is meant to smooth over for API questions, and it is less well handled for build questions.

## Packaging produces a directory and a zip, then ClawHub does the publishing

Distribution is handled by a packaging script rather than by a release process, since the repository has no GitHub releases. The README describes the pack command as a one step operation that builds the API documentation into docs/, packages SKILL.md, the documentation and the server into dist/easyeda-api/, and generates dist/easyeda-api.zip for upload. A fast variant exists for the case where the documentation has already been built.

```bash
npm run pack
```

```bash
npm run pack:fast
```

Publishing then goes to ClawHub, either through the command line:

```bash
npx clawhub@latest publish dist/easyeda-api/
```

or by uploading the zip file at the clawhub.ai upload page. The output directory dist/ is gitignored, and the packaged directory easyeda-api/ is what gets published. So the delivery chain is: build docs, package, publish to a skill registry. The version that travels with it is the one in package.json, currently 1.1.56, and since there is no release history on the repository, that manifest field is the only version reference a consumer can find.

## No releases, an unstated licence, and a repository that still changes

Two governance facts stand out. The repository lists no GitHub releases, so there is no changelog, no release notes and no published artefact trail to inspect; the packaged zip and the ClawHub listing are the distribution record instead. And the licence field of the repository is not stated, so there is no licence identifier to check against, no license file mentioned in the top level listing, and no grant of rights visible in the README either. For anyone planning to copy code or documentation from this package into a product, that gap has to be closed by asking, not by assuming.

The code itself, meanwhile, is being changed. The repository is not archived and the last push was on 2026-10-17. Since the package version lives in package.json and there is no tagged release, a consumer pinning easyeda-api at a version gets a snapshot of the manifest, while the bridge server and the documentation builder can change underneath that pin. Anyone automating a build around this package should track the version in package.json and the last push separately, because they answer different questions.

## Conclusion

Adopt this package when you build EasyEDA Pro extensions with an AI coding tool and want the agent to look up API signatures and test code against a live client, and accept that the bridge is a local loopback service exposing an execute endpoint. Do not adopt it as a general design automation library, since the skill targets EasyEDA Pro only and its licence is not stated in the repository. Verify first that npm run server and npm run build:docs exist in your checkout of package.json, that the run-api-gateway.eext extension from jlcext.com can reach a port in the 49620 to 49629 range, and read the licence situation before shipping anything derived from it.

## FAQ

### How do I start the EasyEDA API Skill bridge server?

Install dependencies with npm install and run npm run server, which starts the Node.js bridge. The server picks an available port in the 49620 to 49629 range and waits for the EasyEDA client to connect.

### How does the EasyEDA client find the bridge server?

The run-api-gateway.eext extension, downloaded from the jlcext.com item page, scans the port range and verifies the handshake before connecting, so no port needs to be entered by hand.

### Which npm scripts does the easyeda-api package declare?

The package.json included with the repository declares a single script, server, which runs node scripts/bridge-server.mjs. The README also refers to build:docs, pack and pack:fast, so check the manifest in your checkout before relying on those.

### Can I use EasyEDA API Skill without running EasyEDA Pro?

For extension development you can use the API references, type information, usage examples and the document source format specifications without a running client. The live debugging path needs both the bridge server and the extension inside EasyEDA.

## Sources

- [easyeda/easyeda-api-skill on GitHub](https://github.com/easyeda/easyeda-api-skill)
- [Issues](https://github.com/easyeda/easyeda-api-skill/issues)
- [README](https://github.com/easyeda/easyeda-api-skill/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/easyeda-easyeda-api-skill