Remove needs: dependencies that do not exist

GitHub Actions schedules a job the moment every job named in its needs: list finishes, regardless of whether the runner sat idle waiting. When a needs: edge was added for readability, to mirror a copy-pasted job, or just because someone assumed lint should come before test, the two jobs still run one after another even though the runner pool has capacity to run them at the same time. Total wall-clock time becomes the sum of both jobs' durations instead of the longer of the two, and nothing in the workflow file signals that the wait was avoidable, because the YAML is valid and the run finishes green either way.

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  unit-tests:
    runs-on: ubuntu-latest
    # No needs:. lint and unit-tests each check out and install independently,
    # so they start together instead of one waiting on the other.
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    # Also independent of lint and unit-tests; it reads only the checkout.
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

1. 01

   List every needs: edge in the workflow: grep -rn 'needs:' .github/workflows/ (both the single-job needs: build form and the list needs: [lint, build] form).

2. 02

   For each edge, open the downstream job's steps and check for actions/download-artifact (or actions/cache/restore) pulling something the upstream job uploaded with actions/upload-artifact. If it downloads nothing from that job, the edge is not artifact-backed.

3. 03

   Check for needs.<job>.outputs.* referenced anywhere in the downstream job's with:, env:, or if: blocks. If the job name from needs: never appears inside needs.<job-name>.outputs, no output is being consumed.

4. 04

   Check for a genuine side-effect dependency: does the downstream job deploy to an environment, install a package, or read a resource that only exists once the upstream job (a publish, a migration, an infrastructure apply) has completed. This is real even with no artifact or output.

5. 05

   Anything left after those three checks come back empty is an edge kept only for ordering or readability, and can be removed.

• -

  A gate job that is meant to fail fast before burning runner minutes on a doomed run is a genuine reason to keep an edge even with no artifact or output changing hands: needs: lint on an expensive integration-test job can be intentional cost control, not an accident. Keep it, and say in a comment that it is a deliberate gate.

• -

  A deploy job must not start before the jobs that verify the build are done; removing needs: from a deploy job to save wall-clock time turns a safety check into a race and is a regression, not an optimization.

• -

  Removing an edge changes what a partial failure looks like: with needs:, a failed upstream job skips the downstream one; without it, downstream jobs run and may report their own failures on top of the real one, which can be noisier to triage even though it finishes faster.

• -

  If two jobs happen to be independent today but a future change will make one produce something the other needs, removing the edge now means someone has to remember to add it back; leaving a short comment explaining why there is no needs: helps the next author not reintroduce it out of caution.

A needs: edge is genuine only when the downstream job consumes something the upstream job produced. There are exactly three ways that happens: the downstream job runs actions/download-artifact for a file the upstream job uploaded with actions/upload-artifact; the downstream job reads needs.<job>.outputs.* set via a step's outputs and the job's own outputs: map; or the downstream job depends on a side effect the upstream job performed that only exists after it runs, a package published to a registry, an environment deployed, an image pushed. If a downstream job's steps do not do any of these three things with the specific job named in needs:, the edge exists only to make one job start after another, and that ordering can be had for free by running both at once instead.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to run this audit and open the fix as a reviewable PR.

Audit this repository's GitHub Actions workflows for unnecessary needs: dependencies and remove the ones that only enforce ordering.

1. grep .github/workflows/ for needs: and list every edge, including both the
   single-job form (needs: build) and the list form (needs: [lint, build]).
2. For each edge, open the downstream job and check three things: does it run
   actions/download-artifact (or actions/cache/restore) for something the
   upstream job uploaded; does it reference needs.<job>.outputs anywhere in
   with:, env:, or if:; does it depend on a side effect the upstream job
   performed (a deploy, a publish, a migration). If none of the three hold,
   the edge is ordering-only and is a candidate for removal.
3. Before removing an edge, check whether the upstream job is a deliberate
   fail-fast gate (an expensive job intentionally kept behind a cheap one to
   save runner minutes on a doomed run) or precedes a deploy that must not
   run before checks pass. Leave those edges in place.
4. Read the GitHub Actions needs context and workflow syntax docs linked on
   this page before editing.
5. Show the full diff and open a pull request rather than applying changes
   blindly. In the PR body, list each removed edge with file and line, state
   why it was not artifact-, output-, or side-effect-backed, and describe how
   to verify: check the run's workflow graph for the jobs starting together
   and compare total wall-clock time before and after.