@nevzatcirak/review-mcp 2.0.0 → 2.1.0-rc.2

package/NOTICE

@@ -15,7 +15,9 @@ review agent, licensed under the MIT License. In particular:
 - the token budgeting approach,
 - the per-tool prompt design and structured output schemas for review,
   question-answering, pull-request description and code-suggestion tools,
-  including the self-review scoring of code suggestions.
+  including the self-review scoring of code suggestions,
+- the idea of reviewing only the files touched since the last review
+  (incremental review); only the idea follows PR-Agent, no code is copied.
 
 review-mcp is an independent reimplementation in Go. No PR-Agent source code
 is included in this repository; the logic, prompt design, and schemas were

package/README.md

@@ -187,7 +187,7 @@ except `job_result`).
 | `pr_info` | Which branch a pull request merges into and who has reviewed or approved it: human reviewers with their states, approval counts, required approvals and merge status where the provider exposes them. review-mcp's own reviews and comments are reported separately and never count as approvals. Also reports the CI results of the head commit (`ci`: state, counts and the failing checks), read from the provider; nothing is built or run. Read-only, no LLM call; see [Pull request status](docs/pr-info.md). |
 | `pr_comment_reply` | Replies to a pull request comment (inside the thread on Bitbucket Server and GitLab, and on GitHub for an inline comment; as a quoting PR-level comment on Gitea, and on GitHub for a general comment). |
 | `pr_comment_create` | Posts a new comment on a pull request, PR-level or on a changed line (`file` and `line`). A line outside the diff is refused, never posted at PR level instead. |
