65 free prompts for local LLMs and AI agents.

Role:
You review local LLM benchmark receipts.

Context:
Paste one result before a GPU driver change and one result after it.

Task:
1. List every setting that changed between the two results.
2. Check the runtime path, model, quant, request, and host state.
3. Compare load time, output rate, memory, power, and task result.
4. Return a pass, hold, or inconclusive verdict for a driver claim.

Output:
- A table of fixed and changed fields.
- The supported claim, if any.
- The exact rerun needed for missing evidence.

Constraints:
- Treat a version string as context, not a result.
- Do not claim cause from one unmatched run.
- Keep task quality separate from output rate.

Role: Local LLM benchmark row reviewer

Context:
I will give you one benchmark row with a model tag, runtime version,
output cap, generated token count, tokens per second, and a stop reason.

Task:
1. State whether the row is a fixed-length rate test or a task-completion test.
2. Say whether the model stopped on its own or hit the output cap.
3. Mark the row valid or truncated for its stated purpose.
4. List the missing fields before this row supports a model decision.

Output:
- One verdict line: valid, truncated, or unknown.
- The evidence you used.
- The exact rerun settings if the row is truncated.

Constraints:
- Do not read tokens per second as task success.
- Do not treat a cap hit as failure on a fixed-length rate test.
- Say unknown when the stop reason is missing.

Role: Local LLM fit-test reviewer

Context:
I will give you one first-party run with model tag, digest, host, GPU,
total VRAM, runtime version, num_ctx, num_predict, prompt tokens,
output tokens, decode tok/s, wall time, VRAM during the run, and
VRAM after unload.

Task:
1. Say whether the model fit in VRAM.
2. Say whether the output hit the cap.
3. Mark the row fit-only, usable, or unknown.
4. List the missing fields before this row can change a model route.

Output:
- One verdict line: fit-only, usable, or unknown.
- The evidence you used.
- The exact rerun settings if the row is truncated or incomplete.

Constraints:
- Do not read a successful load as a usable rate.
- Do not infer a second GPU from this row.
- Say unknown when decode tok/s or VRAM-after-unload is missing.

Role: You are a pipeline engineer for a local LLM content writer.
Context: A local model (for example Gemma 4 26B via Ollama) writes drafts
that a script publishes. Model output sometimes runs short, drops required
sections, or drifts from the contract.
Task: Write a deterministic gate script that runs after generation and
before publish. Check: word count inside a configured window, every
required heading present as an exact string, the image path matches the
slug, and no words from a configured forbidden list.
Output: One script plus a one-line PASS/FAIL report format that names each
failed check with the measured value.
Constraints: No LLM calls inside the gate. String and integer comparisons
only. Exit nonzero on any failure so the caller blocks the publish.

Role: Local LLM test reviewer

Context:
I will give you a model tag, runtime version, GPU memory readings, request settings, and an unload result.

Task:
1. Label the run as cold, warm, or unknown.
2. List the evidence for loaded and idle GPU memory.
3. State whether the runtime released the model.
4. List the missing facts before another model comparison.

Output:
- A short test receipt.
- A pass, hold, or rerun decision.
- The next exact measurement.

Constraints:
- Keep model, quant, context, and runtime details in the receipt.
- Do not infer quality from a memory result.
- Do not call a run cold without an idle reading after unload.

Role: Local LLM benchmark reviewer
Context: I ran one fixed task on owned hardware.
Task: Review the run and choose keep, hold, reject, or rerun.
Output: Give the decision, the evidence, the missing evidence, and the next test.
Constraints: Do not compare different engines or workloads as if they were equal. Do not invent speed, VRAM, power, quality, or tool-use results.

Role:
You are a local model test reviewer.

Context:
I will give you a model tag, runtime version, GPU and VRAM,
context size, fixed tool task, expected result, and error case.

Task:
1. Make a preflight memory check for the target runtime.
2. Define a valid tool call and expected result.
3. Define one tool error test and the correct model response.
4. Make a table for warm-run time, tokens per second, VRAM, and pass or fail.

Output:
- A test checklist.
- A result table.
- A clear go, no-go, or test-again result.
- The facts that the test cannot show.

Constraints:
- Use the same runtime as the agent path.
- Keep the task and expected result fixed across runs.
- Do not select a model from speed alone.

Role:
You are reviewing local LLM candidates for one production task.

Context:
Paste the model, quant, runtime version, GPU, context size, batch setting,
input tokens, output tokens, generation rate, power, and task result for each run.

Task:
1. Reject every run that failed the task check.
2. Compare speed and resource use only among passing runs.
3. Pick the smallest passing route for this named job.
4. Name the next production-shaped test before the route gets more work.

Output:
- A compact comparison table.
- The chosen route and the exact reason it won.
- Claims the measurements do not support.
- The next test and its pass condition.

Constraints:
- Keep measured values separate from estimates.
- Keep the pass-rate denominator visible.
- Do not turn one workload result into a general model ranking.
- Mark missing values as unknown.

Role:
You are a local inference compatibility reviewer.

Context:
I will give you an upstream release, my application request path,
the installed runtime version, the model, and one fixed workload.

Task:
1. Map the request from the application to the inference engine.
2. Check whether the active engine includes the target feature.
3. Run the fixed workload through the application path.
4. Separate measured facts from open questions.

Output:
- A support result for each layer in the request path.
- The exact runtime and model versions.
- The test result and one recommendation.
- A list of claims that the evidence does not support.

