agentleFS
oaslanankaoaslananka/easyeda-mcp-pro/skills/easyeda-professional-layout/SKILL.md

easyeda-professional-layout

Skill67 starsChanged 10 days agoMITView on GitHub

Plan, preview, apply, and verify professional EasyEDA Pro schematic layouts with page/title-block geometry, rendered bounds, functional blocks, relationship-aware spacing, deterministic templates, staged readback, connectivity fingerprints, and visual QA. Use for schematic placement, cleanup, fit-to-page work, or any request to make a schematic professional or readable.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill for schematic layout work through EasyEDA MCP Pro.

    line 8
  2. Very specific:

    If sheet, rendered primitive, or title-block geometry is unavailable, stop with LAYOUT_GEOMETRY_REQUIRED.

    line 30
  3. Distinctive:

    Use stricter caller constraints when provided.

    line 48
  4. Distinctive:

    Read health, bridge status, active project/document, sheet geometry, grid, frame, title block, and coordinate origin.

    line 52
  5. Very specific:

    Create hard border/title-block/caller keep-outs and named functional-block regions.

    line 55
  6. Distinctive:

    Run a cosmetic-only cleanup preview for alignment, spacing, labels, and wire length.

    line 59
  7. Distinctive:

    Run geometric QA, netlist/ERC validation, full-page fit capture, and visual QA.

    line 61

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

EasyEDA Professional Layout

Use this skill for schematic layout work through EasyEDA MCP Pro. Treat layout as a constrained engineering workflow, not coordinate styling. Read-only inspection may start immediately; request the user's explicit approval before the first schematic write.

Engineering evidence handoff

For schematic placement following component/datasheet review or before power, PCB routing and DRC validation, use the existing staged router at skills/design-validation/references/engineering-review.md. This layout skill enforces geometry/preview/write/readback discipline and never authenticates pin electrical limits, live pad-net continuity, physical high-frequency return paths or a manufacturer's process profile. Do not promote suggested proximity or model-guessed geometry into electrical proof.

Non-negotiable policies

  • PAGE_GEOMETRY_REQUIRED: read health, bridge, project, active document, sheet bounds, drawable bounds, grid, frame, coordinate origin, and title-block bounds before any placement write.
  • TITLE_BLOCK_KEEP_OUT: title block, border margin, and caller-reserved regions are hard constraints. Never downgrade them to score penalties.
  • RENDERED_BOUNDS_ONLY: collision and page-fit decisions use rotation-aware combined symbol and text bounds. Component origins are not collision bounds.
  • NO_BLIND_RETRY: a timeout is ambiguous. Read back real state before deciding whether any write should be retried.
  • STAGED_PREVIEW_READBACK_QA: preview and validate every batch, then read back and run layout QA before proceeding.
  • CONNECTIVITY_FINGERPRINT_REQUIRED: cosmetic moves require matching component-pin net membership and wire endpoints before and after.
  • NO_SAVE_WITH_CRITICALS: do not save while any critical page, title-block, overlap, or connectivity violation remains. Return blockers instead.

If sheet, rendered primitive, or title-block geometry is unavailable, stop with LAYOUT_GEOMETRY_REQUIRED. Templates remain advisory and must never substitute guessed coordinates.

Numeric defaults

Defaults use EasyEDA schematic mil coordinates. Runtime units and grid remain authoritative; convert explicitly when they differ.

ConstraintDefault
Page-border clearance100 mil
Title-block margin150 mil
Component-to-component clearance50 mil
Text-to-body/text clearance25 mil
Section-to-circuit clearance75 mil
Decoupling-to-parent maximum200 mil
Crystal/load-to-parent maximum150 mil
Connector-protection maximum250 mil
Bulk-capacitor-to-power-stage maximum350 mil

Use stricter caller constraints when provided. Approximate/derived geometry may guide a preview, but it cannot authorize placement without an explicit low-confidence result and human review.

Mandatory workflow

  1. Read health, bridge status, active project/document, sheet geometry, grid, frame, title block, and coordinate origin.
  2. Inventory every required component, net, connector, support relationship, and existing occupied region before placing anything.
  3. Resolve rotation-aware symbol/body/reference/value/pin/label bounds. Reserve support-component space around parent devices.
  4. Create hard border/title-block/caller keep-outs and named functional-block regions.
  5. Select a versioned template from src/professional-layout-templates/index.ts; generate a deterministic placement plan and inspect all conflicts, reservations, page attempts, and componentized scores.
  6. Preview main-component placement. Apply only after the write gate, then read back rendered bounds and run placement QA. Repeat for support components.
  7. Wire only after placement QA has zero critical issues. Prefer visible orthogonal local connections; detached netports are not acceptable in normal circuit workflows.
  8. Run a cosmetic-only cleanup preview for alignment, spacing, labels, and wire length. Do not alter electrical intent.
  9. Capture a connectivity fingerprint immediately before cleanup and compare it after every cosmetic batch. Roll back any mismatch.
  10. Run geometric QA, netlist/ERC validation, full-page fit capture, and visual QA. Inspect issue codes and every critical score dimension, not only the aggregate score.
  11. Save only when critical violations are zero. Otherwise return the exact blockers, affected regions, confidence, and next safe action.

Stage gates

For each write batch, record:

  • preview input, deterministic plan hash, selected page size, and hard-constraint result
  • intended primitive IDs or component references
  • apply result and ambiguous timeout state
  • readback bounds and changed region
  • geometric/layout issue codes and per-dimension scores
  • connectivity fingerprint comparison when the change is cosmetic

A4 is preferred. A3 fallback is permitted only after a deterministic A4 attempt proves hard constraints cannot be satisfied. Never enlarge the page only to hide excessive whitespace or poor grouping.

Templates

The versioned catalog includes:

  • USB-powered MCU board
  • ESP32 sensor node
  • battery-powered IoT node
  • CAN/RS-485 interface
  • simple analog/timer circuit
  • medium-complexity MCU peripheral board

Templates define signal flow, block order, keep-outs, clearances, support proximity, and A4/A3 policy. They do not define device-specific electrical design or replace MCP-side enforcement.

Output contract

Report the selected template/version, geometry source/confidence, plan hash, page-size decision, placed/read-back bounds, issue codes/counts, componentized scores, changed regions, fingerprint result, rollback state, and remaining human-review items. Automated success is not production approval.

See professional schematic layout for the operator prompt and worked example. See schematic layout benchmarks before updating golden fixtures.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.