prr-kit 2.0.8 → 2.0.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prr-kit",
-  "version": "2.0.8",
+  "version": "2.0.9",
   "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/tasks/workflow.xml

@@ -6,6 +6,7 @@
     <rule>ALWAYS update frontmatter state when writing output</rule>
     <rule>ALWAYS halt at decision points and wait for user input</rule>
     <rule>ALWAYS load config variables before starting any workflow</rule>
+    <rule>Use native file-reading tools for file content — avoid shell commands for reading files</rule>
   </rules>
 
   <variable-resolution>

package/src/core/workflows/party-mode/steps/step-00-user-instructions.md

@@ -41,6 +41,8 @@ Display EXACTLY:
      • Mix freely   "security only, focus on JWT handling, context: auth rewrite in progress"
 ```
 
+**IMPORTANT: Output this prompt as plain text only — do NOT use interactive question UI or structured choice tools. Wait for free-form text input.**
+
 **HALT — wait for user response before continuing.**
 
 ### 3. Parse Response

package/src/prr/workflows/2-analyze/collect-pr-context/steps/step-01-analyze-files.md

@@ -28,18 +28,14 @@ For each file in the PR diff, extract:
 - Directory path segments (e.g., `src`, `stores`)
 
 **File categories:**
-```javascript
-const fileCategories = {
-  'src/components/*.vue': 'vue-component',
-  'src/views/*.vue': 'vue-view',
-  'src/stores/*.js': 'pinia-store',
-  'src/router/*.js': 'vue-router',
-  'src/composables/*.js': 'composable',
-  '*.test.js|*.spec.js': 'test',
-  'src/utils/*.js': 'utility',
-  '*.css|*.scss': 'stylesheet'
-}
-```
+
+Infer category from the file's path, extension, and directory name. Use project-specific structure — there are no fixed categories. Examples of common patterns:
+- `src/components/**` or `ui/**` → component
+- `src/stores/**` or `state/**` → state management
+- `*.test.*` or `*.spec.*` or `tests/**` → test
+- `*.css` / `*.scss` / `*.sass` → stylesheet
+- `src/utils/**` or `helpers/**` → utility
+- Adapt freely based on what the actual project structure reveals
 
 ### 3. Detect Domains
 
@@ -77,29 +73,11 @@ Extract these annotations with:
 
 ### 5. Identify Config Files Needed
 
-Based on file types changed:
-
-```javascript
-const configMapping = {
-  '.vue': ['.eslintrc*', '.prettierrc*', 'vite.config.*'],
-  '.js|.ts': ['.eslintrc*', '.prettierrc*', 'tsconfig.json'],
-  '.py': ['pyproject.toml', '.flake8', 'mypy.ini'],
-  '.css|.scss': ['.stylelintrc*']
-}
-```
+Based on detected file types and stacks, identify relevant config files that likely contain lint rules, formatting, or build constraints. Look for common config patterns for the detected languages/frameworks — linter configs, formatter configs, compiler configs, build tool configs. Don't assume specific filenames; check what actually exists in the repo root.
 
 ### 6. Identify Docs Needed
 
-Based on domains and categories:
-
-```javascript
-const docsMapping = {
-  'vue-component': ['CONTRIBUTING.md → Component section', 'docs/components.md'],
-  'pinia-store': ['ARCHITECTURE.md → State management', 'docs/state-management.md'],
-  'security': ['CONTRIBUTING.md → Security section', 'docs/security.md'],
-  'api': ['docs/api-guidelines.md', 'ARCHITECTURE.md → API section']
-}
-```
+Based on detected domains and categories, identify relevant documentation files that reviewers should consult. Look for CONTRIBUTING.md, ARCHITECTURE.md, CLAUDE.md, AGENTS.md, and any domain-specific docs (e.g., `docs/api.md`, `docs/security.md`). Match docs to the actual domains found in this PR — don't load docs unrelated to the changed files.
 
 ### 7. Detect Technology Stacks
 
@@ -284,37 +262,23 @@ If no stack is confidently detected → `detected_stacks: []` — steps downstre
 
 ### 8. Build Analysis Summary
 
-```javascript
-{
-  "files_changed": [
-    {
-      "path": "src/stores/todoStore.js",
-      "extension": ".js",
-      "category": "pinia-store",
-      "domains": ["state-management"],
-      "annotations": [
-        {
-          "line": 10,
-          "type": "@pattern",
-          "content": "Use composition API only"
-        }
-      ]
-    },
-    {
-      "path": "src/views/TodoListView.vue",
-      "extension": ".vue",
-      "category": "vue-view",
-      "domains": ["ui-components", "state-management"]
-    }
-  ],
-  "context_needs": {
-    "configs": [".eslintrc.js", ".prettierrc", "vite.config.js"],
-    "docs": ["CONTRIBUTING.md", "ARCHITECTURE.md"],
-    "primary": ["CLAUDE.md", "AGENTS.md"],
-    "domains": ["state-management", "ui-components"]
-  },
-  "detected_stacks": ["vue3", "typescript"]
-}
+Build a summary object for all changed files using the structure below. Replace the example values with actual data from this PR:
+
+```
+files_changed:
+  - path: {actual file path}
+    extension: {actual extension}
+    category: {inferred category for this project}
+    domains: [{relevant domains}]
+    annotations: [{any @context/@security/@pattern/@rule comments found}]
+
+context_needs:
+  configs: [{config files found that are relevant to changed file types}]
+  docs: [{doc files relevant to domains changed}]
+  primary: [{CLAUDE.md, AGENTS.md, or equivalent if present}]
+  domains: [{all unique domains across changed files}]
+
+detected_stacks: [{stack keys from step 7}]
 ```
 
 ### 9. Report Analysis

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

@@ -46,28 +46,18 @@ Display EXACTLY:
      • Mix freely   "security only, focus on JWT handling, context: auth rewrite in progress"
 ```
 
+**IMPORTANT: Output this prompt as plain text only — do NOT use interactive question UI or structured choice tools. Wait for free-form text input.**
+
 **HALT — wait for user response before continuing.**
 
 ### 3. Parse Response
 
 **If user pressed Enter / left empty:**
 - Set `user_instructions.provided` = `false`
-- Set `user_instructions.review_scope` = `"all"`
-- Set all other fields to `null`
+- Set all fields to `null`
 
 **If user typed something**, parse the free-form text and extract:
 
-**`review_scope`** — which reviews to run:
-- Parse for scope signals: "only X", "just X", "X only", "skip X", "no X review", "X and Y"
-- Map to codes: `GR` (general), `SR` (security), `PR` (performance), `AR` (architecture), `BR` (business), `IC` (improve code)
-- Examples:
-  - "only security" → `[SR]`
-  - "security and architecture" → `[SR, AR]`
-  - "skip performance" → `[GR, SR, AR, BR]`
-  - "security, focus on JWT" → `[SR]` (scope signal found)
-  - "focus on SQL injection" (no scope signal) → `"all"` (focus only, all reviews still run)
-- If no scope restriction found → `"all"`
-
 **`focus_areas`** — specific things reviewers must prioritize (list of strings), or `null` if none mentioned.
 
 **`custom_requirements`** — mandatory checks user specified (list of strings), or `null`.
@@ -85,7 +75,6 @@ Set `user_instructions.provided` = `true`.
 ```
 ✅ Instructions captured — driving all downstream review steps.
 
-   📋 Scope:         {scope_list joined with ", "  OR  "all reviews (standard)"}
    🎯 Focus:         {focus_areas joined with ", "  OR  "standard coverage"}
    ✅ Requirements:  {custom_requirements joined with ", "  OR  "none"}
    📝 Context:       {context_notes joined with "; "  OR  "none"}

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

@@ -22,7 +22,6 @@ Using the `manual_context` variable set in step-03:
 
 - **If `manual_context` is null** (user skipped): set `user_instructions.provided = false`, all other fields `null`.
 - **If `manual_context` is not null** (user provided text): set `user_instructions.provided = true`, `raw = manual_context`, then parse the free-form text:
-  - `review_scope` — look for scope signals ("only SR", "skip performance", "security and architecture"). Default `"all"` if none found.
   - `focus_areas` — extract specific things to prioritize (e.g. "focus on JWT handling" → `["JWT handling"]`). `null` if none.
   - `custom_requirements` — extract mandatory checks the user stated (e.g. "all endpoints must have auth middleware"). `null` if none.
   - `context_notes` — extract background info, trade-offs, constraints. `null` if none.
@@ -45,13 +44,12 @@ pr_metadata:
 
 # ⚠️  IMPORTANT — Human-provided instructions from the user.
 # All reviewers MUST read this section before starting any review.
-# review_scope controls which reviews run. focus_areas, custom_requirements, and context_notes
+# focus_areas, custom_requirements, and context_notes
 # are highest-priority guidance — align all findings against them.
 user_instructions:
   # 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}
-  review_scope: {"all" | [SR] | [SR, AR] | ...}   # "all" = run all reviews; list = only those codes
   focus_areas: {list of strings, or null}           # specific things every reviewer must prioritize
   custom_requirements: {list of strings, or null}   # mandatory checks the user specified
   context_notes: {list of strings, or null}         # background info, trade-offs, constraints
@@ -337,7 +335,7 @@ Example: `_prr-output/reviews/2026-03-02-1430-pr123-feature-auth/pr-context.yaml
    • ESLint rules: {n}
    • Guidelines: {m}
    • Inline annotations: {k}
-   • User instructions: ⚠️ YES — scope: {scope}, focus: {focus_count} areas, requirements: {req_count}
+   • User instructions: ⚠️ YES — focus: {focus_count} areas, requirements: {req_count}
      OR
    • User instructions: none — full standard review
    • MCP tools used: {mcp_list or "none"}

package/src/prr/workflows/2-analyze/describe-pr/steps/step-02-classify.md

@@ -36,20 +36,19 @@ Based on PR type and what was changed:
 - **🟡 Medium Risk**: Core business logic, API changes, database schema
 - **🟢 Low Risk**: UI tweaks, docs, test additions, minor refactors
 
-### 3. Generate Review Recommendations
-
-Based on classification, recommend specific reviews:
-- bugfix → GR + SR (if security-related) + BR (if user-facing)
-- feature → GR + AR + PR (if DB/async) + BR (user impact + feature completeness)
-- security → SR (mandatory) + GR + BR (business/compliance risk)
-- performance → PR + GR + BR (if user-facing slowness)
-- refactor → AR + GR
-- hotfix → GR + SR + BR (high deployment risk — assess before shipping)
-- test → GR (light)
-- docs → (skip or GR light)
-- config → GR
-- chore → GR (light)
-- All high-risk PRs → SR mandatory + BR mandatory
+### 3. Suggest Review Focus
+
+Based on classification and risk level, suggest which reviews are most relevant — the orchestrator will use these as input alongside user instructions:
+- bugfix → GR is core; SR if the fix touches security paths; BR if user-facing behavior changes
+- feature → GR + AR to check design; PR if performance-sensitive changes; BR for user impact
+- security → SR is highest priority; GR and BR for full picture
+- performance → PR is core; GR for code quality; BR if user-facing impact
+- refactor → AR to check structural consistency; GR for quality
+- hotfix → fast GR + SR + BR to assess risk before shipping
+- test/docs/config/chore → light GR or skip heavy reviews if changes are low-risk
+- High-risk PRs → expand scope, don't skip SR or BR
+
+These are starting suggestions — adapt based on what was actually changed and any user instructions.
 
 ### 4. Load Next Step
 

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

@@ -10,7 +10,7 @@
       <output>❌ No PR selected. Please run [SP] Select PR first.</output>
       <stop/>
     </check>
-    <action>Read {pr_context} and load git diff</action>
+    <action>Read {pr_context}</action>
     <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>

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

@@ -16,7 +16,6 @@
     <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>
 
     <output>💼 Starting Business Review
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

@@ -15,14 +15,11 @@
     <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>
 
     <output>🔍 Starting General Code Review
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 PR: {target_branch} → {base_branch}
 Context: Loaded fresh PR-specific knowledge base
-Strategy: {diff_strategy}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</output>
   </step>
 

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

@@ -10,7 +10,7 @@
       <output>❌ No PR selected. Please run [SP] Select PR first.</output>
       <stop/>
     </check>
-    <action>Read {pr_context} and load git diff</action>
+    <action>Read {pr_context}</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>

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

@@ -16,7 +16,6 @@
     <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
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Scope: Secrets scan (always) + adapted checks for detected stack

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

@@ -19,6 +19,8 @@ Set `date` = today's date (YYYY-MM-DD).
 **Note:** Context will be collected dynamically in Phase 2.5 after describing the PR.
 No pre-collected context file needed. Context is always fresh and PR-specific.
 
+**File access:** Pre-saved diff files are available at `{session_output}/diffs/` after Phase 1f. Use native file-reading tools throughout this session — avoid shell commands for reading file content. When full file context is needed beyond the diff, read files directly from the working directory. For most accurate review results, ensure the current branch is the PR's target branch.
+
 ---
 
 ## PHASE 1 — SELECT PR
@@ -324,22 +326,13 @@ On completion, store `pr_knowledge_base` = path to the generated context file.
 ---
 
 ## PHASE 3 — REVIEW
-*Execute all review types automatically, one by one.*
-
-**Before each review, confirm these variables are set in working context (all set by earlier phases):**
-- `target_branch`, `base_branch`, `pr_number` — set by Phase 1 (Select PR)
-- `pr_knowledge_base` — set by Phase 2.5 (`{session_output}/pr-context.yaml`)
-- `session_output` — set by Phase 1 when session folder was created
-- `target_repo`, `communication_language` — from config
-- `output_file` — per-review path defined below *(ensures findings are saved to disk for [RR] and [PC] later)*
 
-**Scope gate:** Read `user_instructions.review_scope` from `{pr_knowledge_base}`.
-- If `"all"` (or knowledge base missing) → run all reviews 3a–3e normally.
-- If a list (e.g. `[SR, AR]`) → only run reviews whose code is in the list. For each skipped review, print:
-  `⏭️ {Review Name} skipped (not in scope)`
-  and do NOT write its output file.
+**Context:** Confirm `target_branch`, `base_branch`, `session_output`, `pr_knowledge_base`, `communication_language` are in working context from earlier phases. Set `output_file` per review as defined below.
 
-Review codes: `GR` = General · `SR` = Security · `PR` = Performance · `AR` = Architecture · `BR` = Business
+**Review orchestration:** Read `user_instructions` from `{pr_knowledge_base}`. Use judgment to decide which review skills (3a–3e) to run, in what order, and with what focus — based on the user's actual intent, the PR type, and the project context.
+- No user instructions provided → run all reviews in default order.
+- User specified scope, focus, or constraints → adapt accordingly: skip irrelevant reviews, reorder, or narrow focus to serve the user's actual need. Reviews are optional skills — invoke only what genuinely serves the request.
+- For each skipped review: print `⏭️ {Review Name} skipped` and do not write its output file.
 
 ### 3a. General Review
 Set `output_file` = `{session_output}/general-review.md`
@@ -383,7 +376,7 @@ Print section header: `## 💼 Business Review`
 ## PHASE 4 — GENERATE REPORT
 *Execute automatically.*
 
-Compile all findings from phases 3a–3e.
+Compile all findings from completed reviews.
 
 Sort by severity: 🔴 Blockers first → 🟡 Warnings → 🟢 Suggestions → 📌 Questions.