From a744ed7722c05344b737b3ef7605ea1ad31ed3c6 Mon Sep 17 00:00:00 2001 From: "user.email" Date: Thu, 29 Oct 2026 20:55:46 -0700 Subject: [PATCH 1/2] feat(review): post one plain-language review Each pass was posting its own GitHub review, so one diff showed up as a comment and an approval. Dispatch now waits for every pass and posts a single review: plain language first, then path and failure mode. --- plugins/corbits-skills/skills/review/SKILL.md | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/plugins/corbits-skills/skills/review/SKILL.md b/plugins/corbits-skills/skills/review/SKILL.md index 2d6aaad91..4b12aa631 100644 --- a/plugins/corbits-skills/skills/review/SKILL.md +++ b/plugins/corbits-skills/skills/review/SKILL.md @@ -59,22 +59,26 @@ Raise what helps the author. Flag real defects and architecture that would const ## 6. Report and post -Summarize with the findings. When the target has an open GitHub PR, post the finished review on it; a review that only lives in chat is not done. Post when the operator asked for a PR review, when `/implement`'s whole-branch gate runs on a branch with an open PR, or when a record on the PR is the purpose. Do not post a private local read, and do not reopen the analysis while writing the body. +Summarize with the findings. When the target has an open GitHub PR, post the finished review on it; a review that only lives in chat is not done. Post when the operator asked for a PR review, when `/implement`'s whole-branch gate runs on a branch with an open PR, or when a record on the PR is the purpose. Do not post a private local read. Do not implement fixes. Do not reopen the analysis while writing the body. + +Wait until every pass Dispatch started has reported. Passes do not post to GitHub and do not approve, comment, or request changes. + +Then post exactly one review with `gh pr review`. One verdict for the whole diff. Use one of `--approve`, `--comment`, or `--request-changes`, and swap that flag to match the verdict: ```bash gh pr review --comment --body-file ``` -Use `--approve` or `--request-changes` for the verdict. Shape: +The body is for a person first. Open with what the branch does now, in plain language. Then what goes wrong, in plain language. Do not name the passes. Do not use finder jargon (no "trust check", "lens", "nullMeansUnset", "injected parser"). -```markdown -## Review · +Under that, each finding is one bullet an agent can act on: `path:line`, then the concrete failure mode. A clean review says "No findings." after the plain summary. No throat-clearing, praise to soften a finding, emoji, or "nit:" taste. - +```markdown + -### Findings + -- `path/to/file.ts:12` — concrete problem and why it matters +- `path/to/file.ts:12` — concrete failure mode ``` -A clean review says "No findings." after the one line. No throat-clearing, praise to soften a finding, emoji, or "nit:" taste. When more than one lens produced a distinct judgment (reviewer, planner waiver, warden), each posts its own labelled review, and only the lens that owns the merge verdict may approve. Paste the review URL back to the operator. Posting does not change Linear state. Remove the PR worktree afterward. +The note back to the operator is that same body plus the review URL. Do not write a second, more technical summary in chat. Posting does not change Linear state. Remove the PR worktree afterward. From 6dbd30247a8c639d9992c422afe62771067fab73 Mon Sep 17 00:00:00 2001 From: "user.email" Date: Thu, 29 Oct 2026 21:10:20 -0700 Subject: [PATCH 2/2] feat(review): list findings by severity and line range A review was a paragraph plus a bare path. Each finding is now one bullet: blocking, should-fix, or informational, then what goes wrong, then the line range. --- plugins/corbits-skills/skills/review/SKILL.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/plugins/corbits-skills/skills/review/SKILL.md b/plugins/corbits-skills/skills/review/SKILL.md index 4b12aa631..7aea010bb 100644 --- a/plugins/corbits-skills/skills/review/SKILL.md +++ b/plugins/corbits-skills/skills/review/SKILL.md @@ -52,9 +52,10 @@ Deeper work (file-by-file behavior, architecture, coherence) can go to sub-agent Raise what helps the author. Flag real defects and architecture that would constrain future work. Skip hypothetical problems in cases the code need not handle, stylistic nits, and vague remarks like "could be cleaner". -- Every finding has a `path:line` and a concrete failure mode. Severity is the review action, not adjectives. +- Every finding is one of **blocking** (breaks the contract or the behavior), **should-fix** (a real defect that should change in this diff), or **informational** (true, but not something this diff has to change; the same rank as file-for-later). Severity is the review action, not an adjective. +- Cite a line range, `path:start-end`, not a single line unless the failure is one line. A range is the lines a reader opens to see the failure. - Describe the branch as it stands now, in present tense, from `git diff ...HEAD`, not the journey or the PR description. -- Write to a colleague: propose rather than command, say why, describe consequences instead of "wrong" or "broken", and suggest the one-liner when the fix is small. +- Write the description for a person: what goes wrong, and the consequence. No finder jargon, no pass names. - **Cite the check.** Every affirmative claim ("tests pass", "no regressions") names the command or file range that proved it. Otherwise run the check, strike the claim, or narrow it to what you examined ("read `lock.go:42-68`, no acquire-while-holding cycle there"). ## 6. Report and post @@ -69,16 +70,18 @@ Then post exactly one review with `gh pr review`. One verdict for the whole diff gh pr review --comment --body-file ``` -The body is for a person first. Open with what the branch does now, in plain language. Then what goes wrong, in plain language. Do not name the passes. Do not use finder jargon (no "trust check", "lens", "nullMeansUnset", "injected parser"). +The body is one short paragraph of what the branch does now, then a bullet list. Nothing else. Do not name the passes. Do not use finder jargon. -Under that, each finding is one bullet an agent can act on: `path:line`, then the concrete failure mode. A clean review says "No findings." after the plain summary. No throat-clearing, praise to soften a finding, emoji, or "nit:" taste. +Each bullet is the severity, then the description, then the line range: ```markdown - - -- `path/to/file.ts:12` — concrete failure mode +- **blocking** — `path/to/file.ts:12-18` +- **should-fix** — `path/to/file.ts:40-44` +- **informational** — `path/to/file.ts:7` ``` +Request changes when any bullet is blocking or should-fix. Comment when every bullet is informational. Approve when there are no bullets, and say "No findings." after the paragraph. No throat-clearing, praise, emoji, or "nit:". + The note back to the operator is that same body plus the review URL. Do not write a second, more technical summary in chat. Posting does not change Linear state. Remove the PR worktree afterward.