Very fair question.

One could build a simple version of this easily - e.g. setup an endpoint that listens for the particular event you are concerned with, and fire off the headless agent with your hook specific prompt - but the amount of work involved to listen for that particular event while filtering out noise and orchestrating the task is actually not trivial.

Plus, that involves writing a lot of code. It's really magical to express all of this in natural language.

For example, this is the YAML frontmatter for a a daemon that keeps a GitHub PR in a mergeable state in the event of CI failures or branch base changes.

  ---
  id: pr-mergeability
  purpose: Keep non-draft pull requests mergeable and CI-green without changing PR intent/scope, while staying anchored to one trigger context per run.
  watch:
    - Branch sync and update events on non-draft PRs.
    - Check-status signals on non-draft PRs for checks that affect mergeability.
  routines:
    - Resolve mechanical merge conflicts when the safe resolution is clear and preserves PR intent/scope.
    - 'Apply low-risk mergeability fixes: snapshot updates, lockfile drift fixes, lint autofix, and flaky-test retries when tied to the trigger context.'
    - Escalate semantic/intention conflicts between base and branch instead of auto-resolving.
  deny:
    - When triggered by a check-status signal, do not fix or comment on unrelated failing checks.
    - Do not open new pull requests or new issues.
    - Do not review, approve, or request changes on pull requests.
    - Do not implement review-comment suggestion patches.
    - Avoid force-push by default; if force is absolutely required, use `--force-with-lease` only after fresh remote verification.
    - Do not make changes beyond mergeability maintenance.
  ---

Note the lack of any code or required knowledge of GitHub webhooks.