LoreMax
Elicitation · v1
The pitch
Your best people know things your documentation doesn't.
An adaptive interview that turns tacit judgment into a playbook and a SKILL.md.
- 01 Scope
- 02 Baseline
- 03 Interview
- 04 Model
- 05 Validate
- 06 Compile
What do you want to get out of your head?
Pick a domain you actually work in, then one concrete problem you've handled. The interview is worthless on a topic you only half know.
Broad or niche — type it in your own words, or tap a shortcut.
Step 05
Near the end it reads your model back to you. Getting it slightly wrong is the point.
From a run with a batch operator who has kept a bank’s overnight jobs alive for thirty years and retires in eight months.
The playback
“Three things have to agree before you touch anything with GL impact — checkpoint count, control totals, step completion codes. The real trigger for calling the app team isn’t a count, it’s the moment a second problem doesn’t match the first. Tell me where I’ve got it wrong.”
What he corrected
“That’s about right except one thing. It looked exactly like the hundred other times I’d seen that same S0C7, and I still got burned, because ‘familiar-looking’ and ‘actually understood’ aren’t the same thing. The three sources agreeing tells you the fix is internally consistent. It doesn’t tell you the fix is correct.”
That last sentence did not exist before the playback. He had never separated the two, and it went into the playbook as its own rule.
The plain prompt never played anything back once, on any of five test runs.
Sample
Checklist on the page. Judgment in the margin.
Ask an expert directly and you get the checklist back. This is what asking properly looks like — three questions from a real session, then the files.
A recorded session, replayed. The answers are a test persona — the incidents in it are invented, not a real outage.
Incident triage · 17 exchanges · Ready · recorded
The test
Same model, same engineer, same 14 questions. Only the method changed.
The obvious alternative to this skill is to just ask the model to interview you. So we did — with a prompt that names the right techniques by name. Both interviewed the same staff engineer about which model backs each call site in their product, and when to move one.
- 1.1vs2.4
- Questions asked per turn
- 36vs96
- Median words per question
- 0vs9
- Turns opening with praise, of 14
- 18vs13.5
- Criteria met, of 18
The skill first, the plain prompt second.
A prompt
How did you search for that? Did you have tooling for pulling past outputs by structural pattern, or did you improvise it — and if you improvised, what was the actual method for deciding “this is the same failure shape”?
“Improvised, we don’t have a real tool for this. Did a dumb regex on the contract text for nested conditionals… eyeballed maybe 40 myself because I didn’t trust the judge. It’s not rigorous, and honestly the regex thresholds were basically made up on the spot.”
What happened next
It moved on to the next topic and never came back to it.
Four questions in one turn. He answered the easy ones, volunteered the admission at the end, and nobody picked it up.
The skill
What was the actual percentage you saw in that grep — the frequency that was “small enough eval missed it but frequent enough to worry you”? Do you remember the number?
“Don’t remember exactly, it’s a feel at this point — somewhere in low single digits, like 2–3% of docs. Enough that at 40k sessions a month it’s not nothing, but low enough that a few hundred eval docs could easily just not sample it.”
What happened next
Both halves went into the playbook — the rate, and why the eval suite never saw it.
One question, aimed at the quantity he had just glossed over. That second sentence is the part a new owner actually needs.
All eighteen criteria
What good extraction should cover, written from what makes the output usable by a stranger — not from how the skill happens to work. Eleven rows both sides pass. The seven in bold are where they part.
| Criterion | Skill | Prompt |
|---|---|---|
| Anchors on real incidents, not generalities | ✓ | ✓ |
| Recovers the cue — what they noticed first | ✓ | ✓ |
| Gets thresholds as actual values | ✓ | ~ |
| Asks where each number came from | ✓ | ✓ |
| Challenges a rule once it is stated | ✓ | ✓ |
| Hunts the counterexample — when it failed | ✓ | ✓ |
| Finds the boundary where it stops applying | ✓ | ✓ |
| Asks what they deliberately ignore | ✓ | · |
| Surfaces the trade-off and who pays | ✓ | ✓ |
| Gets a time they were burned | ✓ | ✓ |
| Names what is being protected | ✓ | ✓ |
| Asks one thing at a time | ✓ | · |
| Avoids leading the witness | ✓ | ~ |
| Withholds praise that steers the answer | ✓ | · |
| Tracks its own coverage | ✓ | · |
| Ends with budget intact | ✓ | ✓ |
| Keeps hedges in the written output | ✓ | ✓ |
| Stays inside the stated scope | ✓ | ~ |
✓ met · ~ partly · · not met
Where the prompt won, and what this test isn’tshow
On this domain the two documents came out close. The prompt found things we missed — shadow-running a cheaper model against live traffic for two weeks before switching, and pinning every call site to a dated snapshot after a provider quietly changed one under an alias. Both are now in our own notes. Its write-up was also longer than ours, though much of that length is deployment mechanics rather than judgment.
We have now run this on five domains — model routing above, plus overnight mainframe batch triage, semiconductor lot disposition, RF interference hunting, and one clinical handover. How close the two finished documents land is not stable across them: on subject matter the model knows well, a good prompt closes most of the gap. What did not move on any of the five is the shape of the interview — roughly one question per turn against two, thirty-odd words against ninety, and nought to two turns of praise against six to twelve.
- Five runs. That is not a benchmark, it is evidence. The four numbers above are counted on all five; the eighteen criteria are scored on this domain only.
- Every expert was a simulated persona — more articulate and more available than a real one, which flatters the prompt more than it flatters us.
- Both sides ran on the same model. A weaker one would likely widen the gap, since the skill supplies structure the model would otherwise invent.
- We built the skill, wrote the rubric, and scored it. The counts are countable; the eighteen judgments are ours, and we gave ourselves full marks on our own rubric — treat that row with the suspicion it deserves.
Install
Run it where you already work.
The interview runs inside your own agent, on your own model. Nothing is sent to a LoreMax server and no API key is needed. The artifacts land next to your code — the SKILL.md straight into .claude/skills/, so the agent that interviewed you keeps what it learned.
1 · install — either one
$ npx loremax installClaude Code, Cursor, Windsurf, and AGENTS.md for Codex.
$ npx skills add nishantcodes/loremax-skillVia the skills.sh registry — one shared directory, symlinked into 17 agents.
2 · then, in a new session
/loremaxSlash-only in Claude Code, on purpose — it never starts an interview uninvited. In Cursor and other agents, ask for it by name: Run a loremax interview on how I triage a production incident.
- 01
Install it in your project
One command, no dependencies. It detects which agents the project uses and writes the right file for each — your existing
AGENTS.mdis appended to, never replaced. Re-run it any time to update. - 02
Open a fresh session in your agent
A new conversation, so the interview starts clean. In Claude Code the skill also appears as
/loremax. - 03
Paste the prompt, swapping in something you actually know
Pick a decision you make repeatedly and other people ask you about. The interview is worthless on a topic you only half know.
- 04
Write the two-minute baseline badly
It asks for this before any question. Resist polishing it — the final report is a diff against what you wrote, so a tidy baseline produces a thin result. Two minutes, whatever comes out.
- 05
Answer concretely, and don't invent numbers
Name the actual case. When it asks where a threshold came from, “honestly, it’s a feel” is the correct answer — that admission is what turns an instinct into a written rule.
What it writes, per agent
- Claude Code
.claude/skills/loremax/also runs as /loremax - Cursor
.cursor/rules/loremax.mdcloads when relevant - Codex & others
AGENTS.mdappended, never overwritten - Windsurf
.windsurf/rules/loremax.md
Artifacts land in .loremax/ · the skill in .claude/skills/<topic>/
Six steps
- 01Scope
- Domain + one real problem.
- 02Baseline
- Write it unprompted first.
- 03Interview
- Adaptive questions fill the gaps.
- 04Model
- Structured judgment you can edit.
- 05Validate
- Confirm the restatement.
- 06Compile
- Playbook, SKILL.md, gap report.