docs: clarify in a few spots

Author: omarkohl

README.md

@@ -9,13 +9,14 @@ request. When you update a PR, jip posts a comment showing what you changed
 
 ## Features
 
-- **One commit = one PR** — each commit gets its own focused, reviewable PR
+- **One commit = one PR** — each commit gets its own focused, reviewable PR,
+  with title and description taken from the commit message
 - **Review comments on update** — when you update a PR, jip posts a diff
   showing only what you changed (rebase noise is filtered out)
 - **Automatic bookmarks** — no need to manually create jj bookmarks
 - **Fork workflow** — works without write access to the target repo
 - **Normal GitHub merge** — no special "land" command, just merge PRs as usual
-- **Merge commits in stacks** — supports non-linear revision graphs
+- **Stacks may contain merge commits** — supports non-linear revision graphs
 
 ## Installation
 

docs/reviewing.md

@@ -16,14 +16,17 @@ highlighted commit (5670b0e in the screenshot above).
 
 ## How to review
 
-### The simple approach (recommended for most reviewers)
+### The standard approach
 
 1. **Start from the bottom of the stack** (PR #1 in the example above).
 2. **Review only the commit highlighted in the description.** Each PR is one
    self-contained change.
-3. **Approve or request changes** as you would with any normal PR.
-4. **Merge from the bottom up.** Merge PR #1 first. The PR author will then
-   rebase and update the remaining PRs so PR #2 targets `main` directly.
+3. **Approve or request changes** as you would with any normal PR. If the
+   highlighted commit of the PR looks good, approve the PR, even if some
+   earlier PR in the chain might require a fix.
+4. **Merge from the bottom up.** Merge PR #1 first, then PR #2 etc. The PR
+   author will rebase and update the remaining PRs if necessary (e.g. if GitHub
+   claims there is a conflict).
 
 ### The minimal approach (if stacked PRs feel overwhelming)
 

docs/why.md

@@ -30,6 +30,10 @@ this to GitHub's PR model by turning each commit into its own PR.
 
 ## The force-push problem
 
+If a commit is the unit of review it means that any improvements that are
+uncovered during review need to be fixed by amending the commit, which in turn
+means you need to force push the PR branch.
+
 When you update a PR by force-pushing, GitHub shows the full diff against the
 base branch but provides no good way to see *what changed since the last
 review*. Reviewers are left re-reading the entire PR or mentally diffing