Legal Test Builder Patrick Munro

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