Feature Idea
Summary: Add a CI authoring-contract lint that keeps each workflow’s source (gh-aw-*.md), trigger example (example.yml), and per-workflow README inputs/safe-outputs in sync.
Why a Customer Would Want This
Maintainers and downstream adopters rely on workflow READMEs and examples to configure triggers correctly. When a workflow source adds/changes standard inputs or safe outputs but docs/examples drift, users copy incomplete config and only discover problems at runtime. A contract lint would catch this before merge and reduce onboarding/support churn.
Rough Implementation Sketch
- Add a script (for example
scripts/check-workflow-authoring-contract.py) that validates, per workflow slug:
.github/workflows/gh-aw-<slug>.md exists and defines workflow_call.inputs + safe-outputs.
gh-agent-workflows/<slug>/example.yml references the matching gh-aw-<slug>.lock.yml@v0.
gh-agent-workflows/<slug>/README.md Inputs table includes standard inputs exposed by the source (with a small allowlist for intentionally hidden/internal inputs).
- README Safe Outputs section matches source safe-output capabilities.
- Wire it into existing CI (
.github/workflows/ci.yml) alongside check-nav-catalog.
- Document the lint in
gh-agent-workflows/DEVELOPING.md and expose a make target for local execution.
Why It Won't Be That Hard
The repository already has lightweight consistency gates and patterns for this exact kind of check (scripts/check-nav-catalog.py + CI invocation), and workflow naming/layout is standardized (gh-aw-<name>.md plus gh-agent-workflows/<name>/...). This is mostly parsing and deterministic comparisons, with minimal surface area.
Evidence
What is this? | From workflow: Trigger Product Manager Impersonator
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Feature Idea
Summary: Add a CI authoring-contract lint that keeps each workflow’s source (
gh-aw-*.md), trigger example (example.yml), and per-workflow README inputs/safe-outputs in sync.Why a Customer Would Want This
Maintainers and downstream adopters rely on workflow READMEs and examples to configure triggers correctly. When a workflow source adds/changes standard inputs or safe outputs but docs/examples drift, users copy incomplete config and only discover problems at runtime. A contract lint would catch this before merge and reduce onboarding/support churn.
Rough Implementation Sketch
scripts/check-workflow-authoring-contract.py) that validates, per workflow slug:.github/workflows/gh-aw-<slug>.mdexists and definesworkflow_call.inputs+safe-outputs.gh-agent-workflows/<slug>/example.ymlreferences the matchinggh-aw-<slug>.lock.yml@v0.gh-agent-workflows/<slug>/README.mdInputs table includes standard inputs exposed by the source (with a small allowlist for intentionally hidden/internal inputs)..github/workflows/ci.yml) alongsidecheck-nav-catalog.gh-agent-workflows/DEVELOPING.mdand expose a make target for local execution.Why It Won't Be That Hard
The repository already has lightweight consistency gates and patterns for this exact kind of check (
scripts/check-nav-catalog.py+ CI invocation), and workflow naming/layout is standardized (gh-aw-<name>.mdplusgh-agent-workflows/<name>/...). This is mostly parsing and deterministic comparisons, with minimal surface area.Evidence
gh-agent-workflows/DEVELOPING.mdlines 159-163)..github/workflows/ci.ymllines 30, 36, 55).setup-commandsfor Internal Gemini CLI Web Search (.github/workflows/gh-aw-internal-gemini-cli-web-search.mdline 35; setup step wiring at lines 97 and 99).setup-commands(gh-agent-workflows/internal-gemini-cli-web-search/README.md, Inputs section).What is this? | From workflow: Trigger Product Manager Impersonator
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.