Clarify workflow validation guidance

.github/CONTRIBUTING.md

@@ -11,6 +11,8 @@
 ## Review/testing note
 
 - When using the repo-managed environment for local workflow checks, run `bash .codex/install.sh` first so the expected tooling is available before running YAML parsing checks.
+- Bash syntax checks such as `bash -n` are not applicable to `.github/workflows/*.yml` files because GitHub Actions workflows are YAML, not shell scripts.
+- If shell validation is needed, run `bash .codex/shellcheck.sh` or `bash -n` only against actual `.sh` files or extracted shell snippets, not the workflow YAML itself.
 - Local YAML validation warnings against `.github/workflows/release.yml` should be interpreted carefully.
 - Direct parser check used during review/testing:
 

.github/instructions/workflows.instructions.md

@@ -11,6 +11,8 @@ When reviewing GitHub Actions workflows in this repository:
 - For new sanity or guard workflows, verify that initial branch pushes, pull_request events, and shallow clones are handled intentionally.
 - Suggest minimal fixes rather than broad workflow rewrites unless the current approach is likely to fail.
 - For local workflow-review parsing checks in the repo-managed environment, run `bash .codex/install.sh` first so the expected tooling is available.
+- Do not recommend `bash -n` against `.github/workflows/*.yml`; Bash syntax checking is not applicable to YAML workflow files.
+- If shell validation is still needed, limit `bash -n` or `shellcheck` to real `.sh` files or extracted shell snippets.
 - If review notes include a Python YAML parse example such as `python3 - <<'PY'` with `import yaml`, call out that it depends on PyYAML being installed.
 - Prefer a guarded check like `python3 -c 'import yaml'` before YAML parsing when you want to separate dependency/setup issues from workflow content validation.
 - Be explicit in review comments that a missing YAML parser dependency is a local tooling problem, not a GitHub Actions workflow syntax defect.