prizmkit 1.1.32 → 1.1.35

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.32",
-  "bundledAt": "2026-04-14T08:14:47.343Z",
-  "bundledFrom": "466ccf2"
+  "frameworkVersion": "1.1.35",
+  "bundledAt": "2026-04-16T01:23:04.438Z",
+  "bundledFrom": "253edf2"
 }

package/bundled/dev-pipeline/reset-bug.sh

@@ -330,7 +330,6 @@ print('?')
     fi
 
     # -- Execute reset --
-    local _reset_tmpstderr _reset_stderr
     _reset_tmpstderr=$(mktemp)
     if [[ "$DO_CLEAN" == true ]]; then
         log_info "Cleaning $CUR_BUG_ID (reset + delete artifacts)..."

package/bundled/dev-pipeline/reset-feature.sh

@@ -340,7 +340,6 @@ print('?')
     fi
 
     # ── Execute reset ──
-    local _reset_tmpstderr _reset_stderr
     _reset_tmpstderr=$(mktemp)
     if [[ "$DO_CLEAN" == true ]]; then
         log_info "Cleaning $CUR_FEATURE_ID (reset + delete artifacts)..."

package/bundled/dev-pipeline/reset-refactor.sh

@@ -328,7 +328,6 @@ print('?')
     fi
 
     # -- Execute reset --
-    local _reset_tmpstderr _reset_stderr
     _reset_tmpstderr=$(mktemp)
     if [[ "$DO_CLEAN" == true ]]; then
         log_info "Cleaning $CUR_REFACTOR_ID (reset + delete artifacts)..."

package/bundled/dev-pipeline/scripts/generate-bootstrap-prompt.py

@@ -195,8 +195,8 @@ def detect_test_commands(project_root):
         except Exception:
             pass
 
-    # Return deduplicated space-separated list
-    return " ".join(dict.fromkeys(test_commands)) if test_commands else ""
+    # Return deduplicated commands joined with && for correct shell execution
+    return " && ".join(dict.fromkeys(test_commands)) if test_commands else ""
 
 
 def extract_baseline_failures(test_cmd, project_root):
@@ -273,6 +273,29 @@ def format_global_context(global_context, project_root=None):
     return "\n".join(lines)
 
 
