u/Old_Geologist_5277

I've been in AI for 4 years, last 2 specifically in production RAG and multi-agent systems. Before that I was in data science, back when this wasn't even called AI engineering yet.

For the last 2 years I was completely heads down in production RAG, building actual RAG applications and multi-agent orchestration. Somewhere in that grind, thanks to doomscrolling eating whatever brain cells I had left, my basics went rusty. To clear that rust I need a serious accountability partner, not another passive group chat.

I've also interviewed fresher AI engineering candidates at my company. So I know what actually gets a resume shortlisted and what makes an interviewer stop listening halfway through an answer.

I've joined learning squads before. Every single one died in two weeks. People show up once, get busy, go quiet, and nobody says anything about it. I'm done doing that.

Here's what's in it for you. If you've been stuck in that pile of scattered ML/DL material, random courses, half-finished playlists, and you can't cleanly explain how something works when someone actually pushes on it, that's where I can help. I've always been good at breaking things down, ask anyone who's crammed with me before an exam, they walked out understanding it better than the professor explained it. I can also tell you exactly what an interviewer is listening for versus what's just noise, because I've sat on that side of the table.

What I need in return: my DSA has gone rusty and needs rebuilding. So does my depth on ML, DL, and transformer internals. I know the one-liner versions, token prediction, self-attention lets tokens attend to each other, produces the KV values, but I can't yet explain the underlying mechanics cleanly when pushed, and it's the same story across a lot of core ML and DL. I want all of that revised properly, not the surface version I already have.

What I'm looking for on your end is honesty, consistency, and actually showing up. If you know you can't hold that, this probably won't work for either of us, and that's fine, better to know now than three days in.

If it sounds like a fit, comment or DM with what you're working on right now and a time window that actually works for you, 1 to 1.5 hours, morning or evening.

I kept getting prompts back from agents that looked fine but weren't.

Ask it to design an email classifier for a PM. It writes a system prompt immediately. No clarifying questions about format, examples, edge cases, or which model will run it. A PM pastes that into production and wonders why accuracy is at 70%.

Ask it to debug a hallucinating legal summarizer. It adds "do not hallucinate" to the system prompt and calls it fixed. The underlying problem is truth bias: the model has no retrieval anchor, so it fabricates plausible case numbers from its training distribution. Telling it not to doesn't change what it doesn't have.

So I stopped fixing prompts one at a time and wrote a skill that encodes what actually worked across two years of reading, building, and breaking things. Not a template. A decision tree.

What the skill forces the agent to do:

Ask clarifying questions before writing. If the user hasn't specified format, examples, model, edge cases, or evaluation criteria, stop and ask. A prompt shipped without answers to those is a prompt that will fail in ways you won't see until production.
Diagnose root cause before patching. A failing prompt is rarely fixed by adding more words. It's fixed by understanding which first-principles axiom is being violated. Hallucination is a truth bias problem. Inconsistent output is a format specification problem. Ambiguous answers are a direction problem.
Apply the Five Principles in order. Give Direction first. Then Specify Format. Then Provide Examples. Then Evaluate Quality. Then Divide Labor if the task outgrew a single prompt. No principle skipped. No principle applied out of order.
Ship nothing unevaluated. Every prompt ships with test cases, recommended parameters, known limitations, and an accuracy estimate. If you can't measure whether the prompt works, you can't ship it.

The skill is grounded in how LLMs actually work: single-pass, left-to-right, mimicking the training distribution. These aren't opinions. They're consequences of the architecture.

Does this actually change what the agent produces?

I wrote benchmark tasks with good references and bad references, validated every scorer (16/16 deterministic gates pass), and ran the same model with and without the skill:

"Design an email classification prompt" → Without: writes prompt immediately. With: stops and asks 5 clarifying questions before writing anything.
"Debug this hallucinating legal summarizer" → Without: "add don't hallucinate to prompt." With: identifies the truth bias axiom violation, proposes retrieval anchoring and citation-grounded output format.
"Fix an inconsistent classifier output" → Without: suggests adding more rules to the prompt. With: identifies format specification as the weak principle, proposes structured JSON output with schema enforcement.

The skill didn't make the answers more verbose. It made the agent stop and ask the questions that prevent failures before the prompt ever reaches a user.

I wrote three other skills from the same philosophy — agent architecture, FastAPI for GenAI, and production RAG — because the same pattern applies: gate before you build.

The repo is github.com/gnkbhuvan/cartographer. Install with npx skills add gnkbhuvan/cartographer. The prompt-engineering skill is one file you can grab on its own if the others aren't relevant to your work.

I wrote this from what survived two years of trial and error. If you've got prompt design patterns, evaluation methods, or edge cases that held up under real use, the repo is open. Add them.

AI engineer (4 yrs, 2 in production RAG/multi-agent) looking for one serious interview prep partner, not another dead study group

I spent two years reading prompt engineering philosophy. The stuff that worked became a skill that gates my agents before they write anything.