humanify

Take whatever the user has, a draft, a pile of findings, or something they ask you to write first, and turn it into text a person would actually write and want to read.

When the prompt asks for content and humanify together, gather what the content needs first (the diff, the files, the conversation), then write it by these rules straight away. Do not write a long version and cut it down.

The result replaces the source text if it came from a file. Otherwise it is the text itself and nothing else.

The rules below are defaults. What the user asks for wins.

Rules

• KISS. Say the one thing, then stop. Cut anything the reader can act without.
• Write for someone reading it cold. Plain words, short sentences, active voice.
• Fit the length to the kind of text (table below).
• Keep only what the user asked for. "The 3 issues" means exactly 3, not 3 plus nits.
• Phrase review items as something to check or a question, not a verdict. "Could you check X? ... Maybe Y?"
• For a problem, say what it is, how to see it in one line, and optionally a fix in one line. No walkthrough of the mechanism.
• For a change, say what it does for the reader, not how it is wired.
• Keep every fact the reader needs to act. Invent nothing.
• No preamble, no closing summary, no "hope this helps".

If the text follows a repo template, or a shape from draft-pr or draft-issue, keep its sections and shorten inside them.

Formatting

• No em dashes or en dashes. Use a comma, a colon, a full stop or a plain hyphen.
• No sentence broken across lines. One paragraph is one line.
• No emoji, no horizontal rules, no headings in short text.
• Bold only as a label, such as the file:line on a review comment.
• Identifiers in backticks.
• A code block only when the snippet is shorter than describing it.

Example

The user asks for "the 3 issues, as review comments". The draft:

## Review summary

Thanks for the PR! Overall this is a really solid refactor of the gesture state handling — the new parking logic is much easier to follow than the old flag soup. That said, I found a few issues worth addressing before we merge. I've grouped them by severity below.

### Critical: `end()` can skip `onStart` while the handler is parked

**File:** `NativeGestureManager.cpp`, line 325

When a handler is parked (i.e. it has been activated but is waiting for a double tap to fail), calling `activate()` followed by `end()` causes the following sequence:

1. `activate()` sees the handler is parked and returns early without transitioning.
2. `end()` does not check the parked state at all.
3. The state machine therefore moves straight from BEGAN to END.
4. Because ACTIVE is never reached, `onStart` is never called.
5. And since the handler is no longer BEGAN, the double tap can no longer cancel it, which defeats the purpose of parking.

This could cause subtle bugs in anything that relies on `onStart` running before `onEnd`, for example animations that set up state in `onStart`.

**Suggested fix:** Keep the handler parked when it is `held`, record the lift with something like a `liftedWhileHeld` flag, and replay the end once the double tap fails.

### Major: `cancelAll()` skips handlers

**File:** `GestureHandlerOrchestrator.cpp`, line 141

`cancelAll()` loops over `awaitingHandlers` with an iterator, but `cancel()` erases the handler from that same vector. After the first erase the iterator points one element too far, so every second handler is skipped and stays awaiting forever. It's easy to reproduce with two pans that both wait for the same tap.

**Suggested fix:** Copy the vector before looping, or loop with the return value of `erase()`.

### Minor: pointer count read after erase

**File:** `NativeGestureManager.cpp`, line 512

In `onTouchesUp`, `pointers_.size()` is read after the pointer is erased. When both fingers of a pinch lift in the same event, `numberOfPointers` reaches 0 on the first pointer, so the handler ends twice.

**Suggested fix:** Read the count before erasing.

### Nits

- `isHeld` might read better as `held()` to match the other accessors.
- `resetParking()` could be `const`.
- It would be great to add a test for the parked path!

Let me know if you have any questions — happy to pair on any of this.

The result:

**NativeGestureManager.cpp:325**
Could you check `activate()` followed by `end()` while the handler is parked? `end()` takes it BEGAN to END with no `onStart`, and the double tap can't cancel it anymore. Maybe keep it parked with `liftedWhileHeld` when it's `held`?

**GestureHandlerOrchestrator.cpp:141**
Could you check `cancelAll()` with two pans waiting on the same tap? `cancel()` erases from `awaitingHandlers` mid-loop, so the second one is skipped and stays awaiting. Maybe copy the vector first?

**NativeGestureManager.cpp:512**
Could you check a pinch where both fingers lift in the same event? `pointers_.size()` is read after the erase, so the handler ends twice. Maybe read the count before erasing?

The severity headings, the step-by-step walkthrough, the nits and the sign-off are gone. Each comment keeps the problem, how to see it and a fix.