How do you use JAMF Compose

I suggest you contact Jamf support and read the admininstrator guide.

In today's Mac Admin world, I would consider Composer to be a "tool of last resort" not one for daily use. But it does have its place.

Before looking to use Composer:

1. Try to get a PKG installer from your developer. There's no need for Composer in most cases where the developer has supplied the package. I believe all the apps you listed are delivered as Apple PKG installers.
2. Consult the app developer's support website for documentation about mass deployment. Contact the developer directly if you can't find anything.
3. Search Jamf Nation for ways to deploy an app. You may find ways that don't involve repackaging with Composer. I prefer scripts that will download apps directly from the Internet and install them to avoid having to maintain any installer packages.
4. Avoid packaging plists/preferences. If you need to manage an app, trying using a Configuration Profile instead. As an alternative, see if you can script settings. Profiles and scripts are created and applied from within Jamf Pro and are far easier to manage.
5. Try to use each app's method of installing updates. For example, manage Microsoft AutoUpdate using a Configuration Profile to manage updates for Office.

Only after you've exhausted your methods to install and update software should you look to Composer. In cases where you receive something like an app that behaves as an installer (complain to the software developer about this and ask for a native Apple installer package) you can use Composer's snapshot feature on a VM to see what it's installing. Those cases will be unique.

Remove any cruft (unrelated files to the app) from the package source you create in Composer. Again, avoid deploying anything in the Users folder. Those are likely preferences not required files.

Finally, if you do need to deploy preferences, manage with a firm hand but a light touch. For example, is it really a big deal if a user goes through the Chrome or Microsoft Office welcome screens? That depends on your environment and your philosophy of management. While it's nice to set a lot of defaults for various apps, it's also a lot of work that folks may or may not appreciate in the end.

@talkingmoose has pretty much nailed it.
Probably a few times I go to Composer are.
One: To use the snapshot, but only to see what went where.
Two: If you get an installer that has to be run from command line, putting down /tmp files and running a post install script works well with composer.
Three: Distributing straight files to a machine for whatever reason (templates, shared docs, that kind of thing).

Otherwise there are kind of better and or faster ways to get things done, especially now that a lot of applications try to verify the source before installation / execution, which basically means it if came as a DMG you have to package that up and deploy from it, which is just messy with Composer.

There was a great drag and drop tool floating around somewhere for making an app containing DMG into a PKG that's just miles more efficient than doing it with Composer. Maybe from @mm2270 ?

I do use Composer occasionally (for big site-licenced stuff like MATLAB or SPSS Statistics etc.), but I find myself using the really handy Simple Package Creator more often than not, particularly for OSS:

https://derflounder.wordpress.com/2014/04/29/simple-package-creator-app/

I will second everyone's approach on here. Composer has its place and I use it primarily for packaging drag n drop apps and static files personally. I use it for understanding how a package works, but not necessarily for building it.

Occasionally some vendor will use a lame third party installer or in the case of some very rare exceptions, their PKG installer is brain damaged and cannot be used as is. Some Corel-based ones come to mind. In those cases, I try to make sure that any updating mechanisms still continue to work flawlessly and the original vendor receipts get laid down in case the program needs to have access to them. The "right way" would be to lobby the vendor to fix that...especially with macOS Catalina coming out. I wonder with notarization how long repackaging will even continue to work honestly.

If you are going to use Composer snapshots for anything, I recommend a VM containing a near virgin install of macOS on the target build, and perhaps another VM to test it on (the second VM would obviously have a different MAC address)...this way you get an idea about what happens when you deploy your package to a second machine.

If you use composer and export as DMG, make sure your file format is HFS+

APFS formatted mac's can open APFS & HFS+ DMG's
HFS+ formatted can't open APFS DMG's

If you need to add files to existing / future user profiles, use DMG format.

Exporting as DMG allows you to update all current profiles, and gives you the option for the default template (for any future user profiles).

@jstillio I would not consider modifying the user template as being an approach with a long term future.

Agree @sdagley although at this point in time there are still unfortunately a myriad of apps, especially in an education environment, where the only real valid way of dealing with them in a lab environment is to populate certain files into User Templates, you can get around it with things like LaunchAgents that do it on login etc... for new users but that comes with it's own set of messy!