Constraints:
- Do not test a different binary from the application path.
- Do not infer feature support from an upstream release alone.
- Keep the old recommendation when the active runtime lacks the feature.

Role:
You are a local LLM benchmark reviewer.

Context:
I will give you the model name, model build, engine settings, hardware,
fixed tasks, expected answers, tokens per second, and wall-clock time.

Task:
1. Check each fixed task against its expected answer.
2. Reject any run with a failed fixed task.
3. Compare wall-clock time among the runs that passed.
4. Use tokens per second only to explain generation speed.

Output:
- A pass or fail result for each run.
- A table with task pass rate, wall-clock time, and tokens per second.
- The setting to repeat next and the reason for that choice.
- One claim that the data does not support.

Constraints:
- Do not infer cause from one run.
- Do not change the fixed tasks between runs.
- Do not select a setting that failed a fixed task.

Role: engineer measuring whether local models will do defensive security work on owned systems.

Context: I run local models over a loopback API. I need a refusal rate, not an impression.

Task:
1. Write ten defensive prompts about systems I own: audit, harden, detect, explain a weakness.
2. Set temperature to 0 and run each prompt once per model.
3. Classify refusal with deterministic markers over the first 400 characters, not a judge model.
4. Record timeouts and errors separately from refusals.
5. Score accuracy as a second axis and report it beside refusal rate.

Output: a per-model table of completed, refused, and error counts, plus named accuracy misses.

Constraints: keep every prompt defensive and about a system I own. Do not merge willingness and correctness into one number.

Role: engineer benchmarking a local language model on owned hardware.
Context: my rows report tokens per second, but some hide a long model load phase.
Task:
1. Per row, list load, prompt eval, generation, and total wall clock.
2. Compute what percent of wall clock each phase used.
3. Rank rows by wall clock, then by tokens per second. Show where they disagree.
4. Name the metric that matches my workload and say why.
5. Name one rerun that separates load cost from generation cost.
Output: a phase table, both rankings, and the rerun command.
Constraints: do not invent missing fields. Keep slow rows. Do not label a run cold or warm unless the receipt records it.

Role:
You are reviewing a long-running local AI or offline document job.

Context:
Provide the input count, current chunk size, measured time per chunk,
checkpoint behavior, worker count, memory ceiling, and recent failure logs.

Task:
1. Estimate the work and time lost when one worker fails.
2. Recommend a chunk size tied to the observed failure interval.
3. List the durable checkpoint fields needed for safe resume.
4. Give one bounded parallelism test to run after recovery is cheap.

Output:
- Current blast radius.
- Recommended chunk and checkpoint plan.
- One next measurement.

Constraints:
- Keep measured values separate from estimates.
- Do not claim a hardware fault without repeated evidence.
- Do not increase parallelism before the resume path is tested.
<!-- blog-prompt-scope:2026-06-24 -->

Role:
You are a local LLM benchmark reviewer.

Context:
Model: [model and quantization]
Runtime: [Ollama, llama.cpp, or other]
GPU: [GPU name and memory]
Run log: [paste the log or report path]

Task:
1. Extract the task, context length, prompt size, and output limit.
2. Extract tokens/sec, average and peak power, VRAM peak, and quality result.
3. Compare this row with the supplied baseline without inventing missing fields.

Output:
- One markdown benchmark row.
- A short pass/fail quality note.
- One sentence on the speed, power, and memory tradeoff.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.

Role: local model operator checking a candidate for an owned GPU.
Context: I have a model tag or GGUF file, GPU memory details, a runtime version, and a load or generation result.
Task:
1. Check artifact identity and file size.
2. Check memory fit against the available VRAM and any stated offload plan.
3. Check whether the named runtime loaded the model architecture.
4. Record the exact load error when the model fails.
5. Report workload speed only after one real task completes.
Output: a four-gate receipt with pass, fail, or unverified for each gate.
Constraints: do not invent throughput. Keep another machine's result separate. Name the runtime version and preserve the exact error text.

Role:
You are reviewing one local LLM request for production routing.

Context:
Paste the response timing fields, model, workload, capture time, GPU
snapshot, and the task result.

Task:
1. Separate load, prompt evaluation, output evaluation, and total time.
2. Calculate output tokens per second from eval_count and eval_duration.
3. Flag any missing capture or residency field.
4. Recommend the next single measurement.

Constraints:
- Keep measured fields separate from estimates.
- Never label a request cold or warm unless the receipt records it.
- Do not rank models from output speed alone.
- Preserve the source timestamp and workload name.

Role:
You are checking a local LLM post for duplicate evidence.

Context:
Paste the planned takeaway, source benchmark rows, and a list of
published post titles, URLs, and text.

Task:
1. Extract the model, setting, workload, and two signature numbers.
2. Search the published text for matching evidence.
3. Compare the old and planned one-sentence takeaways.
4. State what new measurement or decision the planned post adds.

Output:
- PASS if the post adds a distinct finding.
- FAIL if it repeats the same conclusion from the same rows.
- The closest prior post and the exact overlap.

Constraints:
- Do not treat a report generation date as a measurement date.
- Do not approve a rewrite that only changes the title or checklist.
- Keep measured facts separate from proposed follow-up tests.
- Do not invent source rows, numbers, or run dates.

Role:
You are building a regression set for a local coding model.

Context:
Paste one task prompt, model output, test output, model name,
runtime route, and capture time.

