| name | local-first-legal-workspace |
| title | local-first-legal-workspace |
| description | Use when users say "is this legal AI app local-first", "what leaves the machine", "BYOK privacy", "audit network calls", "where are documents stored", or need a legal AI workspace reviewed for local storage, credentials, model-provider calls, conversion, and privacy boundaries. |
| author | LegalQuants |
| author_url | https://github.com/LegalQuants/lq-skills/tree/main/skills/local-first-legal-workspace |
| license | Apache-2.0 |
| version | 0.1.0 |
| execution_mode | open |
| jurisdiction | general |
| practice | general |
| language | en |
| tags | ["local-first","privacy","legal-ai","document-management","byok","security"] |
local-first-legal-workspace
When to Use
- A lawyer wants to use AI with confidential documents without adopting a hosted matter platform.
- A desktop or local web app stores legal documents and generated work product.
- The user needs to reason about BYOK model calls, local storage, workspace backups, or privacy boundaries.
- A workflow must explain exactly what leaves the machine.
This skill is a design and audit checklist. It is not a claim that local-first equals risk-free.
Audience and Work Shape
Audience: legal-technology counsel, privacy/security-aware lawyers, and legal engineers reviewing a legal AI workspace with technical input where needed.
Work shape: pattern-matched audit when evidence exists; accretive design review when the user is designing a workflow. Keep those paths separate in the output.
Legal Failure Modes
- Legal support, not legal advice: the skill maps data flows and uncertainty so a lawyer can assess risk; it does not certify privacy, security, privilege, or regulatory compliance.
- Privilege/confidentiality: model calls, document conversion, logs, and external lookups can affect privilege/work-product treatment. Include privilege/work-product implications in the disclosure note when legal matter data is involved.
- Accountability: the responsible lawyer, DPO, security lead, or system owner decides whether the workspace is acceptable for a matter or client.
Access Modes
This skill works in three modes:
- Code/runtime evidence mode - inspect repository code, configuration, dependencies, logs, network observations, or runtime behavior.
- User-supplied architecture mode - use diagrams, README files, screenshots, settings exports, or descriptions supplied by the user.
- No-evidence mode - produce an audit plan and questions only. Do not assert what stays local or what leaves the machine.
If code, runtime evidence, or provider documentation is unavailable, mark claims unknown or not_observed_not_excluded. Do not treat a product's privacy statement as verified architecture.
How It Works
1. Define the workspace boundary
Identify where local data lives:
- Documents.
- Database or index.
- Generated files.
- Chat history.
- Settings.
- Logs.
- API keys or credential references.
Prefer one user-chosen workspace folder so backup, deletion, and migration are understandable.
2. Map all network paths
