Pillar Legal Skills Authoring

Architectural Pillar: Legal Skills Authoring

Scope

This pillar defines the principle that skills are the primary unit of legal knowledge in the Louis system. Each skill is a standalone markdown file with structured YAML frontmatter. Skills are versioned, peer-reviewable by lawyers, swappable without code changes, and composable at runtime.

This principle is what makes the no-fine-tuning bet (see [[pillar-architectural-bet-no-fine-tuning]]) executable: the skill library is the expert knowledge layer.

The principle

Skills are first-class artifacts. Each skill = one markdown file with frontmatter. Versioned, reviewable, swappable.

What a skill is

A skill is a markdown file that encodes one unit of legal expert behavior — either a piece of substantive legal knowledge, a behavioral rule, a document template, a workflow, or a persona. Every skill has:

1. YAML frontmatter — machine-readable metadata for routing, discovery, and version management
2. A body — human-readable expert content that instructs the model on how to handle the skill's domain

The frontmatter schema:

---
name:          [kebab-case identifier, globally unique]
description:   [1-4 sentences for routing — "Use when…"]
license:       MIT
metadata:
  id:          [dot-notation original id, e.g., draft.NDA-unilateral]
  category:    [draft | review | kb | persona | router | pillar | eng | …]
  practice_area: [corporate-commercial | employment | arbitration | …]
  jurisdictions: [LB | UAE | DIFC | KSA | EG | FR | UK | US | __multi__ | …]
  priority:    [P0 | P1 | P2 | P3]
  intent:      [routing keywords]
  related:     [list of related skill names]
  source:      [provenance note]
  version:     "x.y"
---

Why skills as files

Version control

Skills stored as files live in git. Every change is a diff. A lawyer can review a skill change the same way an engineer reviews a code change. History is preserved. Bad changes are reversible.

Separation of concerns

Legal knowledge lives in skill files; model behavior lives in the foundation model; routing logic lives in the router. Each concern can be changed independently. Updating a skill does not require redeploying the model.

Peer review

A subject-matter expert (e.g., a Lebanese law specialist) can review and approve changes to skills covering Lebanese law without needing to understand the underlying ML infrastructure. The review workflow is the same as code review.

Composability

Multiple skills can be loaded into a single prompt at runtime. A user asking about an NDA in Lebanon might trigger: draft-nda-unilateral + kb-lob-contracts-lebanon + persona-partner-mode + heuristic-no-us-style-boilerplate-in-civil-law-jx. The router selects and composes.

Discovery and coverage tracking

Because every skill has frontmatter, the system can generate a complete inventory of covered practice areas, jurisdictions, and document types — and, by inversion, identify gaps where no skill exists.

Skill categories

Skill quality standard

A skill should be:

• Precise enough to be acted on: every sentence must add information the model will use. No padding.
• No wider than one topic: a skill for NDA drafting should not also contain advice on employment contracts. Composability requires granularity.
• Jurisdiction-specific where needed: a generic skill is acceptable for widely shared principles; jurisdiction-specific details belong in jurisdiction-specific skills or in a jurisdictional notes section.
• Accurate: no fabricated statute numbers or case citations. Where uncertain, say so explicitly.
• Interlinked: related skills should be cross-referenced with [[wikilinks]] so the skill set is a navigable graph.

Thin skills (one or two sentences) are almost never useful as skills — they become useful only when expanded to real depth. The quality bar is: would a competent practitioner find this genuinely helpful?

Skill lifecycle

Author (lawyer + engineer) → Draft skill → Peer review (SME lawyer) → 
Merge to main → Router picks up → Runtime use → Feedback / issue logged → 
Update skill → Review → Merge

Skills are never "done" — they are maintained like living documents. The legal landscape changes; skills must change with it.

Priority levels signal maintenance urgency:

• P0: mission-critical; must be accurate and current; reviewed quarterly
• P1: high-value; reviewed semi-annually
• P2: useful; reviewed annually or on-demand
• P3: supporting/internal; reviewed when foundational assumptions change

How the router uses skills

The router (see [[router-skill-selector]]) matches the user's request against skills by:

1. Matching intent keywords against the request
2. Filtering by jurisdictions if jurisdiction is known from context
3. Filtering by practice_area if the matter area is known
4. Ranking by priority
5. Loading the top N matching skills into the prompt context

The description field is the most important routing signal — it must accurately answer "when should this skill be used?"

Caveats

The skill-as-file approach works well for a skill library of hundreds to low thousands of skills. At very high scale (tens of thousands), indexing and retrieval become engineering concerns. See [[eng-skill-registry]] for the registry implementation.

Related skills

• [[pillar-architectural-bet-no-fine-tuning]] — why skills replace fine-tuning
• [[pillar-context-across-apps]] — how skills declare and consume matter context
• [[pillar-live-data-mcp]] — live data as a complement to static skill knowledge
• [[eng-skill-registry]] — engineering implementation: how skills are indexed and loaded
• [[router-skill-selector]] — how the router selects and composes skills at runtime