What fits a repetitive pull request task such as drafting a description?
Why A is the answer
A generated summary that you then read and correct
Generated text saves time, but the author still checks that it describes the change accurately.
In detail
- A generated summary saves time, and you stay responsible for it.
- You stay responsible for what it says.
Use case
An illustrative scenario, not a real incident.
A developer lets Copilot draft a pull request summary, then corrects one line that misdescribes the change. Reviewers get a clear description in less time.
See it in different ways
stateDiagram-v2 [*] --> Suggested Suggested --> Reviewed: check correctness, security and fit Reviewed --> Accepted: passes review Reviewed --> Rejected: fails review Accepted --> [*] Rejected --> [*]
flowchart LR S0["Generate summary"] --> S1["Read it"] --> S2["Correct it"] --> S3["Open for review"]
Key point: Generate the summary, then read and correct it.
Why the other options are wrong
- B. Leaving the description empty, so that reviewers read the diff
- An empty description gives reviewers less help.
- C. An instructions file that lists every file in the repository
- A list of files is not a description of the change.
- D. A longer branch name that explains what the change does
- A branch name cannot explain a change.