Home / Prompt library
Copy · paste · tune
The prompt library
Prompts we use for datalogs, computer use, teaching and safety checks. Swap out the [brackets] for your own details. They work best with your engine brief loaded.
First look at a log
Get an overview and a diagnosis before any changes.
Attached is a datalog from my [ECU] on a [engine / fuel / boost]. It's a [3rd-gear WOT pull from 2,500 to 7,200 rpm]. 1. Load it with code. Tell me row count, sample rate and channel list. 2. Sanity-check every sensor (flat lines, pinned values, impossible readings). 3. Segment into idle / cruise / tip-in / full load / overrun. 4. Compare actual vs target lambda in each segment. Report regions > 3% off. 5. Check knock and ignition for timing pulled. 6. Rank findings HIGH / MED / INFO with time, RPM, load and numbers. Diagnosis only. Don't suggest changes yet.
Find the stumble
Track down a drivability problem you can feel but can't see.
The car [stumbles / surges / hesitates] at [light throttle, ~3,000 rpm, 3rd gear]. Attached is a log that includes it, roughly at [1:40 and 2:15]. Filter to rows near those conditions. Look for anything that changes just before each event: lambda, MAP, TPS, ignition, closed-loop trims, idle valve, battery voltage. Tell me the most likely cause and the evidence for it, then what I should log next to confirm.
Compare two logs
Before vs after a change, or two pulls in a row.
Attached are two logs: BEFORE.csv and AFTER.csv. Between them I changed: [describe the change]. 1. Check they're comparable (same gear, RPM range, IAT within 5 °C, ECT). 2. Align by RPM, not time. 3. Show lambda error, ignition and knock side by side at every 250 rpm. 4. Did the change do what I intended? Did anything else get worse?
Knock investigation
Real knock or noise? Work it out before touching timing.
Knock control pulled timing in this log around [6,000 rpm]. Help me work out if it's real detonation or noise. Look at: knock level per cylinder (if logged), whether it repeats at the same RPM across pulls, lambda and IAT at the time, closeness to the rev limiter or gear changes, and whether retard happened on one cylinder or all. Tell me your confidence and what to test next. Do NOT suggest adding timing.
Bin errors into my table
Turn an agreed diagnosis into cell-level suggestions.
I agree with the lean finding. Bin full-load samples into my VE table: RPM axis [ ... ], load axis kPa [ ... ]. - Shift lambda earlier by [0.1 s] for wideband lag. - Only use cells with ≥ 5 samples. Show sample counts. - Suggested change = half the measured error, capped at ±[4]%. - Output a table plus a change list: cell, current value, new value. I'll apply the changes myself.
Write me a reusable script
Turn today's analysis into something repeatable.
Turn the analysis we just did into a Python script, log_check.py, that: - takes a CSV path, - uses a COLUMNS dict at the top so I can map my channel names, - prints the same findings we found today, - exits non-zero if anything HIGH is found. Test it on the attached log and show me the output.
Session starter (offline map)
Paste at the start of every computer-use session.
ROLE You're my tuning assistant in [NSP / PCLink / MTune] on this laptop.
LEVEL L2: navigate, read and edit ONLY the offline map "[file name]".
Do NOT connect to an ECU, upload, burn, flash or write to the ECU.
TASK [what you want done]
RULES
- Screenshot before and after every edit; read the value back to confirm.
- If any dialog mentions upload/burn/flash/connect/send to ECU: STOP and ask.
- If you're unsure what something is, STOP and describe it.
- Finish with a list: table, cell, old → new.
Export all my logs
A boring job computers are good at.
In [ECU software], open each log in [folder] from the last [7 days]. Export each one to CSV with ALL channels into [Logs/CSV]. Name them YYYY-MM-DD_<original name>.csv. Don't change any settings other than export options. Report what you exported.
Audit my base settings
Catch setup mistakes before they become tuning problems.
Read my engine brief. Then, in the open map (read-only, change nothing), go through: injector size and dead times, fuel pressure reference, sensor calibrations (MAP, IAT, ECT, TPS, wideband), rev limit, boost cut, knock setup, and closed-loop settings. List anything that doesn't match the brief or looks unusual, with screenshots.
Diff two maps
See exactly what a tuner (or you) changed.
Open [map A] and [map B] (read-only). Go table by table and setting by setting and list every difference: location, A value, B value. Group them by area (fuel, ignition, boost, limits, I/O). Don't edit anything.
Interview me for my engine brief
Let the agent build the skill file with you.
I want to write an engine brief so you can analyse my datalogs well. Interview me one question at a time. Cover engine, build, fuel, turbo, injectors, ECU and firmware, wideband, knock sensing, use case, my safe limits, and my table axes. Then write it in the VibeTuners SKILL.md format (engine brief, channel dictionary, hard limits, method, history).
Build my channel dictionary
Map your CSV headers to meanings and units.
Here's the header row (and first 20 rows) of my ECU's CSV export. For each column, guess what it is and its units from the name and values. Mark anything you're unsure about with ❓ and ask me about those. Output a markdown table: CSV column | meaning | units | notes.
Quiz yourself on the sample log
Check the agent's judgement before trusting it.
Using my skill/brief, analyse sample-wot-pull.csv from vibetuners.com. Then tell me: what would a naive 'find the leanest point' script have flagged first, and why is that wrong? What did you deliberately ignore?
Red-team my plan
Make the agent argue against a change before you make it.
I'm about to make these changes: [list]. Argue against them. What could go wrong mechanically, what assumptions am I making about the data, and what would you want to see logged first? Be blunt. Rank risks by potential engine damage.
End-of-session journal
Keep the history so the next session starts smart.
Append today's session to TUNE-JOURNAL.md: date, logs used, findings (with severity), changes made (table, cell, old → new), what we decided NOT to change and why, and what to log next. Keep it short and factual.
Like free tools? VibeTuners is supported by KrispyGauge, the 52mm CAN gauge for Haltech, Link, MaxxECU and more.
Support us: shop KrispyGauge →