-| `pr_review` | Reviews a pull request with your LLM. The title, description, existing comments and diff are sent to your LLM endpoint. Optionally publishes the review: one overview comment, edited in place on later runs, and inline comments on the changed lines. The model is also given the head commit's CI results (failing and pending checks, and a CI line in the overview), the project's guidelines file (`.review-mcp/guidelines.md`, else `CONTRIBUTING.md`) and a listing of the directories the change touches, both read at the target branch so a pull request cannot rewrite its own rules. `focus` (`security`, `architecture`, `performance`, `ux`, `tests` or free text) reviews one area and never publishes; the findings of several focused reviews are merged by the client and published once with `findings` and `publish=true`, without another model call (the `multi_perspective_review` prompt describes the steps). See [Reviewing pull requests](docs/review.md). |
+| `pr_review` | Reviews a pull request with your LLM. The title, description, existing comments and diff are sent to your LLM endpoint. Optionally publishes the review: one overview comment, edited in place on later runs, and inline comments on the changed lines. The model is also given the head commit's CI results (failing and pending checks, and a CI line in the overview), the project's guidelines file (`.review-mcp/guidelines.md`, else `CONTRIBUTING.md`) and a listing of the directories the change touches, both read at the target branch so a pull request cannot rewrite its own rules. `focus` (`security`, `architecture`, `performance`, `ux`, `tests` or free text) reviews one area and never publishes; the findings of several focused reviews are merged by the client and published once with `findings` and `publish=true`, without another model call (the `multi_perspective_review` prompt describes the steps). With `incremental=true` (or `review.incremental`) it reviews only the files whose content changed since the last review it published, and lists the earlier findings the overview held without an inline comment on files that did not change; nothing changed means no model call and nothing posted. See [Reviewing pull requests](docs/review.md#incremental-review). |
 | `pr_ask` | Answers a free-text question about a pull request, grounded in its title, description and diff. Optionally publishes the question and answer as a PR comment. |
 | `pr_describe` | Describes a pull request with your LLM: a title, the change types, a short summary and a walkthrough of the changed files. The title, description, branch names, commit messages and diff are sent to your LLM endpoint. By default it only reads; `publish=true` writes to the pull request, either one comment that later runs edit in place or a marked region at the end of the description (the author's text is never changed), and `update_title=true` also replaces the title. Files the model did not describe are listed, never padded in. See [Describing pull requests](docs/describe.md). |
 | `pr_improve` | Suggests code changes for a pull request with your LLM: for each suggestion the existing and the improved code, a label and a score from 0 to 10 given by a second, self-review model call; suggestions below `improve.min_score` are dropped and counted, never silently lost. Each suggestion is checked against the head version of the file before it is called anchored; ones that cannot be are marked, not hidden. The title, description, branch names, existing comments and diff are sent to your LLM endpoint, with the project's guidelines file and the listing of the touched directories read at the target branch, as for `pr_review`. By default it only reads; `publish=true` writes to the pull request: one overview comment that later runs edit in place, and an inline comment on each verified suggestion that is on changed lines of one hunk (not repeated on later runs), with the change as a native suggestion block on GitHub and GitLab and as a diff block on Gitea and Bitbucket Server. See [Suggesting code changes](docs/improve.md). |
@@ -197,7 +197,7 @@ except `job_result`).
 
 - [Setup guide](docs/setup.md): install, token checklist, LLM endpoint, client configuration, first run.
 - [Serve mode](docs/serve.md): one shared HTTP server for a team, the header contract, TLS, the container.
-- [Reviewing pull requests](docs/review.md): what `pr_review` sends to the LLM, choosing `llm.context_window`, reading coverage and notes, large pull requests reviewed in parts, `publish` (the overview and inline comments), discussion awareness, CI results, project guidelines and the file tree, focused reviews and the merged publish (the `multi_perspective_review` prompt), slow endpoints and `job_result`, `diag review --dry-run`.
+- [Reviewing pull requests](docs/review.md): what `pr_review` sends to the LLM, choosing `llm.context_window`, reading coverage and notes, large pull requests reviewed in parts, `publish` (the overview and inline comments), discussion awareness, CI results, project guidelines and the file tree, focused reviews and the merged publish (the `multi_perspective_review` prompt), incremental review, slow endpoints and `job_result`, `diag review --dry-run`.
 - [Asking questions about a pull request](docs/ask.md): what `pr_ask` sends to the LLM, files the question names, grounding and honesty, coverage, `publish` and the slash sanitization, `diag ask --dry-run`.
 - [Describing pull requests](docs/describe.md): what `pr_describe` sends to the LLM, the result, large pull requests described in parts with a summary call, files that were not described, `publish` as a comment or as a marked region of the description (how to remove it, `update_title`, concurrent edits, Bitbucket Server reviewers), permissions, `diag describe --dry-run`.
 - [Suggesting code changes](docs/improve.md): what `pr_improve` sends to the LLM (and what the self-review does not get), parts, the self-review score and `improve.min_score`, ranking and the cap, verification against the head file, `publish` (the overview edited in place, inline comments with a diff block, no repeated suggestions), permissions, `improve.*` settings, `diag improve --dry-run`.
@@ -217,7 +217,9 @@ parts of the review and answer output presentation are adapted from PR-Agent; [N
 lists every adapted file and carries PR-Agent's license. See it for details on
 what was derived and
 `docs/research/pr-agent-porting-map.md` for the pinned upstream revision
-studied during the porting research.
+studied during the porting research. The idea of reviewing only the files
+touched since the last review follows PR-Agent's incremental review (MIT); no
+code is copied.
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nevzatcirak/review-mcp",
-  "version": "2.0.0",
+  "version": "2.1.0-rc.2",
   "description": "MCP server for AI-assisted pull-request review on Gitea and Bitbucket Server.",
   "keywords": [
     "mcp",
@@ -23,12 +23,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@nevzatcirak/review-mcp-linux-x64": "2.0.0",
-    "@nevzatcirak/review-mcp-linux-arm64": "2.0.0",
-    "@nevzatcirak/review-mcp-darwin-x64": "2.0.0",
-    "@nevzatcirak/review-mcp-darwin-arm64": "2.0.0",
-    "@nevzatcirak/review-mcp-win32-x64": "2.0.0",
-    "@nevzatcirak/review-mcp-win32-arm64": "2.0.0"
+    "@nevzatcirak/review-mcp-linux-x64": "2.1.0-rc.2",
+    "@nevzatcirak/review-mcp-linux-arm64": "2.1.0-rc.2",
+    "@nevzatcirak/review-mcp-darwin-x64": "2.1.0-rc.2",
+    "@nevzatcirak/review-mcp-darwin-arm64": "2.1.0-rc.2",
+    "@nevzatcirak/review-mcp-win32-x64": "2.1.0-rc.2",
+    "@nevzatcirak/review-mcp-win32-arm64": "2.1.0-rc.2"
   },
   "files": [
     "bin/review-mcp.js",