Diligence-AI Pull Request Workflow
Confirm gh auth status, then use authenticated gh directly for GitHub operations. For
GitLab, use its configured authenticated tooling. Existing repository permissions and the
operator's task authority remain the limit.
Before branch or PR work, check whether the active task has a Linear issue. If it does, use linear-workflow to keep its status current. Link the PR after it opens, and record QA evidence before merge. Do not pass a checkpoint while tracked work is disconnected from its issue, because Linear will otherwise show stale work.
- Branch from
devor the repository default. Keep code and its task documentation on one branch, and link the plan or task document from the Linear issue when one exists. - Open a draft PR as soon as the branch has a change that GitHub or GitLab can compare. Link the PR from its Linear issue when the task is tracked there.
- Share the PR link, not a raw file or commit link.
- Before asking for human review, run a thorough self-review in fresh agent context. Resolve each valid finding, then test the change end to end in the way a user will use it.
- Write a PR description that explains what changed, why, how it was tested, and what needs reviewer attention. State any deliberate omission and link its tracking issue.
- Mark the PR ready only after self-review and QA pass. Every PR needs final human review.
- Any code change after the review gate repeats the gate: self-review, QA, and human approval must pass again before merge.
- Merge only with the required approval, passing required checks, and explicit authority for the merge. Do not bypass repository controls.
For an operator-requested Opus or Fable review, use external-code-review. For user-flow testing after a feature reaches staging, use staging-browser-qa.
For the Diligence org-skills repository, follow org-skill-authoring; its ready-PR rule overrides the draft-PR rule above.