Could Tuist support ensuring an arbitrary file exists at project generation time?

In my project, I’m trying to use a project description helper to automatically add a Swiftlint script phase to each of my targets. Ideally, I’d like to do this without disabling the ENABLE_USER_SCRIPT_SANDBOXING flag, which means I need to provide my Linting script phase with an input .xcfilelist containing the list of files to be linted.

It makes sense then (I think) to generate that file list by running a git diff in a prior script phase which produces the .xcfilelist as an output. However, if the input .xcfilelist path does not point to a file which already exists on disk prior to the build starting, then my target’s build will fail without ever running the script which would generate the .xcfilelist.

I’m wondering, then, if it would be a) technically feasible and b) acceptable for Tuist to support ensuring that an arbitrary file (relative to a given manifest) exists on disk when the project is generated? My goal is that if someone manually adds a new target to the project, they shouldn’t need to know to create a corresponding placeholder .xcfilelist. And my preference is to have these files added to the .gitignore, to avoid any messiness of them showing up as pending changes as the contained lists of files to lint changes.

I tried just adding logic inside the project description helper itself to “touch” the file using FileManager.default.createFile(atPath:, but since the manifest and project description helpers can be cached, this doesn’t ensure that the file’s existence is rechecked on every generation.

An alternate solution would be to add the generation of these file lists to the scheme’s build pre-actions rather than as a script phase on each target. But ideally I’d like to be using the autogenerated schemes in at least some cases rather than creating manual schemes, and there is no way to add a prebuild action to the automatic schemes.

Updating to say that after some reading, I’ve changed course and am just focusing on moving to using Swiftlint via the build tool plugin, so this is no longer a particular concern for my team. It might still be interesting/useful in some cases to have more ability to inject various settings into autogenerated schemes, but but otherwise this is probably a dead end.