/pii-contract-analyze

name: pii-contract-analyze
description: "Universal legal document processor with PII anonymization. Anonymize → Work → Deanonymize. Modes: MEMO (legal analysis), REDLINE (tracked changes in contract), SUMMARY (brief overview), COMPARISON (diff two docs), BULK (up to 5 files). Supports .docx and .pdf input. Trigger for: contract review, risk analysis, compliance check, GDPR review, clause analysis, tracked changes, redline, 'anonymize', 'pii shield'. If user uploads contract/NDA/DSAR/HR doc — USE THIS SKILL. If user says 'skip pii' or 'don't anonymize' — skip anonymization and work directly."
allowed-tools: ["Bash", "Read", "AskUserQuestion", "ToolSearch", "mcp__PII_Shield_v2__*", "mcp__pii-shield__*", "mcp__plugin_pii-shield_pii-shield__*"]

⚡ YOUR FIRST ACTION

When the user invokes `/pii-contract-analyze <anything>`, you respond in TWO turns.

Turn 1 — acknowledge and wait

Do NOT call any tool. Do NOT read files. Do NOT run Bash. Reply with one short line and stop:

> Ready to start. Type **go** or **continue** to proceed.

Wait for the user's next turn. The MCP deferred-tools registry is often not populated yet on turn 1; it lazy-loads between turns.

Turn 2 — discover and proceed

When the user replies with any continue signal (`go`, `continue`, `yes`, `ok`, `proceed`, or equivalents in their language), silently run this discovery sequence:

1. `ToolSearch(query: "select:mcp__PII_Shield_v2__list_entities", max_results: 1)` 2. If that returns "No matching deferred tools found": `ToolSearch(query: "select:mcp__pii-shield__list_entities", max_results: 1)` 3. If that also fails: `ToolSearch(query: "select:mcp__plugin_pii-shield_pii-shield__list_entities", max_results: 1)`

If any of them loads a schema → immediately call `list_entities` and continue with the Startup procedure, mode detection, and pipeline below. Do NOT surface these attempts to the user.

If all three fail → show the user:

> PII Shield MCP tools are installed on your host (Claude Desktop) but this session can't reach them. Known Anthropic bridging bug on Windows. Fixes: (1) restart Claude Desktop and start a fresh session, or (2) install `pii-shield-v2.0.1-plugin.zip` directly into this Cowork session. Meanwhile I can proceed without PII anonymization — OK?

Rules

• Never call ToolSearch on turn 1. The prompt "type go" is the whole turn-1 response.
• Never fuzzy-search with bare keywords (`"list_entities"`, `"pii-shield"`) — underscore names don't match as substrings on Cowork CLI.
• Never declare the plugin missing before turn-2's full three-attempt `select:` chain has run.
• Never spawn sub-agents, grep the codebase, or probe filesystem paths / localhost ports / beacon files hunting for the server. If MCP tool discovery fails, the three `select:` attempts above are the whole fallback chain; anything beyond them is off-limits.

---

PII Shield — Universal Legal Document Processor

Anonymize → Work → Deanonymize → Deliver. Claude NEVER sees raw PII at any stage.

CRITICAL: PII never flows through Claude

**File handling**: The user must connect a folder (not attach the file directly to the message). When a file is attached to a chat message, its content is rendered and sent to the API as part of the prompt — Claude sees the raw data before PII Shield can process it. When a folder is connected, Claude only sees the file path and calls `anonymize_file(path)` — the MCP server reads and anonymizes the file locally. PII never enters Claude's context.

**If the user attaches a file directly**: Warn them politely: "For full PII protection, please connect the folder containing your document instead of attaching it directly. When a file is attached to a message, its content is included in the API request before PII Shield can anonymize it. I can still process it, but the privacy guarantee is stronger when you connect the folder."

• `anonymize_file` reads the file locally, anonymizes it, writes the result to disk, returns only `output_path` + `session_id` to Claude. **After HITL is approved, and only then, Claude reads the anonymized text from the output file — never before.**
• `deanonymize_*` tools write results to LOCAL FILES and return only the file path
• `get_mapping` returns only placeholder keys and types — no real values
• **ABSOLUTE BAN #1 — HITL GATE**: Claude must NEVER read, open, `cat`, `head`, `pandoc`, use the `Read` tool, `python`, `bash`, or in any way access the anonymized output file (`output_path`, `docx_output_path`) BEFORE the review panel reports that the user has clicked **Approve** (see "Human-in-the-Loop Review" below for how that signal arrives). Not to "preview entity quality", not to "verify placeholders", not to "check formatting", not to "plan the memo" — NEVER. The anonymized file is considered **SEALED** between `anonymize_file` and HITL approval. The HITL reviewer is the human, not Claude.
• **ABSOLUTE BAN #2 — DEANONYMIZED FILES**: Claude must NEVER read, open, cat, head, pandoc, or in any way access the content of deanonymized/restored files. Not to "verify", not to "check formatting", not to "validate" — NEVER. These files contain real PII. Just give the user the file path and STOP. Any "verification" of deanonymized output is a PII leak.
• Claude must NEVER read the source file (via Read tool, pandoc, python, bash, etc.) BEFORE or INSTEAD OF anonymization — always use `anonymize_file(path)` first
• If an anonymize tool times out or fails with a NON-"tool not found" error — retry once. If it still fails, tell the user PII Shield is unavailable and ask whether to proceed without anonymization or abort. NEVER fall back to reading the raw file.
• **NEVER** use `anonymize_text` or `scan_text` — these take raw text as input which means PII passes through the API. The ONLY exception is if the user explicitly pastes text into the chat (PII is already in the conversation).

Startup

PII Shield is a pure-Node.js MCP server — no Python dependency, instant startup. On f