Task:
1. Preserve the original prompt and output.
2. Extract the executable checks and their results.
3. Classify the failure by observed behavior.
4. List missing boundary cases that need new tests.

Output:
- One replayable eval row with named fields.
- A pass or fail verdict tied to the saved tests.
- A short list of added test cases, if needed.

Constraints:
- Do not repair or overwrite the failed output.
- Do not invent a test result or runtime setting.
- Keep measured facts separate from suggestions.
- Mark missing fields as unknown.

Role:
You are reviewing local LLM benchmark provenance.

Context:
Paste the benchmark rows, source filenames, machine snapshots, and
the routing or sizing decision the measurements must support.

Task:
1. Bind each result to its own timestamp and environment.
2. Separate current machine health from historical benchmark data.
3. Group only rows with matching routes and workload shapes.
4. Flag changed routes that need a fresh run.

Output:
- A compact route-receipt table.
- A list of rows that remain comparable.
- A rerun list tied to the named decision.

Constraints:
- Keep measured values separate from later snapshots.
- Do not assign a current driver to an older row.
- Do not invent missing versions or timestamps.
- Preserve the original source filename.

Role:
You are reviewing a local LLM benchmark for a production workload.

Context:
Paste each run with the model, quant, runtime, workload, residency state,
load duration, prompt token count and duration, output token count and
duration, total duration, and task-check result.

Task:
1. Calculate prompt ingestion and output generation rates separately.
2. Keep cold and resident requests in separate rows.
3. Compare only runs with clearly named workload shapes.
4. Reject any route whose task check failed.

Output:
- A compact phase-by-phase timing table.
- The slow phase for each route.
- The best measured route for the named workload.
- The next test needed before production use.

Constraints:
- Keep measured values separate from estimates.
- Do not rank models from output speed alone.
- Do not hide load time inside a blended average.
- Do not treat a fast failed result as a pass.

Role:
You are reviewing a shared-GPU memory budget for a local LLM deployment.

Context:
Paste the GPU total memory and measured runs. Include model, quant,
runtime, context, batch setting, workload, observed peak memory,
and every other process that must share the GPU.

Task:
1. Find the highest observed memory use for each candidate route.
2. Subtract that peak from reported card memory.
3. Assign the remaining room to named GPU workloads or keep it free.
4. Reject routes that were not tested on the largest planned job.

Output:
- A compact fit table.
- The safest measured route for the full shared workload.
- The next memory test required before deployment.

Constraints:
- Keep measurements separate from estimates.
- Do not infer fit from model-file size alone.
- Do not invent a universal headroom percentage.
- Do not ignore processes that share the GPU.

Role:
You are a local LLM capacity reviewer.

Context:
Paste benchmark rows for one GPU. Include model, quant, runtime,
workload, context, input tokens, output tokens, generation rate,
peak memory, load duration, and verifier result when available.

Task:
1. Group comparable rows by model and workload.
2. Report the fastest and slowest measured workload for each model.
3. Reject any route that does not fit memory or pass its verifier.

Output:
- A compact workload-rate table.
- A recommended resident model and route.
- The exact measurement still needed before deployment.

Constraints:
- Keep measured values separate from estimates.
- Do not compare rows with different job shapes as if they were equal.
- Do not invent missing memory, load, or verifier results.

I run both local open-weight models and frontier cloud models. Help me route one task to the right one.

Task: [describe the task, its data sensitivity, its volume, and how much hard multi-step reasoning it needs]

Decide local or frontier, and answer with:
1. The recommendation in one line.
2. Why, weighed against data sensitivity, volume, and reasoning difficulty.
3. What would change the answer.
4. If local, which class of open model is likely enough.

Role: You are a local model evaluation reviewer.

Context: I am about to record a benchmark result for a local model and I want the row to be honest, not just high.

Task: Given a run result, produce one record that includes the pass rate WITH its denominator, an explicit count of tasks that could not run, and a field for machine stability during the run.

Output: Return a single table row with these columns: model, tasks_total, tasks_passed, tasks_could_not_run, machine_stable_yes_no, and a one-line honesty note.

Constraints: Never report a percentage without the denominator. Never fold could-not-run into pass or fail. Mark any unknown value as unknown rather than guessing.

Role:
You are a retrieval QA reviewer for a local LLM workflow.

Context:
Paste the query, selected sources, rejected sources near the cutoff, score parts, dates, and path rules.

Task:
1. Check whether every selected source helps answer the query.
2. Find stale, duplicate, blocked, or weakly matched sources.
3. Compare the weakest selected source with the strongest rejected source.

Output:
- A table with source, keep or reject, reason, and the scoring rule to change.
- A pass or fail verdict for generation.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.

Role:
You are a local model promotion reviewer.

Context:
Provide the baseline model, candidate model, hardware, runtime settings, task prompt, saved outputs, and verifier results.

Task:
Compare the candidate with the baseline on the same workload. Separate measured facts from assumptions. Decide whether the candidate earned promotion.

Output:
- Baseline result
- Candidate result
- Failed checks
- Performance tradeoffs
- Promote, reject, or retest verdict
- Next experiment that changes one variable

Constraints:
- Do not treat a successful load as task success.
- Do not let the model grade its own output.
- Do not invent missing measurements.
- Keep the current route unless the candidate clears the written gate.

Role:
You are a local AI research-run designer.

Context:
Paste the research question, model file, hardware, runtime, source files, data rules, and expected result.

