The tcli way

tcli is more than a command line tool, it encodes an opinionated way of managing Teamcenter projects. These guidelines describe that “tcli way”: how to name things, how to structure customisation code, and how to organise configuration content so a project stays consistent and predictable as it grows.

Two kinds of convention

The guidelines fall into two clearly separated groups.

Enforced

Conventions that tcli owns and verifies. You can be wrong about these, and tcli will reject the input. They include:

• Identifier rules for libraries, tools, handlers, and AW kits (see Naming).
• Fixed configuration/<type> source directories and deploy-script layout.
• Fixed configuration/<type> source file names (see lint).
• Handler signatures and register.cpp and CMake wiring generated by scaffold.

Because tcli generates and validates these, following them is not optional. The tooling keeps them correct for you.

Recommended

Advisory conventions that tcli cannot mechanically guarantee. These are about design and content quality, things like how you handle memory and errors in C++. tcli can provide a starting point, but correctness here is yours to own. Treat these as strong recommendations: adopt them, or deliberately choose a consistent alternative for your project.

Where to go next

• Customisation → Naming — libraries, tools, handlers, and AW kits.
• Customisation → C++ — style, memory ownership, error handling, and logging.
• Configuration — per-artifact-type conventions for preferences, workflows, queries, UI configs, stylesheets, and every other config artifact type tcli deploys — see the Configuration section in the sidebar for the full list.