prr-kit 1.3.0 → 2.0.0

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

@@ -0,0 +1,125 @@
+---
+name: "step-00-user-instructions"
+description: "Collect user instructions before the party review begins"
+nextStepFile: "./step-01-load-reviewers.md"
+---
+
+# Step 0: User Instructions
+
+## Goal
+Always ask the user for scope, focus, requirements, or context before reviewers are loaded.
+This step runs even if a `pr-context.yaml` already exists — fresh instructions override any prior `user_instructions` in the file.
+
+## Sequence of Instructions
+
+### 1. Show PR Summary
+
+Display:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🎉 Party Mode — Review Setup
+
+   Branch: {target_branch} → {base_branch}
+   Files:  {file_count} changed
+   PR:     {pr_number if set, else "local branch"}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### 2. Prompt User
+
+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"
+```
+
+**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`
+
+**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)
+- Examples:
+  - "only security" → `[SR]`
+  - "security and architecture" → `[SR, AR]`
+  - "skip performance" → `[GR, SR, AR, BR]`
+  - "focus on SQL injection" (no scope signal) → `"all"` (focus only, all reviewers still active)
+- If no scope restriction found → `"all"`
+
+**`focus_areas`** — specific things reviewers must prioritize (list of strings), or `null` if none.
+
+**`custom_requirements`** — mandatory checks user specified (list of strings), or `null`.
+
+**`context_notes`** — background info, trade-offs, constraints (list of strings), or `null`.
+
+**`raw`** — full original text from user.
+
+Set `user_instructions.provided` = `true`.
+
+### 4. Acknowledge
+
+**If user provided instructions:**
+
+```
+✅ Instructions captured.
+
+   📋 Scope:        {scope_list joined with ", "  OR  "all reviewers"}
+   🎯 Focus:        {focus_areas joined with ", "  OR  "standard coverage"}
+   ✅ Requirements: {custom_requirements joined with ", "  OR  "none"}
+   📝 Context:      {context_notes joined with "; "  OR  "none"}
+```
+
+**If user left empty:**
+
+```
+▶️  Full standard review — all reviewers, standard focus.
+```
+
+### 5. Write to pr-context.yaml
+
+Write `user_instructions` to `{session_output}/pr-context.yaml`:
+
+- **If `pr-context.yaml` exists**: update only the `user_instructions:` section, leave all other sections intact.
+- **If `pr-context.yaml` does not exist** (Party Mode was run without prior DP/context collection):
+  Create a minimal file with just `pr_metadata` and `user_instructions`:
+
+```yaml
+# PR-Specific Context (minimal — created by Party Mode)
+# Generated: {timestamp}
+
+pr_metadata:
+  pr_number: {pr_number or null}
+  branch: {target_branch}
+  base_branch: {base_branch}
+  collected_at: {ISO timestamp}
+
+user_instructions:
+  provided: {true|false}
+  review_scope: {value}
+  focus_areas: {value}
+  custom_requirements: {value}
+  context_notes: {value}
+  raw: {value}
+```
+
+Store `pr_knowledge_base` = `{session_output}/pr-context.yaml` in working context.
+
+### 6. Load Next Step
+
+Add `step-00-user-instructions` to `stepsCompleted`. Load: `{nextStepFile}`

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

@@ -8,35 +8,50 @@ nextStepFile: "./step-02-discussion.md"
 
 ## Sequence of Instructions
 
-### 1. Introduce Party Mode
+### 1. Load PR Knowledge Base
 