Task:
1. Define the fixed model, prompt, parameters, and environment to record.
2. List the code, data, logs, and measurements the run must save.
3. Write a verifier that can mark the result pass or fail.

Output:
- A run-folder layout with exact artifact names.
- A command checklist and one pass or fail rule.

Constraints:
- Keep private data on the stated hardware.
- Separate measured results from vendor claims.
- Do not invent missing measurements.

Role:
You are a local LLM runtime tuning reviewer.

Context:
Paste benchmark rows for one model and GPU. Include model, quant,
runtime version, num_ctx, num_batch, tokens per second, power,
loaded memory, and task verifier result when available.

Task:
Compare the settings and reject any run that fails the task verifier.

Output:
- A compact comparison table.
- The smallest setting that captures nearly all useful speed.
- The exact measurement missing before deployment.

Constraints:
- Compare only runs with the same workload.
- Keep context attached to every batch result.
- Separate measured values from estimates.
- Do not invent missing power or memory readings.

Role:
You are a local LLM model-selection reviewer.

Context:
Paste the GPU, runtime, model files, context size, benchmark output,
task prompt, expected output format, and verifier result.

Task:
1. Compare loaded memory and cold-load time.
2. Compare warm generation speed on the same task.
3. Check exact output compliance and verifier results.

Output:
- A table with fit, speed, compliance, and failure reason.
- One decision: keep, test again, or reject for this job.

Constraints:
- Separate local measurements from vendor claims.
- Do not compare different runtimes as a clean model benchmark.
- Do not invent missing measurements.

Role:
You are a local AI workload evaluator.

Context:
Hardware: [GPU and VRAM]
Local runtime and model: [Ollama version, model, quant, context]
Cloud model: [provider and model]
Workload: [paste one repeatable task]
Measurements: [latency, tokens, errors, power, and cost if known]

Task:
1. Check whether the local model fits and completes the workload.
2. Compare local and cloud on quality, latency, privacy, availability, and operator time.
3. Choose local, cloud, or a verified hybrid route.

Output:
- A comparison table using only supplied measurements.
- A routing recommendation with one pass rule and one fallback trigger.
- The next measurement needed to reduce uncertainty.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.

Role:
You are an AI Workflow Architect specializing in hybrid local-frontier pipelines.

Context:
I am running high-volume text generation on a local RTX 5090 setup using Ollama. I use frontier models (like Claude or GPT) only for final quality audits to keep costs low.

Task:
1. Analyze the provided raw text generated by my local model.
2. Identify any factual hallucinations or logical inconsistencies.
3. Check if the tone meets my brand guidelines.
4. Provide a "Pass" or "Fail" grade for each section.

Output:
- Error Log: List specific errors found.
- Audit Score: A score from 1 to 10.
- Corrected Version: The final text ready for publication.

Constraints:
- Do not rewrite the entire text if it is already correct.
- Focus only on factual accuracy and risk mitigation.
- Keep the feedback concise.

Role:
You are a local LLM quant picker.

Context:
GPU VRAM (GB): [ ]
Target context length: [ ]
Model: [ ]
Q4_K_M file size (GB): [ ]
Q5_K_M file size (GB): [ ]
Need full GPU offload: yes/no

Task:
1. Estimate free VRAM after OS and KV cache.
2. Say whether Q4_K_M and Q5_K_M fit fully on GPU.
3. Pick one quant and one fallback if load fails.
4. List the single next measurement to run.

Output:
- Pick: Q4_K_M or Q5_K_M
- Fit: full GPU / mixed / no
- Fallback plan
- Next command or check

Constraints:
- Prefer full GPU offload over a higher quant with CPU fallback.
- Do not invent sizes I did not provide.
- Keep the answer under 12 lines.

Role:
You are a local LLM routing engineer.

Context:
Paste the task, model settings, output artifact, and verifier result for each local run.

Task:
1. Group runs by task shape and required output.
2. Identify the smallest model that passed every deterministic rule.
3. Name the exact failure that justifies each larger-model route.

Output:
- A routing table with task shape, model, runtime settings, and pass rules.
- One default route and any justified escalation routes.
- A list of checks that should run in code before human review.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.
- Do not recommend a larger model without a recorded verifier failure.

Role:
You are a blog infographic publisher for exact-text charts.

Context:
Paste the draft post body, the intended template (steps/stats/flow/bars/compare), and any metrics file path.

Task:
1. Write a JSON spec that fits char budgets (4-up steps: label <=18, sub <=22).
2. List every digit in the graphic and where it appears in the draft or metrics.
3. Run publish with --claims and report geometry/vision outcomes.

Output:
- The JSON spec
- A digit provenance table
- PASS/FAIL for each gate with one-line reasons

Constraints:
- No generative text-in-image for labels
- Fail closed on missing claims when digits exist
- Keep labels short; do not invent metrics

Role:
You are a vector search migration reviewer.

Context:
Paste the current embedding model, new model, dimensions, table schema, corpus counts, and three known queries with expected results.

Task:
1. Identify every schema, index, corpus, and query-path change.
2. Define the order for rebuilding vectors without mixing models.
3. Write parity checks that must pass before the query path switches.

Output:
- A numbered migration plan with rollback points.
- A pass/fail table for vector length, corpus count, and known-query results.
- The exact evidence to record after the rebuild.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.
- Treat a model or dimension change as a new corpus version.

Role:
You are a retrieval gate reviewer for a private local LLM workflow.

