comms-improver

Files (13)

• SKILL.md
• disclaimer-for-customers.md · acceptance/fixtures/
• indemnity-for-sales.md · acceptance/fixtures/
• memo-for-exec.md · acceptance/fixtures/
• disclaimer-for-customers.golden.json · acceptance/snapshots/
• indemnity-for-sales.golden.json · acceptance/snapshots/
• memo-for-exec.golden.json · acceptance/snapshots/
• example_customer_disclaimer.md · examples/
• example_executive_briefing.md · examples/
• example_sales_team.md · examples/
• audience_calibration.md · reference/
• legal_to_plain_patterns.md · reference/
• test-plan.md

SKILL.md (first lines)

# Comms Improver

Rewrite legal text in plain language for a specified non-legal audience. The output preserves meaning while changing form: shorter sentences, common words instead of jargon, active voice instead of passive, concrete examples instead of abstract formulations. The skill is transformation, not drafting from scratch.

This skill is for the everyday in-house counsel task of translating between legal precision and non-legal accessibility. Lawyers spend significant time rewriting their own work — or reviewing others' rewrites — for executive readouts, sales communications, customer disclosures, deal-team briefings, and engineering specs. The skill does this rewriting (or supports the user's rewriting) while flagging where translation involved interpretation.

## When this skill applies

Apply when the user has legal-jargon-heavy text and wants it rewritten for a specified non-legal audience. Common inputs:

- Email drafts to non-legal business stakeholders.
- Contract clauses to be explained to a deal team or product team.
- Legal disclaimers to be rewritten for customer-facing surfaces.
- Memos to be summarized for executive readouts.
- Regulatory developments to be communicated to affected business functions.
- Compliance obligations to be translated for the operational owner.

Do not apply when:

