prr-kit 1.2.2 → 1.3.0

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">
@@ -46,25 +48,75 @@ The framework installs into your project as a `_prr/` folder. Agents and workflo
 
 The installer handles configuration interactively — no manual file editing required. During `npx prr-kit install`, you'll be prompted for your name, language, output folder, target repo, and platform.
 
-All values are written automatically to `_prr/prr/config.yaml`:
+All values are written to `_prr/prr/config.yaml`. Full schema overview:
 
 ```yaml
-user_name: YourName
-communication_language: English
-target_repo: .
-platform: auto                        # auto-detect from git remote
-platform_repo: "owner/repo"           # optional — needed for PR listing and inline comments
-review_output: /abs/path/_prr-output/reviews
+# ─── Identity ──────────────────────────────────────────────────────────────
+user_name: YourName                    # Your name — used in review reports
+communication_language: English        # Any language: English | Vietnamese | Japanese | French | …
 
-context_collection:
-  enabled: true
-  mode: pr-specific                   # always fresh, never cached
+# ─── Project ───────────────────────────────────────────────────────────────
+project_name: my-project               # Display name in reports (cosmetic only)
+target_repo: .                         # Path to git repo (. = current dir, or ../other-repo)
+
+# ─── Platform ──────────────────────────────────────────────────────────────
+platform: auto                         # auto | github | gitlab | azure | bitbucket | none
+platform_repo: "owner/repo"           # owner/repo slug — required for PR listing + inline comments
+                                       # leave blank for local-only mode (git diff only)
 
+# ─── Output ────────────────────────────────────────────────────────────────
+review_output: ./_prr-output/reviews   # Where review reports + context files are written
+auto_post_comment: false               # true → auto-post findings after every review (skips PC prompt)
+
+# ─── Context Collection ────────────────────────────────────────────────────
+context_collection:
+  enabled: true                        # false → disable context collection entirely
+  skip_manual_input_context: false     # true → skip the manual context input prompt
+                                       # false (default) → agent asks user for additional context
+                                       # before building the knowledge base; input is marked ⚠️ IMPORTANT
+  mode: pr-specific                    # only value: pr-specific (always fresh, never cached)
+
+  # Sources below are auto-detected — override only if needed:
+  # primary_sources:  [CLAUDE.md, AGENTS.md, .github/CLAUDE_CODE_RULES.md, .clauderules]
+  # config_files:     [.eslintrc*, .prettierrc*, tsconfig.json, vite.config.*, webpack.config.*, …]
+  # standards_docs:   [CONTRIBUTING.md, ARCHITECTURE.md, docs/**/*.md]
+  # inline_annotations: { enabled: true, patterns: [@context:, @security:, @pattern:, @rule:] }
+
+# ─── External Sources ──────────────────────────────────────────────────────
+# MCP tools + RAG systems available in your AI IDE session.
+# Agent auto-discovers tools and maps them to declared intents.
 external_sources:
-  enabled: false                      # set true to activate MCP + RAG enrichment
+  enabled: false                       # true → activate MCP + RAG enrichment
+
+  mcp:
+    enabled: true                      # toggle MCP independently of master switch
+    intents:                           # what kinds of context to fetch via MCP tools
+      - knowledge_base                 # Confluence, Notion → team standards, ADRs
+      - project_management             # Jira, Linear → linked issue + acceptance criteria
+      - design                         # Figma, Zeplin → design specs (UI PRs only)
+      # - code_intelligence            # Sourcegraph → similar patterns
+    hints:
+      branch_issue_pattern: "([A-Z]+-\\d+)"  # regex to extract issue key from branch name
+                                              # e.g. feature/ENG-123-auth → ENG-123
+
+  rag:
+    enabled: false                     # true → query RAG systems (vector DB, embeddings)
+    intents:
+      - similar_patterns               # find similar code in the codebase
+      - past_decisions                 # previous review decisions for similar code
+      # - architecture_examples        # embedded architecture docs
+
+  sources: []                          # plain URL sources — always fetched via WebFetch
+  # sources:
+  #   - type: url
+  #     name: Shared ESLint config
+  #     url: https://raw.githubusercontent.com/org/standards/main/eslint.md
+  #   - type: url
+  #     name: Security guidelines
+  #     url: https://wiki.company.com/public/security-standards
 ```
 
