elastic / elastic/ai-github-actions
[product-manager-impersonator] Scheduled agent run manifest
- Dominant language
- Python
- Stars
- 11
- Forks
- 16
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 31
Description
## Feature Idea
**Summary:** Add a lightweight run-manifest step to scheduled agent workflows that writes the resolved run configuration to `$GITHUB_STEP_SUMMARY` before the agent starts.
## Why a Customer Would Want This
Maintainers running many scheduled agents need quick per-run context without opening workflow YAML or scanning raw logs. A compact summary showing the workflow source, model, title prefix, close-older behavior, setup status, trigger, actor, repo/ref, and previous-findings location would make failed or noisy scheduled runs much easier to triage.
## Rough Implementation Sketch
- Add a small reusable shell step or fragment for scheduled workflows that appends a `## Run Manifest` block to `$GITHUB_STEP_SUMMARY`.
- Wire it into the shared scheduled audit surface where inputs are already centralized, e.g. `.github/workflows/gh-aw-scheduled-audit.md:22-60` defines `model`, `title-prefix`, `issue-label`, `setup-commands`, `close-older-issues`, `allowed-bot-users`, and `messages-footer`.
- Place it before existing pre-agent setup steps such as `.github/workflows/gh-aw-scheduled-audit.md:83-104`, so the manifest is available even if previous-finding fetch or repo-specific setup later fails.
- Document the behavior in `gh-agent-workflows/scheduled-audit/README.md`; its current inputs table at `gh-agent-workflows/scheduled-audit/README.md:32-41` already gives the user-facing metadata to summarize.
## Why It Won't Be That Hard
This should be a small additive change: scheduled workflows already resolve all of the relevant inputs before the agent runs, and `$GITHUB_STEP_SUMMARY` requires no new permissions, API calls, or safe-output schema changes. The implementation can start with the generic `scheduled-audit` workflow and then be reused by specialized scheduled detectors that import the same scheduled-audit pattern.
## Evidence
- `.github/workflows/gh-aw-scheduled-audit.md:22-60` centralizes the inputs that maintainers need to see when debugging a scheduled run.
- `.github/workflows/gh-aw-scheduled-audit.md:83-104` already has pre-agent shell steps where a summary-writing step could fit naturally.
- `gh-agent-workflows/scheduled-audit/example.yml:14-20` shows consumers call the reusable lock workflow and provide `title-prefix`, `issue-label`, and `additional-instructions`, but there is no quick run-level summary of the resolved values.
- Recent activity includes multiple workflow-run/debugging fixes and reports, including run pagination (#1248), agent credit failures, and safe-output replay receipts (#893), which shows maintainers are actively improving run operability; this idea is narrower than a health watchdog or outcome-output feature.
---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Product Manager Impersonator](https://github.com/elastic/ai-github-actions/actions/runs/28021449441)
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Contributor guide
Research direction
Start with .github/workflows/gh-aw-scheduled-audit.md:22-60 to trace the centralized inputs, then inspect the pre-agent steps at lines 83-104 and the consumer example in gh-agent-workflows/scheduled-audit/example.yml:14-20. Add the reusable manifest behavior and document it in gh-agent-workflows/scheduled-audit/README.md, with the resolved run details visible in $GITHUB_STEP_SUMMARY before setup or agent execution.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, markdown, shell
- Domain
- ci-cd
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100