+def format_user_context(user_context):
+    """Format user_context array as a markdown section.
+
+    Returns empty string if user_context is empty or absent,
+    so the template placeholder resolves to nothing.
+    """
+    if not user_context or not isinstance(user_context, list):
+        return ""
+    items = [item for item in user_context if isinstance(item, str) and item.strip()]
+    if not items:
+        return ""
+    lines = [
+        "### User-Provided Context (HIGHEST PRIORITY)",
+        "",
+        "> The following materials were provided by the user. "
+        "They take precedence over AI inference.",
+        "",
+    ]
+    for item in items:
+        lines.append("- {}".format(item))
+    return "\n".join(lines)
+
+
 def get_completed_dependencies(features, feature):
     """Look up dependency features and list those with status=completed.
 
@@ -1352,6 +1375,7 @@ def build_replacements(args, feature, features, global_context, script_dir):
         "{{FEATURE_LIST_PATH}}": os.path.abspath(args.feature_list),
         "{{FEATURE_TITLE}}": feature.get("title", ""),
         "{{FEATURE_DESCRIPTION}}": feature.get("description", ""),
+        "{{USER_CONTEXT}}": format_user_context(feature.get("user_context", [])),
         "{{ACCEPTANCE_CRITERIA}}": format_acceptance_criteria(
             feature.get("acceptance_criteria", [])
         ),

package/bundled/dev-pipeline/scripts/generate-bugfix-prompt.py

@@ -126,6 +126,29 @@ def format_error_source_details(error_source):
     return "\n".join(lines)
 
 
+def format_user_context(user_context):
+    """Format user_context array as a markdown section.
+
+    Returns empty string if user_context is empty or absent,
+    so the template placeholder resolves to nothing.
+    """
+    if not user_context or not isinstance(user_context, list):
+        return ""
+    items = [item for item in user_context if isinstance(item, str) and item.strip()]
+    if not items:
+        return ""
+    lines = [
+        "### User-Provided Context (HIGHEST PRIORITY)",
+        "",
+        "> The following materials were provided by the user. "
+        "They take precedence over AI inference.",
+        "",
+    ]
+    for item in items:
+        lines.append("- {}".format(item))
+    return "\n".join(lines)
+
+
 def format_environment(env):
     """Format environment dict as a key-value list."""
     if not env or not isinstance(env, dict):
@@ -245,6 +268,7 @@ def build_replacements(args, bug, global_context, script_dir):
         "{{SEVERITY}}": bug.get("severity", "medium"),
         "{{VERIFICATION_TYPE}}": vtype,
         "{{BUG_DESCRIPTION}}": bug.get("description", ""),
+        "{{USER_CONTEXT}}": format_user_context(bug.get("user_context", [])),
         "{{ERROR_SOURCE_TYPE}}": error_type,
         "{{ERROR_SOURCE_DETAILS}}": format_error_source_details(error_source),
         "{{ACCEPTANCE_CRITERIA}}": format_acceptance_criteria(

package/bundled/dev-pipeline/scripts/generate-refactor-prompt.py

@@ -186,6 +186,29 @@ def format_global_context(global_context, project_root=None):
     return "\n".join(lines)
 
 
+def format_user_context(user_context):
+    """Format user_context array as a markdown section.
+
+    Returns empty string if user_context is empty or absent,
+    so the template placeholder resolves to nothing.
+    """
+    if not user_context or not isinstance(user_context, list):
+        return ""
+    items = [item for item in user_context if isinstance(item, str) and item.strip()]
+    if not items:
+        return ""
+    lines = [
+        "### User-Provided Context (HIGHEST PRIORITY)",
+        "",
+        "> The following materials were provided by the user. "
+        "They take precedence over AI inference.",
+        "",
+    ]
+    for item in items:
+        lines.append("- {}".format(item))
+    return "\n".join(lines)
+
+
 def format_scope(scope):
     """Format scope object into markdown detail lines."""
     if not scope or not isinstance(scope, dict):
@@ -411,6 +434,7 @@ def build_replacements(args, refactor, refactors, global_context, script_dir):
         "{{PRIORITY}}": refactor.get("priority", "medium"),
         "{{COMPLEXITY}}": refactor.get("complexity", "medium"),
         "{{REFACTOR_DESCRIPTION}}": refactor.get("description", ""),
+        "{{USER_CONTEXT}}": format_user_context(refactor.get("user_context", [])),
         "{{ACCEPTANCE_CRITERIA}}": format_acceptance_criteria(
             refactor.get("acceptance_criteria", [])
         ),

package/bundled/dev-pipeline/templates/agent-prompts/dev-implement.md

@@ -16,16 +16,13 @@ Update the AC Verification Checklist in context-snapshot.md by marking each item
 
 ## Test Failure Recovery (Convergence-Based)
 
-If tests fail during implementation, use convergence-based recovery — keep fixing as long as progress is being made:
+If tests fail, use convergence recovery — keep fixing while progress is being made:
 
-1. **Run tests, record results**: count failures, note which tests failed (exclude baseline failures)
-2. **Check termination**:
-   - All tests pass → Done
-   - Plateau: same failures for 3 consecutive rounds → Cannot resolve, document and stop
-   - Failures decreased → Continue fixing
-3. **Fix and iterate**: analyze, apply fix, re-run `$TEST_CMD`, go back to step 1
+1. **Run tests, record results**: count failures, exclude baseline failures
+2. **Check termination**: All pass → done | Plateau (same failures 3 rounds) → stop | Failures decreased → continue
+3. **Fix and iterate**: analyze, apply fix, re-run `($TEST_CMD)`, go back to step 1
 
-**Key rule**: If failures decrease (even by 1), the plateau counter resets to 0.
+**Key rule**: If failures decrease (even by 1), plateau counter resets.
 **Do NOT block completion** if unable to resolve — only NEW REGRESSIONS (not in baseline) require fixing.
 **If any AC cannot be verified** due to test failure: the feature is incomplete, add to failure notes.
 

package/bundled/dev-pipeline/templates/agent-prompts/reviewer-review.md

@@ -3,6 +3,6 @@
 2. Read `.prizmkit/specs/{{FEATURE_SLUG}}/plan.md` for architecture decisions and completed tasks
 3. Read `.prizm-docs/root.prizm` and relevant L1/L2 docs for RULES, PATTERNS, TRAPS
 4. Run /prizmkit-code-review with artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/: Phase 1 diagnostic review across all applicable dimensions, then Phase 2 fix strategy for any findings. Read ONLY files referenced in completed plan.md tasks for diagnosis; MAY read additional files for impact analysis.
-5. Run the full test suite using `{{TEST_CMD}}`. When running tests: `{{TEST_CMD}} 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep `/tmp/review-test-out.txt` for details — do NOT re-run the suite multiple times. Write and execute integration tests covering all goals from spec.md.
+5. Run the full test suite using `{{TEST_CMD}}`. When running tests: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep `/tmp/review-test-out.txt` for details — do NOT re-run the suite multiple times. Write and execute integration tests covering all goals from spec.md.
 6. review-report.md will be written to .prizmkit/specs/{{FEATURE_SLUG}}/ by prizmkit-code-review.
 Report: number of findings found, or 'no findings' if clean."

package/bundled/dev-pipeline/templates/bootstrap-prompt.md

@@ -11,6 +11,8 @@
 - **Description**: {{FEATURE_DESCRIPTION}}
 - **Slug**: {{FEATURE_SLUG}}
 
+{{USER_CONTEXT}}
+
 ### Acceptance Criteria
 
 {{ACCEPTANCE_CRITERIA}}

package/bundled/dev-pipeline/templates/bootstrap-tier1.md

@@ -18,6 +18,8 @@ You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATU
 
 {{FEATURE_DESCRIPTION}}
 
+{{USER_CONTEXT}}
+
 ### Acceptance Criteria
 
 {{ACCEPTANCE_CRITERIA}}
@@ -48,7 +50,7 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 4. **One task at a time** — In Phase 3 (implement), complete and test one task before starting the next.
 5. **Minimize tool output** — Never load full command output into context. First capture to a temp file (`cmd 2>&1 | tee /tmp/out.txt | tail -20`), then scan the head/tail to identify relevant fields, and use targeted filtering (`grep`, `sed`, `awk`) to extract only the information needed for the current task. Only read the filtered result — never the raw full output.
 6. **No intermediate commits** — Do NOT run `git add`/`git commit` during Phase 1-3. All changes are committed once at the end in Phase 4 via `/prizmkit-committer`.
-7. **Capture test output once** — When running test suites, always use `$TEST_CMD 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
+7. **Capture test output once** — When running test suites, always use `($TEST_CMD) 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
 
 ---
 
@@ -129,7 +131,7 @@ Never commit compiled binaries, build output, or generated artifacts.
 You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS` (one or more commands). Then record baseline:
 ```bash
 # Run each test command, capture output
-$TEST_CMD 2>&1 | tee /tmp/test-baseline.txt | tail -20
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
 ```
 
 **3b.** Run `/prizmkit-implement` — this handles the full implementation cycle:
@@ -150,38 +152,15 @@ $TEST_CMD 2>&1 | tee /tmp/test-baseline.txt | tail -20
 
 **CP-2**: All acceptance criteria met, all tests pass.
 
-### Test Failure Recovery Protocol
-
-When tests fail during Phase 3, use **convergence-based recovery** — keep fixing as long as progress is being made.
-
-**Recovery Loop**:
-
-1. **Run tests and record results**: count total failures, note which tests failed. Exclude pre-existing baseline failures.
+### Test Failure Recovery (Convergence-Based)
 
-2. **Check termination conditions** (evaluate BEFORE each fix attempt):
-   - **All tests pass** → Done. Exit recovery loop.
-   - **Plateau detected** — same failure count AND same failing tests for 3 consecutive rounds → AI cannot resolve. Document and exit.
-   - **Still making progress** — failure count decreased vs. previous round → Continue fixing.
-   - **First round** — no history yet → Proceed to fix.
-
-3. **Fix and iterate**: analyze remaining failures, apply fix, re-run `$TEST_CMD`, go back to step 1.
-
-**Convergence tracking example**:
-```
-Round 1: 5 failures [test_a, test_b, test_c, test_d, test_e]
-Round 2: 3 failures [test_b, test_d, test_e]          ← progress, continue
-Round 3: 3 failures [test_b, test_d, test_e]          ← plateau 1/3
-Round 4: 3 failures [test_b, test_d, test_e]          ← plateau 2/3
-Round 5: 3 failures [test_b, test_d, test_e]          ← plateau 3/3 → STOP
-```
-**Key rule**: If failures decrease (even by 1), the plateau counter resets to 0.
+When tests fail, use convergence recovery — keep fixing while progress is being made:
 
-**When recovery loop exits with remaining failures**:
-   - Document in Implementation Log: test name, root cause, category, rounds attempted, plateau point
-   - **Do NOT block commit** — unresolved failures are deferred to next session
-   - If any AC cannot be verified due to test failure: feature is incomplete
+1. **Run tests, record results**: count failures, exclude baseline failures
+2. **Check termination**: All pass → done | Plateau (same failures 3 rounds) → stop | Failures decreased → continue
+3. **Fix and iterate**: analyze, fix, re-run `($TEST_CMD)`, go back to step 1
 
-**Context-Aware Optimization**: If Implementation Log already confirms "all tests passing," skip full suite re-run.
+**Key rule**: If failures decrease (even by 1), plateau counter resets. Do NOT block commit for unresolved failures — document and defer to next session.
 
 
 {{IF_BROWSER_INTERACTION}}

package/bundled/dev-pipeline/templates/bootstrap-tier2.md

@@ -18,6 +18,8 @@ You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATU
 
 {{FEATURE_DESCRIPTION}}
 
+{{USER_CONTEXT}}
+
 ### Acceptance Criteria
 
 {{ACCEPTANCE_CRITERIA}}
@@ -48,7 +50,7 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 4. **One task at a time** — In Phase 4 (implement), complete and test one task before starting the next.
 5. **Minimize tool output** — Never load full command output into context. First capture to a temp file (`cmd 2>&1 | tee /tmp/out.txt | tail -20`), then scan the head/tail to identify relevant fields, and use targeted filtering (`grep`, `sed`, `awk`) to extract only the information needed for the current task. Only read the filtered result — never the raw full output.
 6. **No intermediate commits** — Do NOT run `git add`/`git commit` during Phase 1-5. All changes are committed once at the end in Phase 6 via `/prizmkit-committer`.
-7. **Capture test output once** — When running test suites, always use `$TEST_CMD 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
+7. **Capture test output once** — When running test suites, always use `($TEST_CMD) 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
 
 ---
 
@@ -88,7 +90,7 @@ If any agent times out:
 
 You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS`. Then record baseline:
 ```bash
-$TEST_CMD 2>&1 | tee /tmp/test-baseline.txt | tail -20
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
 ```
 Save pre-existing failing tests as `BASELINE_FAILURES`.
 
@@ -263,7 +265,7 @@ Prompt:
 > 2. Read `.prizmkit/specs/{{FEATURE_SLUG}}/plan.md` for architecture decisions and completed tasks
 > 3. Read `.prizm-docs/root.prizm` and relevant L1/L2 docs for RULES, PATTERNS, TRAPS
 > 4. Run /prizmkit-code-review with artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/: Phase 1 diagnostic review across all applicable dimensions, then Phase 2 fix strategy formulation for any findings. Read ONLY files referenced in completed plan.md tasks for diagnosis; MAY read additional files for impact analysis.
-> 5. Run the full test suite using `{{TEST_CMD}}`. When running: `{{TEST_CMD}} 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep the file for details — do NOT re-run the suite multiple times. Write and execute integration tests covering all goals.
+> 5. Run the full test suite using `{{TEST_CMD}}`. When running: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep the file for details — do NOT re-run the suite multiple times. Write and execute integration tests covering all goals.
 > 6. review-report.md will be written to .prizmkit/specs/{{FEATURE_SLUG}}/ by prizmkit-code-review.
 > Report: number of findings found, or 'no findings' if clean."
 

package/bundled/dev-pipeline/templates/bootstrap-tier3.md

@@ -18,6 +18,8 @@ You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATU
 
 {{FEATURE_DESCRIPTION}}
 
+{{USER_CONTEXT}}
+
 ### Acceptance Criteria
 
 {{ACCEPTANCE_CRITERIA}}
@@ -89,7 +91,7 @@ If any agent times out:
 **Step 2 — Record pre-existing failure baseline**:
 ```bash
 # Run each test command, capture output
-$TEST_CMD 2>&1 | tee /tmp/test-baseline.txt | tail -20
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
 ```
 Save the list of **pre-existing failing tests** (if any) as `BASELINE_FAILURES`. These are known failures that existed before this session — Dev must NOT be blamed for them, but must list them in COMPLETION_SIGNAL.
 
@@ -328,7 +330,7 @@ Prompt:
 > 2. Read `.prizmkit/specs/{{FEATURE_SLUG}}/plan.md` for architecture decisions and completed tasks
 > 3. Read `.prizm-docs/root.prizm` and relevant L1/L2 docs for RULES, PATTERNS, TRAPS
 > 4. Run /prizmkit-code-review with artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/: Phase 1 diagnostic review across all applicable dimensions, then Phase 2 fix strategy formulation for any findings. Read ONLY files referenced in completed plan.md tasks for diagnosis; MAY read additional files for impact analysis.
-> 5. Run the full test suite using `{{TEST_CMD}}`. When running tests: `{{TEST_CMD}} 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep `/tmp/review-test-out.txt` for details — do NOT re-run the suite multiple times. Write and execute integration tests covering all goals from spec.md.
+> 5. Run the full test suite using `{{TEST_CMD}}`. When running tests: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep `/tmp/review-test-out.txt` for details — do NOT re-run the suite multiple times. Write and execute integration tests covering all goals from spec.md.
 > 6. review-report.md will be written to .prizmkit/specs/{{FEATURE_SLUG}}/ by prizmkit-code-review.
 > Report: number of findings found, or 'no findings' if clean."
 

package/bundled/dev-pipeline/templates/bug-fix-list-schema.json

@@ -186,6 +186,11 @@
               3
             ]
           },
+          "user_context": {
+            "type": "array",
+            "items": { "type": "string" },
+            "description": "User-provided supplementary materials, preserved verbatim. Each entry is either inline content/rules (stored as-is) or a file reference (e.g. 'src/auth/login.ts:42-78', 'src/utils/ — focus on validation logic')."
+          },
           "model": {
             "type": "string",
             "description": "AI model ID for this bug fix. Overrides $MODEL env var."

package/bundled/dev-pipeline/templates/bugfix-bootstrap-prompt.md

@@ -19,6 +19,8 @@ You are the **bug fix session agent**. Fix Bug {{BUG_ID}}: "{{BUG_TITLE}}".
 
 {{BUG_DESCRIPTION}}
 
+{{USER_CONTEXT}}
+
 ### Error Source
 
 - **Type**: {{ERROR_SOURCE_TYPE}}

package/bundled/dev-pipeline/templates/feature-list-schema.json

@@ -165,6 +165,11 @@
             },
             "description": "AI-generated summary of key changes from this feature session. Used to provide rich dependency context to downstream features. Each item is a concise statement about what was built/changed (e.g. APIs added, models created, key file paths)."
           },
+          "user_context": {
+            "type": "array",
+            "items": { "type": "string" },
+            "description": "User-provided supplementary materials, preserved verbatim. Each entry is either inline content/rules (stored as-is) or a file reference (e.g. 'src/auth/login.ts:42-78', 'src/utils/ — focus on validation logic')."
+          },
           "browser_interaction": {
             "type": "object",
             "description": "Browser verification config for features with UI. Requires playwright-cli. AI auto-detects dev server command, URL, and port from project config at runtime.",

package/bundled/dev-pipeline/templates/refactor-bootstrap-prompt.md

@@ -31,6 +31,8 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 
 {{REFACTOR_DESCRIPTION}}
 
+{{USER_CONTEXT}}
+
 ### Scope
 
 **Files:**

package/bundled/dev-pipeline/templates/refactor-list-schema.json

@@ -184,6 +184,11 @@
             },
             "description": "AI-generated summary of key changes from this refactor session. Used to provide rich dependency context to downstream refactors. Each item is a concise statement about what was refactored (e.g. modules extracted, files restructured, interfaces changed)."
           },
+          "user_context": {
+            "type": "array",
+            "items": { "type": "string" },
+            "description": "User-provided supplementary materials, preserved verbatim. Each entry is either inline content/rules (stored as-is) or a file reference (e.g. 'src/auth/login.ts:42-78', 'src/utils/ — focus on validation logic')."
+          },
           "critic": {
             "type": "boolean",
             "description": "Enable adversarial critic review for this refactor. Default: true for critical/high priority refactors, false for others.",

package/bundled/dev-pipeline/templates/sections/context-budget-rules.md

@@ -10,7 +10,7 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 4. **One task at a time** — Complete and test one task before starting the next.
 5. **Minimize tool output** — Never load full command output into context. First capture to a temp file (`cmd 2>&1 | tee /tmp/out.txt | tail -20`), then scan the head/tail to identify relevant fields, and use targeted filtering (`grep`, `sed`, `awk`) to extract only the information needed for the current task. Only read the filtered result — never the raw full output.
 6. **No intermediate commits** — Do NOT run `git add`/`git commit` during implementation phases. All changes are committed once at the end via `/prizmkit-committer`.
-7. **Capture test output once** — When running test suites, always use `$TEST_CMD 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
+7. **Capture test output once** — When running test suites, always use `($TEST_CMD) 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
 8. **Scaffold / generated file awareness (CRITICAL)** — When you run a scaffolding tool or package manager init command (`npm init`, `npx create-*`, `vite create`, `cargo init`, `go mod init`, `rails new`, `django-admin startproject`, `npx shadcn-ui init`, etc.), the output files are **generated boilerplate**. You MUST:
    - Identify and mentally tag all files created by the tool as "scaffold files"
    - Record the list of scaffold-generated files in context-snapshot.md under a `### Scaffold Files (do not re-read)` section

package/bundled/dev-pipeline/templates/sections/feature-context.md

@@ -3,6 +3,8 @@
 
 {{FEATURE_DESCRIPTION}}
 
+{{USER_CONTEXT}}
+
 ### Acceptance Criteria
 
 {{ACCEPTANCE_CRITERIA}}

package/bundled/dev-pipeline/templates/sections/phase-implement-lite.md

@@ -19,7 +19,7 @@ Never commit compiled binaries, build output, or generated artifacts.
 You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS`. Then record baseline:
 ```bash
 # Run each test command, capture output
-$TEST_CMD 2>&1 | tee /tmp/test-baseline.txt | tail -20
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
 ```
 
 **3b.** Run `/prizmkit-implement` — this handles the full implementation cycle:

package/bundled/dev-pipeline/templates/sections/phase0-test-baseline.md

@@ -5,7 +5,7 @@
 **Step 2 — Record pre-existing failure baseline**:
 ```bash
 # Run each test command, capture output
-$TEST_CMD 2>&1 | tee /tmp/test-baseline.txt | tail -20
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
 ```
 Save the list of **pre-existing failing tests** (if any) as `BASELINE_FAILURES`. These are known failures that existed before this session — Dev must NOT be blamed for them, but must list them in COMPLETION_SIGNAL.
 

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-agent.md

@@ -20,19 +20,11 @@ When tests fail during implementation (Phase 3 / Phase 4), use **convergence-bas
      - **Pre-existing baseline failure**: Expected, do NOT fix
      - **New regression**: Fix the code
      - **Brittle test**: Fix the test or environment setup
-   - Apply fix, re-run `$TEST_CMD`, go back to step 1
+   - Apply fix, re-run `($TEST_CMD)`, go back to step 1
 
 ### Convergence Tracking
 
-Maintain a mental (or logged) record each round:
-
-```
-Round 1: 5 failures [test_a, test_b, test_c, test_d, test_e]
-Round 2: 3 failures [test_b, test_d, test_e]          ← progress, continue
-Round 3: 3 failures [test_b, test_d, test_e]          ← same as round 2 (plateau 1/3)
-Round 4: 3 failures [test_b, test_d, test_e]          ← plateau 2/3
-Round 5: 3 failures [test_b, test_d, test_e]          ← plateau 3/3 → STOP
-```
+Track failures each round. Example: 5→3→3→3→3 = plateau at round 3, stop at round 5 (3/3).
 
 **Key rule**: If failures decrease (even by 1), the plateau counter resets to 0.
 

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-lite.md

@@ -20,19 +20,11 @@ When tests fail during implementation, use **convergence-based recovery** — ke
      - **Pre-existing baseline failure**: Expected, do NOT fix
      - **New regression**: Fix the code
      - **Brittle test**: Fix the test or environment setup
-   - Apply fix, re-run `$TEST_CMD`, go back to step 1
+   - Apply fix, re-run `($TEST_CMD)`, go back to step 1
 
 ### Convergence Tracking
 
-Maintain a mental (or logged) record each round:
-
-```
-Round 1: 5 failures [test_a, test_b, test_c, test_d, test_e]
-Round 2: 3 failures [test_b, test_d, test_e]          ← progress, continue
-Round 3: 3 failures [test_b, test_d, test_e]          ← same as round 2 (plateau 1/3)
-Round 4: 3 failures [test_b, test_d, test_e]          ← plateau 2/3
-Round 5: 3 failures [test_b, test_d, test_e]          ← plateau 3/3 → STOP
-```
+Track failures each round. Example: 5→3→3→3→3 = plateau at round 3, stop at round 5 (3/3).
 
 **Key rule**: If failures decrease (even by 1), the plateau counter resets to 0.
 

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.32",
+  "version": "1.1.35",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

package/bundled/skills/bug-planner/SKILL.md

@@ -39,9 +39,18 @@ After planning is complete, you MUST:
 3. If the user wants to adjust → continue refining the bug list
 4. NEVER auto-execute the pipeline, launcher, or any fix step
 
-## When to Use
+## User-Provided Content Priority (Hard Rule)
+
+When the user provides detailed specifications, rules, or implementation requirements:
+
+1. **Verbatim preservation**: The user's exact wording MUST be preserved in `description` and `acceptance_criteria` fields. Do NOT paraphrase, summarize, abstract, or simplify.
+2. **No autonomous simplification**: A 200-word user specification must NOT become a 30-word description. Match the detail level of the user's input.
+3. **Clarify, don't assume**: If any user-provided rule is ambiguous or potentially conflicts with another, ASK the user to clarify. No limit on clarification rounds. Do NOT proceed with unresolved ambiguities.
+4. **Populate `user_context`**: ALL user-provided materials (supplementary content, rules, file path references) MUST be written into the `user_context` array of each bug in the generated `.prizmkit/plans/bug-fix-list.json`. Format:
+   - Supplementary content or rules → store as-is (verbatim text)
+   - File references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
 
-User says:
+## When to Use
 - "plan bug fixes", "report bugs", "create bug list"
 - "generate bug list", "I have some bugs to fix"
 - "these tests are failing", "here's an error log", "parse these errors"
@@ -109,7 +118,9 @@ Gather project metadata from the project's own configuration and documentation
    - If none found, ask the user
 3. **Identify testing framework**: Read from `.prizmkit/config.json` `tech_stack.testing`, or auto-detect from package.json/requirements.txt/etc., or ask user
 4. **Clarify context** — if the project context, affected systems, or bug scope is unclear, ask questions one at a time (cite the unclear point, give a recommended answer with rationale) until you fully understand the environment. No limit on rounds or number of questions.
-5. **Collect reference materials** — before proceeding to bug collection, explicitly ask the user whether they have any supplementary materials for you to review:
+5. **Collect reference materials** — **Upfront Material Detection (Hard Rule)**: If the user has already provided materials (file paths, URLs, rules, specifications, code snippets) in the same message that invoked this skill: (a) Acknowledge what was received: "I received the following materials: [list]"; (b) Read/fetch all provided materials immediately; (c) You MUST still ask: "Are there any additional materials you'd like to provide?"; (d) NEVER skip this collection step just because the user already provided some materials.
+
+   If the user has NOT provided any materials upfront, explicitly ask whether they have any supplementary materials for you to review before proceeding to bug collection:
    > "Do you have any reference materials I should review to better understand these bugs? This can include:
    > - **Code paths** — files or directories where the bugs likely originate
    > - **Documents** — related design docs, API specs, or architecture docs for the affected area

package/bundled/skills/feature-planner/SKILL.md

@@ -47,6 +47,17 @@ The user chose this skill intentionally. Respect that choice.
 3. If the user wants to adjust → continue refining `.prizmkit/plans/feature-list.json`
 4. **NEVER auto-execute** the pipeline, launcher, or any implementation step
 
+## User-Provided Content Priority (Hard Rule)
+
+When the user provides detailed specifications, rules, or implementation requirements:
+
+1. **Verbatim preservation**: The user's exact wording MUST be preserved in `description` and `acceptance_criteria` fields. Do NOT paraphrase, summarize, abstract, or simplify.
+2. **No autonomous simplification**: A 200-word user specification must NOT become a 30-word description. Match the detail level of the user's input.
+3. **Clarify, don't assume**: If any user-provided rule is ambiguous or potentially conflicts with another, ASK the user to clarify. No limit on clarification rounds. Do NOT proceed with unresolved ambiguities.
+4. **Populate `user_context`**: ALL user-provided materials (supplementary content, rules, file path references) MUST be written into the `user_context` array of each feature in the generated `.prizmkit/plans/feature-list.json`. Format:
+   - Supplementary content or rules → store as-is (verbatim text)
+   - File references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
+
 ## When to Use
 
 Trigger this skill for requests like:
@@ -166,7 +177,9 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 ### Interactive Phases
 1. Clarify scope and goals
    1.1 **Requirement clarification** — for ANY unclear aspect of the user's goals or scope, ask questions one at a time (cite the unclear point, give a recommended answer with rationale) until you fully understand. No limit on rounds. Do not proceed to Phase 2 with unresolved ambiguities.
-   1.2 **Collect reference materials** — before proceeding, explicitly ask the user whether they have any supplementary materials for you to review. Present this as a single prompt covering all material types:
+   1.2 **Collect reference materials** — **Upfront Material Detection (Hard Rule)**: If the user has already provided materials (file paths, URLs, rules, specifications, code snippets) in the same message that invoked this skill: (a) Acknowledge what was received: "I received the following materials: [list]"; (b) Read/fetch all provided materials immediately; (c) You MUST still ask: "Are there any additional materials you'd like to provide?"; (d) NEVER skip this collection step just because the user already provided some materials.
+
+   If the user has NOT provided any materials upfront, explicitly ask whether they have any supplementary materials for you to review. Present this as a single prompt covering all material types:
    > "Do you have any reference materials I should review before planning? This can include:
    > - **Code paths** — files or directories I should read to understand existing implementation
    > - **Documents** — design docs, PRDs, API specs, architecture proposals, or internal wiki pages

package/bundled/skills/feature-workflow/SKILL.md

@@ -113,7 +113,13 @@ Ask the user to describe what they want to build. Listen for:
 
 ### Step 1.2: Collect Reference Materials
 
-**Ask the user explicitly** what resources they have. Do NOT skip this step — user-provided materials are far more valuable than blind directory scanning.
+**Upfront Material Detection (Hard Rule)**: If the user has already provided materials (file paths, URLs, rules, specifications, code snippets) in the same message that invoked this skill:
+1. Acknowledge what was received: "I received the following materials: [list]"
+2. Read/fetch all provided materials immediately
+3. You MUST still ask: "Are there any additional materials you'd like to provide?"
+4. NEVER skip this collection step just because the user already provided some materials
+
+**If the user has NOT provided any materials upfront**, ask the user explicitly what resources they have. Do NOT skip this step — user-provided materials are far more valuable than blind directory scanning.
 
 Ask:
 1. **Existing code** — "Is there existing code I should look at? Which files or directories are relevant?"

package/bundled/skills/refactor-planner/SKILL.md

@@ -44,9 +44,18 @@ The user chose this skill intentionally. Respect that choice.
 4. If the user wants to adjust → continue refining `.prizmkit/plans/refactor-list.json`
 5. **NEVER auto-execute** the pipeline, launcher, or any implementation step
 
-## When to Use
+## User-Provided Content Priority (Hard Rule)
+
+When the user provides detailed specifications, rules, or implementation requirements:
+
+1. **Verbatim preservation**: The user's exact wording MUST be preserved in `description` and `acceptance_criteria` fields. Do NOT paraphrase, summarize, abstract, or simplify.
+2. **No autonomous simplification**: A 200-word user specification must NOT become a 30-word description. Match the detail level of the user's input.
+3. **Clarify, don't assume**: If any user-provided rule is ambiguous or potentially conflicts with another, ASK the user to clarify. No limit on clarification rounds. Do NOT proceed with unresolved ambiguities.
+4. **Populate `user_context`**: ALL user-provided materials (supplementary content, rules, file path references) MUST be written into the `user_context` array of each refactor item in the generated `.prizmkit/plans/refactor-list.json`. Format:
+   - Supplementary content or rules → store as-is (verbatim text)
+   - File references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
 
-Trigger this skill for requests like:
+## When to Use
 - "Plan refactoring", "Scope a restructuring"
 - "Prepare .prizmkit/plans/refactor-list.json", "Prepare dev-pipeline input for refactoring"
 - "Assess code for refactoring", "Identify refactoring targets"
@@ -127,7 +136,9 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 2. Read `.prizmkit/config.json` for tech stack info
 3. Identify existing test suite and coverage
 4. Summarize project context to the user: "Here's what I found about your project..."
-5. **Collect reference materials** — before proceeding to goal collection, explicitly ask the user whether they have any supplementary materials for you to review:
+5. **Collect reference materials** — **Upfront Material Detection (Hard Rule)**: If the user has already provided materials (file paths, URLs, rules, specifications, code snippets) in the same message that invoked this skill: (a) Acknowledge what was received: "I received the following materials: [list]"; (b) Read/fetch all provided materials immediately; (c) You MUST still ask: "Are there any additional materials you'd like to provide?"; (d) NEVER skip this collection step just because the user already provided some materials.
+
+   If the user has NOT provided any materials upfront, explicitly ask whether they have any supplementary materials for you to review before planning the refactoring:
    > "Do you have any reference materials I should review before planning the refactoring? This can include:
    > - **Code paths** — specific files or directories that are refactoring targets or dependencies
    > - **Documents** — design docs, architecture proposals, refactoring RFCs, or technical debt analyses

package/bundled/skills/refactor-workflow/SKILL.md

@@ -121,7 +121,13 @@ Then ask:
 
 ### Step 1.2: Collect Reference Materials
 
-**Ask the user explicitly** what resources they have. Do NOT skip this step — user-provided materials are far more valuable than blind directory scanning.
+**Upfront Material Detection (Hard Rule)**: If the user has already provided materials (file paths, URLs, rules, specifications, code snippets) in the same message that invoked this skill:
+1. Acknowledge what was received: "I received the following materials: [list]"
+2. Read/fetch all provided materials immediately
+3. You MUST still ask: "Are there any additional materials you'd like to provide?"
+4. NEVER skip this collection step just because the user already provided some materials
+
+**If the user has NOT provided any materials upfront**, ask the user explicitly what resources they have. Do NOT skip this step — user-provided materials are far more valuable than blind directory scanning.
 
 Ask:
 1. **Code paths** — "Which files or directories are the main targets? Any specific files I should look at?"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.32",
+  "version": "1.1.35",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {