prr-kit 1.3.0 → 1.4.0

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

@@ -7,13 +7,15 @@ description: "Run the multi-reviewer discussion and compile unified findings"
 
 ## Sequence of Instructions
 
+> **Active reviewers only.** Read the active reviewer list from step 1 (determined by `user_instructions.review_scope`). Skip any reviewer section below whose code is not in the active list. Only active reviewers speak and produce findings.
+
 ### 1. Round 1 — Each Reviewer's Initial Take
 
 Go through the diff once per reviewer. Each reviewer applies rules from the PR knowledge base loaded in step 1 in addition to their domain expertise.
 
 ---
 
-**👁️ Alex says:**
+**👁️ Alex says:** *(skip if GR not in scope)*
 
 [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]
 
@@ -25,7 +27,7 @@ Format each finding as:
 
 ---
 
-**🔒 Sam says:**
+**🔒 Sam says:** *(skip if SR not in scope)*
 
 [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]
 
@@ -38,7 +40,7 @@ Format each finding as:
 
 ---
 
-**⚡ Petra says:**
+**⚡ Petra says:** *(skip if PR not in scope)*
 
 [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]
 
@@ -51,7 +53,7 @@ Format each finding as:
 
 ---
 
-**🏗️ Arch says:**
+**🏗️ Arch says:** *(skip if AR not in scope)*
 
 [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]
 
@@ -66,7 +68,7 @@ Format each finding as:
 
 ### 2. Round 2 — Biz Translates + Cross-Review Discussion
 
-**💼 Biz speaks last** — synthesizes findings from Alex/Sam/Petra/Arch into business impact:
+**💼 Biz speaks last** *(skip if BR not in scope)* — 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, and project-specific business concerns from knowledge base]
 
@@ -103,7 +105,7 @@ After discussion, produce a unified finding list, deduplicated and prioritized:
 ## 🎉 Party Mode — Unified Findings
 
 **PR:** {target_branch} → {base_branch}
-**Session participants:** Alex 👁️ + Sam 🔒 + Petra ⚡ + Arch 🏗️ + Biz 💼
+**Session participants:** {active reviewers from step 1}
 
 ### 🔴 Blockers ({count})
 [all blockers from all reviewers, attributed to reviewer]

package/src/core/workflows/party-mode/workflow.md

@@ -2,7 +2,7 @@
 name: party-mode
 description: "Multi-reviewer discussion: all specialized agents review and debate the PR together"
 main_config: "{project-root}/_prr/prr/config.yaml"
-nextStep: "./steps/step-01-load-reviewers.md"
+nextStep: "./steps/step-00-user-instructions.md"
 ---
 
 # Party Mode Workflow 🎉
@@ -11,9 +11,10 @@ nextStep: "./steps/step-01-load-reviewers.md"
 
 ## WORKFLOW ARCHITECTURE
 
-2-step process:
-1. Load reviewer personas and assign sections
-2. Run structured discussion with each reviewer contributing findings
+3-step process:
+1. Collect user instructions (scope, focus, requirements, context) — always runs, user must respond
+2. Load reviewer personas filtered by scope
+3. Run structured discussion with each active reviewer contributing findings
 
 ## WHEN TO USE
 
@@ -26,9 +27,8 @@ Use Party Mode when you want:
 ## INITIALIZATION
 
 Load config from `{main_config}`.
-Load PR context from `{review_output}/current-pr-context.yaml`.
-
-If no PR context exists, prompt user to run [SP] Select PR first.
+Use `session_output`, `target_branch`, `base_branch`, `pr_number` from working context.
+If not set: prompt user to run [SS] Select Session or [SP] Select PR first.
 
 ## EXECUTION
 

package/src/prr/config-template.yaml

@@ -21,9 +21,6 @@ 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/1-discover/select-pr/steps/step-05-confirm.md

@@ -1,7 +1,6 @@
 ---
 name: "step-05-confirm"
 description: "Show PR scope summary and confirm before proceeding to review"
-contextOutputFile: "{review_output}/current-pr-context.yaml"
 ---
 
 # Step 5: Confirm Scope
@@ -10,10 +9,104 @@ contextOutputFile: "{review_output}/current-pr-context.yaml"
 
 ## STEP GOAL
 
-Show a clear summary of what will be reviewed, write PR context to file, and confirm the user wants to proceed.
+Show a clear summary of what will be reviewed, create the session output folder, store PR metadata in working context, and confirm the user wants to proceed.
 
 ## Sequence of Instructions
 
+### 0. Compute Session Output Folder
+
+Generate a unique, human-readable folder for this PR review session:
+
+```
+sanitized_branch = selected_branch
+  .toLowerCase()
+  .replace(/[^a-z0-9]+/g, '-')
+  .replace(/^-+|-+$/g, '')
+  .substring(0, 40)
+
+if pr_number is set:
+  session_slug = "pr{pr_number}-{sanitized_branch}"
+else:
+  session_slug = "{sanitized_branch}"
+
+datetime_prefix = current datetime as "YYYY-MM-DD-HHmm"   (e.g. 2026-03-02-1430)
+
+session_output = "{review_output}/{datetime_prefix}-{session_slug}"
+```
+
+Examples:
+- `_prr-output/reviews/2026-03-02-1430-pr44-feature-auth-login`
+- `_prr-output/reviews/2026-03-02-1430-feature-auth-login`
+
+Create the folder:
+```bash
+mkdir -p "{session_output}"
+```
+
+**Store `session_output` in working context** — all subsequent workflows in this session will use it.
+
+### 0b. Generate Diffs Folder
+
+Parse the diff already loaded in memory and write per-file markdown files under `{session_output}/diffs/`, mirroring the repo folder tree.
+
+**For each changed file in the diff:**
+
+1. Determine file path, status, and line counts from the diff header.
+2. Construct output path: `{session_output}/diffs/{file_path}.md`
+3. Create parent directories:
+   ```bash
+   mkdir -p "{session_output}/diffs/{file_dir}"
+   ```
+4. Write the markdown file:
+
+```markdown
+# {file_path}
+**Status:** {modified|added|deleted|renamed} | **+{lines_added} / -{lines_removed} lines**
+---
+
+**Line {start_line}** *(or **Lines {start}–{end}** for multi-line hunks)*
+```diff
+- old line content
++ new line content
+```
+
+*(repeat for each hunk in this file)*
+```
+
+**Rules:**
+- **New file:** show all lines as `+` additions under a single hunk block.
+- **Deleted file:** show all lines as `-` deletions under a single hunk block.
+- **Renamed file with no content change:** write status line only, no diff blocks.
+- **Renamed file with changes:** write status `renamed` and include change hunks as normal.
+- One `.md` file per changed file. Folder structure mirrors the repo exactly.
+
+**Example output for a modified file:**
+
+```markdown
+# src/auth/login.ts
+**Status:** modified | **+45 / -12 lines**
+---
+
+**Line 23**
+```diff
+- const token = localStorage.getItem('token')
++ const token = cookieStorage.get('auth_token')
+```
+
+**Lines 67–70**
+```diff
+- async function login(user, pass) {
+-   const result = await db.users.findOne(user)
++ async function login(user: string, pass: string): Promise<User> {
++   const result = await db.users.findOne({ email: user })
+```
+```
+
+After writing all files, print:
+```
+✓ Diffs saved: {file_count} files → {session_output}/diffs/
+```
+
 ### 1. Display Scope Summary
 
 Present a clear summary:
@@ -45,29 +138,7 @@ Recommended reviews for this PR:
   [BR] Business Review — for feature PRs, data migrations, or any high-risk change
 ```
 
-### 2. Write PR Context File
-
-Write `{contextOutputFile}` with:
-
-```yaml
-pr:
-  target_branch: "{selected_branch}"
-  base_branch: "{base_branch}"
-  pr_number: "{pr_number}"
-  pr_title: "{pr_title}"
-  diff_stats: |
-    {diff_stats}
-  commit_count: {commit_count}
-  files_changed:
-    {files_changed_list}
-  diff_strategy: "{diff_strategy}"
-  date: "{date}"
-review:
-  completed: []
-  findings: []
-```
-
-### 3. Ask for Confirmation
+### 2. Ask for Confirmation
 
 ```
 ✅ Ready to review. Which review would you like to run first?

package/src/prr/workflows/1-discover/select-pr/workflow.md

@@ -23,7 +23,7 @@ This uses **step-file architecture** with sequential orchestration:
 - 🛑 NEVER start reviewing without completing this workflow first
 - 📖 Read entire step file before executing
 - ⏸️ ALWAYS halt at user selection points — never auto-select
-- 💾 Write PR context to `{review_output}/current-pr-context.yaml` after confirmation
+- 💾 Create session folder `{session_output}` and store PR metadata in working context after confirmation (step 5)
 
 ## INITIALIZATION
 

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

@@ -1,88 +1,102 @@
 ---
 name: "step-03-manual-context-input"
-description: "Collect additional context manually from the user"
+description: "Collect user instructions, requirements, and context for this review session"
 nextStepFile: "./step-04-build-knowledge-base.md"
 ---
 
-# Step 3: Manual Context Input
+# Step 3: User Instructions & Context
 
 ## 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.
+Let the user guide the review — they can restrict scope, set focus areas, add mandatory requirements, or provide background context. Their input directly controls which reviews run and what each reviewer prioritizes.
 
 ## Sequence of Instructions
 
-### 1. Check Config
+### 1. Show Collection Summary
 
-Read `context_collection.skip_manual_input_context` from the loaded config.
-
-If `skip_manual_input_context: true`:
+Print a brief summary of what was automatically collected so far:
 
 ```
-⏭️  Manual context input skipped (skip_manual_input_context: true in config)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ Auto-collection complete.
+
+📊 Collected:
+   🗂️  Files changed:  {files_count}
+   🎯 Domains:         {domains_list}
+   🧩 Stacks:          {stacks_list or "none"}
+   📘 Primary docs:    {primary_docs_found}
+   ⚙️  Config files:   {config_files_found}
+   💬 Annotations:     {annotations_count}
+   🔌 External:        {mcp_and_rag_summary or "none"}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-Set `manual_context: null`. Add `step-03-manual-context-input` to `stepsCompleted`. Load: `{nextStepFile}`
+### 2. Prompt User
 
-**STOP — do not read further.**
+Display EXACTLY:
 
----
+```
+💬 Any instructions for this review?
+   Press Enter to run a full standard review, or type your instructions below.
+
+   You can specify:
+     • Scope        "only security" / "security and architecture" / "skip performance"
+     • Focus        "focus on SQL injection and rate limiting"
+     • Requirements "all API endpoints must have auth middleware"
+     • Context      "hotfix — ignore refactoring suggestions"
+     • Mix freely   "security only, focus on JWT handling, context: auth rewrite in progress"
+```
 
-### 2. Show Collection Summary
+**HALT — wait for user response before continuing.**
 
-Print a brief summary of what was automatically collected so far:
+### 3. Parse Response
 
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-💬 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"}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
+**If user pressed Enter / left empty:**
+- Set `user_instructions.provided` = `false`
+- Set `user_instructions.review_scope` = `"all"`
+- Set all other fields to `null`
 
-### 3. Prompt User
+**If user typed something**, parse the free-form text and extract:
 
-Ask the user:
+**`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"`
 
-```
-💬 Do you have any additional context for the reviewers?
+**`focus_areas`** — specific things reviewers must prioritize (list of strings), or `null` if none mentioned.
 
-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
+**`custom_requirements`** — mandatory checks user specified (list of strings), or `null`.
 
-Type your notes and press Enter, or type "skip" to continue without adding context.
-```
+**`context_notes`** — background info, trade-offs, constraints (list of strings), or `null`.
 
-### 4. Capture Input
+**`raw`** — full original text from user.
 
-Wait for the user's response.
+Set `user_instructions.provided` = `true`.
 
-- 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`
+### 4. Acknowledge
 
-### 5. Acknowledge
+**If user provided instructions**, print a confirmation of what was parsed:
 
-**If user provided context:**
 ```
-✅ Context noted — reviewers will treat this as ⚠️ high-priority input.
+✅ 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"}
 ```
 
-**If user skipped:**
+**If user left empty:**
+
 ```
-⏩ Skipped — continuing with auto-collected context only.
+▶️  Full standard review — all reviewers, standard focus.
 ```
 
-### 6. Load Next Step
+### 5. Load Next Step
 
 Add `step-03-manual-context-input` to `stepsCompleted`. Load: `{nextStepFile}`

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

@@ -32,15 +32,19 @@ pr_metadata:
   files_changed: {n}
   collected_at: {ISO timestamp}
 
-# ⚠️  IMPORTANT — Human-provided context from the PR author.
+# ⚠️  IMPORTANT — Human-provided instructions from the user.
 # All reviewers MUST read this section before starting any review.
-# Align all findings and focus areas against this input.
-manual_context:
+# review_scope controls which reviews run. 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}
-  content: |
-    {manual_context text, or null if not provided}
+  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
+  raw: {original text from user, or null}           # verbatim input
 
 files_analysis:
   changed_files:
@@ -245,7 +249,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.
+  # ⚠️  If user_instructions.provided is true — reviewers MUST check findings against user_instructions first.
   critical:
     - "Verify no v-html with user input (security requirement)"
     - "Check ESLint error-level rules compliance"
@@ -261,7 +265,10 @@ review_priorities:
     - "Optional optimizations"
 
 reviewer_guidance:
-  # ⚠️  If manual_context.provided is true — read manual_context BEFORE starting any review.
+  # ⚠️  If user_instructions.provided is true:
+  #     PREPEND each reviewer's list with user_instructions.focus_areas (if any)
+  #     APPEND each reviewer's list with user_instructions.custom_requirements prefixed "MANDATORY: "
+  #     Example: if focus_areas = ["JWT handling"], add "FOCUS: JWT handling" as first item
   general_review:
     - "Check for ESLint rule violations (no-var, prefer-const)"
     - "Verify component naming follows standards"
@@ -287,29 +294,21 @@ 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
+  user_instructions: {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
 ```
 
-### 3. Determine Output Filename
+### 3. Output Filename
 
-```javascript
-if (pr_number_available) {
-  filename = `pr-${pr_number}-context.yaml`
-} else {
-  // Use sanitized branch name
-  const safeBranchName = branch_name.replace(/[^a-zA-Z0-9-]/g, '-')
-  filename = `pr-${safeBranchName}-context.yaml`
-}
-```
+Always: `pr-context.yaml` — the session folder already identifies the PR uniquely.
 
 ### 4. Write Knowledge Base to File
 
-Write to: `{review_output}/{filename}`
+Write to: `{session_output}/pr-context.yaml`
 
-Example: `_prr-output/pr-123-context.yaml`
+Example: `_prr-output/reviews/2026-03-02-1430-pr123-feature-auth/pr-context.yaml`
 
 ### 5. Report Completion
 
@@ -322,9 +321,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)
+   • User instructions: ⚠️ YES — scope: {scope}, focus: {focus_count} areas, requirements: {req_count}
      OR
-   • Manual context: none
+   • User instructions: none — full standard review
    • MCP tools used: {mcp_list or "none"}
    • RAG patterns: {rag_count}
    • Issue context: {issue_key or "none"}
@@ -337,16 +336,11 @@ Example: `_prr-output/pr-123-context.yaml`
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-### 6. Store Context Path
-
-Update PR context file to include knowledge base path:
+### 6. Store Knowledge Base Path in Working Context
 
-```yaml
-# {review_output}/current-pr-context.yaml
-pr_knowledge_base: "{review_output}/{filename}"
-```
+Store `pr_knowledge_base` = `{session_output}/pr-context.yaml` in working context.
 
-This allows review workflows to find the knowledge base.
+Review workflows (GR, SR, PR, AR, BR) find the knowledge base via working context or directly at `{session_output}/pr-context.yaml`.
 
 ### 7. Workflow Complete
 

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

@@ -3,7 +3,7 @@ name: collect-pr-context
 description: "Collect fresh, PR-specific context from multiple sources after describing the PR"
 main_config: "{project-root}/_prr/prr/config.yaml"
 nextStep: "./steps/step-01-analyze-files.md"
-output_file: "{review_output}/pr-{pr_number}-context.yaml"
+output_file: "{session_output}/pr-context.yaml"
 ---
 
 # Collect PR-Specific Context Workflow
@@ -108,16 +108,14 @@ If a stack has no matching data file, skip it silently and proceed with general
 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. **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
+3. **Manual context input** — prompt the user for any additional context (business rationale, focus areas, known trade-offs). **Always runs — user must respond before continuing.** 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
 
 Load config from `{main_config}`.
 
-Check if PR number is available:
-- If available: use `pr-{pr_number}-context.yaml`
-- If not: use `pr-{branch_name}-context.yaml`
+Output filename is always `pr-context.yaml` — the session folder already identifies the PR uniquely.
 
 ## EXECUTION
 

package/src/prr/workflows/2-analyze/describe-pr/steps/step-01-load-context.md

@@ -14,11 +14,11 @@ Load the PR context file and the actual code diff for analysis.
 
 ### 1. Load PR Context
 
-Read `{review_output}/current-pr-context.yaml`.
+Use `session_output`, `target_branch`, `base_branch`, `pr_number` from working context.
 
-If file not found:
+If not set:
 ```
-❌ No PR selected yet. Please run [SP] Select PR first.
+❌ No active session. Run [SS] Select Session to resume a past session, or [SP] Select PR to start a new one.
 ```
 Stop workflow.
 

package/src/prr/workflows/2-analyze/describe-pr/steps/step-04-output.md

@@ -1,7 +1,7 @@
 ---
 name: "step-04-output"
 description: "Write PR description to file and display summary"
-outputFile: "{review_output}/pr-description-{date}.md"
+outputFile: "{session_output}/pr-description.md"
 templateFile: "../templates/pr-description.template.md"
 ---
 
@@ -24,14 +24,13 @@ Using the template at `{templateFile}`, generate the PR description with:
 
 ### 2. Write to File
 
-Write to `{outputFile}` (replace {date} with actual date: YYYY-MM-DD).
+Write to `{outputFile}`.
 
-### 3. Update PR Context
+### 3. Update Working Context
 
-Update `{review_output}/current-pr-context.yaml`:
-- Add `description_generated: true`
-- Add `pr_type: "{classified_type}"`
-- Add `risk_level: "{risk_level}"`
+Store in working context:
+- `pr_type` = `{classified_type}`
+- `risk_level` = `{risk_level}`
 
 ### 4. Display Summary
 

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

@@ -20,8 +20,8 @@ nextStep: "./steps/step-01-load-context.md"
 ## INITIALIZATION
 
 Load config from `{main_config}`.
-Load PR context from `{review_output}/current-pr-context.yaml`.
-If context file does not exist, instruct user to run [SP] Select PR first.
+Use `session_output`, `target_branch`, `base_branch`, `pr_number` from working context.
+If not set: prompt user to run [SS] Select Session (to resume a past session) or [SP] Select PR (to start a new one).
 
 ## EXECUTION
 

package/src/prr/workflows/3-review/architecture-review/checklist.md

@@ -22,5 +22,4 @@ validation-target: "Architecture review output file"
 - [ ] ❓ QUESTION findings include: specific question + list of potentially affected files outside the diff
 
 ## Output
-- [ ] Findings written to `{review_output}/architecture-review-{date}.md`
-- [ ] PR context updated with `architecture-review` in completed list
+- [ ] Findings written to `{session_output}/architecture-review.md`

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

@@ -7,11 +7,12 @@ user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
 target_repo: "{config_source}:target_repo"
 review_output: "{config_source}:review_output"
+session_output: "working-context:session_output || latest-session-folder-in:{review_output}"
 date: system-generated
 
 installed_path: "{project-root}/_prr/prr/workflows/3-review/architecture-review"
 instructions: "{installed_path}/instructions.xml"
 validation: "{installed_path}/checklist.md"
 
-pr_context: "{review_output}/current-pr-context.yaml"
-output_file: "{review_output}/architecture-review-{date}.md"
+pr_context: "working-context:target_branch,base_branch,pr_number,pr_knowledge_base"
+output_file: "{session_output}/architecture-review.md"

package/src/prr/workflows/3-review/business-review/checklist.md

@@ -23,5 +23,4 @@ validation-target: "Business review output file"
 - [ ] Post-ship monitoring noted: what to watch after deploy
 
 ## Output
-- [ ] Findings written to `{review_output}/business-review-{date}.md`
-- [ ] PR context updated with `business-review` in completed list
+- [ ] Findings written to `{session_output}/business-review.md`