-> See **[CONFIGURATION.md](CONFIGURATION.md)** for the full schema reference — including MCP tool intents, RAG systems, inline annotations, and URL sources.
+> See **[CONFIGURATION.md](CONFIGURATION.md)** for detailed explanations, examples, and FAQs.
 
 ## Platform Support
 
@@ -99,11 +151,11 @@ 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 |
-| `BR` | Business Review | User impact, business risk, feature completeness, data safety, observability |
+| `GR` | General Review | Logic, naming, readability, DRY, best practices, etc. — adapted to your stack |
+| `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 — adapted to your project |
 | `IC` | Improve Code | Concrete BEFORE/AFTER code suggestions |
 | `AK` | Ask Code | Q&A about specific changes in this PR |
 | `RR` | Generate Report | Compile all findings → Markdown report in `_prr-output/reviews/` |
@@ -145,11 +197,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? |
-| 💼 Business (BR) | Real-world impact | User impact? Business risk? Feature completeness? Data safe? Observability? |
+| 👁️ General (GR) | Code quality + stack practices | Is the logic correct? Naming clear? DRY? Tests present? *(adapted to your stack)* |
+| 🔒 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? *(adapted to your project)* |
+
+> 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.
 
@@ -160,7 +214,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.3.0",
   "description": "AI-driven Pull Request Review Kit — structured agent workflows for thorough, consistent code review",
   "main": "tools/cli/prr-cli.js",
   "bin": {

package/src/core/agents/prr-master.agent.yaml

@@ -48,23 +48,23 @@ agent:
 
     - trigger: "GR or fuzzy match on general-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/general-review/workflow.yaml"
-      description: "[GR] General Review: Logic, naming, readability, best practices"
+      description: "[GR] General Review: Code quality analysis — adapted to your stack"
 
     - trigger: "SR or fuzzy match on security-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/security-review/workflow.yaml"
-      description: "[SR] Security Review: OWASP top 10, injection, auth, API key exposure"
+      description: "[SR] Security Review: Security analysis — adapted to your project"
 
     - trigger: "PR or fuzzy match on performance-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/performance-review/workflow.yaml"
-      description: "[PR] Performance Review: N+1 queries, memory leaks, async patterns, bundle size"
+      description: "[PR] Performance Review: Performance analysis — adapted to your stack"
 
     - trigger: "AR or fuzzy match on architecture-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/architecture-review/workflow.yaml"
-      description: "[AR] Architecture Review: SOLID, layering, coupling, consistency with codebase"
+      description: "[AR] Architecture Review: Architecture analysis — adapted to your codebase"
 
     - trigger: "BR or fuzzy match on business-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/business-review/workflow.yaml"
-      description: "[BR] Business Review: User impact, business risk, feature completeness, data safety, observability"
+      description: "[BR] Business Review: Business impact analysis — adapted to your project"
 
     - trigger: "IC or fuzzy match on improve-code"
       workflow: "{project-root}/_prr/prr/workflows/4-improve/improve-code/workflow.yaml"

package/src/core/tasks/help.md

@@ -21,11 +21,11 @@ Use `/prr-help` anytime for guidance on what to do.
 
 ### Available Reviews
 
-- **[GR] General Reviewer** 👁️ — Logic, naming, readability, DRY, best practices
-- **[SR] Security Reviewer** 🔒 — OWASP Top 10, injection, auth, secrets, API key exposure
-- **[PR] Performance Reviewer** ⚡ — N+1 queries, memory leaks, async patterns, bundle size
-- **[AR] Architecture Reviewer** 🏗️ — SOLID, layering, coupling, consistency, blast radius
-- **[BR] Business Reviewer** 💼 — User impact, business risk, feature completeness, data safety, observability
+- **[GR] General Reviewer** 👁️ — Logic, naming, readability, DRY, best practices, etc. — adapted to your stack
+- **[SR] Security Reviewer** 🔒 — OWASP Top 10, injection, auth, secrets, etc. — adapted to your project
+- **[PR] Performance Reviewer** ⚡ — N+1 queries, memory leaks, async patterns, etc. — adapted to your stack
+- **[AR] Architecture Reviewer** 🏗️ — SOLID, layering, coupling, consistency, etc. — adapted to your architecture
+- **[BR] Business Reviewer** 💼 — User impact, business risk, feature completeness, data safety, etc. — adapted to your project
 
 ### Finding Severity Levels
 

package/src/core/workflows/party-mode/steps/step-01-load-reviewers.md

@@ -39,27 +39,27 @@ If no knowledge base exists (DP was not run), proceed with local context only
 Internally adopt all reviewer personas simultaneously. All reviewers apply rules from the PR knowledge base in their respective areas.
 
 **👁️ Alex (General Reviewer)**
-- Focus: code logic, naming, readability, DRY, best practices, test coverage, side effects
+- Focus: code logic, naming, readability, DRY, best practices, test coverage, side effects, and stack-specific best practices from knowledge base
 - Style: pragmatic, balances perfection with practicality
 - Output format: 🔴/🟡/🟢/❓ with file:line references + suggested fix
 
 **🔒 Sam (Security Reviewer)**
-- Focus: OWASP Top 10, secrets, auth, injection, rate limiting, input validation
+- Focus: OWASP Top 10, secrets, auth, injection, rate limiting, input validation, and stack-specific security threats from knowledge base
 - Style: paranoid-but-practical, every finding is a risk statement
 - Output format: WHAT / WHERE (file:line) / HOW exploitable / HOW TO FIX
 
 **⚡ Petra (Performance Reviewer)**
-- Focus: N+1 queries, async patterns, memory leaks, caching, payload size, bundle bloat
+- Focus: N+1 queries, async patterns, memory leaks, caching, payload size, bundle bloat, and stack-specific performance patterns from knowledge base
 - Style: data-driven, quantifies impact when possible ("adds ~Xms per request")
 - Output format: impact estimate + root cause + fix
 
 **🏗️ Arch (Architecture Reviewer)**
-- Focus: SOLID, layering, coupling, consistency with codebase, shared module blast radius
+- Focus: SOLID, layering, coupling, consistency with codebase, shared module blast radius, and stack-specific architectural patterns from knowledge base
 - Style: big-picture thinker, values consistency over theoretical purity
 - Output format: pattern analysis + reference to existing pattern + recommendation
 
 **💼 Biz (Business Reviewer)**
-- Focus: user impact, feature completeness vs acceptance criteria, business risk, data safety, observability
+- Focus: user impact, feature completeness vs acceptance criteria, business risk, data safety, observability, and project-specific business concerns from knowledge base
 - Style: speaks in business terms — revenue impact, user churn, compliance risk
 - Runs last, references findings from Alex/Sam/Petra/Arch and translates them to business consequences
 - Output format: risk level (CRITICAL/HIGH/MEDIUM/LOW) + user impact + deployment recommendation

package/src/core/workflows/party-mode/steps/step-02-discussion.md

@@ -15,7 +15,7 @@ Go through the diff once per reviewer. Each reviewer applies rules from the PR k
 
 **👁️ Alex says:**
 
-[Alex reviews for: logic correctness, naming, readability, DRY violations, missing error handling, test coverage, side effects, resource cleanup]
+[Alex reviews for: logic correctness, naming, readability, DRY violations, missing error handling, test coverage, side effects, resource cleanup, and stack-specific code quality issues from knowledge base]
 
 Format each finding as:
 ```
