---
name: legal-case-analysis
description: 基于裁判文书、监管决定和官方材料生成法律/合规案例分析。Use when analyzing court judgments, procedural orders, injunctions, stay/interim relief decisions, regulatory fines, enforcement notices, administrative decisions, data protection, AI governance, platform regulation, competition, consumer protection, cybersecurity, GDPR Chapter V, SCCs, TIA, cross-border transfer, or when the user asks for 案例分析、裁定书分析、判决精读、监管决定分析、案件脉络、实务启示、内部备忘录.
---

# Legal Case Analysis

## Goal

Use this skill to turn complex legal, regulatory, or compliance case materials into accurate, source-grounded, reviewable analysis with practical value.

The output must help readers understand:

- the facts and procedural posture;
- what the current document decides;
- what it does not decide;
- the court or regulator's reasoning;
- unresolved issues and next procedural steps;
- practical implications for companies, regulators, counsel, or compliance teams.

## Core Principles

### Prefer Original Sources

Anchor key facts, issues, reasoning, and outcomes in official materials.

Source priority:

1. Court judgment, order, official case page, official PDF.
2. Regulator final decision, penalty decision, corrective order, press release, FAQ, enforcement summary, official procedural notice.
3. Procedural filings and party materials: complaint, appeal, motion, defence, expert opinion, evidence summary, company statement.
4. Third-party materials: official summaries by bodies such as EDPB, OECD, NIST, ENISA, FTC, ICO, DPC; mainstream media; law firm or academic commentary.

Use third-party materials only for orientation, public procedural status, or industry reaction. Return legal conclusions to official sources.

### Determine Procedural Posture First

Before analysis, identify:

- document type;
- first instance, appeal, further appeal, remittal, or interim relief;
- merits review or procedural review;
- final judgment or interim order;
- regulator final decision or draft decision;
- whether later proceedings remain;
- whether only part of the case is decided;
- whether any issue is remitted;
- whether fines, corrective orders, deadlines, or stay relief are final.

Avoid these errors:

- treating procedural success as merits success;
- treating interim relief as final merits conclusion;
- treating regulator allegations as court findings;
- treating party arguments as holdings;
- treating media headlines as legal conclusions.

### Separate Information Types

Always distinguish:

| Information type | Treatment |
|---|---|
| Court-confirmed fact | May be used as factual baseline |
| Court legal holding | May be stated as holding |
| Regulator finding | Attribute to regulator |
| Party argument | Attribute as argument or submission |
| Expert opinion | Attribute source and role |
| Media report | Use only as secondary support |
| Unresolved issue | Mark as unresolved |
| Analytical inference | Explain basis |

## Standard Workflow

### Step 1: Build A Case Card

```markdown
## Case Card

| Item | Content |
|---|---|
| Case name |  |
| Court / regulator |  |
| Jurisdiction |  |
| Document type |  |
| Case / reference number |  |
| Decision date |  |
| Publication date |  |
| Parties |  |
| Applicable law |  |
| Procedural posture |  |
| Core issues |  |
| Outcome |  |
| Later status |  |
| Official sources |  |
```

### Step 2: Confirm Procedural Posture

Use this checklist:

```markdown
## Procedural Posture

This document addresses:

- [ ] Merits infringement / liability
- [ ] Fine amount
- [ ] Corrective order
- [ ] Suspension order / injunction / stay
- [ ] Interim relief
- [ ] Jurisdiction / admissibility / standing
- [ ] Permission to appeal
- [ ] Fair procedures / due process
- [ ] Evidence admission
- [ ] Other

This document does not decide, or has not finally decided:

-
```

If multiple documents exist, explain each document's procedural function separately.

### Step 3: Reconstruct Facts And Timeline

Use official documents as the factual baseline. Do not add unverified facts.

Separate:

- factual background;
- alleged facts;
- admitted facts;
- findings of fact;
- procedural history.

```markdown
## Timeline

| Date | Event | Procedural / legal significance | Source |
|---|---|---|---|
| YYYY-MM-DD |  |  |  |
```

### Step 4: Break Down Issues

Analyze each issue in a stable format:

```markdown
## Issue X

### Issue

### Party / regulator positions

### Court or regulator treatment

### Reasoning

### Practical impact

### Unresolved questions
```

Keep fact disputes, legal standards, remedies, and procedural questions separate unless the document itself ties them together.

