prr-kit 1.2.2 → 1.2.3

package/README.md

@@ -34,6 +34,8 @@ Then open your IDE in the installed project and use one of these commands to sta
 - `/prr-quick` — one command, full pipeline (select PR → review → report)
 - `/prr-master` — full menu with all options
 
+> **Note:** The exact command depends on your IDE. See [IDE Support](https://prrkit.sitenow.cloud/docs/ide-support) for the command specific to your IDE.
+
 ## How It Works
 
 <p align="center">
@@ -100,9 +102,9 @@ Only pauses once to ask which PR/branch to review.
 | `SP` | Select PR | Fetch latest → list open PRs (via `gh`) or branches → select head + base → load diff |
 | `DP` | Describe PR | Classify PR type, generate summary, file-by-file walkthrough |
 | `GR` | General Review | Logic, naming, readability, DRY, best practices |
-| `SR` | Security Review | OWASP Top 10, secrets, auth, rate limits, injection |
-| `PR` | Performance Review | N+1 queries, memory leaks, async patterns, caching |
-| `AR` | Architecture Review | SOLID, layers, coupling, consistency with codebase |
+| `SR` | Security Review | OWASP Top 10, secrets, auth, rate limits, injection, etc. — adapted to your project |
+| `PR` | Performance Review | N+1 queries, memory leaks, async patterns, caching, etc. — adapted to your stack |
+| `AR` | Architecture Review | SOLID, layers, coupling, consistency with codebase, etc. — adapted to your architecture |
 | `BR` | Business Review | User impact, business risk, feature completeness, data safety, observability |
 | `IC` | Improve Code | Concrete BEFORE/AFTER code suggestions |
 | `AK` | Ask Code | Q&A about specific changes in this PR |
@@ -146,11 +148,13 @@ Specialist reviewer agents are orchestrated internally by the master agent and p
 | Reviewer | Focus | Key questions |
 |---|---|---|
 | 👁️ General (GR) | Code quality | Is the logic correct? Naming clear? DRY? Tests present? |
-| 🔒 Security (SR) | OWASP Top 10 | XSS? Injection? Secrets exposed? Auth correct? |
-| ⚡ Performance (PR) | Efficiency | N+1 queries? Memory leaks? Missing await? |
-| 🏗️ Architecture (AR) | Structure | Layer violations? Coupling? Consistent with codebase? |
+| 🔒 Security (SR) | OWASP Top 10 + stack threats | XSS? Injection? Secrets exposed? Auth correct? *(adapted to your stack)* |
+| ⚡ Performance (PR) | Efficiency + stack patterns | N+1 queries? Memory leaks? Missing await? *(adapted to your stack)* |
+| 🏗️ Architecture (AR) | Structure + conventions | Layer violations? Coupling? Consistent with codebase? *(adapted to your architecture)* |
 | 💼 Business (BR) | Real-world impact | User impact? Business risk? Feature completeness? Data safe? Observability? |
 
+> Checks are adaptive — each reviewer skips categories not relevant to your project and generates additional checks based on detected stacks, project guidelines, and inline annotations.
+
 **Business Review (BR)** runs last and translates technical findings into business language — user impact, GDPR risk, migration safety, deployment recommendations, and post-ship monitoring checklist.
 
 ## Severity Levels
@@ -160,7 +164,7 @@ All findings use a standard format:
 - 🔴 **[BLOCKER]** — Must fix before merge
 - 🟡 **[WARNING]** — Should fix (with explanation)
 - 🟢 **[SUGGESTION]** — Nice-to-have improvement
-- 📌 **[QUESTION]** — Needs clarification from author
+- ❓ **[QUESTION]** — Needs clarification from author
 
 ## Context Collection
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prr-kit",
-  "version": "1.2.2",
+  "version": "1.2.3",
   "description": "AI-driven Pull Request Review Kit — structured agent workflows for thorough, consistent code review",
   "main": "tools/cli/prr-cli.js",
   "bin": {

package/src/prr/workflows/3-review/architecture-review/instructions.xml

@@ -14,15 +14,18 @@
     <action>Load PR-specific knowledge base from {pr_knowledge_base}</action>
     <action>Extract architectural patterns from knowledge_base.relevant_guidelines (ARCHITECTURE.md sections, ADRs)</action>
     <action>Check pattern annotations from knowledge_base.inline_context (@pattern:)</action>
+    <action>Adapt review scope: use knowledge_base.stack_context, knowledge_base.files_analysis, and knowledge_base.reviewer_guidance.architecture_review to evaluate which of the default check categories below are relevant to this project and this PR. Categories that have no applicability to the project's architectural style should be skipped or reduced.</action>
+    <action>Identify stack-specific architecture rules from knowledge_base.stack_context.rules — these will be applied as additional checks in the dedicated step below.</action>
     <action>Also examine surrounding non-changed files to understand existing patterns</action>
     <output>🏗️ Starting Architecture Review
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Focus: Layer violations | Coupling | SOLID | Codebase consistency
-Context: Loaded architectural patterns & ADRs from ARCHITECTURE.md
+Scope: Adapted to project architecture and detected stack
+Context: Loaded architectural patterns & ADRs from project docs
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</output>
   </step>
 
   <step n="2" goal="Check layer/separation of concerns violations">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="layers">
       <item>Business logic in controllers/routes (should be in services)</item>
       <item>Database queries in wrong layer (direct DB access from controller bypassing service)</item>
@@ -33,6 +36,7 @@ Context: Loaded architectural patterns & ADRs from ARCHITECTURE.md
   </step>
 
   <step n="3" goal="Check coupling and cohesion">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="coupling">
       <item>Tight coupling: does this change force changes in many unrelated files?</item>
       <item>New module dependencies: are new imports appropriate? circular dependencies introduced?</item>
@@ -42,6 +46,7 @@ Context: Loaded architectural patterns & ADRs from ARCHITECTURE.md
   </step>
 
   <step n="4" goal="Check consistency with existing codebase patterns">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="consistency">
       <item>Naming conventions: matches existing naming style (camelCase vs snake_case, etc.)?</item>
       <item>File/folder structure: new files placed where convention dictates?</item>
@@ -52,7 +57,7 @@ Context: Loaded architectural patterns & ADRs from ARCHITECTURE.md
   </step>
 
   <step n="5" goal="Shared module blast radius and backward compatibility">
-    <note>A change to any shared/common/generic module is high-risk because it affects all consumers — not just the code in this PR. This step must always run when any such file is changed.</note>
+    <note>Skip if no shared/common/generic modules are changed in this PR. When shared modules ARE changed, always run this step — it is high-risk because it affects all consumers, not just the code in this PR.</note>
     <check-list id="blast-radius">
       <item>Identify: is the changed file a shared/common/generic resource? (utility modules, shared libraries, base classes, common interfaces/headers, core services, shared data models, global state)</item>
       <item>Consumer count: search for all files importing or using this module and list them. Any breaking change is a 🔴 BLOCKER regardless of consumer count — high consumer count amplifies urgency but is not the deciding factor.</item>
@@ -74,6 +79,7 @@ Context: Loaded architectural patterns & ADRs from ARCHITECTURE.md
   </step>
 
   <step n="6" goal="SOLID principles (only flag real violations, not theoretical ones)">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="solid">
       <item>SRP: class/module doing more than one thing AND causing maintenance problems?</item>
       <item>OCP: existing code modified instead of extended (when extension was clearly better)?</item>
@@ -84,6 +90,13 @@ Context: Loaded architectural patterns & ADRs from ARCHITECTURE.md
     <note>Only flag SOLID violations when they cause REAL maintainability or extensibility problems — not theoretical purity</note>
   </step>
 
+  <step n="6b" goal="Stack-specific and project-specific architecture checks">
+    <action>Apply all architecture rules from knowledge_base.stack_context.rules for each detected stack</action>
+    <action>Apply architecture-related guidelines from knowledge_base.relevant_guidelines and any ADRs found</action>
+    <action>Apply guidance from knowledge_base.reviewer_guidance.architecture_review</action>
+    <note>Generate additional checks specific to this project's architectural patterns and domain that go beyond the default categories above. If knowledge_base contains no stack-specific architecture rules, skip this step silently.</note>
+  </step>
+
   <step n="7" goal="Compile and write findings">
     <action>Group findings: Layer Violations | Coupling Issues | Consistency Problems | SOLID Violations | ❓ Questions for Author</action>
     <action>For each finding: reference the EXISTING pattern that should be followed instead</action>

package/src/prr/workflows/3-review/business-review/instructions.xml

@@ -14,6 +14,7 @@
 
     <action>Read {pr_context} to get: target_branch, base_branch, pr_type, pr_knowledge_base, completed_reviews</action>
     <action>Load PR-specific knowledge base from {pr_knowledge_base} — extract issue_context (acceptance criteria) if available from MCP tools</action>
+    <action>Adapt review scope: use knowledge_base.stack_context, knowledge_base.files_analysis, and knowledge_base.reviewer_guidance.business_review to adjust business focus based on detected project type and domain.</action>
     <action>Load findings already collected from completed reviews (GR, SR, PR, AR) to translate them into business impact</action>
     <action>Run: git diff {base_branch}...{target_branch} --stat in {target_repo} for file scope</action>
 

package/src/prr/workflows/3-review/general-review/instructions.xml

@@ -14,6 +14,7 @@
     <action>Read {pr_context} to get: target_branch, base_branch, diff_strategy, files_changed, pr_knowledge_base</action>
     <action>Load PR-specific knowledge base from {pr_knowledge_base} (e.g., pr-123-context.yaml)</action>
     <note>Knowledge base contains: relevant ESLint rules, guidelines from CLAUDE.md/CONTRIBUTING.md/ARCHITECTURE.md, inline annotations, external rules</note>
+    <action>Adapt review scope: use knowledge_base.stack_context, knowledge_base.files_analysis, and knowledge_base.reviewer_guidance.general_review to adjust focus based on detected technology and project patterns.</action>
     <action>Run: git diff {base_branch}...{target_branch} in {target_repo}</action>
     <action>Note diff_strategy: if 'chunked', process file by file</action>
 

package/src/prr/workflows/3-review/performance-review/instructions.xml

@@ -13,14 +13,17 @@
     <action>Read {pr_context} and load git diff</action>
     <action>Load PR-specific knowledge base from {pr_knowledge_base}</action>
     <action>Extract performance guidelines from knowledge_base.relevant_guidelines</action>
+    <action>Adapt review scope: use knowledge_base.stack_context, knowledge_base.files_analysis, and knowledge_base.reviewer_guidance.performance_review to evaluate which of the default check categories below are relevant to this project and this PR. Categories that have no applicability to the detected project type should be skipped entirely.</action>
+    <action>Identify stack-specific performance rules from knowledge_base.stack_context.rules — these will be applied as additional checks in the dedicated step below.</action>
     <output>⚡ Starting Performance Review
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Focus: N+1 queries | Memory | Async | Bundle size | Caching
+Scope: Adapted to detected stack and project context
 Context: Loaded performance best practices from docs
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</output>
   </step>
 
   <step n="2" goal="Database and query performance">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="database">
       <item>N+1 queries: DB call inside a loop? Should use batch/join instead</item>
       <item>Missing pagination: queries that could return unbounded result sets</item>
@@ -32,6 +35,7 @@ Context: Loaded performance best practices from docs
   </step>
 
   <step n="3" goal="Async and concurrency patterns">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="async">
       <item>Sequential awaits in loop: `for (x of arr) { await fn(x) }` should be Promise.all</item>
       <item>Unnecessary await: async function that doesn't need to be async</item>
@@ -42,6 +46,7 @@ Context: Loaded performance best practices from docs
   </step>
 
   <step n="4" goal="Memory management">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="memory">
       <item>Event listener cleanup: listeners added but not removed (memory leak pattern)</item>
       <item>Large objects held in closure/module scope unnecessarily</item>
@@ -52,6 +57,7 @@ Context: Loaded performance best practices from docs
   </step>
 
   <step n="5" goal="Frontend performance (if applicable)">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="frontend">
       <item>Bundle size: large new dependencies imported? Is tree-shaking possible?</item>
       <item>Unnecessary re-renders: state changes causing full component re-renders</item>
@@ -61,6 +67,13 @@ Context: Loaded performance best practices from docs
     </check-list>
   </step>
 
+  <step n="5b" goal="Stack-specific and project-specific performance checks">
+    <action>Apply all performance rules from knowledge_base.stack_context.rules for each detected stack</action>
+    <action>Apply performance-related guidelines from knowledge_base.relevant_guidelines</action>
+    <action>Apply guidance from knowledge_base.reviewer_guidance.performance_review</action>
+    <note>Generate additional checks specific to this project's technology and domain that go beyond the default categories above. If knowledge_base contains no stack-specific performance rules, skip this step silently.</note>
+  </step>
+
   <step n="6" goal="Compile and write findings">
     <action>Distinguish: impactful issues vs micro-optimizations — only include impactful ones</action>
     <action>For each finding: assign severity based on impact scope — 🔴 if causes measurable regression or data integrity risk, 🟡 if significant but not blocking, 🟢 if low-impact optimization, ❓ if impact cannot be determined without author context</action>

package/src/prr/workflows/3-review/security-review/instructions.xml

@@ -14,11 +14,13 @@
     <action>Load PR-specific knowledge base from {pr_knowledge_base}</action>
     <action>Extract security guidelines from knowledge_base.relevant_guidelines</action>
     <action>Check for security annotations from knowledge_base.inline_context (@security:)</action>
+    <action>Adapt review scope: use knowledge_base.stack_context, knowledge_base.files_analysis, and knowledge_base.reviewer_guidance.security_review to evaluate which of the default check categories below are relevant to this project and this PR. Step 2 (hardcoded secrets) always runs. Other categories should be evaluated for relevance before running.</action>
+    <action>Identify stack-specific security rules from knowledge_base.stack_context.rules — these will be applied as additional checks in the dedicated step below.</action>
     <action>Run: git diff {base_branch}...{target_branch} in {target_repo}</action>
     <output>🔒 Starting Security Review — Thinking like an attacker
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-OWASP Top 10 scan + secrets detection + auth review
-Context: Loaded security guidelines from CLAUDE.md/CONTRIBUTING.md
+Scope: Secrets scan (always) + adapted checks for detected stack
+Context: Loaded security guidelines from project docs
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</output>
   </step>
 
@@ -35,6 +37,7 @@ Context: Loaded security guidelines from CLAUDE.md/CONTRIBUTING.md
   </step>
 
   <step n="3" goal="OWASP A01-A05: Broken Access Control, Crypto, Injection, Insecure Design, Misconfiguration">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="owasp-1-5">
       <item>A01 Broken Access Control: authorization checks present? role-based? privilege escalation possible?</item>
       <item>A02 Cryptographic Failures: weak hashing (MD5/SHA1)? HTTP instead of HTTPS? key management?</item>
@@ -45,6 +48,7 @@ Context: Loaded security guidelines from CLAUDE.md/CONTRIBUTING.md
   </step>
 
   <step n="4" goal="OWASP A06-A10: Vulnerable Components, Auth, Integrity, Logging, SSRF">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="owasp-6-10">
       <item>A06 Vulnerable Components: new dependencies added? check for known CVEs</item>
       <item>A07 Auth Failures: session management? password policies? brute force protection? JWT validation?</item>
@@ -55,6 +59,7 @@ Context: Loaded security guidelines from CLAUDE.md/CONTRIBUTING.md
   </step>
 
   <step n="5" goal="Rate limiting and input validation">
+    <note>Run only if relevant to the project type and the changes in this PR. Skip entirely if this category has no applicability.</note>
     <check-list id="input-rate">
       <item>Rate limiting on auth endpoints (login, register, password reset)</item>
       <item>Input length limits enforced server-side</item>
@@ -63,6 +68,13 @@ Context: Loaded security guidelines from CLAUDE.md/CONTRIBUTING.md
     </check-list>
   </step>
 
+  <step n="5b" goal="Stack-specific and project-specific security checks">
+    <action>Apply all security rules from knowledge_base.stack_context.rules for each detected stack</action>
+    <action>Apply security-related guidelines from knowledge_base.relevant_guidelines</action>
+    <action>Apply guidance from knowledge_base.reviewer_guidance.security_review</action>
+    <note>Generate additional checks specific to this project's technology and domain that go beyond the default categories above. If knowledge_base contains no stack-specific security rules, skip this step silently.</note>
+  </step>
+
   <step n="6" goal="Compile and write security findings">
     <action>Group findings by severity: 🔴 Critical/High → 🟡 Medium → 🟢 Low/Info → ❓ Questions for Author</action>
     <action>For each finding include: WHAT, WHERE (file+line), IMPACT (how exploitable), HOW TO FIX</action>