meshix

Files (7)

• SKILL.md
• openai.yaml · agents/
• usb-c-tag-isometric.png · assets/examples/
• logo-large.png · assets/
• logo.svg · assets/
• image-to-cad.md · references/
• setup.md · references/

SKILL.md (first lines)

# Meshix

Meshix is an AI-assisted 3D CAD product at `https://meshix.app`. Use this skill
when the user wants to make, revise, understand, or review a physical part or a
Meshix-generated design.

## Start

- For browser use, send the user to `https://meshix.app` or Meshix Studio.
- For agent use, use the live Meshix MCP server first. The public endpoint is
  `https://meshix.app/mcp`.
- Before the first generation call in an MCP session, call `get_account_status`
  when present to confirm sign-in and backend health.
- If the MCP server is available, use its current tool schemas as the contract.
  Do not rely on remembered or copied schemas when the live tool metadata is
  present.
- For first-time agent connection, OAuth, or MCP setup problems, read
  [setup.md](references/setup.md).
- If the user provides an image or sketch as a CAD reference, read
  [image-to-cad.md](references/image-to-cad.md). Meshix MCP currently accepts
  text CAD briefs, so translate the image into physical geometry first.

## Routing

- Use `prepare_cad_request` when routing or physical-fit inputs are unclear.
  It does not start generation. Read its missing fields and recommended tool,
  ask only for the information needed, and use its argument skeleton.
- Use `create_3d_cad` for general prompt-driven CAD.
- Use `create_3d_cad_gridfinity` only with known `length_u`, `width_u`, and
  `height_u`. One footprint U is 42 mm; one height U is 7 mm. Do not guess fit.
- Use `create_3d_cad_multiboard` only with known install orientation, mount side,
  access side, connector layout, security, and pad mode. Ask before choosing a
  side or retention strategy.
- Assembly beta requires explicit user opt-in. Only then pass
  `template_id="assembly"` to `prepare_cad_request` or `create_3d_cad`. Describe
  the components, interfaces, relative placement, and separate component outputs.
  Multi-part prose alone is not beta opt-in. Omit `template_id` for normal
  auto-routing; typed Gridfinity and Multiboard tools do not accept it.
- Omit `generation_model` and `grading_model` unless the user requests an
  override; then use only exact ids from the live schema and follow its
  guidance.

## Discovery Requests

When the user asks to find, list, search, open, inspect, or identify a Meshix
design, design version, Community History entry, public gallery item, or prior
run, treat that as a Meshix MCP discovery task.

- Use Meshix MCP before web search or general STL sites.
- For signed-out Studio History → Community, use `list_public_history`, then
  `get_public_history` with a returned `design_id`. These read public prompts
  and latest run progress or failure, including active and needs-attention runs
  with no selected version. Community uses recent public-design visibility
  windows; private designs and private history are excluded.
- Use Community's `type` and `status` filters from the live schema, including
  `in_progress` and `needs_attention`. Multiboard's history type is `multiboard`,
  not the gallery's `board_mount`. Pass `next_cursor` unchanged with the same
  filters; continue after short or empty pages until `next_cursor` is null.
- For owned designs or gallery discovery, use `list_designs` with `scope="mine"`
  first. Unless the user asked for private-only results, also check
  `scope="public"` when owned results are empty or too few are relevant, and
  report which scopes you checked. The published gallery is a subset of
  historical work, but can include designs published by other users outside
  recent Community or your owned History.
- Use `get_design` for an owned design and `get_design_history` for owned
  version/run history. `get_public_design` reads only a public selected or
  published version; use `get_public_history` for Community runs without one.
  History reads do not return signed download URLs. Carry returned opaque IDs
  into later calls; a display label such as v2 is not a `version_id`.
- If the exact query has no MCP match, report the MCP-backed misses and the
  closest MCP-backed candidates. Label any result from outside Meshix as not
  MCP-backed.

## Workflow

1. Capture the physical intent: what the part does, what it attaches to, and
   what must fit.
2. Ask for dimensions, clearances, material or printer constraints, and mounting
   context when those affect the result.
3. Prepare and create through the route above. Keep the returned `design_id`,
   `run_id`, and `studio_url`.
4. After creating, revising, or forking, call `render_design_progress` once with
   the returned `next_tool_args`. It accepts `design_id` and optional
   `version_id`, never `run_id`. The host may present an interactive progress
   card; summarize the status briefly and include the Studio link without
   commenting on whether the card appeared.
5. Follow any `action_required` instruction before ending the turn. If the run
   needs clarification, use the checkpoint workflow below and present the saved
   questions. Do not invent answers or bypass the checkpoint.
   Report an error or Studio-only action with its returned reason and link.
6. For a queued or active run with no required action, end the turn. Call
   `get_design` when the user asks for status. Never start an automatic polling
   loop or promise automatic updates or completion notifications.
7. On completion, use `get_design_assets` for fresh download URLs and inspect
   the renders and relevant CAD artifacts for fit, thickness, orientation,
   access, and printability. Asset readiness is separate from run completion;
   report missing outputs rather than claiming they exist.
8. Return the Studio design/run URL and the reviewed result. Use `version_id`
   when inspecting or downloading an exact historical result.

## Clarification and Revisions

- For an owned run requiring clarification, call `get_clarification_checkpoint`
  with its exact `design_id` and `run_id`. Present the saved questions and use
  the returned `checkpoint_id` unchanged.
- Call the tool its `next_action` names with the same `design_id`, `run_id`,
  and `checkpoint_id`: `answer_clarification_questions` saves a complete answer
  for each saved question; `retry_clarification_review` retries a failed
  review; `start_clarified_run` starts the prepared run. Follow each returned
  `next_action`. Do not replace the design or run to bypass a checkpoint, and
  do not invent answers.
- For `restart_typed_setup`, use the returned Studio link.
- Use `revise_design` for a completed owned result. Revisions preserve its
  generation family; create a new design when the family must change. Omitted
  model overrides retain the parent's model and effort.
- Use `fork_public_design` when the user asks to revise a public selected
  version into their own design. Pass its exact public `version_id`; the source
  stays unchanged and Assembly is inherited only from an Assembly parent.
- Follow queued revisions and forks through the same progress and artifact

From shpitdev/skills, MIT.

More from shpitdev/skills