Box

View saved version →

---
name: box
description: "Foundation skill for working with Box in ChatGPT or Codex. Use whenever a request involves Box files, folders, search, sharing, metadata, AI, Hubs, Doc Gen, authentication, MCP, Codex CLI or REST access, SDK code, webhooks, or Box errors. Start here to select the available tool path and relevant domain reference."
---

# Box

## Overview

This skill targets OpenAI products. In ChatGPT, use Box MCP only and ignore all CLI and REST paths. In Codex, MCP, CLI, and REST are available as described below. When building application code in Codex, preserve the repository's existing Box SDK or REST architecture.

## Route The Request

### Identify the product and authenticated tools

- **ChatGPT:** Use only Box MCP. Call `who_am_i`; a successful response confirms the connected Box user. If it fails with an authentication error, complete the client-provided Box OAuth flow and retry. If MCP is not configured, use `references/auth-and-setup.md`. Do not check for or use CLI or REST.
- **Codex:** Check the available Box paths:
  - **MCP:** Call `who_am_i`. A successful response confirms the connected Box user.
  - **CLI:** Run `box users:get me --json`. A successful response confirms that Box CLI is installed, authenticated, and identifies the active CLI actor.
  - **REST:** Confirm `BOX_ACCESS_TOKEN` is present without printing it, then call `GET https://api.box.com/2.0/users/me` to validate the token and identify its actor.

In Codex, use authenticated MCP when available. If a check fails, use `references/auth-and-setup.md`, `references/box-cli.md`, or `references/rest-calls.md` for the relevant path.

Tool definitions and current Box documentation are authoritative for live parameters, supported operations, and limits.

### Domain routing

Choose the matching domain reference regardless of tool path:


| Request                                                                              | Reference                           |
| ------------------------------------------------------------------------------------ | ----------------------------------- |
| Authentication, actor selection, or initial setup                                    | `references/auth-and-setup.md`      |
| Uploads, downloads, previews, files, folders, moves, copies, properties, or metadata | `references/content-workflows.md`   |
| Collaborations, shared links, comments, or access changes                            | `references/collaboration.md`       |
| Keyword, folder-name, or metadata search                                             | `references/mcp-search.md`          |
| Box AI Q&A, extraction, summarization, or document retrieval                 | `references/ai-and-retrieval.md`    |
| Box Hubs creation, curation, or Q&A                                                  | `references/mcp-hubs.md`            |
| Box Doc Gen templates or generated documents                                         | `references/mcp-doc-gen.md`         |
| Bulk organization, folder trees, migrations, moves, or metadata writes               | `references/bulk-operations.md`     |
| Webhooks, events, ingestion, or catch-up synchronization                             | `references/webhooks-and-events.md` |
| 401, 403, 404, 409, 429, missing content, missing tools, or wrong-actor errors       | `references/troubleshooting.md`     |


### Codex-only CLI and REST fallbacks

Ignore these paths in ChatGPT.

- **Use CLI in Codex** only after `box users:get me --json` confirms it is configured and authenticated. Use it when the required operation is unavailable through MCP, the user explicitly requests CLI, or the deliverable requires a local reproducible command. For bulk actions, prefer CLI only when this availability check succeeds. Read `references/box-cli.md` in addition to the domain reference.
- **Use REST in Codex** when building or debugging application code that calls the Box API, or when neither MCP nor CLI can perform the required operation. Use it only after confirming REST authentication is configured. Read `references/rest-calls.md` in addition to the domain reference. Prefer an existing official Box SDK or HTTP abstraction in application code.

## MCP

The Box MCP server is the only Box tool path in ChatGPT. It provides structured operations for content, search, collaboration, AI, metadata, Hubs, and Doc Gen.

### Tool availability and documentation

