Update to skima

{
  "description": "Use the authenticated official skima app connection for skima project, floorplan, modeling, and drawing requests in ChatGPT Work or Codex.",
  "included_files": [],
  "name": "skima-connected-account",
  "skill_md_contents": "---\nname: skima-connected-account\ndescription: Use the authenticated official skima app connection for skima project, floorplan, modeling, and drawing requests in ChatGPT Work or Codex.\n---\n\n# Use the connected skima account\n\nBefore the first requested skima operation, choose the tools supplied by the user's connected official skima app. A plugin can expose both a registered app connection and a standalone MCP server pointing to the same URL. Those transports do not necessarily share credentials. Prefer the registered app tools when both are available; keep using that connection for subsequent operations. Resolve the available tools rather than hardcoding an account link or a generated namespace suffix.\n\nFollow the user's requested operation directly. This routing step does not require an extra project lookup, a new project, or a connection change. Preserve the selected account, existing scopes, write confirmations, and project selection rules.\n\nAn authentication-required response from the standalone transport alone does not prove that the connected account has expired. If that transport was used accidentally and the corresponding official app tools are available, switch to the connected app for a read-only check once. For a mutation with an uncertain outcome, inspect its state through the authenticated connection before considering a retry; preserve the existing idempotency contract. If the connected app also requires authentication, stop and request reconnection instead of repeating calls or switching accounts.\n\nNever obtain or print tokens, construct Authorization headers, reuse web-session credentials, or weaken server authentication. Describe the result and any required user action without exposing transport details in ordinary architectural replies.\n\n## Independent modeling operations\n\nInspect the tool definitions available in this conversation. Only when `cad.modeling.session.resume` is available and both `shell.apply` with `proposalScope` and `review.record` with `reviewScope` explicitly declare `submissionContractVersion` v2 in their available input schemas, use `submissionContractVersion: modeling-domain-submission/v2` when creating an image workflow, or on a state read followed by the next typed write. Pass the version only to a tool whose available input schema declares it. A state read does not change the stored contract. During independent tool approvals, keep the issued legacy handoff if any required definition is missing. Calling the new resume tool without the optional version preserves the prior contract.\n\nUse `cad.modeling.shell.apply` only for physical building proposals. Walls, windows, roofs and layers are typed architectural data within that coherent operation. Use `cad.modeling.review.record` for evidence-based stage assessments and upstream design-change requests; these do not themselves apply proposed physical geometry. Use `cad.modeling.session.resume` only when the user asks to continue an eligible paused session, preserving its session, latest revisions and retry ID. Resume does not create geometry, grant credits or bypass errors.\n\nFollow the current `publicSubmission`, targets, evidence and revision constraints; do not discover or invent callable operations from state data. Cached earlier tool definitions continue to use their issued contracts. Do not copy legacy `imageWorkflowResponse` instructions into a v2 session. An uncertain write must be checked before retrying with the same request ID.\n"
}