@@ -27,7 +27,7 @@ Format each finding as:
 
 **🔒 Sam says:**
 
-[Sam reviews for: secrets/credentials, SQL injection, XSS, authentication checks, authorization, rate limiting, error message exposure, OWASP Top 10]
+[Sam reviews for: secrets/credentials, SQL injection, XSS, authentication checks, authorization, rate limiting, error message exposure, OWASP Top 10, and stack-specific security threats from knowledge base]
 
 Format each finding as:
 ```
@@ -40,7 +40,7 @@ Format each finding as:
 
 **⚡ Petra says:**
 
-[Petra reviews for: N+1 queries, missing indexes, sync I/O on hot paths, unbound queries, missing caching, large payloads, memory leaks, inefficient loops]
+[Petra reviews for: N+1 queries, missing indexes, sync I/O on hot paths, unbound queries, missing caching, large payloads, memory leaks, inefficient loops, and stack-specific performance issues from knowledge base]
 
 Format each finding as:
 ```
@@ -53,7 +53,7 @@ Format each finding as:
 
 **🏗️ Arch says:**
 
-[Arch reviews for: layer violations, circular dependencies, tight coupling, inconsistent patterns, shared module blast radius, backward compatibility breaks]
+[Arch reviews for: layer violations, circular dependencies, tight coupling, inconsistent patterns, shared module blast radius, backward compatibility breaks, and stack-specific architecture concerns from knowledge base]
 
 Format each finding as:
 ```
@@ -68,7 +68,7 @@ Format each finding as:
 
 **💼 Biz speaks last** — synthesizes findings from Alex/Sam/Petra/Arch into business impact:
 
-[Biz reviews for: user-facing regressions, feature completeness, data safety, deployment risk, observability gaps, compliance issues]
+[Biz reviews for: user-facing regressions, feature completeness, data safety, deployment risk, observability gaps, compliance issues, and project-specific business concerns from knowledge base]
 
 For each 🔴 finding from prior reviewers, Biz adds business consequence:
 ```

