reasonix 0.7.12 → 0.8.0

package/dist/cli/{prompt-2OABSPAW.js → prompt-POARCKKR.js}

@@ -2,9 +2,9 @@
 import {
   CODE_SYSTEM_PROMPT,
   codeSystemPrompt
-} from "./chunk-5DZMZCCW.js";
+} from "./chunk-DVBNMXA6.js";
 export {
   CODE_SYSTEM_PROMPT,
   codeSystemPrompt
 };
-//# sourceMappingURL=prompt-2OABSPAW.js.map
+//# sourceMappingURL=prompt-POARCKKR.js.map

package/dist/index.js

@@ -3525,6 +3525,34 @@ ${NEGATIVE_CLAIM_RULE}
 ${TUI_FORMATTING_RULES}
 
 The 'task' the parent gave you is the research question. Stay on it.`;
+var BUILTIN_REVIEW_BODY = `You are running as a code-review subagent. Your job is to inspect the changes the user is about to ship \u2014 usually the current git branch vs its upstream \u2014 and produce a focused review the parent can hand back to the user.
+
+How to operate:
+- Default scope: the current branch's diff vs the default branch. If the user's task names a specific commit range or files, honor that instead.
+- Discover scope first: \`run_command git status\`, \`git diff --stat\`, \`git log --oneline\` to see what changed. Then \`git diff\` (or \`git diff <base>...HEAD\`) for the actual hunks.
+- Read the touched files (\`read_file\`) when the diff alone doesn't carry enough context \u2014 function signatures, surrounding invariants, callers.
+- For "any callers depending on this?" questions: \`search_content\` against the symbol BEFORE asserting impact.
+- Stay read-only. Never \`run_command git commit\`, never write files, never propose SEARCH/REPLACE blocks. The parent decides whether to act on your findings.
+- Cap yourself at ~12 tool calls. If the diff is too big to review in one pass, pick the riskiest 2-3 files and say so explicitly.
+
+What to look for, in priority order:
+1. **Correctness bugs** \u2014 off-by-one, null/undefined handling, race conditions, wrong sign / wrong operator, edge cases the code doesn't handle.
+2. **Security** \u2014 injection (SQL, shell, path traversal), secrets in code, missing authz checks, unsafe deserialization.
+3. **Behavior changes the diff hides** \u2014 renames that miss callers, removed branches that were load-bearing, error-handling that now swallows what used to surface.
+4. **Tests** \u2014 does the change have tests for the new behavior? Are existing tests still meaningful, or did the change make them tautological?
+5. **Style + consistency** \u2014 only flag deviations that matter (unsafe \`any\`, missing types in TypeScript, inconsistent error shape). Don't pile on cosmetic nits if the substance is clean.
+
+Your final answer:
+- Lead with a one-sentence verdict: "ship as-is" / "minor nits, OK to ship after" / "blocking issues, do not ship".
+- Then a short bulleted list of issues, each with: file:line citation + the problem in one sentence + what to change.
+- Group by severity if you have more than 4 items: **Blocking**, **Should-fix**, **Nits**.
+- If everything looks clean, say so plainly. Don't manufacture concerns.
+
+${NEGATIVE_CLAIM_RULE}
+
+${TUI_FORMATTING_RULES}
+
+The 'task' the parent gave you describes WHAT to review (a branch, a file set, or "the pending changes"). Stay on it; don't redesign the feature.`;
 var BUILTIN_SKILLS = Object.freeze([
   Object.freeze({
     name: "explore",
@@ -3541,6 +3569,14 @@ var BUILTIN_SKILLS = Object.freeze([
     scope: "builtin",
     path: "(builtin)",
     runAs: "subagent"
+  }),
+  Object.freeze({
+    name: "review",
+    description: "Review the pending changes (current branch diff by default) in an isolated subagent \u2014 flags correctness, security, missing tests, hidden behavior changes; reports verdict + per-issue file:line. Read-only; the parent decides what to act on.",
+    body: BUILTIN_REVIEW_BODY,
+    scope: "builtin",
+    path: "(builtin)",
+    runAs: "subagent"
   })
 ]);