Update to EasyGerber

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -5,37 +5,35 @@
 
 # EasyGerber board design
 
-Use the installed EasyGerber MCP tools for the requested board workflow. Hosts may prefix tool names differently; discover the tools available on the EasyGerber connection and follow their current schemas. If the connection is missing, direct the user to https://easygerber.com/agents. Never ask for tokens in chat or read credentials from project files.
+Use the installed EasyGerber MCP tools and their current schemas. Hosts may prefix tool names differently. If the connection is missing, direct the user to https://easygerber.com/agents. Never ask for credentials in chat or read them from project files.
 
-## Create and deliver a board
+Follow [the workflow reference](references/workflow.md) for the thin schematic format, physical settings, recovery, and permission details.
 
-Follow [the workflow reference](references/workflow.md) for the compact schematic example, supported settings, and recovery details.
+## Create and continue a board
 
-1. Read only relevant firmware and requirements to identify signals, power, and connectors. Send the minimum needed board data, not the whole repository. Clarify electrical choices that cannot be inferred.
-2. Finish any pending guest claim, then reuse this task's guest session or authorized account. If neither is established, call `start_guest_session` directly; `account_connected` means use the account. Do not probe with `get_profile` or `list_organizations`, including in parallel. Users need not choose an account mode or mention guests. Retain the returned capability and pass `guestToken` to guest catalog and board tools. A successful start creates a new session; never repeat it to recover a lost or ambiguous response.
-3. Search published parts and reuse returned catalog facts and verified pins. Only the first search candidate is enriched with pins; call `get_part` when the selected part lacks needed pins or facts. Check electrical compatibility and supporting circuitry. Preserve catalog IDs, pin identities, footprints, and available 3D models; never invent them.
-4. Call `create_board` with a name, a fresh UUID `requestId`, and the thin intent. Map the returned catalog `id` to `dbId` and the chosen `pins[].number` to connection `padId`. Omit `boardEdits` to use normal defaults; specify only requested app-visible changes. If layout is requested, use the created board's `id` and `revision` directly with `generate_layout` when nothing has changed; no extra board read is needed between them.
-5. When generating a layout, poll the exact generation ID at the returned interval until terminal. After completion, read `get_board` for the saved revision and preview, check the current layout with `check_board_layout`, and export the requested files. A saved schematic is not yet a completed layout. If the check tool is unavailable, report the service/integration mismatch; never substitute another tool or call an unavailable check a pass.
-6. Return the private board link and requested artifacts. Preserve stable private download links exactly, including their capability fragment; they return the exported snapshot without an automatic expiry or a customer-facing renewal step. One guest board supports preview, manufacturing ZIP, and `.egb` export before signup, without lifetime operation caps or automatic expiry when `expiresAt` is null. Normal request-rate, complexity, and shared compute protections apply.
+1. Read only the relevant requirements and firmware to identify signals, power, and connectors. Send the minimum needed board data. Clarify electrical choices that cannot be inferred.
+2. Search published parts immediately with `search_parts` and `get_part`; public browsing needs no account or board. Reuse returned catalog facts and verified pins. Only the first search candidate is enriched with pins; look up a selected part when its needed pins or facts are missing. Preserve catalog IDs, pin identities, footprints, and available 3D models. For an existing board's strict Part List, retain its `boardRef` on every catalog call.
+3. For a new board, generate one private `boardRef`: `egbr1_` followed by 32 cryptographically random bytes encoded as unpadded base64url (43 characters after the prefix). Call `create_board` with that reference, a fresh UUID `requestId`, a name, and the complete thin intent. The service uses the valid connected account or establishes private access automatically. No guest setup or account-mode choice is needed. Omit `boardEdits` for normal defaults; author only requested app-visible settings. Never invent parts or hidden routing/manufacturing constraints.
+4. Keep the same `boardRef` in private tool context across turns and pass it to all subsequent board operations. It replaces the need to coordinate a board ID and a separate access token. Read `get_board` before editing, then use its `revision` as `expectedRevision` and a new request ID for a new edit. On a revision conflict, reread and reconcile instead of overwriting a newer change.
+5. When layout is requested, use the latest saved revision with `generate_layout`. Follow the returned `generation.id` with `get_generation`; if the ID was lost, `get_generation` with the same `boardRef` reads the current job. Wait the returned interval and stop at completed, failed, or cancelled. Read the saved board after completion. Never generate again merely to ask whether a job finished.
+6. Return the private board link and requested artifacts. For manufacturing export, check the current saved layout with `check_board_layout` and report any blocking issues. For an editable `.egb` backup, export the valid saved project directly, even if layout is missing, incomplete, or stale; do not generate or check a layout solely for that backup.
 
-For an editable backup, read `get_board` and call `export_board` with `format: "egb"` and its saved revision. A valid saved project can be exported with missing, incomplete, or stale layout; do not generate or run `check_board_layout` solely for this export. Manufacturing ZIPs require current PCB geometry and electrical requirements and a layout check.
+The reference is private authority, not a public board UUID or a request ID. Keep it in tool arguments/results or supported private host state, never in ordinary messages, source files, analytics, or diagnostic logs. In isolated code execution, preserve it for later calls rather than returning only a success summary and discarding the state. Do not assume a host retains variables between executions. The returned private board URL is the user-facing exception needed to return to the board.
 
