csprocessor new --name <title> --product <productname> --version <version> --brand <brand> --edition <edition> --subtitle <subtitle> --dtd <dtd> --description "<description>" --bzcomponent=<bzcomponent> --bzproduct=<bzproduct> Generates a local Content Spec project, containing a Content Spec with the metadata section populated. --name is the only obligatory argument, as it is needed for the file / directory name. Any arguments that are not specified on the command line appear in the content spec, but commented out, so something like: #BZPRODUCT=<Bugzilla Product> It also creates the local project directory. At the top of the spec, and in the csprocessor.cfg file you could put: ID=NEW That let's csprocessor know that it hasn't been committed yet. Then when the user does csprocessor push, it will create the spec project on the server and update the local version to correct ID. Basically this would be the default workflow for most users to create a new content spec project. csprocessor new --name "My New Content Spec" cd My_New_Content_Spec nano My_New_Content_Spec.contentspec csprocessor push
Since a csp project directory is supposed be a set up project (ie one that exists on the server) I believe that it shouldn't be created. Also you are then hiding part of the workflow since push should only be used to update a content specification, that is the way it was designed when I redid it in 0.22.0. Create should be used to create a new content specification on the server and that shouldn't change. For those main reasons I don't believe a new directory should be created. However this, then is very close to the template command, so I propose that the functionality be added to that populate the values by command line attributes.
You can actually already create a new csprocessor project from the command line already.