humanifylisted

# 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". | Kind of text | Length | |---|---| | Review comment | 1-3 sentences, under a `file:line` label | | Message | A few lines | | PR description | A short paragraph, plus a list only when needed | |