### Step 5: Map The Outcome

Use a table to separate upheld, rejected, adjusted, remitted, and unresolved items.

```markdown
## Outcome Structure

| Issue | Prior decision / position | Current outcome | Impact |
|---|---|---|---|
| Infringement / liability |  |  |  |
| Fine basis |  |  |  |
| Fine amount |  |  |  |
| Corrective order |  |  |  |
| Suspension / injunction |  |  |  |
| Procedural standard |  |  |  |
| Later procedure |  |  |  |
```

### Step 6: State What The Document Confirms And Does Not Confirm

```markdown
## Confirmed / Not Confirmed

| Confirmed by the document | Not confirmed by the document | Practical note |
|---|---|---|
|  |  |  |
```

This module is mandatory for complex or multi-document cases.

### Step 7: Analyze Win / Loss Structure

Avoid simplistic win/loss framing when outcomes are mixed.

Use this structure:

```markdown
## Win / Loss Structure

### Points supported for one side

### Points supported for the other side

### Issues both sides still face

### More accurate conclusion
```

Prefer:

- "The court upheld the regulator's core infringement finding but required reconsideration of the corrective order."
- "The company gained procedural relief, but the merits remain unresolved."

Avoid unless the source expressly supports it:

- "The company fully won."
- "The regulator completely failed."
- "The decision was entirely overturned."
- "The fine has necessarily been cancelled."
- "The court approved the company's current practice."

### Step 8: Convert To Practical Implications

```markdown
## Practical Implications

### For companies

### For regulators

### For counsel / compliance teams

### For legal or regulatory development
```

Make implications executable where possible: evidence pack, policy update, risk assessment, audit trail, contract revision, regulator response, litigation posture, or communications posture.

## Output Modes

Choose the mode that matches the user's request.

### Quick Brief

```markdown
# Case Brief

## One-sentence conclusion
## What happened
## Current procedural status
## Core issues
## Holding / decision
## Practical impact
## Next watch points
```

### Professional Article

```markdown
# Title

## Introduction
## 1. Calibrate the document: what this decision decides
## 2. Case background and timeline
## 3. Prior decision or lower-instance ruling
## 4. Core issue one
## 5. Core issue two
## 6. Core issue three
## 7. What the court upheld
## 8. What the court adjusted, vacated, or remitted
## 9. What remains unresolved
## 10. Practical implications
## 11. Conclusion
## Official sources
```

### Judgment Deep Read

```markdown
# Judgment Deep Read

## Document structure
## Key paragraph index
## Key concepts
## Issue-by-issue analysis
## Logic map
## Quotable holdings
## Practical translation
```

### Internal Memo

```markdown
# Legal / Compliance Memo

## Executive Summary
## Case identification
## Relevance to us
## Facts and procedure
## Core legal issues
## Holding / regulator conclusion
## Risk mapping
## Recommended actions
## Open questions
## Sources
```

### Short Comment

```markdown
# Case Comment

## One-sentence conclusion
## What happened
## Latest procedural node
## Three important changes
## Common misunderstandings
## Impact on companies
## Next watch points
```

## Source-to-Structure Pipeline

Do not choose the final output mode too early for complex cases. First inspect the source materials and produce an orientation snapshot.

Run these steps in order:

1. Extract procedural posture.
2. Extract outcome map.
3. Extract grounds / issues.
4. Map each ground or issue to source anchors.
5. Present the results of steps 1-4 to the user as an orientation snapshot.
6. Select output mode with the user or make a reasoned recommendation.
7. Select document-type and subject-matter modules.
8. Build a working issue list.
9. Draft.
10. Fact-check against source anchors.
11. Prepare publish or delivery artifacts.

The orientation snapshot must be short but decision-useful:

```markdown
## Source Orientation Snapshot

### Procedural posture

- Document type:
- Procedural stage:
- What is decided:
- What remains unresolved:

### Outcome map

| Issue | Outcome | Later status |
|---|---|---|
|  |  |  |

### Issue / ground map

| Issue or ground | Party / regulator position | Court / regulator treatment | Source anchor |
|---|---|---|---|
|  |  |  |  |

### Initial module recommendation

| Layer | Recommended module | Why |
|---|---|---|
| Document type |  |  |
| Subject matter |  |  |

### Output mode choices

| Mode | Best for | Tradeoff |
|---|---|---|
| Quick Brief |  |  |
| Professional Article |  |  |
| Judgment Deep Read |  |  |
| Internal Memo |  |  |
| Short Comment |  |  |
```

