Catia V5 Production Operator

CATIA V5 Production Operator

Use this skill as the runtime operating contract for CATIA V5 work through the target MCP server. This skill constrains how available tools are used; it does not substitute for server capabilities that are absent or unverified.

Mandatory execution rules

1. Execute CATIA MCP calls serially. Do not issue overlapping CATIA mutations against the shared active session unless the active server explicitly guarantees serialized STA execution.
2. Establish the active document and document type before modifying an existing model. For a new-document task, create the document first and then verify the resulting active document.
3. Separate command completion from design correctness. A normal tool response or clean CATIA update is not sufficient evidence that the intended geometry exists.
4. Decompose modeling into the smallest steps that have executable postconditions: inspect -> mutate -> update -> measure -> decide.
5. Discover references before use. Do not invent feature names, parameter paths, component names, sketch geometry indices, faces, or edges.
6. Treat names and indices as short-lived observations after model mutation. Re-query them before reuse.
7. Use exact face/edge operations only when the active server resolves and consumes deterministic BRep references and can reject stale references.
8. Keep recovery bounded. Do not continue trial-and-error mutations in a model whose integrity has not been re-established.
9. Persist changes only when required by the task. Saving, overwriting, closing, and exporting are separate side effects and must not be performed implicitly.
10. Use screenshots as supporting evidence only. Prefer structural and numeric verification whenever the result is measurable.

Capability-profile rule

Use references/capability-matrix.md as the baseline contract for the repository implementation represented by this skill.

If the active server exposes a stronger capability/status contract, a capability may be promoted only when all of the following are explicit and verifiable:

• the input is consumed by the implementation;
• target-reference semantics are defined;
• failure behavior is typed or otherwise deterministic;
• a relevant postcondition can be evaluated;
• the capability has a live CATIA validation path where COM/BRep behavior is involved.

Do not infer stronger support from a tool name, schema field, successful transport call, or feature-tree entry alone.

Reference loading

Read references/capability-matrix.md before holes, patterns, mirror, fillet, chamfer, shell, draft, thickness, exact face/edge selection, or assembly constraints.

Read references/verification-policy.md for all multi-step modeling, parameter propagation, or dimensional/material assertions.

Read references/failure-recovery.md after any exception, update failure, no-effect result, wrong-effect result, timeout, modal-block condition, or ambiguous state.

Read references/topology-and-assembly.md before topology-sensitive Part Design or precision assembly mating.

Read references/tool-workflows.md for common verified execution sequences.

Preflight

For a mutation task:

1. Establish connection state with catia_connect when needed.
2. Determine whether the task creates a new document or modifies an existing document.
3. For a new CATPart/CATProduct, create it first, then call catia_get_active_document_info and verify the document type.
4. For an existing model, call catia_get_active_document_info before mutation and require the expected type.
5. For an existing CATPart, capture an applicable baseline:
   • catia_list_features;
   • catia_get_inertia when a measurable solid exists;
   • catia_get_bounding_box when geometry exists;
   • catia_get_parameters for parameters that may be changed.
6. For an existing CATProduct, capture component and constraint listings before precision assembly work.
7. Define the expected postconditions internally: expected feature, material-effect direction, key dimensions, parameter values, and any required persistence side effect.

If a required geometric reference cannot be discovered through the active tool contract, classify the operation as unsupported rather than guessing the reference.

Modeling cycle

For each material-changing feature:

1. Capture the pre-step evidence needed for the assertion, typically volume and relevant dimensions.
2. Execute one feature operation.
3. Call catia_update_part.
4. Verify expected structural state with catia_list_features when applicable.
5. Re-measure volume and relevant bounding-box dimensions.
6. Re-read changed parameters when applicable.
7. Continue only if the evidence is consistent with the intended effect.

A later successful update must not be used to retroactively validate an earlier unverified feature.

Geometry-effect classification

Classify a material mutation as one of:

• PASS: update succeeds and structural/numeric evidence matches the intended effect within an explicit tolerance.
• NO_EFFECT: update succeeds but a required material change is effectively zero.
• WRONG_EFFECT: update succeeds but the material change has the wrong sign or an implausible magnitude.
• UPDATE_FAILED: CATIA rebuild/update fails.
• INCONCLUSIVE: the active contract cannot produce enough evidence to verify the requested effect.

Do not report NO_EFFECT, WRONG_EFFECT, or INCONCLUSIVE as successful design completion.