GitHub Actions prompts should identify the workflow event and trust boundary before changing YAML. A job that works on a branch push can fail on a forked pull request because its credentials and context differ. A faster dependency step may also restore the wrong files if its cache key ignores a relevant input. These prompts focus on understanding the run, mapping permissions and measuring proposed improvements.
Collect the workflow and the triggering event
Provide the workflow file, runner environment, package manager and failed step output. Include whether the run was a push, pull request, scheduled job or manual invocation. If reusable workflows are involved, supply the called files as well. An agent cannot explain inherited behavior by reading only the top-level job name.
GitHub's token documentation explains that workflows can control the permissions of their generated token. Use that reference for token behavior; the review prompts below are original suggestions for applying it. Keep credential values out of the evidence bundle.
Map permissions to actual operations
A permission review should connect every requested capability to a concrete step. Reading source, publishing a package and posting a pull request comment are separate needs. Ask the agent to consider untrusted inputs, including event fields interpolated into commands. It should flag uncertainty instead of granting a broad permission to make the error disappear.
Review {{workflow_path}} for GitHub Actions permission boundaries.
For each job, list its event, trusted inputs, token operations and minimum
permissions supported by the steps. Inspect called workflows and actions.
Explain forked-PR behavior and any command interpolation of untrusted text.
Propose a focused diff and validation cases. Do not broaden access merely
to suppress a failing step.
Diagnose the earliest failed assumption
A red job can be caused by installation, toolchain drift, unavailable secrets or the application itself. Ask for a short sequence from setup to failure. Comparing the last passing run is more useful than changing several action versions at once. Preserve the original error and test one explanation at a time.
Investigate this Actions failure: {{failed_step_log}}.
Read {{workflow_path}} and compare {{last_passing_run_details}}.
Identify the first failed assumption and separate runner, dependency,
credential and application causes. Suggest the smallest diagnostic change.
Then propose a fix and the event types that must be re-run to verify it.
Optimize caching using comparable runs
Set a measurable objective such as reducing dependency setup time without changing installed versions. Ask what belongs in the cache and what should be rebuilt. A cache hit is not automatically a good result if extraction costs more than installation. Include lockfile changes and a cold run in the validation plan.
Review dependency caching in {{workflow_path}} for {{package_manager}}.
Use these timings: {{run_timings}}. Identify cached paths, key inputs,
restore fallbacks and invalidation behavior. Propose one improvement.
Compare cold, warm and changed-lockfile runs. Report elapsed time and
correctness checks; do not claim a speedup without measured evidence.
Make the workflow change reviewable
Before merging, inspect the generated workflow as a fresh reviewer would. Can you tell which events run it, which jobs can publish and how failure stops deployment? Check cancellation behavior for superseded runs and verify required checks retain their expected names. Keep deployment approval rules visible when optimizing the pipeline.
Save the reviewed workflow prompt in Kipt with variables for event, workflow path and run evidence. For another CI platform, use the GitLab CI prompts, which focus on pipeline rules and artifact dependencies rather than translating syntax mechanically.