package/src/prr/agents/architecture-reviewer.agent.yaml

@@ -5,7 +5,7 @@ agent:
     title: "Architecture Code Reviewer"
     icon: "🏗️"
     module: prr
-    capabilities: "SOLID principles, design patterns, layered architecture, coupling and cohesion, API design, consistency with existing codebase patterns"
+    capabilities: "SOLID principles, design patterns, layered architecture, coupling and cohesion, API design, consistency with existing codebase patterns, and stack-specific architectural patterns"
     hasSidecar: false
     no_launcher: true
 
@@ -38,7 +38,7 @@ agent:
 
     - trigger: "AR or fuzzy match on architecture-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/architecture-review/workflow.yaml"
-      description: "[AR] Architecture Review: SOLID, layering, coupling, codebase consistency"
+      description: "[AR] Architecture Review: Architecture analysis — adapted to your codebase"
 
     - trigger: "IC or fuzzy match on improve-code"
       workflow: "{project-root}/_prr/prr/workflows/4-improve/improve-code/workflow.yaml"

package/src/prr/agents/business-reviewer.agent.yaml

@@ -5,7 +5,7 @@ agent:
     title: "Business Impact Reviewer"
     icon: "💼"
     module: prr
-    capabilities: "user impact, feature completeness, business risk, data safety, observability, deployment risk, acceptance criteria validation"
+    capabilities: "user impact, feature completeness, business risk, data safety, observability, deployment risk, acceptance criteria validation, and project-specific business concerns"
     hasSidecar: false
     no_launcher: true
 
@@ -39,7 +39,7 @@ agent:
 
     - trigger: "BR or fuzzy match on business-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/business-review/workflow.yaml"