-Display:
+Load the PR knowledge base from working context (`pr_knowledge_base`), or read directly at `{session_output}/pr-context.yaml`.
+It contains stack-specific rules, ESLint/linting rules, project guidelines (CLAUDE.md, CONTRIBUTING.md, ARCHITECTURE.md sections), inline code annotations, and external context.
+
+If no knowledge base exists (DP was not run), proceed with local context only — do not block.
+
+**Read `user_instructions`** from the knowledge base:
+
+- **`review_scope`**: determines active reviewers
+  - If `"all"` (or knowledge base missing) → all 5 reviewers are active.
+  - If a list (e.g. `[SR, AR]`) → only activate reviewers matching those codes:
+    `GR` = Alex · `SR` = Sam · `PR` = Petra · `AR` = Arch · `BR` = Biz
+
+- **`focus_areas`** / **`custom_requirements`** / **`context_notes`**: if `user_instructions.provided` is true, store these in working context — all active reviewers will apply them in step 2:
+  - `focus_areas` → each reviewer must prioritize these areas above their default checklist
+  - `custom_requirements` → treat as mandatory checks (prefix each with "MANDATORY:")
+  - `context_notes` → background info explaining trade-offs or constraints; do not flag issues the user has explicitly accepted
+
+### 2. Introduce Party Mode
+
+Display, listing only the **active** reviewers:
 ```
 🎉 Party Mode activated!
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Reviewers joining this session:
 
-  👁️  Alex     — General Code Quality
+  {active reviewers only, e.g.:}
   🔒  Sam      — Security
-  ⚡  Petra    — Performance
   🏗️  Arch     — Architecture
-  💼  Biz      — Business Impact
 
 PR: {target_branch} → {base_branch}
 Files changed: {file_count} | Lines: +{additions} -{deletions}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-### 2. Load PR Knowledge Base
-
-Read `{review_output}/current-pr-context.yaml` to get `pr_knowledge_base` path.
-Load the knowledge base file — it contains stack-specific rules, ESLint/linting rules, project guidelines (CLAUDE.md, CONTRIBUTING.md, ARCHITECTURE.md sections), inline code annotations, and external context.
-
-If no knowledge base exists (DP was not run), proceed with local context only — do not block.
+If reviewers were filtered, also print:
+```
+⏭️  Skipped: {inactive reviewer names} (not in review scope)
+```
 
 ### 3. Load Reviewer Personas
 
-Internally adopt all reviewer personas simultaneously. All reviewers apply rules from the PR knowledge base in their respective areas.
+Internally adopt only the **active** reviewer personas (determined by scope in step 1). All active 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, and stack-specific best practices from knowledge base
@@ -64,7 +79,7 @@ Internally adopt all reviewer personas simultaneously. All reviewers apply rules
 - 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
 
-### 4. Scan the Diff and Assign Focus Areas
+### 4. Scan the Diff and Assign Focus Areas (active reviewers only)
 
 Read the diff and file list from the knowledge base. Assign focus areas:
 - SQL/DB files → Petra leads (N+1, missing index), Sam checks (injection)
@@ -74,6 +89,6 @@ Read the diff and file list from the knowledge base. Assign focus areas:
 - Any file touching auth, payments, PII → Sam mandatory
 - Schema/migration files → Biz flags (data safety, rollback plan)
 
-### 4. Load Next Step
+### 5. Load Next Step
 
 Add `step-01-load-reviewers` to `stepsCompleted`. Load: `{nextStepFile}`

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

@@ -7,13 +7,20 @@ 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.
+
+> **User instructions (if `user_instructions.provided` is true):** Before each reviewer begins, they must:
+> 1. Prioritize any `focus_areas` above their default checklist
+> 2. Include all `custom_requirements` as mandatory checks (prefix each finding with "MANDATORY:")
+> 3. Use `context_notes` as background — do not flag issues the user explicitly accepted as trade-offs
+
 ### 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.
+Go through the diff once per reviewer. Each reviewer applies rules from the PR knowledge base loaded in step 1, applies `user_instructions` (focus areas, mandatory requirements, context notes), and uses 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 +32,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 +45,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 +58,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 +73,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 +110,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,107 @@ 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 in working context** — all subsequent workflows in this session will use these values:
+- `session_output` = computed above
+- `target_branch` = `selected_branch`   ← canonical name used by all downstream workflows
+- `base_branch`, `diff_range`, `pr_number`, `pr_title`, `pr_author`, `pr_body`, `pr_head_sha`, `active_platform`, `platform_repo` = from step 3
+
+### 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 +141,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}`