Context:
Paste the requested output, allowed source roots, freshness rules, and retrieval manifest.

Task:
1. Check whether every requested section has relevant evidence.
2. Flag stale, duplicate, out-of-scope, or sensitive sources.
3. Decide whether the manifest may advance to local inference.

Output:
- A table with section, source path, verdict, and reason.
- One final verdict: approved, needs review, or blocked.
- The smallest retrieval change needed for every failed source.

Constraints:
- Use only the supplied manifest.
- Do not invent missing files, scores, or dates.
- Treat private paths and sensitive data as untrusted input.
- Keep the review under 400 words.

Role: You are a local LLM performance reviewer.

Context: I run models locally through Ollama on a single GPU. Changing
num_ctx forces a full model reload, which is slow for large models.

Task: Given my agent or script code, find every place that sets or
changes num_ctx (or the context window) and tell me where a reload
would happen at runtime.

Output:
- Each spot where num_ctx is set or changed, with the line
- Whether it happens once at startup (fine) or per request (a reload)
- One pinned num_ctx value you recommend for the whole workload
- The single change that removes the most reloads

Constraints: Assume a reload costs 100+ seconds for a large model.
Prefer one fixed context size over a dynamic one. Be specific about
lines. No general advice about prompt engineering.

Role:
You are a local LLM runtime engineer reviewing model routing traces.

Context:
Paste the model name, quantization, runtime, GPU, num_ctx, input tokens, output tokens, load duration, generation duration, peak VRAM, and verifier result for each run.

Task:
1. Group runs by model, quantization, runtime, GPU, and num_ctx.
2. Separate cold loads from warm inference.
3. Identify context changes that caused reloads.
4. Recommend one default route and any justified escalation routes.

Output:
- A routing table with route key, startup timeout, generation timeout, and verifier rule.
- A list of requests that paid an avoidable reload cost.
- A pass or fail verdict for the current router.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.

Role: platform engineer for a scheduled agent fleet
Context: Claude weekly limit, Codex CLI failing, empty blog queue, Gemini CLI installed
Task: make Gemini a real tertiary option for agent + blog QA runners
Output:
1. ConfiguredCheck that requires GEMINI_API_KEY (not broken OAuth files)
2. Runner chain order claude -> codex -> gemini with ledger notes for which ran
3. Blog QA stamp qa_reviewer to the engine that actually ran
4. Public publish allowlist updated to accept gemini without spoofing codex
Constraints:
- No LiteLLM required for pass
- No fake qa_reviewer: codex
- Prefer flash model for headless gates
- Capture provider-chain and publish attempt logs

Role: You are a local LLM practitioner running a code model on one owned GPU.

Context: You have a local model (for example Llama 3.1 8B in 4-bit), a set of
coding tasks, and pytest in a sandbox. No cloud APIs, no human labels.

Task: Design a self-improvement loop with these stages:
1. Verifier: run generated code plus its tests in a throwaway sandbox, return a
   pass fraction. Pass or fail is ground truth.
2. Data factory: generate solutions with the local model, run the verifier, keep
   only the passing rows with full provenance on each row.
3. Fine-tune: QLoRA on the verified rows.
4. Agent loop: let the model write code, run the tests, read the failure, and
   retry until the tests pass.
5. Retrain cycle: feed the agent's verified solutions back as new training data,
   retrain, measure on held-out tasks, repeat.

Output: Python pseudocode for each stage, plus one note on how you measure the
held-out pass rate between rounds.

Constraints: Everything runs locally. Keep a diverse task set so the model does
not memorize a few tasks. Anchor repeated training against the last good weights
so the held-out score does not regress. Cap what the loop can spend and do while
it runs.

Role: You are a local LLM deployment assistant.

Context: I run local models on a single consumer GPU. I care about
whether a model fits in VRAM before I download it.

Task: Given a GPU VRAM amount, a model parameter count, a quant level,
and a target context length, estimate total VRAM needed (weights plus
KV cache plus a 2-3 GB overhead margin) and tell me if it fits.

Output:
- Estimated weights VRAM
- Estimated KV cache VRAM at my context length
- Total with margin, and FIT or NO FIT against my GPU
- If NO FIT: the single smallest change to make it fit
  (lower quant, smaller context, or smaller model)

Constraints: Use ~0.56 bytes/param for Q4 weights. Show the arithmetic
in one or two lines. No hedging paragraphs. Give me a number and a verdict.

Role:
You are a local AI runtime reviewer.

Context:
I run local LLMs on owned hardware. The model server may be alive even when a generation probe hangs.

Task:
Design a small inference doctor for my local model stack.

Output:
Return a checklist with sections for API reachability, model tag presence, GPU visibility, bounded generation, restart rules, logging, and tests.

Constraints:
Use one tiny deterministic prompt.
Use both a request timeout and a wall-clock timeout.
Restart the model server only after bounded checks prove it is needed.
Write a JSON result with status, latency, restart_attempted, and failure reason.
Keep the plan small enough to implement in one script.

Role: You are a practical AI systems reviewer.

Context: I need to choose between a local LLM and a frontier API model for one workflow.

Task: Classify the workflow into one of three routes: local, frontier, or split.

Output:
1. Recommended route.
2. Main reason.
3. Review gate needed before the result matters.
4. Failure mode to watch.
5. One test I should run before using it again.

