For team level commands in particular, it would be useful to be able to chain commands.
For example, we may have a pre-commit check command which would run rules or analyses related to code quality, security, test coverage, etc. It can be useful for developers to run that command, let’s call it /pre-commit-review, as they work but before they are ready to commit. We may have another command defined, let’s call it /commit-staged-code. This command would run the same checks as /pre-commit-review as well as ask about current work item. If all checks pass, prompt the user for the current work item and generate a meaningful, best-practices driven commit message based on git diff --stage and commit the code.
If the commit-staged-code command could invoke the pre-commit-review command by referencing it then we could write/manage the pre-commit-review in a single place and re-use it as necessary without repetition.
Very brief example:
pre-commit-review command: Run unit tests and code coverage. Any failed tests or overall code coverage <80% is a failure.
commit-staged-code command: Run /pre-commit-review command. If there are no failures, prompt user for JIRA/GitHub/etc. work item. Craft a semantically meaningful, best-practices following commit message including the referenced work item(s) supplied by the user and commit the staged code with that commit message.
I appreciate that. We also have local CI tools that can be leveraged. More generally, from a management perspective, if we are going to have team-level commands, it can be useful to chain and manage maintenance more easily where it makes sense. Pre-commit review/code commit was just a common example use case.
I have a problem: I have never worked in large teams.
For my projects, I usually do local CI so that the Agent gets instant automated feedback. And I have several projects that had git workflows for building releases.
It would be interesting to get feedback if you see problems with this approach when expanding it to a team.
There are a couple issue from an enterprise perspective if there are only local quality checks that I’ve seen. I’m not saying these mean you or anyone else should not do local quality checks, only that these are the stumbling blocks I’ve seen on larger teams, particularly in orgs where software development hasn’t been/isn’t their primary focus.
Organizational: Impossible to meaningfully enforce consistent application, possible license costs. Possibly different rules applied than in source control pipeline quality checks leading to friction/non-compliance/non-usage.
Pragmatic: While it can save time over commit/wait for pipeline results, developers tend to either never setup local checks or never use it. Maybe they should but it just doesn’t seem to happen.
Ultimately the kinds of quality checks you would want to do in a pre-commit check really need to be done in the source control system (e.g. GitHub Advanced Security). Local is like validation in the UI and pipeline/repo pre-commit is like API validation.
So, what I’m saying is anything that can be done locally must be reproducible at the final repo destination in exactly the same way and it must remain as low-friction to the dev as possible while protecting the org.
