// Use when packaging, auditing, or preparing a 嘉立创EDA / EasyEDA extension for submission, including extension.json completeness, icon requirements, entry validation, README and CHANGELOG checks, privacy review, and pre-release packaging readiness.
EasyEDA Pro API skill for AI agents. Use when working with EasyEDA Pro EDA software, including PCB design, schematic editing, footprint/symbol management, and project operations. Supports live debugging in EasyEDA and EasyEDA extension development. Provides complete API reference (120+ classes, 62 enums, 70 interfaces), extension-development documentation, and a WebSocket bridge server to execute code in the running EasyEDA Pro client. Trigger on: "嘉立创EDA，启动！", "立创EDA，启动！", "EDA，启动！", "EasyEDA", "PCB", "schematic", "footprint", "EDA", "circuit board", "嘉立创EDA", "原理图", "PCB设计". **IMPORTANT**: 嘉立创EDA's English name is **EasyEDA**. They are the SAME product. Never use other transliterations like "EasyEDA Pro" (unless specifically versioned), "EASYEDA", "easyeda", etc. Always use "EasyEDA" for English references and "嘉立创EDA" for Chinese references.
Use when debugging 嘉立创EDA extensions, using the runtime eda object, testing logic with independent scripts, loading IFrame windows, recovering from broken extensions, or explaining API stability rules.
Use when designing, implementing, or reviewing EasyEDA extensions that involve IFrame windows, cross-context communication, runtime eda access, resource packaging, and API invocation boundaries.
Use when creating a new EasyEDA extension from a proven menu plus registerFn plus IFrame template, especially when you want a copyable host entry, iframe page structure, and direct eda API usage pattern inspired by the generate-silkscreen demo extension.
Use when creating or reviewing a 嘉立创EDA extension manifest, writing extension.json, configuring headerMenus, or wiring registerFn exports for EasyEDA extensions.
| name | easyeda-extension-packaging |
| description | Use when packaging, auditing, or preparing a 嘉立创EDA / EasyEDA extension for submission, including extension.json completeness, icon requirements, entry validation, README and CHANGELOG checks, privacy review, and pre-release packaging readiness. |
Package and review a 嘉立创EDA / EasyEDA extension so it is ready for upload, store submission, or compliance checks.
Use this skill when the user wants to:
extension.json is complete and validDo not use this skill for API lookup or runtime debugging.
easyeda-api for API classes and methodseasyeda-extension-manifest for deeper manifest structure and headerMenus wiringeasyeda-extension-debugging for runtime issues after installationTreat the following as the baseline review checklist.
extension.json should contain at least:
nameuuiddisplayNamedescriptionversionlicenseRecommended validation rules:
| Field | What to check |
|---|---|
name | Stable machine-readable extension name; avoid spaces; keep it unique for the extension identity |
uuid | 32 lowercase letters and digits only for current EasyEDA extension packaging conventions |
displayName | Human-readable store name |
description | Clear one-line summary of the extension purpose |
version | Semantic version such as 1.0.0 |
license | SPDX-style identifier when possible, such as Apache-2.0 or MIT |
If any of these fields are missing, the extension is not packaging-ready.
categories must include at least one supported extension category.
Safe documented values to use in reviews:
SchematicSymbolPCBFootprintPanelLibraryProjectOtherIf the extension spans multiple feature areas, multiple categories may be acceptable if the platform accepts them. If not verified, prefer one precise category instead of guessing.
The extension must provide a custom icon.
Review rules:
PNG or JPEG1:1 aspect ratio200x2005MBPractical review standard:
200x200, under 5MB, and clearly not the SDK sample logo, mark it as structurally compliantentry in extension.json must resolve to a real, valid extension entry bundle.
Check all of the following:
registerFn referenced by headerMenusCommon mistake:
If the repository is a source repository and dist/ is gitignored, say:
Different extensions with different uuid values must not share the same name.
Review guidance:
uuid reusing the same nameREADME.md should explain both functionality and usage.
Minimum acceptable structure:
A README that only describes development commands is not enough for submission readiness.
CHANGELOG.md should describe release history.
Minimum acceptable content:
If a changelog exists but does not mention the current released version, flag it as incomplete.
The extension package must not include private personal information such as phone numbers.
Review at minimum:
extension.jsonREADME.mdCHANGELOG.mdsrc/, iframe/, locales/, config/Sensitive data to flag:
Be careful not to false-positive on:
@mediaWhen asked to analyze a project, review in this order:
extension.jsonentry, images.logo, categories, and required fieldsREADME.md and CHANGELOG.mdWhen reporting packaging readiness, answer in this order:
Use this severity model for reviews:
Examples of blocking issues:
categoriesentry points to a nonexistent bundleREADME.md or CHANGELOG.md missing entirelyExamples of risk items:
name uniqueness cannot be proven outside the current repository scopePackaging review result: blocking issues found.
Risks:
- `README.md` explains the feature, but in-product usage steps are still brief
- Icon ownership cannot be fully verified from repository contents alone
Compliant items:
- Required manifest fields are present
- `categories` is set
- Custom logo exists and meets size constraints
- `CHANGELOG.md` exists
- No obvious phone numbers or similar privacy data were found
easyeda-extension-manifest for headerMenus, registerFn, and page-key detailseasyeda-extension-iframe-template when the extension still needs a working scaffoldeasyeda-extension-debugging if the package installs but the menu or runtime still fails