Repository navigation
[product-manager-impersonator] Single-workflow compile target #1063
Description
Feature Idea
Summary: Add an optional targeted compile command (make compile-workflow WORKFLOW=<name>) so maintainers can regenerate only one workflow’s generated files during edits.
Why a Customer Would Want This
Workflow maintainers usually touch one workflow at a time, but today the documented path always recompiles and re-syncs the entire catalog. That makes iteration slower and creates large unrelated generated diffs, which is frustrating for contributors and reviewers.
Rough Implementation Sketch
- Add a
compile-workflowMake target that requiresWORKFLOW=<name>and compiles only the matching workflow source/lock file. - Extend
scripts/dogfood.shwith an optional workflow filter so sync can regenerate onlytrigger-<name>.yml(including existing dogfood override and remediation-chain behavior). - Keep
make compileas the full-repo path; the new target is additive for focused edits. - Document the new command in
gh-agent-workflows/DEVELOPING.mdnext to the currentmake compileguidance.
Why It Won't Be That Hard
This is a focused ergonomics improvement with a small implementation surface (Makefile target + optional filter in one script + docs). It reuses existing compile/sync logic rather than introducing a new build system path.
Evidence
Makefile#L54-L63lists current make targets and only exposes fullcompile.Makefile#L167-L183showscompilealways runs fullsyncplus full compile/postprocess steps.scripts/dogfood.sh#L55-L150iterates allgh-agent-workflows/*/example.yml, regenerating all triggers every run.gh-agent-workflows/DEVELOPING.md#L145-L154documentsmake compileas the standard edit loop, with no targeted compile option.- Recent PR flow is active and frequent (for example feat(issue-triage): expose GH_AW_GITHUB_TOKEN in workflow_call contract #1026, Add classification-labels input and add-labels safe output to Issue Triage #1030), so tighter iteration loops would pay off immediately for maintainers.
Note
🔒 Integrity filter blocked 11 items
The following items were blocked because they don't meet the GitHub integrity level.
- Issue Fixer can use Ephemeral Token #1025
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #359
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #354
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #336
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #139
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #704
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #248
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #235
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #684
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #505
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #476
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower min-integrity in your GitHub frontmatter:
tools:
github:
min-integrity: approved # merged | approved | unapproved | noneWhat is this? | From workflow: Trigger Product Manager Impersonator
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Activity