Claudeagent and ClaudeagentA workflow's event payload fills the last of the gaps it had against GitHub's. Labels on issues and pull requests carry their `color`, `description` and `default` as the repository has them (one read of its labels, only when the event has any); a push's `pusher.email` is the pusher's noreply address, or g1t's for g1t; a one-commit push lists the paths it `added`, `removed` and `modified` when a `paths` filter has the push compared anyway, which now happens before any of its runs start so every run sees the same payload; and `workflow_run.pull_requests[]` has each pull request's `id`, `number`, `url` and its `head` and `base` with `ref`, `sha` and `repo`, leaving out one from a fork as GitHub does. The fixtures carry GitHub's shapes for these, the known differences are down to the ids the API takes back, and the Actions guide says what each field holds.0f364efHistory
README.md
GitHub's workflow schema
workflow-v1.0.json is GitHub's schema for workflow files, copied unchanged from
actions/languageservices, file
workflow-parser/src/workflow-v1.0.json, at commit
4043eda158e16579cc5fb1b0b07a4bce2a76f0b5 (5 August 2026). It is MIT licensed;
LICENSE is that repository's licence, copied from the same commit.
g1t does not read it at run time. src/syntax.rs lists the keys each part of a
workflow may have, and its tests check those lists against this file, so they
cannot drift from GitHub's. To update it, copy the file again, write the commit
here, and run cargo test -p g1t-actions.