I find development of intents in conjunction with the shortcut app incredibly frustrating. It seems that the support for intents is very fragile. While I had success a year ago, I've since tried to make improvements only to be stymied with similar problems. After a couple weeks of struggles trying to add parameters to my intent, I found that when you add parameters, you have to delete the derived data, clean the build folder, and delete the shortcut app. I have no idea why the shortcut app has to be deleted since the parameter I added is not a parameter that is modifiable by the shortcut app. Nonetheless, it was required. That procedure worked for me for a while. Then I added another parameter and its broken again. Even after deleting the derived data and cleaning the build folder and deleting the shortcut app, the system make no attempt to resolve the new parameter. Furthermore, the system does not attempt to resolved the parameters in the order that they appear in the parameter list of the intents definition interface. I can only assume that there is some other trick that must be done to make the system want to resolve every parameter and in the order that they appear. So, if there is anyone out there that has experienced this and learned what the solution it, I would be so grateful for an explanation.

I think I came up with a solution. I just added a parameter that gives the hint on the first attempt to prompt the user for a value. After the hint is given, I always return success so that the hint prompt is no longer given. I'll probably let the user have a choice as to whether they hear the hint again.

Ok, the problem with the parameters not being resolved in the correct order is due to the fact that I moved a couple parameters from being last in the list to being first in the list (as I mentioned in my comment above). The source of the problem is that these two parameters had disambiguous prompts that referenced other parameters. Once they were moved, the reference to the other parameters now became prompts to parameters that had not been resolved yet. So, once I cleaned that up, all is well. I still do not understand how or when the Disambiguation Introduction or the Subsequent Introduction are spoken by Siri. Can't seem to find this in the documentation.

I should also mention that the order of the parameters shown above is not the initial order of the parameters that existed when I first created the intents definition file. In fact, I am pretty sure that the partsListName and the woodSpecies may have been the last parameters in the list. I later moved them to the front. That is one reason that I deleted the derivedData and cleaned the build file thinking that that might clear whatever data/mechanism that determines the order of parameter resolution. But as I said, that did not help either. So if anyone can give me a suggestion on how to get this working as advertised, I would really appreciate it.

After months of frustration, I finally got this working. I had to create a new app with custom intents implemented. I cut and pasted all the relevant code listed above, and low and behold, it worked. Then I painstakingly went through every setting until I found the problem. There is a checkbox under Build Phases/Embed App Extensions (selected my project in the project navigator and then selected my App target). This checkbox "Copy only when installing" was checked. After unchecking this, everything works. Since I don't know what this is, I must have checked it out of desperation after seeing this as a solution to someone's post on intents. Also, it turns out that the errors I mentioned in the problem statement above are not errors of any consequence. They occur regardless.

It turns out that this problem is a result of defining a custom parameter type. I don't know why a custom parameter type would cause the auto generation of the pronunciationHint, but by using the standard parameter types for my app, this problem goes away. While this is not a great answer, it allows me to move forward.

I found that there is something that I did not see in any documentation. Perhaps this is just for objective-C, but it fixes the problem. The solution is to assign your NSUserActivity to the view controller’s built-in userActivity property. The view controller automatically invokes becomeCurrent and resignCurrent for us. At first I tried doing this manually but that does not seem to work. The Apple documentation seems to suggest that you should manually invoke [activity becomeCurrent]. But the sample code that @edford pointed to did not manually invoke [activity becomeCurrent]. This led me to find an objective C implementation (I can't link to the article, but search for Integrating iOS 12 Siri Shortcuts using Objective-C - PQVST) of Siri Shortcuts that noted that it is important to use the view controller's built-in userActivity property.