By Calin Pop · Altipoint AI LLC · Updated August 25, 2026
The assignment arrives before the interview: build an AI skill, bring it running, and let the panel test it on two product specifications you have never seen.
The assignment was narrow. You build a small skill called ai-feature-privacy-review. Its input was a short description of an AI-powered feature. Its output was a structured first pass for counsel: the issues the facts raised, the information still missing, and the conditions to resolve before moving forward. It was not supposed to give final legal advice or produce client-ready work.
The employer gives you scenario assumptions and a practice use case to build against. During the interview, it would run the skill on two new use cases and question the results. The brief was explicit: polished code was not the point. The panel wanted to see the reasoning—and, above all, whether the skill would ask for a missing material fact instead of inventing one.
That exercise changes what AI fluency means in legal and compliance hiring. The test is not whether you know the names of popular tools. It is whether you can turn work you already know into a repeatable workflow, use it to make a first pass faster and more consistent, and stay in control when the facts change. That points to a practical standard: if you claim applied AI fluency as a legal or compliance professional, be ready to show one bounded, tested skill.
Build an AI Skill. Show Your Work.
What the exercise was actually testing
A working skill makes professional judgment inspectable. The interviewer can change one fact, remove another, question a source, and ask why the output moved—or why it did not. That exposes capabilities a résumé cannot:
Can you encode work you already understand? The value comes from knowing which facts, distinctions, and exceptions actually control the task.
Can the workflow transfer to unfamiliar facts? A rehearsed answer may survive one demo. A useful skill has to behave sensibly on a new matter.
Can you supervise what you built? You should be able to explain its sources, assumptions, limits, and stopping points—and repair it when it fails.
The goal is augmentation, not delegation without review. A good skill removes repeated setup, organizes the first pass, and makes gaps visible. The lawyer still decides what the analysis means and what happens next.
You do not need to build a software product. A documented instruction set, a few examples, a stable output format, and a test file can be enough. What turns a prompt into a skill is repeatability: someone can run it again, see its rules, and understand where its answer ends.
The capability an employer can inspect
The lesson from WordPerfect, Lexis, and Westlaw
WordPerfect, Lexis, and Westlaw changed the fluency lawyers needed without replacing judgment. Generative AI adds a harder problem: it can sound complete while hiding a missing fact, so fluency must include instructions, sources, tests, and stopping points.
Build an interview-ready AI skill in eight moves
Start with a recurring task you know well enough to spot a bad answer. “Answer any legal question” is too broad. “Produce a first-pass issue map from an AI-feature specification” is narrow enough to build and test. Then work through these moves:
Choose one narrow task. Pick repeatable, information-based work such as issue intake, clause comparison, checklist generation, or routing—not a final legal conclusion.
Name the user and purpose. My skill was for counsel preparing a first pass. It was not a self-service answer tool or a client deliverable.
Define the minimum inputs. For an AI-feature review, these might include purpose, data involved, model or provider, storage and retention, users, and deployment location.
Map the decision path. Write the important distinctions as plain if-then branches. Separate facts supplied by the user from assumptions and unanswered questions.
Set source rules. Name the sources the skill may use, their priority, their date limits, and what to do when they conflict or cannot be verified.
Fix the output structure. Use the same sections every time: facts provided, issue map, missing facts, assumptions, and conditional next steps.
Add stopping conditions. Tell the skill to ask, qualify, or escalate when a material fact is missing, sources conflict, or the matter falls outside its scope.
Test, revise, and version. Record what you expected, what happened, what rule you changed, and whether the revised version still passes earlier tests.
Build the smallest useful version first. Interface polish can come later. In an interview, a plain workflow whose behavior you can defend is stronger than a beautiful interface whose reasoning you cannot explain.
Run it on facts you have never seen
The live portion uses two specifications you have never seen. That mattered because a workflow tested only on its practice example may simply be reproducing the pattern it was shown. New facts reveal whether the skill can transfer.
Do not grade the output by how polished it sounds. Grade the behavior. A changed fact should produce one of three responses:
Change the result. A material fact changes the issue map or the conditions to clear.
Keep the result. A cosmetic or irrelevant change leaves the analysis stable.
Suspend the result. A missing or contradictory fact triggers a question instead of a guess.
In the privacy-review example, learning that prompts and responses are retained may change the assessment. Changing only the document’s heading should not. Omitting the deployment region or the kind of data involved should make the skill pause and ask. All three outcomes can be correct; what matters is whether the reason is correct.
Build a small test matrix: a normal case, one material change, one immaterial change, one missing fact, one contradiction, and one instruction that tries to push the skill outside its role. Write the expected behavior before you run each case. Otherwise, whatever the model returns can be mistaken for success.
When a test fails, repair the cause, not the sentence. If the skill guessed around a missing fact, add a required-input check. If irrelevant wording changed the result, sharpen the material distinction. If it invented a source, restrict the source set and require verification. Record the expected and actual behavior, revise the rule, and rerun both the failed case and the earlier tests the change could affect.
Bring proof, not polish
The artifact alone is not the proof. The proof is the connection between the skill’s design, its behavior on named tests, and your explanation of its limits. Keep the package compact enough to discuss in a few minutes.
What to bring
A one-page skill specification and version.
A small test matrix with expected and actual behavior.
The sources, assumptions, and data boundaries.
The human-review and stopping rules.
What they are really testing
Can you turn a process you know into a skill that makes the first pass faster?
Does it encode your domain knowledge rather than paraphrase the input?
Does it transfer to unseen facts and ask instead of guessing?
Can you explain a failure, the repair, and the remaining limit?
Why this matters in interviews now
At one level, this is a familiar work sample: legal employers have long changed facts and questioned a candidate’s analysis. The new element is the object being examined. The candidate brings a reusable system and has to explain how it behaves when the panel changes the inputs.
Prepare for that conversation, not just the demonstration. Be ready to explain why you chose the task, which facts control the result, what the skill got wrong, how you repaired it, and where a lawyer must take over. Build with synthetic or public facts, use a tool you can lawfully access, and bring a readable copy in case the live setup fails.
Add one AI skill before your next interview
Pick one recurring task you already understand. Build the narrowest useful version. Test one material change, one immaterial change, and one missing fact. Then bring the skill, the results, the sources and assumptions, and the rules for when it stops.
Building the skill develops fluency because it forces you to discover where AI helps, where it fails, and which parts of the work depend on your judgment. Showing the evidence proves more than a claim on a résumé. The artifact shows what you built; the test trail shows how you think.