-For requested physical or electrical constraints, the shared tools support part clearances, keepout regions, and per-pin current requirements. Use the workflow reference for their patch and replacement rules. Read back the saved values and check the resulting layout before reporting compliance; accepting a requirement does not establish that the PCB meets it.
+For a lost creation response, resend the original `boardRef`, `requestId`, and exact arguments. Do not mint a replacement reference. Changed input needs a new request ID, but a consumed reference cannot create another board. For existing work, use its reference or owning account; missing, invalid, revoked, or rejected access never authorizes replacement work. The service cannot recover private authority from an IP address, client label, public UUID, or memory of a board name.
 
-Keep `guestToken` in tool arguments only, never in project files, logs, or ordinary messages. The returned private viewer link is the user-facing exception needed to return to the board. On detailed validation errors, repair the reported fields while preserving valid intent and the same guest session. Changed input needs a new `requestId`; retry unchanged input with the same ID. Inspect an existing board before editing, and reread after a revision conflict instead of overwriting a newer change. Reuse known operations after uncertain outcomes.
+## Account access
 
-## Account access and saving a guest board
+Use the host's normal sign-in flow for account work. When the user connects an account to keep working on this private board, call `get_board` with the same `boardRef`; with authorized write access, the service saves it into that account. No separate claim tool is needed in the normal workflow. Read the returned state and revision before further edits. Finish any active layout before this account transition; `get_generation` and `stop_generation` do not themselves claim the board. Follow a busy response without cancelling the job or switching identities. The saved account copy preserves the layout, but not the old job history: a null generation after the transition does not require regeneration when `get_board` reports a current layout.
 
-Existing account boards and organization work require the host's sign-in flow; an expired account connection is not permission to recreate private work as a guest. In the private guest viewer, signing in or creating an account saves the board and opens it automatically after the server confirms the save. This browser sign-in does not authorize the agent connection. Read the guest/account section of the workflow reference when handling host sign-in or a pending claim.
+New account boards are personal by default. Use `get_profile` only when account identity matters and `list_organizations` only for requested organization work. Existing boards retain their actual ownership and permissions. Signing in solely for feedback or deletion does not authorize transferring another private board. Invalid account credentials require reconnection, never silent fallback to anonymous access.
 
-When the user chooses sign-in or account board work with a guest board in this task, automatically save that board to their personal account. Signing in solely to delete an account board or submit feedback does not authorize claiming a guest board; never claim a guest board merely to delete it or send feedback. Use `claim_guest_board` with its original `guestToken` to initiate account authorization, then retry that same claim immediately when authentication resumes. Do not ask a separate “Keep board?” question or use `get_profile` as a substitute for the pending claim. Follow the workflow reference for busy retries and the returned account board ID. Generic native Settings **Authenticate** has no guest-board context; after that flow, the agent must resume the claim to complete the save.
+## Scope and compatibility
 
-New account boards belong to the personal account by default; `get_profile` is needed only when account identity matters to the request. Use `list_organizations` and pass `organizationId` only for an organization the user requested. Existing boards retain their saved ownership, subject to the user's permissions.
+Use `delete_board` only for an explicit request to delete a specified account board. It requires separate `boards:delete` consent, appropriate ownership, and a fresh saved revision. Ordinary sign-in must not request deletion permission. Only `{ boardId, deleted: true }` confirms deletion; `not_found` or a lost response does not. Never claim a private board merely to delete it.
 
-## Deletion, feedback, and scope
+Use `submit_feedback` only when the user asks or agrees to send feedback. Read the workflow's feedback section first. Send only the approved message, never automatic transcripts, diagnostics, board content, credentials, or private links. Feedback needs no board or sign-in. Return its receipt without promising a response. If unavailable, offer [GitHub Issues](https://github.com/EasyGerber/easygerber-agent-plugin/issues) and explain that issues are public before posting.
 
-Use `delete_board` only for an explicit user request to delete a specified account board, never for unsolicited cleanup. Deletion is permanent, has no restore operation, and cancels active jobs. It requires separately approved `boards:delete` access plus personal ownership or an organization owner/admin role; `boards:write` is insufficient. Read `get_board` first and pass its revision as `expectedRevision`. Guest boards cannot be deleted through this tool. Read the deletion section of the workflow reference before calling it. Report success only from `{ boardId, deleted: true }`; `not_found` can mean unavailable, insufficient ownership, or already absent and does not prove this request deleted the board.
+Older clients may still use `guestToken`, `guestCreationKey`, or explicit guest-start/claim calls. These are compatibility inputs, not setup steps for new work. Preserve an existing task's valid access and follow the workflow reference when continuing such a task.
 
-Use `submit_feedback` only when the user asks or agrees to send a bug report, feature request, or general feedback to EasyGerber. Read the feedback section of the workflow reference first. Send a concise approved message, never automatic transcripts, raw diagnostics, board exports, credentials, or private links. Feedback can be anonymous without signing in, starting a guest session, or creating a board; existing valid account or guest access can attribute it. Do not expand board permissions for feedback. Return the receipt without promising a response or roadmap commitment. If the connection or service is unavailable, offer [GitHub Issues](https://github.com/EasyGerber/easygerber-agent-plugin/issues) and explain that issues are public before any posting.
-
-Keep actions within the user's requested scope. Creating, revising, or exporting a board does not authorize deletion, public sharing, or purchasing fabrication. Explain returned electrical or manufacturing issues accurately; successful generation or no blocking issues is not a safety certification. Return the board link and requested artifacts, and distinguish saved, generated, exported, and explicitly confirmed deleted states.
+Creating, revising, generating, or exporting does not authorize deletion, public sharing, or purchasing fabrication. Report saved, generated, checked, and exported states accurately. Successful generation is not a safety certification; an unavailable check is not a pass.