Feature Idea
Summary: Add a per-workflow meta.yml manifest that declares dogfood behavior (for example excluded-from-dogfood and auto-remediation chaining) so maintainers don’t need to edit hardcoded lists in scripts/dogfood.sh.
Why a Customer Would Want This
Maintainers adding or changing workflows want one obvious place to declare workflow behavior. Today, behavior is split between workflow directories and script-level arrays, which makes onboarding and maintenance error-prone and increases review churn when a new workflow needs special handling.
Rough Implementation Sketch
- Add optional
gh-agent-workflows/<workflow>/meta.yml with a tiny schema (for example: dogfood.exclude: true|false, dogfood.auto_remediation: true|false).
- Update
scripts/dogfood.sh to derive exclusion and remediation behavior from each workflow’s metadata, with sensible defaults when metadata is absent.
- Add a lightweight validator script (invoked from CI/lint) to fail on malformed metadata keys/values.
- Document the manifest and examples in
gh-agent-workflows/DEVELOPING.md.
Why It Won't Be That Hard
This is a small, contained change: one sync script, one validator, and docs. No compiler changes are required, and the behavior already exists today in hardcoded arrays, so this is mainly moving existing logic to a declarative source of truth.
Evidence
Duplicate Check Notes
- Checked
/tmp/previous-findings.json; related ideas exist (e.g., scaffolding/linting/setup improvements), but none propose a per-workflow declarative metadata manifest to replace dogfood.sh behavior lists.
- Targeted open-issue searches for
dogfood metadata returned no open matches.
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 per-workflow
meta.ymlmanifest that declares dogfood behavior (for example excluded-from-dogfood and auto-remediation chaining) so maintainers don’t need to edit hardcoded lists inscripts/dogfood.sh.Why a Customer Would Want This
Maintainers adding or changing workflows want one obvious place to declare workflow behavior. Today, behavior is split between workflow directories and script-level arrays, which makes onboarding and maintenance error-prone and increases review churn when a new workflow needs special handling.
Rough Implementation Sketch
gh-agent-workflows/<workflow>/meta.ymlwith a tiny schema (for example:dogfood.exclude: true|false,dogfood.auto_remediation: true|false).scripts/dogfood.shto derive exclusion and remediation behavior from each workflow’s metadata, with sensible defaults when metadata is absent.gh-agent-workflows/DEVELOPING.md.Why It Won't Be That Hard
This is a small, contained change: one sync script, one validator, and docs. No compiler changes are required, and the behavior already exists today in hardcoded arrays, so this is mainly moving existing logic to a declarative source of truth.
Evidence
scripts/dogfood.sh(EXCLUDED_WORKFLOWSat lines 20-36, consumed at lines 60-67).scripts/dogfood.sh(REMEDIATION_WORKFLOWSat lines 40-49, consumed at lines 122-126 and appending chain at lines 151-160).gh-agent-workflows/DEVELOPING.md(for example lines 38, 118, 141, 201-203).Duplicate Check Notes
/tmp/previous-findings.json; related ideas exist (e.g., scaffolding/linting/setup improvements), but none propose a per-workflow declarative metadata manifest to replacedogfood.shbehavior lists.dogfood metadatareturned no open matches.What is this? | From workflow: Trigger Product Manager Impersonator
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.