-      description: "[BR] Business Review: User impact, business risk, feature completeness, data safety"
+      description: "[BR] Business Review: Business impact analysis — adapted to your project"
 
     - trigger: "IC or fuzzy match on improve-code"
       workflow: "{project-root}/_prr/prr/workflows/4-improve/improve-code/workflow.yaml"

package/src/prr/agents/general-reviewer.agent.yaml

@@ -5,7 +5,7 @@ agent:
     title: "General Code Reviewer"
     icon: "👁️"
     module: prr
-    capabilities: "code logic, naming conventions, readability, DRY principles, error handling, test coverage, code smells"
+    capabilities: "code logic, naming conventions, readability, DRY principles, error handling, test coverage, code smells, and stack-specific best practices"
     hasSidecar: false
     no_launcher: true
 
@@ -37,7 +37,7 @@ agent:
 
     - trigger: "GR or fuzzy match on general-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/general-review/workflow.yaml"
-      description: "[GR] General Review: Comprehensive code quality analysis"
+      description: "[GR] General Review: Code quality analysis — adapted to your stack"
 
     - trigger: "IC or fuzzy match on improve-code"
       workflow: "{project-root}/_prr/prr/workflows/4-improve/improve-code/workflow.yaml"

package/src/prr/agents/performance-reviewer.agent.yaml

@@ -5,7 +5,7 @@ agent:
     title: "Performance Code Reviewer"
     icon: "⚡"
     module: prr
-    capabilities: "N+1 query detection, memory leak analysis, async/await patterns, bundle size, caching strategies, database query optimization"
+    capabilities: "N+1 query detection, memory leak analysis, async/await patterns, bundle size, caching strategies, database query optimization, and stack-specific performance patterns"
     hasSidecar: false
     no_launcher: true
 
@@ -38,7 +38,7 @@ agent:
 
     - trigger: "PR or fuzzy match on performance-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/performance-review/workflow.yaml"
-      description: "[PR] Performance Review: N+1, memory, async, bundle size analysis"
+      description: "[PR] Performance Review: Performance analysis — adapted to your stack"
 
     - trigger: "IC or fuzzy match on improve-code"
       workflow: "{project-root}/_prr/prr/workflows/4-improve/improve-code/workflow.yaml"

package/src/prr/agents/security-reviewer.agent.yaml

@@ -5,7 +5,7 @@ agent:
     title: "Security Code Reviewer"
     icon: "🔒"
     module: prr
-    capabilities: "OWASP top 10, SQL injection, XSS, auth vulnerabilities, API key exposure, dependency vulnerabilities, cryptography misuse"
+    capabilities: "OWASP top 10, SQL injection, XSS, auth vulnerabilities, API key exposure, dependency vulnerabilities, cryptography misuse, and stack-specific security threats"
     hasSidecar: false
     no_launcher: true
 
@@ -40,7 +40,7 @@ agent:
 
     - trigger: "SR or fuzzy match on security-review"
       workflow: "{project-root}/_prr/prr/workflows/3-review/security-review/workflow.yaml"
-      description: "[SR] Security Review: Full OWASP-based security analysis"
+      description: "[SR] Security Review: Security analysis — adapted to your project"
 
     - trigger: "IC or fuzzy match on improve-code"
       workflow: "{project-root}/_prr/prr/workflows/4-improve/improve-code/workflow.yaml"

package/src/prr/config-template.yaml

@@ -21,6 +21,9 @@ auto_post_comment: false             # Set to true to auto-post findings to GitH
 # ─── Context Collection ────────────────────────────────────────────────────
 context_collection:
   enabled: true
+  skip_manual_input_context: false   # Set to true to skip the manual context input prompt
+                                     # (default: false — agent will ask the user for additional context
+                                     # before building the knowledge base. User input is marked ⚠️ IMPORTANT)
   mode: pr-specific                  # Always fresh, never cached
 
   # Local primary sources (read if file exists)

package/src/prr/workflows/2-analyze/collect-pr-context/steps/step-02-collect-sources.md