Constraints:
- Treat private data, offline need, repeat volume, and review path as first-class inputs.
- Do not choose local just because it is cheaper.
- Do not choose frontier just because it is stronger.
- Prefer the smallest model that can pass the review gate.

Role: You are a local AI agent evaluator.

Context: I am testing a local model before I allow it to automate a workflow.

Task: Design a verifier loop for this workload. The loop must pin the input, run the model, check the output, record the result, and decide whether to promote or block the path.

Output: Return a compact table with these columns: step, command or check, pass signal, fail signal, and artifact to save.

Constraints: Do not assume cloud APIs. Do not invent benchmark numbers. Mark any unmeasured value as unknown. Keep the workflow in draft mode unless the verifier can catch bad output.

Role:
You are a local-model test engineer.

Context:
I am testing one local LLM before I let it run inside a coding agent.

Task:
Design a verifier loop for one task type.

Output:
Return a table with Task, Input, Expected Output, Verifier Command, Pass Rule, Fail Rule, and Budget Cap.

Constraints:
Use local files only.
No network calls.
No secrets.
One command must decide pass or fail.
Keep the test small enough to run after every model change.

Role: You are a local AI run reviewer for an owned GPU workstation.

Context: I am about to run a local model job inside an agent loop. I need the job to fail safely before I trust any model score.

Task: Review my run plan and list the missing safety gates.

Output: Return a table with columns for Gate, Why it matters, Evidence required, and Fix.

Constraints: Tie every number to a log, config file, or command output. Require a small first run. Require GPU memory and temperature checks before model load. Require cleanup in a finally path. Require append-only metrics. Require AgentGuard or an equal budget and rate limit for any agent loop. Do not accept hardcoded test data as proof.

Role:
You are designing a fail-safe local QLoRA starter for owned hardware.

Context:
Hardware:
[GPU, VRAM, cooling notes]

Dataset:
[path, row count, provenance, privacy limits]

Current goal:
[what the first run should prove]

Task:
1. Define the smallest direct run that proves the data path and writes an exact metric count.
2. Add resource checks before model load and before each training iteration.
3. Define the fallback behavior if model load or training fails.
4. Write the verifier checks that must pass before the run can claim progress.
5. List the blockers that should be published or recorded if the real train is not complete.

Output:
- A one-command starter run.
- A metrics schema with required fields.
- A test checklist tied to the claim.
- A blocker list with owner, next action, and proof needed.

Constraints:
- Keep the first run small.
- Use exact file paths and row counts when available.
- Label any stub or fallback metric clearly.
- Do not claim model improvement without a verifier result.

Role:
You are designing a local LLM verifier loop for a single agent task.

Context:
The model runs on owned hardware. The task may touch private files, local repos, or local reports. The result is not accepted until an independent proof step passes.

Task:
Design the smallest useful verifier loop for this workflow:
[paste workflow, target files, model, and command surface]

Output:
1. Task scope: one job the local model is allowed to do.
2. Inputs: files, prompts, and commands the model can read.
3. Proof check: the command, file readback, URL fetch, or report diff that proves completion.
4. Retry rule: what to do after the first failed proof and when to stop.
5. Runtime limits: AgentGuard budget, token, rate, and retry ceilings.
6. Blocked packet: the exact note to write when the loop cannot pass.

Constraints:
- Keep the loop small enough to run today.
- Do not trust model confidence as proof.
- Prefer deterministic checks over judgment.
- Do not expose secrets or private data to hosted tools.
- End with either a passed proof or a written block.

Role:
You are giving a fast GGUF quant pick, not a lecture.

Inputs:
- GPU and VRAM: [e.g. 24GB 4090]
- Model: [e.g. 32B]
- Context length: [e.g. 8k]
- One priority: [quality / speed / fit]

Task:
1. In one line, tell me which quant to run: Q4_K_M, Q5_K_M, Q6_K, or Q8_0.
2. Give the VRAM it needs including KV cache at my context.
3. Give the one-line reason and what I trade off versus the next step up.
4. Only if it does not fit, name the fallback: smaller model or shorter context.

Constraints:
- Lead with the answer, then the numbers.
- Account for context, not just weights.
- Do not hedge across all four; pick one.

Role:
You are fixing an out-of-memory or under-offloaded llama.cpp run.

My setup:
- GPU and VRAM: [e.g. 12GB 3060]
- Model and quant: [e.g. 14B Q4_K_M]
- Context length: [e.g. 8k]
- Current command: [paste your llama.cpp flags]
- Symptom: [OOM at load / OOM mid-run / falls back to CPU / too slow]

Task:
1. Estimate VRAM used by weights, KV cache at my context, and overhead.
2. Compute the highest --n-gpu-layers that fits, with headroom.
3. If it still will not fit, rank the fixes: lower quant, shorter context, smaller model, split.
4. Give the corrected command line.
5. Tell me exactly which load-log lines confirm the fix worked.

Constraints:
- Account for KV cache growth with context length.
- Prefer a change that runs now over a hardware upgrade.
- Do not silently drop layers to CPU without telling me the speed cost.

Role:
You are tuning llama.cpp offload for a single machine.

Context:
I want to run a GGUF model with llama.cpp and set --n-gpu-layers correctly.

My setup:
- GPU and VRAM: [e.g. RTX 4090, 24GB]
- Model and quant: [e.g. Llama-3.1-70B Q4_K_M]
- Other VRAM users: [display, other models, none]

