Ok, I re-read your original question now I realize I should've answered with a little more thought put into it. The coffee master detail is very powerful in part because it can also deal with the issue of predecessors.
But in order for that to be legal you need to have a couple of requirements. One is that the projects and tasks all need to live in the same tables. In other words you would have to designate certain projects to be special template projects and therefore their Tasks become a special tasks which can be used in the copy master detail. You cannot have a separate table to hold the template tasks.
Typically what you do is you set up the special projects with their special tasks and you flag them as being template projects. Then you use permissions to make sure that your regular users can't accidentally mess around with your templates.
Know how much data and kind of investment you already have in your current structure but it's a pretty simple test to set up a Template Project in your Projects table and hence a set of templated tasks. Do the predecessors manually, and then do a test with the API or in fact it may be easier to have your users push a button which can be created with the CopyMaster Detail wizard helper found in the App management Settings for the app.
The use of Copy Master detail it's also very particular that the structure of the app for any of the tables involved must be purely hierarchy. By that I mean one parent has many children and their children can have children of their own. But you can't have any "incestuous" relationship like relationships between parents for example. I imagine that you would want your users to be able to be sitting on a project record and be able to select the special template project which has the template tasks. Soon as you do that you violate the pure hierarchy of relationship.
As I recall I think I got around this in the past by making a connected sync table of the templated of projects. By that I mean just a connected sink table of the template project names and of course the record ideas will come across automatically.
Of course the record ideas of your connected same table will match perfectly with the record IDs in your projects table. They will be identical. So then you would use the record ID of the related template record as kind of a proxy representation for the record ID of the project template record in your main projects table.
Now I hope that's all clear and feel free to post back with any questions or email me directly since currently they are debugging this new Forum and I am not receiving any email notifications when you do updates.
If you come back and see you have too much invested in your current structure to do what I'm suggesting then while I'm not saying that anything is impossible, let me say it's going to be extremely difficult to create some kind of crazy pipeline which will set up the predecessor records. That copy master detail functionality is really ancient code under the covers at QuickBase that does it's magic and it would be very hard to replicate with a fancy pipeline
