Spotted while pushing to a feature branch — every push triggers a workflow validator error on .github/workflows/daily-repo-status.lock.yml:

Invalid workflow file: .github/workflows/daily-repo-status.lock.yml#L1
(Line: 51, Col: 16): Unexpected value ''
(Line: 72, Col: 11): Unexpected value ''
(Line: 75, Col: 16): Unexpected value ''
(Line: 76, Col: 14): Unexpected value ''
(Line: 77, Col: 21): Unexpected value ''
(Line: 134, Col: 12): Unexpected value ''
(Line: 612, Col: 12): Unexpected value ''
(Line: 614, Col: 25): Unexpected value ''
(Line: 644, Col: 27): Unexpected value ''
(Line: 661, Col: 27): Unexpected value ''

All the flagged lines are YAML keys with empty values:

• L51, L75 contents: (no value — should be read/write or removed)
• L72 needs: (empty)
• L76 issues:, L77 pull-requests: (empty permissions)
• L134, L612 id: (empty step IDs)
• L614 timeout-minutes: (empty)
• L644, L661 continue-on-error: (empty)

Looks like the gh-aw generator emitted nulls/empties where the schema requires a value. The file header says:

# This file was automatically generated by gh-aw (v0.45.0). DO NOT EDIT.
# To update this file, edit githubnext/agentics/workflows/daily-repo-status.md@d19056381ba48cb1f7c78510c23069701fa7ae87 and run:
#   gh aw

The same pattern also shows in .github/workflows/issue-triage-agent.lock.yml (1016 lines, same generator).

@DaanHoogland — since you committed the agentic-workflow experiment (#12652 / c0db75b9fa), what's the preferred fix here? Re-run gh aw to regenerate, or hand-patch the empties to safe defaults? Happy to send a PR either way; just want to make sure I don't churn an auto-generated file the wrong way.

Doesn't block actual PR CI (other workflows still run independently), but it does emit a red annotation on every push.