# Triage a technical review from your phone without over-approving

Canonical: https://githtml.com/guides/triage-technical-review-from-phone
Published: 2026-09-26
Publisher: WaveTech LLC / gitHtml

A phone review is useful for triage: understanding the proposed change, spotting missing evidence, and assigning focused follow-up. Limit the review to a clear question and record what you actually inspected. Do not turn a convenient reading session into full approval when the decision requires deeper source inspection or testing.

## Choose a bounded review question

An illustrative question might be whether a migration plan identifies all known callers, not whether the entire migration is safe. Start with the change summary, intended outcome, reviewed revision, and decision requested. A concise HTML packet should expose those facts before detailed logs or diagrams. GitHub's permanent file links help connect a saved packet to stable evidence. If the packet points only to a moving branch, ask which revision its statements describe before investing time in the review.

## Use three passes with different purposes

First scan for scope and consequence: what changes, who is affected, and whether irreversible work is involved. Next read the evidence for the requested decision. Finally list gaps that prevent a conclusion. An illustrative gap is an unverified old-client interaction, not a vague concern that testing seems light. Avoid copying a huge diff into a narrow viewport and pretending it has been reviewed. Use focused excerpts with enough context, and reserve the complete source inspection for the appropriate development environment.

1. Scope pass: identify the decision, revision, affected users, and consequence.
2. Evidence pass: inspect the sources relevant to that specific decision.
3. Handoff pass: name each unresolved question, its owner, and the required evidence.

## Send a precise result through the right channel

Use clear statuses such as ready for deeper review, blocked on compatibility evidence, or question answered within stated scope. Distinguish these from formal approval. Record any sections you could not inspect and avoid relying on memory when you return to the desktop. gitHtml can make a committed HTML review packet readable on an iPhone or iPad, but comments, approvals, code changes, and test execution belong to the user's separate tools and workflow. Keep the packet's key content available without optional scripts so the review does not depend on interactive controls.

## Sources and further reading

- [GitHub Docs: Getting permanent links to files](https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files)
- [W3C WAI: Page Structure Tutorial](https://www.w3.org/WAI/tutorials/page-structure/)

## Related guides

- [Write evidence-backed technical review findings](https://githtml.com/guides/write-evidence-backed-code-review-findings)
- [Review an observability plan by asking what a responder can learn](https://githtml.com/guides/review-observability-plan)
- [Review a technical debt proposal using concrete maintenance costs](https://githtml.com/guides/review-technical-debt-proposal)
- [Review architecture boundaries from a phone without losing context](https://githtml.com/guides/review-architecture-boundaries-on-phone)

Editorial approach: https://githtml.com/guides/about