Consider if it would be valuable to organize workflows around a naming convention (while github doesn't yet work with subdirectories)

[WilliamBerryiii]

Consider if it would be valuable to organize workflows around a naming convention (while github doesn't yet work with subdirectories)

• Prefixing workflows only triggered by other workflows E.G. _checkov-scan.yml, wc-checkov-scan.yml, subwf.checkov-scan.yml, or the like
• Prefixing the triggered workflows to make them distinct from the rest, E.G workflow.weekly-security-maintenance.yml
• Or perhaps a convention which reveals the trigger type regardless. E.G:
  • workflowcall.checkov-scan.yml
  • schedule.weekly-security-maintenance.yml
  • multi_push_pr.gitleaks.yml

Originally posted by @bderusha in #28 (comment)

[WilliamBerryiii]

After researching GitHub OSS community practices, we're closing this as decided against.

Findings:

• GitHub's official documentation provides no naming convention guidance for workflow files
• Large repositories (e.g., github/docs with ~80 workflows) use descriptive, purpose-based names without trigger-type prefixes
• Our current naming approach (pr-validation.yml, weekly-security-maintenance.yml, pester-tests.yml) aligns with these observed patterns

Rationale:
Workflow purpose communicates more clearly than trigger type. A file named pr-validation.yml immediately conveys intent, whereas on-pull-request.validation.yml adds cognitive overhead without improving discoverability. Trigger configuration belongs in the YAML, not the filename.

The current descriptive kebab-case convention serves maintainability well. If future scale reveals a need for additional structure, we can revisit.