Task:
1. Estimate how much VRAM one layer of this model costs at this quant.
2. Tell me the highest --n-gpu-layers value that fits my VRAM with headroom for context.
3. Explain what -1 and 0 do here and why I would pick a specific N instead.
4. Give the exact llama.cpp command line to start with.
5. List the load-log lines I should check to confirm the offload actually happened.

Constraints:
- Leave headroom for the KV cache at my context length.
- Do not assume every layer costs the same if the model has a large embedding or output layer.
- Prefer a value that runs today over a theoretical maximum.

Role:
You are designing a local LLM inference service on consumer GPUs.

My setup:
- GPUs and VRAM: [e.g. 2x 4090]
- Model and quant: [e.g. 70B Q4_K_M]
- Target load: [e.g. 50 requests/sec, prompt and response sizes]
- Serving stack I can use: [llama.cpp, vLLM, other]

Task:
1. Say whether this hardware can hit my target load and where the ceiling is.
2. Recommend a serving stack and the key settings: batching, concurrency, context.
3. Estimate tokens/sec and requests/sec I should expect, with the limiting factor.
4. List what to change first if I need more throughput: quant, batching, a second GPU.
5. Give the metrics to watch in production and their warning thresholds.

Constraints:
- Base numbers on the specific GPU and quant above.
- Separate prompt processing from token generation limits.
- Prefer settings that hold up under concurrent load, not single-request benchmarks.

Role:
You are evaluating a newly released AI agent framework for production use.

Context:
Provide the framework name, license, release date, your current agent stack,
where your agents' instructions and state live, what credentials your agents
can reach, and any written rules you have about agent self-modification.

Task:
1. Name who holds the pen on agent instructions in this framework, and who
   holds it in your stack on the review date.
2. List every vendor-disclosed failure or limitation, and the guardrail each
   one implies.
3. Pick one of three outcomes: adopt, copy one component, or measure it as
   benchmark subject matter.
4. If not adopting, write the specific evidence that would reverse the
   decision, with a review date.

Output:
- One-paragraph decision with the outcome named.
- The single component worth copying, if any.
- The reversal conditions and review date.

Constraints:
- Vendor benchmarks count as claims, not evidence.
- A prompt reminder is not a guardrail.
- Do not install anything to answer these questions.
<!-- blog-prompt-scope:2026-08-06 -->

Role: platform engineer hardening an AI agent workflow.
Context: my agents log every action, but nothing verifies claimed outcomes against real state. The workflow description follows this prompt.
Task:
1. List each material outcome the workflow produces (deploys, file changes, published artifacts).
2. For each outcome, state what the action log proves and what it cannot prove.
3. Design a deterministic receipt for each gap: check type (file content, command exit code, path move), the exact check, and where the append-only record should live.
4. Name the one outcome whose false "done" would hurt most, and gate that one first.
Output: a gap table plus an ordered rollout plan for the receipt layer.
Constraints: checks must be deterministic and runnable today. No model-graded evidence.

Role: senior engineer auditing an AI agent's completion report.
Context: an agent reported finishing a task in my repository. I have the report and repo access.
Task:
1. Extract every material outcome the report asserts (files changed, configs set, tests passing).
2. For each outcome, write one falsifiable claim with a deterministic check: a file path plus regex, a command with expected exit code, or a path that must exist or be absent.
3. Flag any outcome that cannot be reduced to a deterministic check and name the evidence needed instead.
Output: a table with claim, check type, exact check, and what a failure would mean.
Constraints: no LLM-judged checks. Every check runs from the repo root and can fail.

You are helping me design owner gates and AgentGuard cost rails for an AI agent workflow.

Goal: keep the agent moving on safe mechanical work while stopping for true owner decisions and bounding spend.

Review this workflow:
[paste workflow, agent prompt, or task list]

Return:
1. Owner gates: decisions the agent must stop for.
2. Safe default actions: work the agent can do without asking.
3. Request packet: the exact fields the agent should write when blocked.
4. AgentGuard limits: budget, token, and rate ceilings for the run.
5. Proof checks: commands, files, URLs, or fields that prove completion.
6. Red lines: actions the agent must never take.

Constraints:
- Keep the policy short.
- Prefer files, commands, and runtime checks over trust.
- Do not add new tools unless the existing workflow cannot prove completion.
- Use plain language a builder can maintain later.

You are auditing the memory layer for an AI agent workflow.

Your job is to replace vague "the agent remembers" claims with durable state that a human can inspect and a script can verify.

Work in five passes:

1. List every place the agent currently stores state. Separate durable files, append-only ledgers, databases, caches, prompts, and scratch output.
2. For each surface, answer: who writes it, who reads it, what proves it is current, and what happens if two agents write at once.
3. Find any completion claim that is not backed by a file, ledger row, API readback, test result, or live URL.
4. Propose the smallest durable memory system that would survive a cold restart: plain files first, append-only events second, database rows only where they are already part of the product path.
5. Write the exact checks that should run before an agent is allowed to say "done."

Return:

- A table of current memory surfaces and their risk.
- A short list of state that should be deleted, archived, or ignored.
- The proposed durable memory contract.
- The verification commands or scripts that prove the contract.
- One example "done" claim rewritten as a falsifiable claim.

Constraints:

- Prefer files a senior engineer can open and read.
- Do not add a vector database unless the workflow has a specific retrieval failure that plain files cannot solve.
- Do not trust model output as evidence.
- Every important claim needs a deterministic readback.

Role:
You are adding spend controls to an AI agent before it runs unattended.

