@staff0rd/assist 0.218.0 → 0.219.0

package/dist/index.js

@@ -6,7 +6,7 @@ import { Command } from "commander";
 // package.json
 var package_default = {
   name: "@staff0rd/assist",
-  version: "0.218.0",
+  version: "0.219.0",
   type: "module",
   main: "dist/index.js",
   bin: {
@@ -12206,12 +12206,46 @@ async function runApplySession(synthesisPath) {
 import { existsSync as existsSync35, unlinkSync as unlinkSync12 } from "fs";
 
 // src/commands/review/buildReviewerStdin.ts
-var REVIEW_PROMPT = `You are reviewing a code change. The full review request \u2014 branch, base, changed files, and unified diff \u2014 is in request.md in the current working directory.
+var REVIEW_PROMPT = `You are acting as a reviewer for a proposed code change made by another engineer. The full review request \u2014 branch, base, changed files, and unified diff \u2014 is in request.md in the current working directory.
 
-Read request.md, then produce a thorough code review in Markdown. For each finding include:
+Read request.md, then produce a thorough code review in Markdown.
+
+## When to flag a finding
+
+A finding is worth raising only if all of the following hold:
+
+1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.
+2. The issue is discrete and actionable \u2014 not a vague observation about the codebase or a tangle of several things.
+3. Fixing it does not demand more rigour than the rest of the codebase already shows (e.g. don't ask for exhaustive input validation in a repo of one-off scripts).
+4. The issue was introduced by this change. Do not flag pre-existing bugs.
+5. The original author would likely fix it if made aware.
+6. It does not rely on unstated assumptions about the codebase or author's intent.
+7. You can name the concretely affected code path. Speculation that a change *might* disrupt something elsewhere is not enough \u2014 identify the other code that is provably affected.
+8. It is clearly not an intentional change by the author.
+
+## How to write the comment (Impact + Recommendation)
+
+1. Make clear *why* the issue is a bug.
+2. Communicate severity accurately \u2014 do not inflate.
+3. Keep it brief: at most one paragraph of prose. Avoid line breaks inside the natural-language flow unless needed for a code fragment.
+4. Do not paste code chunks longer than 3 lines. Wrap short snippets in inline code or a fenced block.
+5. State explicitly the scenarios, environments, or inputs needed for the bug to manifest \u2014 and signal up front that severity depends on those factors.
+6. Tone is matter-of-fact: not accusatory, not gushing. Read as a helpful assistant, not a performative human reviewer.
+7. Write so the author grasps the point on first read.
+8. Avoid flattery and filler ("Great job\u2026", "Thanks for\u2026"). They are not useful to the author.
+
+Ignore trivial style unless it obscures meaning or violates a documented standard. One finding per distinct issue.
+
+## How many findings to return
+
+List every finding that the original author would want to know about and fix. Do not stop at the first qualifying one. If nothing clears the bar above, return no findings \u2014 empty is better than padded.
+
+## Output format
+
+For each finding include:
 - Severity (blocker, major, minor, nit) \u2014 see rubric below
 - File and line (e.g. \`src/foo.ts:42\`) when the finding is tied to a specific location
-- Impact: what could go wrong
+- Impact: what could go wrong, including the conditions under which it manifests
 - Recommendation: a concrete change
 
 Severity rubric:

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@staff0rd/assist",
-	"version": "0.218.0",
+	"version": "0.219.0",
 	"type": "module",
 	"main": "dist/index.js",
 	"bin": {