@@ -1,7 +1,7 @@
 ---
 name: "step-02-collect-sources"
 description: "Collect context from all identified sources"
-nextStepFile: "./step-03-build-knowledge-base.md"
+nextStepFile: "./step-03-manual-context-input.md"
 ---
 
 # Step 2: Collect Context from Sources
@@ -449,3 +449,4 @@ collected_data:
 ### 9. Load Next Step
 
 Add `step-02-collect-sources` to `stepsCompleted`. Load: `{nextStepFile}`
+

package/src/prr/workflows/2-analyze/collect-pr-context/steps/step-03-manual-context-input.md

@@ -0,0 +1,88 @@
+---
+name: "step-03-manual-context-input"
+description: "Collect additional context manually from the user"
+nextStepFile: "./step-04-build-knowledge-base.md"
+---
+
+# Step 3: Manual Context Input
+
+## Goal
+Give the user the opportunity to provide additional context that automated collection cannot capture — such as business rationale, known trade-offs, special constraints, or specific areas to focus on.
+
+## Sequence of Instructions
+
+### 1. Check Config
+
+Read `context_collection.skip_manual_input_context` from the loaded config.
+
+If `skip_manual_input_context: true`:
+
+```
+⏭️  Manual context input skipped (skip_manual_input_context: true in config)
+```
+
+Set `manual_context: null`. Add `step-03-manual-context-input` to `stepsCompleted`. Load: `{nextStepFile}`
+
+**STOP — do not read further.**
+
+---
+
+### 2. Show Collection Summary
+
+Print a brief summary of what was automatically collected so far:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+💬 Auto-collection complete. Anything to add?
+
+📊 Collected so far:
+   🗂️  Files changed: {files_count}
+   🎯 Domains: {domains_list}
+   🧩 Stacks detected: {stacks_list or "none"}
+   📘 Primary docs: {primary_docs_found}
+   ⚙️  Config files: {config_files_found}
+   📚 Standards docs: {standards_docs_found}
+   💬 Inline annotations: {annotations_count}
+   🔌 External tools: {mcp_and_rag_summary or "none"}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### 3. Prompt User
+
+Ask the user:
+
+```
+💬 Do you have any additional context for the reviewers?
+
+You can share:
+  • Business context or requirements behind this PR
+  • Known trade-offs or constraints you accepted
+  • Specific areas you'd like reviewers to focus on
+  • Known issues or technical debt to be aware of
+  • Links to related tickets, designs, or decisions
+
+Type your notes and press Enter, or type "skip" to continue without adding context.
+```
+
+### 4. Capture Input
+
+Wait for the user's response.
+
+- If the user enters empty input, `skip`, `s`, `done`, or `no` → set `manual_context: null`, announce skip
+- Otherwise → store the full text as `manual_context`
+
+### 5. Acknowledge
+
+**If user provided context:**
+```
+✅ Context noted — reviewers will treat this as ⚠️ high-priority input.
+```
+
+**If user skipped:**
+```
+⏩ Skipped — continuing with auto-collected context only.
+```
+
+### 6. Load Next Step
+
+Add `step-03-manual-context-input` to `stepsCompleted`. Load: `{nextStepFile}`

package/src/prr/workflows/2-analyze/collect-pr-context/steps/{step-03-build-knowledge-base.md → step-04-build-knowledge-base.md}

@@ -1,9 +1,9 @@
 ---
-name: "step-03-build-knowledge-base"
+name: "step-04-build-knowledge-base"
 description: "Build structured PR-specific knowledge base for reviewers"
 ---
 
-# Step 3: Build PR-Specific Knowledge Base
+# Step 4: Build PR-Specific Knowledge Base
 
 ## Goal
 Transform collected data into structured knowledge base optimized for reviewers.
@@ -32,6 +32,16 @@ pr_metadata:
   files_changed: {n}
   collected_at: {ISO timestamp}
 