After presenting this snapshot, choose the output mode. If the user has already clearly selected the mode, still provide a concise orientation snapshot before drafting, then proceed.

## Specialized Modules

Use specialized modules cumulatively. They are not alternatives at the same level.

For complex matters, always complete the Source-to-Structure Pipeline before drafting.

```markdown
## Module Selection

| Layer | Selected module | Why it applies | What it controls in the analysis |
|---|---|---|---|
| Document type |  |  | Procedural posture, standard of review, outcome categories |
| Subject matter |  |  | Domain-specific facts, legal tests, risk vocabulary |
| Output mode |  |  | Article / memo / deep-read structure and level of detail |
```

Default sequence:

1. Complete the Source-to-Structure Pipeline steps 1-4.
2. Present the orientation snapshot to the user.
3. Select or confirm output mode.
4. Select one primary document-type module.
5. Select one or more subject-matter modules.
6. Build the issue list by crossing document-type questions with subject-matter questions.

Example:

| Matter | Document-type module | Subject-matter module | Output mode |
|---|---|---|---|
| Court review of a GDPR transfer decision | Merits Judgment | Cross-Border Data Transfer | Judgment Deep Read / Professional Article |
| Stay pending appeal of a transfer suspension order | Procedural Order / Stay / Injunction | Cross-Border Data Transfer | Professional Article |
| Regulator AI enforcement decision | Regulatory Decision | AI Governance | Case Brief / Professional Article |
| Court judgment reviewing AI enforcement | Merits Judgment | AI Governance | Judgment Deep Read |

The document-type module answers: what kind of legal document is this, what standard applies, and what legal effect does it have?

The subject-matter module answers: what domain-specific facts, duties, risks, and remediation questions must be tracked?

The output mode answers: how much detail and what presentation structure the user needs.

### Document-Type Modules

#### Procedural Order / Stay / Injunction

Cover:

1. What the applicant requested.
2. How the respondent opposed it.
3. Applicable procedural standard.
4. How the court interpreted that standard.
5. How harm was balanced.
6. How public interest was considered.
7. Whether the order affects merits.
8. What happens next.

For stay cases, explicitly distinguish:

| Question | Status |
|---|---|
| Whether the original decision is unlawful | Usually unresolved |
| Whether enforcement is stayed | Decided |
| Scope of stay | Must specify |
| Duration of stay | Must specify |
| Conditions | Must specify |
| Whether merits continue | Usually yes |

#### Merits Judgment

Cover:

1. Object of review.
2. Applicable law.
3. Fact findings.
4. Legal standard.
5. Treatment of prior decision or lower judgment.
6. Whether infringement / liability is upheld.
7. Whether remedies are upheld.
8. Whether fines or damages are upheld.
9. Unresolved issues.
10. Later impact.

#### Regulatory Decision

Cover:

1. Regulator.
2. Trigger for investigation.
3. Scope of investigation.
4. Findings of fact.
5. Applicable law.
6. Infringement findings.
7. Penalties / corrective measures.
8. Cooperation procedure.
9. Company arguments.
10. Industry impact.
11. Appeal or remedy path.

### Subject-Matter Modules

#### Cross-Border Data Transfer

Cover:

1. Whether data leaves the EEA or relevant territory.
2. Whether remote access exists.
3. Server location.
4. Personnel / access location.
5. Data importer or access entity.
6. Transfer tool.
7. Third-country law risk.
8. Whether SCCs are enough.
9. Supplementary measures.
10. Whether essentially equivalent protection is demonstrated.
11. Transparency disclosure.
12. Remediation.

Pay special attention to:

- server location is not enough;
- access actor, access location, purpose, and controls matter;
- remote access, storage, processing, and transfer may be distinct;
- separate different investigations and their procedural status.

#### AI Governance

Cover:

1. AI system type.
2. Role identification: provider, deployer, importer, distributor, user.
3. Risk classification.
4. Data governance.
5. Transparency.
6. Human oversight.
7. Safety, robustness, and cybersecurity.
8. Logging and traceability.
9. Third-party model or toolchain management.
10. Responsibility allocation.
11. Remediation.

