@@ -86,75 +86,58 @@ Parse `$ARGUMENTS` to extract the repo and PR number:
8686
8787# ### Part A: Inline file comments
8888
89- For each specific issue, post a comment on the exact file and line:
89+ For each issue, post a comment on the exact file and
90+ line. Keep comments short (1-3 sentences), end with
91+ ` — Claude Code` . Use line numbers from the ** new
92+ version** of the file.
93+
94+ ** Without suggestion block** — single-line command,
95+ ` < br> ` for line breaks:
9096
9197` ` ` bash
9298gh api -X POST \
9399 -H " Accept: application/vnd.github+json" \
94100 " repos/<owner/repo>/pulls/<number>/comments" \
95- -f body=" Your comment<br><br>— Claude Code" \
96- -f path=" path/to/file" \
97- -F line=< line_number> \
98- -f side=" RIGHT" \
99- -f commit_id=" <headRefOid>"
101+ -f body=" Issue description.<br><br>— Claude Code" \
102+ -f path=" file" -F line=42 \
103+ -f side=" RIGHT" -f commit_id=" <headRefOid>"
100104```
101105
102- ** The command must stay on a single bash line.** Never use newlines in
103- bash commands — use ` <br> ` for line breaks in comment bodies. Never put
104- ` <br> ` inside code blocks or suggestion blocks.
105-
106- Each inline comment must:
107-
108- - Be short and direct — say what's wrong, why it's wrong, and how to
109- fix it in 1-3 sentences
110- - No filler, no complex words, no long explanations
111- - When the fix is a concrete line change (not architectural), include
112- a GitHub suggestion block so the author can apply it in one click:
113-
114- ```` text
115- ```suggestion
116- corrected-line-here
117- ```
118- ````
119-
120- Only suggest when you can show the exact replacement. For
121- architectural or design issues, just describe the problem.
122- Example with a suggestion block:
123-
124- ``` bash
125- gh api ... -f body=$' Missing the update.\
126- <br><br>\n ```suggestion\n \
127- /plugin update shared-guidelines@hub\n \
128- /plugin update scality-skills@hub\n \
129- ```\n <br><br>— Claude Code' ...
130- ```
131-
132- - When the comment contains a suggestion block, use ` $'...' ` quoting
133- with ` \n ` for code fence boundaries. Escape single quotes as ` \' `
134- (e.g., ` don\'t ` )
135- - End with: ` — Claude Code `
136-
137- Use the line number from the ** new version** of the file (the line
138- number you'd see after the PR is merged), which corresponds to the
139- ` line ` parameter in the GitHub API.
106+ ** With suggestion block** — use a heredoc
107+ (` -F body=@- ` ) so code renders correctly:
140108
141- #### Part B: Summary comment
109+ ```` bash
110+ gh api -X POST \
111+ -H " Accept: application/vnd.github+json" \
112+ " repos/<owner/repo>/pulls/<number>/comments" \
113+ -F body=@- -f path=" file" -F line=42 \
114+ -f side=" RIGHT" \
115+ -f commit_id=" <headRefOid>" << 'COMMENT_BODY '
116+ Issue description.
142117
143- ``` bash
144- gh pr comment < number > --repo < owner/repo > \
145- --body " LGTM<br><br>Review by Claude Code "
118+ ```suggestion
119+ first line of suggested code
120+ second line of suggested code
146121```
147122
148- ** The command must stay on a single bash line.** Never use newlines in
149- bash commands — use ` <br> ` for line breaks in comment bodies.
123+ — Claude Code
124+ COMMENT_BODY
125+ ````
150126
151- Do not describe or summarize the PR. For each issue, state the problem
152- on one line, then list one or more suggestions below it:
127+ Only suggest when you can show the exact replacement.
128+ For architectural or design issues, just describe the
129+ problem.
153130
154- ``` text
155- - <issue>
156- - <suggestion>
157- - <suggestion>
131+ #### Part B: Summary comment
132+
133+ Single-line command, ` <br> ` for line breaks. No markdown
134+ headings — they render as giant bold text. Flat bullet
135+ list only:
136+
137+ ``` bash
138+ gh pr comment < number> --repo < owner/repo> \
139+ --body " - file:line — issue<br>\
140+ - file:line — issue<br><br>Review by Claude Code"
158141```
159142
160143If no issues: just say "LGTM". End with: ` Review by Claude Code `
0 commit comments