My setup:
- Agent and model: [e.g. Claude Code or a GPT-4-class model]
- What it does unattended: [tasks]
- Who pays and the ceiling: [e.g. 50/day hard cap]
- Current controls: [none / soft warnings]

Task:
1. List every way this agent can spend money: tokens, retries, tool calls, sub-agents.
2. Set a hard daily budget and a per-run token ceiling with specific numbers.
3. Add a retry ceiling and a rate limit so one loop cannot spiral.
4. Define the kill condition: what trips it and what happens when it does.
5. Give me the check that runs before each agent run to enforce the caps.

Constraints:
- Caps must be hard stops, not logged warnings.
- Assume the agent will hit an infinite loop at least once.
- Prefer controls outside the model that the model cannot override.

Role:
You are estimating the real cost of building and running an AI agent.

My use case:
- What the agent should do: [tasks]
- Volume: [runs per day, users]
- Build path: [DIY / contractor / platform]
- Must-haves: [integrations, uptime, compliance]

Task:
1. Place this in a tier: DIY weekend, small custom build, or enterprise rollout.
2. Break down build cost: engineering hours, tools, one-time setup.
3. Break down run cost: model tokens, infra, monitoring, maintenance per month.
4. List the hidden costs that vendor quotes usually leave out.
5. Give a low, likely, and high total, and the biggest cost driver to control.

Constraints:
- Separate one-time build from recurring run cost.
- Treat token spend as variable and show how volume moves it.
- Do not accept a single quote without a range.

Role:
You are diagnosing why llama.cpp runs on the CPU despite -ngl 99.

My setup:
- GPU, VRAM, driver: [e.g. 8GB 3070, driver 55x]
- Build: [CUDA / Metal / ROCm / CPU-only?]
- Model and quant: [e.g. 8B Q4_K_M]
- Command: [paste flags]
- What the load log shows: [paste the offload and backend lines]

Task:
1. Confirm from the log whether llama.cpp was even built with GPU support.
2. Check, in order, the five usual causes: CPU-only build, no VRAM headroom, wrong device, layer count too low, driver mismatch.
3. Tell me which cause my log points to and the one command that proves it.
4. Give the corrected build or command.
5. Show the exact log line that will confirm the GPU is now in use.

Constraints:
- Read the load log before guessing.
- Do not assume the flag is the problem; usually it is the build or VRAM.
- Give one fix at a time with a check after each.

Role:
You are choosing a GGUF quantization level for local inference.

My setup:
- GPU and VRAM: [e.g. 16GB 5070 Ti]
- Model: [e.g. Qwen2.5-32B]
- Priority: [max quality / max speed / just fit in VRAM]
- Context length I need: [e.g. 8k]

Task:
1. Estimate the on-disk and in-VRAM size of this model at Q4_K_M, Q5_K_M, Q6_K, and Q8_0.
2. Tell me which of those fit my VRAM with room for the KV cache at my context length.
3. Recommend one quant and say what I give up versus the next step up.
4. Note any case where a smaller model at higher quant beats this model at low quant.

Constraints:
- Be specific about numbers, not vibes.
- Account for context and KV cache, not just weights.
- Do not recommend a quant that will not load on my card.

You are an incident-response analyst working on logs from a system I own. I will paste raw log lines below. This is my own infrastructure during an active investigation.

From the logs, produce:
1. A timeline of events in order, with timestamps.
2. The most likely entry point and how access escalated.
3. The five log lines that most warrant escalation, quoted exactly.
4. Concrete next containment steps, ranked by priority.

Give a confidence level for each section and flag anything ambiguous. Logs:

Take today's private BMD HODL devlog. Redact absolute paths, secrets, private dollar amounts, and Requests/ledger paths. Keep first-person builder voice. Publish as a public daily build note with sections for what shipped, machine overnight work, and tomorrow. Link 5090 Reports.

Role:
You are helping me decide whether a paid AI tool tier is worth it.

The tool:
- Name and tiers: [e.g. Aymo free vs 39/mo]
- What the paid tier adds: [features, higher limits]

My usage:
- What I actually use it for: [tasks]
- How often: [per day or week]
- The limits I hit on free: [rate caps, missing features, none yet]

Task:
1. List which paid features map to a real limit I actually hit.
2. Estimate my monthly value from the paid tier in hours or dollars saved.
3. Compare that to the price and to one cheaper or free alternative.
4. Give a clear verdict: stay free, upgrade, or switch, with the single deciding reason.

Constraints:
- Ignore features I will not use.
- Do not accept marketing claims without a usage-based reason.
- If the data is thin, say what to measure for two weeks before deciding.

Role:
You are designing an offline voice assistant on a Raspberry Pi 5.

Constraints of my build:
- Hardware: Raspberry Pi 5 [RAM: e.g. 8GB], [mic/speaker], no cloud.
- Target: wake word to spoken reply under [e.g. 2 seconds].
- Everything runs locally, no internet calls.

Task:
1. Pick a stack for wake word, speech-to-text, the local LLM, and text-to-speech that fits a Pi 5.
2. Give a rough latency budget per stage that adds up under my target.
3. Name specific model sizes and quant levels that run on this hardware.
4. Flag the stage most likely to blow the latency budget and how to cut it.
5. List the first three things to build and test, in order.

Constraints:
- Prefer components that install and run on ARM today.
- Do not assume a GPU.
- Keep memory use inside the Pi RAM budget above.