The maintained list of Box MCP tools is at [https://docs.box.com/en/box-mcp/tools](https://docs.box.com/en/box-mcp/tools). If an expected tool is absent, check that list first, then use the MCP-tool section of `references/troubleshooting.md` for client and Box Admin Console enablement steps.

Referenced files: 12

View saved version →

---
name: box-legal-workflows-contract
description: "Review contracts in Box, compare them with an approved template or playbook, identify candidate differences for attorney review under firm-supplied criteria, create cited variance reports, and scan for renewals or expirations. Use for individual contract review, NDAs, MSAs, contract metadata, or variance analysis."
---

# Contract review in Box

Use the `box` skill for authentication and operations. For mechanics, use `box/references/mcp-search.md`, `box/references/ai-and-retrieval.md`, `box/references/content-workflows.md`, and `box/references/collaboration.md` as relevant.

## Review

1. Resolve the contract and the applicable template, playbook, or jurisdictional addendum. Record each Box file ID and version; ask only when multiple plausible baselines remain.
2. Compare the contract and baseline together. Identify added, missing, and changed provisions and cite both sources. Report unreadable, truncated, or unrepresented sections instead of claiming complete comparison.
3. Extract factual fields with standard structured extraction. Use enhanced extraction only when the user explicitly requests it.
4. Apply documented firm criteria as preliminary analysis, then create and upload a cited variance report that separates source facts, analysis, and attorney decisions. Verify and record its Box ID.
5. After presenting the analysis, ask whether the user wants metadata written if the request did not already decide that. If yes, inspect the firm's current template first; when none exists, ask whether to propose fields or create a template before continuing.
6. Post a routing comment or add attorney access only when requested. Check the file's audience first; keep privileged analysis and internal playbook text in a restricted artifact when the source has broader collaborators. A plain Box comment does not guarantee a targeted mention or notification.



## Variance report

Create one entry per independent difference with: issue, contract position and citation, baseline position and citation, factual difference, preliminary impact under documented criteria, and the attorney or firm decision still needed. If the baseline is silent, label the item **uncovered** or **attorney review**, not a variance.

Example:

```text
Issue: Limitation-of-liability cap
Contract: Section 12.2 — cap is three times fees paid
Baseline: Playbook Section 4.1 — approved position is fees paid
Difference: Contract cap is three times the approved position
Preliminary impact: Outside the documented fallback
Decision needed: Attorney approval or counterproposal
```



## Metadata and date scans

- **Extracted facts:** parties, contract type, effective and expiration dates, renewal language, notice period, value, and governing law.
- **Firm decisions:** status conventions, risk rating, review disposition, and next action.
- **Operational state:** reviewed version, review date, next review date, and alert history.

Treat these as examples and use the live firm schema. Parameterize metadata searches through `query_params` for new contracts, expiration windows, counterparty, or approved ratings.

When requested, run an expiration or renewal scan and report contracts requiring action. Persistent monitoring requires an explicit cadence, state store, and idempotency key; track the alert date or window and reviewed version rather than a permanent yes/no flag.

## Boundaries

- Risk, materiality, favorability, and approval of a deviation are firm or attorney decisions. When approved criteria are absent, report factual differences and unresolved questions rather than assigning a rating.
- Write only approved ratings into final-decision fields, and keep source versions, citations, report IDs, and any write failures in the audit trail. If a source changes during review, state that the result applies to the recorded version.

View saved version →

---
name: box-legal-workflows-intake
description: "Run legal client intake and onboarding in Box: inventory submissions, check completeness, extract client and matter facts, surface cited risk indicators, route attorney review, and generate draft engagement documents. Use for client intake, onboarding, new matters, intake documents, or engagement letters."
---

# Legal intake in Box

Use the `box` skill for authentication and operations. For mechanics, use `box/references/content-workflows.md`, `box/references/ai-and-retrieval.md`, `box/references/mcp-search.md`, `box/references/mcp-doc-gen.md`, and `box/references/collaboration.md` as relevant.

## Workflow

1. Resolve the intake folder and record the relevant file IDs and versions. Cite the original files rather than an AI answer, and state when a result applies to an earlier version because a source changed. Identify the firm's required-document checklist; if it is not already supplied or identifiable, ask for it before assessing completeness.
2. Inventory the submission. In one cited multi-file pass when practical, check each required item for presence, readability, apparent completeness, and observable required fields or signatures, while extracting names, aliases, entities, jurisdictions, values, and other screening inputs.
3. Distinguish missing material from content that is present but unreadable, unsupported, truncated, or otherwise not assessed. Do not call the intake complete while a required item is unrepresented.
4. Use standard structured extraction by default and enhanced extraction only when the user explicitly requests it. Send the cited screening inputs to the firm's approved conflicts, sanctions, PEP, or similar systems; Box AI does not provide clearance.
5. Present the findings, then ask whether the user wants metadata written if the request did not already decide that. Use folder metadata for matter-level status and assignment, file metadata for document facts, or the firm's canonical intake file when that is its record model.
6. Route a summary comment or add access only when requested. Check the item's audience first; put privileged analysis, internal screening information, and other restricted reasoning in an internal artifact when the source has broader collaborators. Do not claim a plain comment targeted or notified a specific person.
7. When requested, generate an engagement-letter draft from the approved template and merge data. Record the template version, destination, output ID, and draft status; check an uncertain asynchronous batch before resubmitting.



## Intake output

Use one entry per checklist requirement. Label it **present and assessed**, **present but not assessed**, **missing**, or **not applicable**, then include the source citation, observed facts, limitation, and next action.

Example:

```text
Requirement: Beneficial ownership form
Status: Present but not assessed
Evidence: ownership-form.pdf, page 1
Limitation: pages 2–3 are unreadable
Next action: request a readable replacement before completeness approval
```

List screening inputs separately, for example: `Acme Holdings LLC — named in intake-form.pdf §2 — send to the firm's conflicts/sanctions system; no clearance conclusion made.`

Useful extracted fields include client and matter name, practice area, jurisdiction, value, and owner. Final risk, acceptance decision, assigned attorney, and decision date come from the authorized firm process and may be written only after approval.

When metadata was not requested, use a direct prompt such as: “I extracted the matter-level and document-level fields above. Do you want me to write them to the firm's existing Box metadata template?”

## Boundaries

- Completeness findings may be automated; authenticity, legal validity, sufficiency, client acceptance, risk rating, staffing, and clearance remain firm or attorney decisions.
- A model may apply documented criteria as preliminary analysis, but preliminary observations must not occupy final-decision metadata fields.
- Do not place preliminary screening hits or other restricted reasoning in broadly visible metadata or comments.
- A generated engagement letter remains a draft until authorized approval. Do not share it externally until approved, and use the audience and access specified by the user or clarify them when ambiguous.

View saved version →

---
name: box-legal-workflows-ma
description: "Build and operate M&A deal rooms in Box: design a transaction-specific due-diligence structure, populate and classify documents, manage scoped access, audit sharing, and answer cited cross-document diligence questions. Use for M&A, VDRs, deal rooms, transaction due diligence, mergers, or acquisitions."
---

# M&A deal rooms in Box

Use the `box` skill for authentication and operations. For mechanics, use `box/references/bulk-operations.md`, `box/references/content-workflows.md`, `box/references/collaboration.md`, `box/references/mcp-search.md`, and `box/references/ai-and-retrieval.md` as relevant.

## Workflow

1. Distinguish a request to plan or analyze from a request to build or modify the room. Use the firm's approved deal-room template when available. Otherwise analyze the transaction prompt, propose a practical numbered folder tree, and confirm it before creating folders.
2. Classify source documents from names and metadata, using content analysis when those are insufficient. Then add, move, or copy them according to the intended record model. Preserve originals when classification is uncertain, and record both IDs when a copy is intentional.
3. Apply internal access at the narrowest useful folder level: deal leads and legal teams may need broader editing access, while finance and other specialists receive their functional subset. MCP cannot grant Co-owner; use Editor or direct the user to a supported Box UI/path.
4. Scope diligence to the request. For a targeted question, use folder-scoped search and then report the analyzed file IDs, versions, and cited findings. For a room-wide review, inventory the expected file IDs and versions and report exclusions, unreadable files, or failures; do not claim complete-room coverage unless that inventory was assessed. Use standard structured extraction when extracting terms.
5. After presenting diligence findings, ask whether the user wants extracted terms or summaries persisted to the firm's metadata schema if the request did not already decide that.
6. Keep a manifest for build and access work: relevant folder IDs, source file IDs and versions, collaboration IDs with audience/scope/role, and unresolved failures.
7. Share externally only at the end of the workflow. Audit the target and relevant ancestors first, then apply the specified audience, folder scope, role or link settings, and expiration and verify the result. Ask only for missing consequential choices; do not claim a complete audit when collaboration listing has partial failures.

## Folder and diligence examples

Derive the tree from the transaction type, requested workstreams, source documents, and user roles. Number folders for stable ordering, but do not create generic categories that the deal does not need.

Example for a software-company acquisition:

```text
Project Cedar VDR/
├── 01 - Corporate & Governance/
├── 02 - Financial & Tax/
├── 03 - Material Contracts/
├── 04 - Employment & Benefits/
├── 05 - Intellectual Property & Technology/
└── 06 - Regulatory & Compliance/
```

Return each diligence finding with the question, assessed file scope, cited finding, coverage gap, and attorney decision needed.

```text
Question: Which contracts require change-of-control consent?
Scope: 42 files in 03 - Material Contracts; 2 unreadable
Finding: Three agreements contain consent language [file and section citations]
Coverage gap: Two unreadable files remain unassessed
Decision needed: Attorney interpretation of whether each clause is triggered
```

## Boundaries

- Folder access covers current and future descendants; do not grant root access when a curated subset is sufficient.
- External counsel receives an appropriate working area, auditors the relevant financial subset, and a prospective buyer a curated subset rather than root access by default.
- Initial collaboration creation does not set expiration. When expiration is required and supported by enterprise policy, update the returned collaboration ID afterward.
- Deal risk, materiality, privilege, and term interpretation remain attorney decisions. The model may identify facts, differences, and preliminary issues under documented criteria.
- Keep the manifest and verification results as the audit trail.

View saved version →

---
name: box-legal-workflows-ocg
description: "Review outside counsel guidelines, billing guidelines, and outside counsel requirements in Box. Use to compare an OCG with a firm playbook, identify cited obligations or variances, recommend responsible teams, draft an issue register, or add one cited Box comment per issue."
---

# OCG review in Box

Use the `box` skill for authentication and operations. For mechanics, use `box/references/ai-and-retrieval.md` and `box/references/collaboration.md` as relevant.

## Assessment basis

- **Playbook comparison:** Use an applicable firm playbook, approved position, or review standard as the baseline. Report a variance only when a cited OCG term differs from a cited firm control, position, threshold, or process. If the playbook is silent, label the item **uncovered requirement**.
- **OCG-only operational assessment:** Use after the user confirms that no playbook will be used. An explicit statement such as “we do not have a playbook” is already confirmation—proceed without asking again. Identify obligations, ambiguities, internal conflicts, approvals, deadlines, and likely process effects; do not claim firm-policy deviation or noncompliance.

Choose the basis before issue analysis. If the user supplied a playbook, use it. If they explicitly said none exists or should be used, proceed OCG-only. Otherwise ask them to identify the applicable playbook; do not silently assume either basis.

## Workflow

1. Resolve the intended OCG and record its Box file ID and version. Apply the assessment-basis rule above, and record the baseline file ID and version when a playbook is used.
2. Review every section, subsection, schedule, and appendix. Maintain an internal ledger with section, locator, requirements, assessment basis, status, and issue IDs. Return a compact coverage summary unless the user asks for the full ledger.
3. If any material is unreadable, truncated, unsupported, or otherwise unrepresented, identify the gap and continue with the assessable sections without claiming complete review.
4. For each issue, cite the OCG and the playbook when applicable. Separate source facts, supported impact, model inference, and attorney decisions.
5. Recommend the team with the first concrete action. Use a firm ownership map when available; otherwise use the fallback below. Treat routing as a recommendation, not a binding assignment.
6. If the user asked only for review or drafting, return the issue preview and do not post comments. If they explicitly asked to add comments, create one self-contained comment per independent issue without another confirmation round, then verify and retain the comment IDs. Clarify only when write-back intent is ambiguous.
7. Report the assessment basis, source versions, coverage gaps, issue and written-comment counts, recommended teams, unresolved attorney decisions, relevant Box IDs, and failures. If a source changes during review, state that the result applies to the recorded version.

## Issue taxonomy and citations

Use the narrowest applicable label: **playbook variance**, **process change**, **approval or exception**, **deadline or reporting duty**, **ambiguity**, **internal conflict**, **uncovered requirement**, or **attorney decision**.

Split independent requirements when their impacts, owners, or resolutions differ. Keep related text together when separating it would make the issue misleading.

Prefer section or subsection number and heading, then a verified page, numbered paragraph or line, then a short identifying excerpt. Cite the original files rather than an AI answer and never invent locators.

## Fallback owner routing

- Rates, budgets, invoices, time-entry, e-billing: **Billing Operations**; support from Matter Team or Finance
- Staffing, matter plans, status reports: **Matter Team**; support from Legal Operations
- Engagement terms, conflicts, ethics, privilege: **Responsible Attorney**; support from Ethics or General Counsel
- Security, breach notice, access controls: **Information Security**; support from Privacy or Matter Team
- Personal data, transfers, privacy retention: **Privacy**; support from Information Security or Records
- Records, destruction, holds, file return: **Records Management**; support from Matter Team or Privacy
- Diversity or supplier reporting: **Legal Operations**; support from HR/DEI or Matter Team
- Taxes, payment terms, currency, expenses: **Finance**; support from Billing Operations
- Insurance: **Risk Management**; support from Finance or Responsible Attorney
- Publicity or client-name use: **Marketing/Communications**; support from Responsible Attorney
- Portals and technical onboarding: **IT**; support from Information Security or Legal Operations
- Client-owned business terms or obligations: **Client Legal/Business Team**; support from Matter Team

Use a firm-provided map instead. Add a supporting team only when needed. Never infer a person's identity; keep the team label when identity is ambiguous, and do not claim a plain comment creates a targeted mention or notification.

## Issue preview and comment format

For each issue include a stable ID, citation, requirement, variance or concern, concrete impact, suggested resolution, recommended owner, and any attorney decision.

Before commenting, check the file's audience. Do not expose confidential playbook text or privileged internal analysis in a comment visible to client or external collaborators; put detailed comparison in a restricted internal artifact when necessary.

Use this shape and shorten it to the current tool limit without dropping its required elements:

```text
Citation: [verified OCG locator; playbook locator only when appropriate for the audience]
Risk/impact: [supported consequence; label inference or attorney judgment]
Suggested resolution: [practical option and any required approval]
Recommended owner: [team label]
```

## Legal boundary

Describe concrete operational or legal-review impact, but do not provide final legal advice, approve a deviation, set a binding risk rating, or make a binding assignment.