A program manager at a 40-person logistics firm wants a weekly competitor-pricing summary posted as an issue. The repo has no automation yet, changes need review, and the logic must be versioned with the code. Which practice for creating agentic workflow files best meets these versioning and review needs?
Select an answer to reveal the explanation.
Short Explanation
You’ve got this — keeping automation where your code lives makes teamwork smoother. A workflow file in the repository gives you traceability like a lab notebook for every change, and pull request reviews can catch mistakes before they run.
Full Explanation
Creating a new workflow definition file inside the repository best meets the versioning and review needs: the workflow can be stored with the code, changes can be reviewed through pull requests, and the file can define the required weekly issue-posting automation. A versioned workflow scheduled weekly to commit the summary to documentation does not meet the requested output: committing documentation is not the same as posting an issue, even though the workflow is stored in the repository and scheduled. A scheduled task in an external automation service can post an issue, but its logic is outside the repository, so it is not versioned with the code or reviewed through the repository’s pull request process. A repository workflow triggered manually preserves in-repository versioning and can post an issue, but a person must trigger it, so it does not provide the requested weekly automatic run. The exam caveat is to verify all constraints together: plausible choices may meet most of them but differ in output, location, or trigger. As a practical check, inspect the merged pull request for the workflow file and its review history, then verify that the configuration schedules a weekly run, has appropriately scoped issue-writing permission, and creates an issue with the expected formatting in a test run.