Summary

• mention HCL Taskfile support in CLI help and global Taskfile flag
• document HCL file names and examples across docs, including getting started and style guide
• note that both YAML and HCL Taskfiles are supported and parsed into ASTs

Testing

• go run ./cmd/task --help
• go run ./cmd/task --taskfile /tmp/InvalidTaskfile.hcl demo (fails: Taskfile parse error)
• golangci-lint run (fails: depguard, paralleltest)
• go test ./...

Prompt

Task 6: Update Documentation, CLI Messages, and Defaults

Purpose: Complete the integration by updating user-facing aspects and ensuring consistency. Users should be aware of HCL support through documentation and help texts, and default behaviors should be adjusted if necessary.
• Implementation:
• CLI Help/Usage: If the --help output or usage text mentions accepted Taskfile names or formats, update it to include HCL. For example, “Task will look for Taskfile.yml (or .yaml)” should now say “Taskfile.hcl or Taskfile (HCL) as well”.
• Error Messages: Search for any error or log messages that reference “YAML”. Update them to either say “configuration file” instead, or include HCL. For instance, errors like ErrCantUnmarshalVar currently say “invalid var YAML”  – consider changing to “invalid variable definition in Taskfile” to be format-agnostic. Ensure that new errors we introduced (like HCL parse errors) are clear and consistent in style with existing messages.
• Documentation: Update the README or docs (if maintained in the repo) to mention HCL support. This includes the list of supported file names (now including .hcl and no extension) and an example of HCL Taskfile syntax for users. Provide a brief guide in docs on converting YAML Taskfiles to HCL (or at least note that the two formats are now supported).
• Default Taskfile Name: Decide if Taskfile (with no extension) should be favored as a default in any case. If the project wants to move towards extensionless (similar to Makefile, Dockerfile conventions), we might prioritize Taskfile in the search order eventually. For now, we’ve kept YAML first for safety. Document this behavior clearly so users know which file will be picked if both exist. Possibly issue a warning if both YAML and HCL Taskfiles are present, to avoid confusion (this could be implemented now or later as a user-experience improvement).
• Internal Defaults: If any internal logic assumed YAML (for example, reading from stdin with -t - might assume YAML format unless filename ends with .yml), update that to detect HCL content if possible (maybe via a heuristic or an option). This might be an edge case; at minimum, document that -t - with HCL content is supported by specifying --format hcl or similar if implemented. If such an option doesn’t exist, consider adding a flag to force HCL vs YAML parse when reading from STDIN.
• Validation:
• Run task --help and verify the output mentions the new file names or formats appropriately.
• Intentionally trigger errors (e.g., a typo in an HCL Taskfile) and confirm the error message is user-friendly and not misleading (it should not, for example, say “YAML error”).
• Build the project and read through the updated documentation (Markdown files or web docs if applicable) to ensure all references to Taskfile format are updated. Optionally, generate the docs site if there’s a process to do so, to confirm formatting.
• If possible, have a colleague or a CI step review that providing an HCL Taskfile works end-to-end using the command-line interface, guided only by the updated help/docs (this ensures our documentation is sufficient for users to adopt the feature).

https://chatgpt.com/codex/tasks/task_e_689215dc272c8330b0eb0fde4d346b0d