+# ⚠️  IMPORTANT — Human-provided context from the PR author.
+# All reviewers MUST read this section before starting any review.
+# Align all findings and focus areas against this input.
+manual_context:
+  # Populated only when the user provided input in step-03-manual-context-input.
+  # If provided: true — treat this content as the highest-priority context in this file.
+  provided: {true|false}
+  content: |
+    {manual_context text, or null if not provided}
+
 files_analysis:
   changed_files:
     - path: src/stores/todoStore.js
@@ -235,6 +245,7 @@ external_context:
 
 review_priorities:
   # Guide reviewers on what to focus on
+  # ⚠️  If manual_context.provided is true — reviewers MUST check findings against it first.
   critical:
     - "Verify no v-html with user input (security requirement)"
     - "Check ESLint error-level rules compliance"
@@ -250,6 +261,7 @@ review_priorities:
     - "Optional optimizations"
 
 reviewer_guidance:
+  # ⚠️  If manual_context.provided is true — read manual_context BEFORE starting any review.
   general_review:
     - "Check for ESLint rule violations (no-var, prefer-const)"
     - "Verify component naming follows standards"
@@ -275,6 +287,7 @@ context_sources:
   config_files: [.eslintrc.js, .prettierrc]
   standards_docs: [CONTRIBUTING.md, ARCHITECTURE.md]
   inline_annotations: yes
+  manual_context: {true|false}    # true if user provided input in step-03
   mcp_tools: []                   # list of MCP tools actually used
   rag_systems: []                 # list of RAG systems queried
   url_sources: []                 # list of plain URLs fetched
@@ -309,6 +322,9 @@ Example: `_prr-output/pr-123-context.yaml`
    • ESLint rules: {n}
    • Guidelines: {m}
    • Inline annotations: {k}
+   • Manual context: ⚠️ YES — reviewers will prioritize this ({char_count} chars)
+     OR
+   • Manual context: none
    • MCP tools used: {mcp_list or "none"}
    • RAG patterns: {rag_count}
    • Issue context: {issue_key or "none"}

package/src/prr/workflows/2-analyze/collect-pr-context/workflow.md

@@ -105,10 +105,11 @@ If a stack has no matching data file, skip it silently and proceed with general
 
 ## WORKFLOW ARCHITECTURE
 
-3-step process:
+4-step process:
 1. **Analyze files** changed in PR — extract metadata, domains, and **detect technology stacks**
 2. **Collect context** from all sources: primary docs, config files, standards docs, inline annotations, **stack-specific rules**, MCP tools, RAG systems
-3. **Build PR-specific knowledge base** — structured YAML with all context, stack rules, and reviewer guidance
+3. **Manual context input** — prompt the user for any additional context (business rationale, focus areas, known trade-offs). Skip automatically if `context_collection.skip_manual_input_context: true` in config. If the user provides input, it is marked **⚠️ IMPORTANT** and reviewers treat it as highest-priority context
+4. **Build PR-specific knowledge base** — structured YAML with all context, stack rules, manual context, and reviewer guidance
 
 ## INITIALIZATION
 

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/architecture-review/workflow.yaml

@@ -1,5 +1,5 @@
 name: architecture-review
-description: "Architecture-focused review: SOLID principles, layering, coupling, codebase consistency"
+description: "Architecture-focused review: SOLID principles, layering, coupling, codebase consistency, etc. — adapted to your architecture"
 author: "PR Review Kit"
 
 config_source: "{project-root}/_prr/prr/config.yaml"

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>
 
@@ -126,6 +127,8 @@ PR type: {pr_type} | Prior reviews loaded: {completed_reviews}
       MINIMAL  = additive feature, no regressions, low risk changes
     </risk-matrix>
 
+    <action>Apply any business-specific guidance from knowledge_base.reviewer_guidance.business_review and knowledge_base.relevant_guidelines to generate additional business checks beyond the default categories above. If no project-specific business guidance exists, skip silently.</action>
+
     <action>Structure the output by category, ordered by severity within each section:
       - Feature Completeness gaps (🔴 first, then 🟡, 🟢, ❓)
       - User Impact issues

