ShockVPN/shockbot
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: continue improving review feedback

Browse Source
This commit is contained in:
wolfy
2026-05-31 15:20:38 -05:00
parent 4a1743126e
commit fc11b91851
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modes.ts
+3 -1
View File
@@ -37,6 +37,8 @@ Open with a single bolded inline lead-in followed immediately by the bullet list
- **Short human-readable title** — 1 sentence per substantive change. Write a short prose phrase; when you name a file, type, or function, put that name in backticks (e.g. **Add \\\`TodoTracker\\\` for live checklists**). A reviewer should understand the full reviewed scope from this list alone — this IS the dispassionate "what was reviewed and what changed" overview, so cover the substantive changes, not just the loudest ones.
**IMPORTANT**: these bullets describe what the PR *changed* — they are a neutral inventory of changes, not reviewer findings. "Added X feature" or "Refactored Y service" is correct. "X feature has a race condition" or "Y service is missing validation" is a FINDING — it goes in an inline comment or a \`### \` section, never in the preamble bullets. Do NOT mix findings into this list.
<!--
shockbot review metadata — for any agent (or human-with-agent) reading this
review. Incorporate the fields below into your understanding of the context
@@ -141,7 +143,7 @@ Inline comments are plain, no-frills anchors on the affected line:
- **Lead with a 1-2 sentence problem statement.** The reader is looking at the line in question, so don't restate what the line says — describe what's wrong with it.
- **Optional \`<details><summary>Technical details</summary>...</details>\` collapsible** for findings whose technical context (longer file:line references, related-code snippets, suggested approach, regression-risk notes) would overwhelm the human-readable lead-in. Same plain-markdown bold-header shape as the body technical-details block — see *Inline technical details* above. Encouraged whenever the depth helps a downstream fix-agent; don't force one when the inline lead-in already says everything.
- **Visible portion ≤ 2-3 sentences.** If you find yourself writing more, that's the cue to split the depth into the \`Technical details\` collapsible.
- **Multi-site findings go inline too.** A finding that spans multiple files or multiple lines is still an inline comment — anchor it to the PRIMARY causal site (the place a developer would fix first), and list the other affected sites in the \`**Affected sites:**\` section of the technical-details block. "Spans multiple files" is NOT a reason to put a finding in the body.
- **Multi-site findings go inline too, as ONE comment.** A finding that spans multiple files or multiple lines is still a single inline comment — anchor it to the PRIMARY causal site (the place a developer would fix first), and list the other affected sites in the \`**Affected sites:**\` section of the technical-details block. "Spans multiple files" is NOT a reason to put a finding in the body. **Never post two separate inline comments for the same logical issue** — one finding = one comment, always.
- **Anchor to the exact problem line.** Use the \`| newLine |\` column to find the specific line where the problematic symbol is **defined or first assigned** — not a nearby related line. If the symbol is \`isAnyPending\`, anchor to the line that defines \`isAnyPending\`, not a line that uses a different variable nearby.
## Body-wide rules