Legal Test Builder
Produces a production-grade interactive HTML legal assessment as a single self-contained file that works offline and renders cleanly in any modern browser.
When to use
- Preparing a candidate for a real take-home assessment
- Assessing legal candidates with a realistic, timed exercise that tests judgment rather than doctrine recall
- Onboarding junior lawyers through scenario-based learning
- Building legal training modules for in-house teams or client education
- Law student moot and drafting exercises
- Compliance or regulatory training where scenario application is the point
Step 1: Gather inputs
Before building, confirm or infer the following. If not specified, make sensible defaults and flag assumptions visibly in the output so the user can correct them.
| Input |
Key questions |
Default if unspecified |
| Role |
What position is being tested or trained for? |
"Legal Counsel" |
| Organisation |
Context for the scenario |
Fictional company from the library below |
| Legal domain(s) |
Contract law, IP, employment, regulatory, M&A, compliance, privacy, etc. |
Commercial contracts |
| Governing law |
English law, German law, French law, New York law, etc. |
English law |
| Test duration |
Total time for the assessment |
3 hours |
| Difficulty |
Junior / Mid / Senior / Partner-equivalent |
Mid-level |
| Purpose |
Candidate assessment vs. training vs. exam prep |
Candidate assessment |
| Number of tasks |
How many distinct exercises |
3-4 tasks |
| Model answers |
Included (training / prep) or excluded (live exam) |
Included as reveals |
For candidate prep and training: always include model answers as hidden reveals.
For live candidate assessment: generate a second "examiner version" that strips the reveals.
Step 2: Design the task stack
A strong 3-hour test uses this structure. Scale task count and timing to the duration.
Task 01: Contract Review and Redline (50-70 min)
The anchor task. Most revealing of practical legal judgment.
- Draft a realistic 6-10 clause agreement with 5-8 embedded problems
- Problems should span critical, high, and medium severity
- Always include at least one missing clause (something not in the contract at all)
- Include at least one trap clause that looks standard but is not (e.g., a licence-back that launders an overbroad IP assignment)
- See
references/contract-design.md for problem-embedding patterns
Task 02: Legal Memo / Written Analysis (35-50 min)
Tests reasoning under novelty. Best structured as a scenario with no clean answer.
- Give a factual scenario with a genuine legal tension
- Specify the governing law and any constraints
- The scenario should be novel enough that the candidate cannot recite a textbook answer
- See
references/scenario-design.md for scenario construction patterns
Task 03: Short Analysis (20-35 min)
A focused issue with one problem and one answer. Good for: conflict of interest, regulatory compliance, specific employment or GDPR question, contractual interpretation.
Task 04: Strategy / Function-Building (30-45 min)
Tests seniority and commercial judgment rather than legal knowledge.
- Classic framing: "You are the first legal hire. It is Day 90. What have you built, what have you deliberately not built, and what keeps you up at night?"
- Alternative: "Identify the three highest-priority legal risks and how you would address each."
- See
references/strategy-questions.md for templates by role type
Step 3: Build the HTML
Read references/html-framework.md before writing code. It contains:
- The full CSS design system (tokens, typography, components)
- The contract annotation pattern with hover tooltips on problem clauses
- The reveal block component
- The timer implementation
- The checklist component
- Colour and severity conventions
Core architectural rules
-
Single file: everything inline. No external dependencies except Google Fonts.
-
Offline-capable: the test must work without internet access once fonts are cached.
-
Timer: sticky header, shows hours:minutes:seconds. Colour shifts: normal → amber (under 30 min) → red and pulsing (under 10 min).
-
Contract problems: annotated with
data-title and data-body attributes on <span class="problem"> elements. A JS tooltip renders on hover. The annotation is invisible until hovered.
-
Reveal blocks: model answers hidden by default. Click to reveal. Never auto-open.
-
Write areas:
<textarea class="write-area"> beneath every question. Candidate writes before revealing.
-
Checklist: final section with clickable items. Use it to encode the marking criteria.
Content quality rules
-
Contract text must be realistic. Not obviously fake. Use proper defined terms, clause numbering, and recitals where appropriate.
-
Problems must be embedded naturally. The bad clause should read plausibly. A poorly-drafted clause spotted only because it is obviously wrong is a bad test.
-
Model answers must be opinionated. Not "it depends." State a conclusion, justify it, then acknowledge genuine uncertainty where it exists.
-
Traps must be explicitly called out in a clearly styled trap box. Candidates need to understand not just what the problem is but why the instinctive response is wrong.
-
Hook quotes: include one memorable framing sentence per major section. One line that captures the strategic point, styled in a hook box.
-
Gaps must be flagged honestly. If a model answer involves a developing area of law, say so. A gap box signals "this is uncertain; here is how to handle it."
Step 4: Severity and priority framework
Use this consistently across all problem rows and scenario analyses:
| Severity |
Colour |
Definition |
| CRITICAL |
Red |
Existential to the organisation's mission, business model, or legal position. A lawyer who misses this fails the test. |
| HIGH |
Amber |
Significant commercial or legal exposure. Should be caught and negotiated. |
| MEDIUM |
Blue |
Suboptimal but not immediately dangerous. Bonus credit for catching it. |
In contract tasks, always include at least 2 CRITICAL problems. The candidates who catch both and articulate why they are existential are the ones worth hiring.
Step 5: Checklist design
The pre-submission checklist is the invisible marking rubric. Design it to:
- Encode what separates a good answer from an excellent one
- Include at least 2 items about how the candidate engaged (honest about uncertainty, conclusions first, no padding) rather than only what they wrote
- End with one sentence capturing the philosophy of the role being tested
Step 6: Two-version output
- For candidate prep or training: build with model answers (reveals included)
- For live assessment: strip reveals and model answer content, leaving task instructions, contract text, and write areas. Present as a clean "examiner version."
To generate the clean version, remove all .reveal-block divs and .reveal-body content. The .reveal-header can be removed or left as a "Marking notes" placeholder visible only to the examiner version.
Reference files
Read these before building:
-
references/html-framework.md: complete CSS and JS implementation with all component patterns
-
references/contract-design.md: how to design realistic contracts with well-embedded problems
-
references/scenario-design.md: scenario construction for memo and analysis tasks
-
references/strategy-questions.md: strategy question templates by role type
Output format
Present the final HTML file. Note in the summary:
- How many tasks, total time budget
- How many embedded contract problems and their severity distribution
- Whether model answers are included or excluded
- Any legal uncertainty flags the candidate or trainer should be aware of