package/src/prr/workflows/3-review/business-review/workflow.yaml

@@ -1,5 +1,5 @@
 name: business-review
-description: "Business impact review: user impact, business risk, feature completeness, data safety, observability"
+description: "Business impact review: user impact, business risk, feature completeness, data safety, observability — adapted to your project"
 author: "PR Review Kit"
 
 config_source: "{project-root}/_prr/prr/config.yaml"

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>
 
@@ -88,6 +89,13 @@ For side effect findings, include the AFFECTED LOCATION (the file outside the di
     </output-format>
   </step>
 
+  <step n="5b" goal="Stack-specific and project-specific code quality checks">
+    <action>Apply all code quality and common bug rules from knowledge_base.stack_context.rules for each detected stack</action>
+    <action>Apply code quality guidelines from knowledge_base.relevant_guidelines</action>
+    <action>Apply guidance from knowledge_base.reviewer_guidance.general_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 code quality rules, skip this step silently.</note>
+  </step>
+
   <step n="6" goal="Compile and write findings">
     <action>Group all findings by severity: 🔴 Blockers first, then 🟡 Warnings, then 🟢 Suggestions, then ❓ Questions</action>
     <action>Add positive observations: acknowledge good practices found</action>

package/src/prr/workflows/3-review/general-review/workflow.yaml

@@ -1,5 +1,5 @@
 name: general-review
-description: "General code quality review: logic, naming, readability, error handling, DRY, test coverage"
+description: "General code quality review: logic, naming, readability, error handling, DRY, test coverage, etc. — adapted to your stack"
 author: "PR Review Kit"
 
 config_source: "{project-root}/_prr/prr/config.yaml"

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/performance-review/workflow.yaml

@@ -1,5 +1,5 @@
 name: performance-review
-description: "Performance-focused code review: N+1 queries, memory leaks, async patterns, bundle size, caching"
+description: "Performance-focused code review: N+1 queries, memory leaks, async patterns, bundle size, caching, etc. — adapted to your stack"
 author: "PR Review Kit"
 
 config_source: "{project-root}/_prr/prr/config.yaml"

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>

package/src/prr/workflows/3-review/security-review/workflow.yaml

@@ -1,5 +1,5 @@
 name: security-review
-description: "Security-focused code review: OWASP top 10, injection, auth, secrets, dependencies"
+description: "Security-focused code review: OWASP top 10, injection, auth, secrets, dependencies, etc. — adapted to your project"
 author: "PR Review Kit"
 
 config_source: "{project-root}/_prr/prr/config.yaml"

package/src/prr/workflows/quick/workflow.md

@@ -202,12 +202,12 @@ Print to screen:
 ---
 
 ## PHASE 2.5 — COLLECT PR-SPECIFIC CONTEXT
-*Execute automatically, no user input.*
+*Execute automatically. May pause once to ask the user for additional context (unless `skip_manual_input_context: true` in config).*
 
 Execute the collect-pr-context workflow in full:
 `{project-root}/_prr/prr/workflows/2-analyze/collect-pr-context/workflow.md`
 
-This workflow analyzes changed files, detects technology stacks, collects relevant context from all sources (primary docs, config files, standards docs, inline annotations, stack-specific rules, external MCP/RAG tools), and builds a structured PR-specific knowledge base at `{review_output}/pr-{pr_number}-context.yaml`.
+This workflow analyzes changed files, detects technology stacks, collects relevant context from all sources (primary docs, config files, standards docs, inline annotations, stack-specific rules, external MCP/RAG tools), asks the user for any additional context (marked ⚠️ IMPORTANT if provided), and builds a structured PR-specific knowledge base at `{review_output}/pr-{pr_number}-context.yaml`.
 
 On completion, store `pr_knowledge_base` = path to the generated context file.