## Turning Modules Into An Issue List

After module selection, do not merely mention the modules. Convert them into a working issue list.

For a merits judgment, combine:

- object of review;
- standard of review;
- grounds of appeal or issues;
- what was upheld;
- what was vacated, adjusted, or remitted;
- what remains unresolved.

With subject-matter questions.

Example for a merits judgment about cross-border data transfers:

```markdown
## Working Issue List

| Issue | Document-type question | Subject-matter question | Source anchor | Expected output section |
|---|---|---|---|---|
| Transfer scope | What fact/legal finding is under review? | Was there EEA-to-third-country transfer or remote access? |  |  |
| Adequacy of transfer assessment | Was the regulator's infringement finding upheld? | Did the controller demonstrate essentially equivalent protection? |  |  |
| Third-country law evidence | How did the court treat the evidence? | What third-country law risk was assessed or missed? |  |  |
| Supplementary measures | Were remedies upheld or remitted? | Did technical and organisational measures affect historical liability or future orders? |  |  |
| Transparency | Was a separate infringement upheld? | Did disclosure identify countries, transfer tools, and access structure? |  |  |
| Fine basis and amount | Did the judgment decide fault, amount, or execution? | What compliance failure supports negligence or intent? |  |  |
| Unresolved issues | What remains for later proceedings? | What transfer arrangements or remediation remain unconfirmed? |  |  |
```

For a procedural order / stay about cross-border data transfers:

```markdown
## Working Issue List

| Issue | Procedural question | Subject-matter question | Source anchor | Expected output section |
|---|---|---|---|---|
| Relief requested | What stay or injunction was sought? | Which transfer, order, or remediation deadline would be affected? |  |  |
| Legal standard | What test governs interim relief? | Does the test account for data subject rights or transfer-risk urgency? |  |  |
| Harm to applicant | What harm is alleged if no stay is granted? | Is the harm operational, technical, financial, or compliance-related? |  |  |
| Harm to public / data subjects | What harm is alleged if stay is granted? | What rights, transfer risks, or enforcement interests are affected? |  |  |
| Merits boundary | Does the court decide underlying legality? | Does the order say anything about actual transfer compliance? |  |  |
| Scope and duration | What exactly is stayed and until when? | Does the stay affect suspension orders, remedial steps, or fines? |  |  |
| Next procedure | What happens next? | What must the regulator or company do while merits continue? |  |  |
```

If no clear working issue list can be built, pause and inspect the source materials again. Do not proceed directly to article drafting.

## Writing Rules

- Write in a professional legal / compliance style.
- Be accurate, restrained, explanatory, and source-dense.
- Avoid sensational, promotional, or slogan-like language.
- Avoid overusing "不是……而是……" as a default paragraph engine.
- Avoid one-sentence paragraphs as the main style.
- Avoid excessive English; keep English terms only when useful and explain them.
- Mark key sources where feasible: "Source: judgment §xx", "Source: DPC Final Decision, para. xx", or "Source: official press release, YYYY-MM-DD".
- If paragraph numbers are unavailable, identify the document and section.

Uncertainty language:

- "Current public materials do not show..."
- "I have not seen an official document confirming..."
- "This point comes from media reporting and needs official confirmation."
- "This is an inference from the available materials."

## Quality Check

Before final output, verify:

- [ ] Document type and procedural posture are clear.
- [ ] Merits decisions and procedural orders are separated.
- [ ] Court holdings, regulator findings, and party arguments are separated.
- [ ] Official sources anchor key conclusions.
- [ ] Media headlines are not used as legal judgments.
- [ ] Unresolved issues are identified.
- [ ] Overclaiming is avoided.
- [ ] Practical implications are executable.
- [ ] Official source links are included when available.
- [ ] There is a precise one-sentence conclusion when useful.
- [ ] Timeline is included for complex cases.
- [ ] Issues are broken down.
- [ ] "Confirmed / not confirmed" is included for complex or mixed outcomes.
- [ ] Next watch points are listed.

## Common Corrections

- Procedural success is not merits success.
- A remittal is not necessarily regulatory failure.
- A stayed order is not necessarily an unlawful order.
- Fine basis, fine amount, and fine execution status are separate.
- Remote access and server storage are separate facts.
- Party expert opinion is not automatically a court finding.