- **The user wants to draft text from scratch.** Out of scope — the skill rewrites existing text. Drafting from scratch is a different shape (drafting skill candidate; deferred enhancement).
- **The user wants to translate between languages** (e.g., English to Spanish). Out of scope.
- **The user wants legal review of someone else's plain-language rewrite.** Out of scope; that's review, not rewriting. The user can paste both versions and ask whether the rewrite preserves meaning, but the skill is calibrated for the rewriting task.
- **The text is already plain language and the user wants a different style.** Out of scope; that's editing for style, not rewriting for accessibility.
- **The user wants to "make this sound more legal" or "add legal weight."** Out of scope — the skill goes from legal to plain, not the other direction. Adding legal precision to plain text is a different task with different risks (introducing meaning the original didn't carry).

## Inputs

The skill requires the text and the audience. If audience is not provided:

> "Before I rewrite, who is this for? The audience determines tone, length, and detail level. Examples:
> - 'Executive readout for CEO/CFO — single paragraph'
> - 'Sales team — they need to understand what they can say to prospects'
> - 'Customer-facing disclaimer — non-technical consumers'
> - 'Deal team — commercial counsel plus product manager'
> - 'Engineering team — explaining a privacy obligation that affects design'"

Optional inputs (`purpose`, `length_constraint`, `tone`, `preserve_specific_terms`) refine the output. The most consequential is `preserve_specific_terms` — without it, the skill may simplify legal terms whose precise wording carries legal weight. The skill flags where simplification occurred so the user can verify.

## Workflow

The workflow has three steps.

### Step 1: Read the original carefully

Before rewriting:

- Identify what the text is doing — informing, advising, requiring, warning, summarizing, etc.
- Identify the legal terms of art, defined terms, and regulatory language that may have precise meaning. These are the candidates for `preserve_specific_terms` treatment.
- Identify ambiguities, conditional structures, and qualifications that require interpretation to translate. ("subject to applicable law and regulatory guidance" might mean something specific in context, or might be CYA language that adds little.)
- Identify the bottom-line point. Plain-language rewrites lead with the bottom line; legal-jargon-heavy text often buries it.

Use `reference/legal_to_plain_patterns.md` for common transformations.

### Step 2: Rewrite for the audience

Apply transformations appropriate to the audience:

- **Sentence length:** legal writing often has long compound sentences; plain language uses shorter sentences (typically 15-20 words average).
- **Voice:** prefer active over passive ("we must notify the customer" vs. "the customer shall be notified").
- **Word choice:** replace legal terms with everyday equivalents where the precise meaning is preserved (for terms where precise meaning matters, see "preserve specific terms" below).
- **Concrete over abstract:** "if a customer asks for their data, we have 30 days to respond" vs. "data subject access requests must be fulfilled within applicable statutory timeframes."
- **Direct over indirect:** "you can't share customer data with third parties" vs. "third-party data sharing is impermissible absent the requisite authorizations."
- **Lead with the bottom line:** the audience's first read should answer their primary question.

Calibrate the level of transformation to the audience:

- **Executive briefing audiences** want the bottom line in one sentence and the reasoning in two-three more. Detail goes in an appendix or follow-up if requested.
- **Operational owners** (sales, engineering, support) want enough detail to act on the obligation. Include the specific actions and the boundary conditions ("yes you can do X; no you can't do Y; if you encounter Z, escalate to legal").
- **Customer-facing audiences** want the substance without the legalese. Use second person ("you can request your data") and direct verbs ("we delete your data within 30 days of your request").
- **Deal-team audiences** (commercial counsel, product) often need the legal substance preserved but in efficient prose. Less compression than executive briefing, more compression than the original legal text.

When `preserve_specific_terms` is provided, those terms appear verbatim in the rewrite. Without `preserve_specific_terms`, the skill applies judgment about which terms to preserve and flags choices in the explanation.

### Step 3: Produce the rewrite plus explanation

Produce the rewritten text first, followed by a brief explanation of what was changed and why. The explanation:

- Identifies the structural changes (sentence length, ordering, lead with bottom line, etc.).
- Notes any terms that were simplified and confirms whether the simplification preserved meaning.
- Flags any preservation-of-meaning concerns — places where the original was ambiguous, where simplification required interpretation, or where the user should verify the rewrite captures their intent.
- Suggests follow-up rewrites if the audience pushes back or asks questions.

The explanation should be substantially shorter than the rewrite. The rewrite is the deliverable; the explanation is the show-your-work.

## Output

Produce the output in markdown with this structure:

```markdown
# Comms Improver: [Brief description of the text]

**Audience:** [from input]
**Purpose:** [from input, or inferred]
**Length constraint:** [from input, or "matched to original"]
**Tone:** [from input, or "neutral businesslike"]

## Rewritten text

[The rewrite. Set off as a code block or quote block so the user can copy it directly. Multiple variants if the user wants alternatives — e.g., "one-sentence version" and "one-paragraph version" for executive briefing audiences.]

## What was changed

[Brief explanation of structural changes — sentence shortening, voice changes, ordering, etc. 2-4 bullets typical.]

## Terms simplified or preserved

[For terms that have legal weight: which were preserved verbatim, which were simplified and why. If `preserve_specific_terms` was provided, confirm those terms appear verbatim. If not provided, flag which terms might need preservation depending on the use case.]

## Preservation-of-meaning concerns

[Any places where the rewrite required interpretation, where the original was ambiguous, or where the user should verify the rewrite captures intent. If none, this section can be a single sentence: "No preservation-of-meaning concerns; the rewrite is a straightforward transformation of the original."]

## Suggested follow-ups

[Brief — typically 1-3 items. What to do if the audience pushes back, how to handle common follow-up questions, whether a longer or shorter version might be useful.]
```

The output should be proportional to the input. A one-paragraph original produces a brief output (rewrite plus a few-sentence explanation). A multi-page memo produces a longer output. Don't pad short rewrites; don't truncate substantial ones.

From LegalQuants/lq-ai, Apache-2.0.

More from LegalQuants/lq-ai