review-pr-comments
PR comments: sequential review workflow
Walk the current PR’s feedback in order, one topic at a time. Treat each comment as something to read and answer; treat each underlying issue as something to fix once. If several comments say the same thing (or the first fix already covers a later remark), do not redo the same code work—use one commit for that shared fix and reply on each later comment pointing at that commit (e.g. “Addressed in <sha> — same fix as …”).
Prerequisites
ghauthenticated (gh auth status).- A PR for the checked-out branch (
gh pr viewwithout a number targets it). - Follow repo rules for git write: do not commit or push unless authorized for this session.
Pick the best gh command per step
gh pr …, gh api (REST), and gh api graphql hit different GitHub APIs—same intent, not interchangeable. There is no blanket rule favoring one surface; choose whatever is correct and clearest for that action.
More from latitude-dev/latitude-llm
gh-issue
Create clear, actionable GitHub issues for bugs, features, and improvements. Issues are primarily consumed by LLMs, so optimize for agent readability and actionability.
4testing
Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.
4docs
Review the current conversation context and git changes, then persist durable repository knowledge into `dev-docs/*.md` by domain and into `AGENTS.md` for cross-cutting repo rules. Use after features, fixes, refactors, architecture changes, schema changes, or when the user mentions docs, documentation, design, architecture, business logic, conventions, or `AGENTS.md`.
4create-pr
Patterns and conventions for creating a good PR
4authentication
Sessions, sign-in/sign-up flows, OAuth, magic links, or organization context on the session.
4analyze-problem
>-
4