An analysis agent generates a feature plan during a GitHub Actions workflow. The plan must be passed to a separate implementation agent in a later job. Which approach best preserves the structured plan so the implementation agent can consume it reliably?
Select an answer to reveal the explanation.
Short Explanation
Think of workflow artifacts like a baton passed between relay runners — uploading the JSON plan hands it off after the planning job, and downloading it picks it up for the implementation job. JSON keeps the structured data machine-readable across job boundaries.
Full Explanation
Workflow artifacts are the canonical inter-job data transport in GitHub Actions. The analysis agent writes its plan to a JSON file, preserving structure, types, and nesting, uploads it with actions/upload-artifact, and the implementation job downloads it with actions/download-artifact. This approach is reliable, auditable because the artifact is visible in the Actions UI, and supports structured data of any size.
The approach that prints the plan to stdout and pipes it through an environment variable using $GITHUB_ENV is wrong because $GITHUB_ENV passes key=value pairs between steps within the same job, not between separate jobs, and it does not support multiline JSON values safely without careful escaping. It is the wrong tool for cross-job communication.
The approach that stores the plan in a GitHub secret is wrong because secrets are write-only from a workflow perspective — they can be read as environment variables but cannot be written by a job at runtime. They are for storing static credentials, not dynamic agent output.
The approach that commits the plan as a JSON file to the main branch is wrong because it introduces an unreviewed commit to the production branch from an automated process, violates branch protection rules in most setups, and conflates the plan artifact with the repository source. It also creates race conditions if multiple agents are running simultaneously.
Uploading a JSON artifact is the intended pattern for agent-to-agent handoffs across job boundaries in GitHub Actions. It keeps the plan immutable, versioned per workflow run, and downloadable for post-hoc audit.