JUNE

View saved version →

---
name: june-create-case-document
description: Create a case document in JUNE from an approved template, supplied text, or an uploaded local file. Use when a user asks to draft, render, file, or upload a document for a specific JUNE case, including DOCX and PDF output.
---

# Create a JUNE case document

Identify the exact case first. Document creation writes data and can create duplicates, so do not guess identifiers or retry automatically.

## Choose the path

### JUNE template

1. Resolve the case with `get_case_by_reference` or `get_case_context`.
2. Call `list_document_templates` for that case before creation.
3. Select only a returned `template_id`, supported output format, and returned addressee `participant_id`. A contact ID is not a participant ID.
4. If the template is blocked or the intended addressee is absent, explain the missing participant role. Use `create_contact` and `add_case_participant` only when the user asks to add that participant.
5. Confirm the case, template, addressee, format, and any claims-account options when they are not already explicit.
6. Call `create_case_document` once.

For PDF, report the filed document ID. For DOCX, surface the short-lived download URL immediately and explain that the file is not yet filed in the case. If the template is designed for interactive editing, retain that warning.

### Text document

Use `create_document_from_text` only after confirming the target case, safe filename, direction, document type, and final text. Preserve user-supplied wording unless asked to edit it.

### Local file upload

Use `request_document_upload` and `finalize_document_upload` only when both tools are available and the client can upload the file bytes to the returned URL with every required header. Resolve `document_type` with `get_value_list` first. Use only letters, digits, spaces, dot, hyphen, and underscore in filenames.

If the client cannot perform the binary upload, tell the user to download or edit the file and file it through JUNE instead of pretending the upload completed.

## Safety and result

Every `create_case_document` call creates a new document. After an error or timeout, check the case before retrying. Do not expose a short-lived download URL beyond the user who requested it. Report the case reference, filename, output format, whether it was filed, document ID when present, and the required next step.

Referenced files: 1

View saved version →

---
name: june-maintain-casework
description: Create and update ordinary case-management records in JUNE safely. Use when a user asks to create or modify a case, contact, case participant, note, deadline, appointment, or document metadata. Use the dedicated facts skill for Case Facts or Document Facts.
---

# Maintain JUNE casework

Resolve the target and required identifiers before changing data. Use JUNE's current record as the source of truth.

## Prepare the change

1. Identify the authenticated user and relevant permissions with `whoami` or `get_user_permissions` when authorization is material.
2. Resolve the case with `get_case_by_reference` or another read tool. Never infer a case ID.
3. Read the current target record before updating it.
4. Resolve controlled values instead of inventing IDs:
   - mandates: `list_mandates`
   - roles, deadline types, appointment types, document types, and other reference values: `get_value_list`
   - contacts: `search_contacts`, then `get_contact` for the selected match
5. If multiple targets or values remain plausible, ask the user to choose.

## Apply the requested operation

Use the narrowest matching tool:

- new records: `create_case`, `create_contact`, `add_case_participant`, `create_note`, `create_deadline`, or `create_appointment`
- existing records: `update_case`, `update_document`, or `update_appointment`

For `add_case_participant`, select an existing contact or create one first, resolve the exact role with `get_value_list("Roles")`, and never confuse contact ID with participant ID.

Use `$june-manage-facts` for `update_casefact`, `create_document_facts`, or `update_document_facts`; those operations require their own schemas and version rules.

Before a destructive-hint update, summarize the exact target and replacement values and obtain explicit confirmation unless the user's latest instruction already states that exact target and change. Do not silently overwrite existing values. Never broaden a requested change to adjacent fields or records.

Create operations may produce duplicates. Do not retry a successful or ambiguous write automatically; read the record back first.

## Report the result

State what changed, identify the case and affected record, and include returned IDs or deep links. If the tool returns an error or an ambiguous outcome, preserve the current state and explain the next safe check.

Referenced files: 1

View saved version →

---
name: june-manage-facts
description: Read, interpret, create, and update Case Facts and Document Facts in JUNE using their live schemas. Use when a user asks about structured case data, extracted document fields, fact schemas, field groups, allowed values, or requests a change to a Case Fact or Document Fact.
---

# Manage JUNE facts

Treat Case Facts and Document Facts as separate systems. Always read the live schema before writing, use exact keys from that schema, and preserve unrelated current values.

## Work with Case Facts

1. Resolve the case with `get_case_by_reference`, then call `get_case_context`.
2. Read from the context:
   - `mandate_id`
   - mandate-specific values and version in `case_facts`
   - global values and version in `case_facts_without_mandate`
   - `is_archived` and `is_read_only`; do not write facts when either blocks changes
3. Load both applicable schema scopes:
   - `get_casefact_schema(mandate_id=<case mandate>)`
   - `get_casefact_schema(mandate_id=-1)` for global Case Facts
4. Use `get_all_casefact_schemas` only for cross-mandate discovery. Use `list_mandates` when a mandate name must be resolved.
5. Match the requested field by schema label, then retain its exact `guid_key`, `data_type`, allowed values, `disabled`, `is_fieldgroup`, and source mandate. Never guess a GUID or treat a global field as mandate-specific. Do not write a disabled field.

For a scalar Case Fact:

1. Check allowed values in the schema.
2. Call `format_casefact_value` with the schema's data type and the user's raw value.
3. Stop if formatting fails or an enum value is not allowed. If the user includes a unit or currency but the schema field is numeric, confirm that only the numeric component will be stored; do not silently encode the unit in a number field.
4. Use the version from the matching current facts block. If no block exists, use a version only when the matching schema or tool result establishes it; otherwise ask instead of guessing.
5. Call `update_casefact` with the exact case ID, GUID key, formatted value, matching mandate ID, and version.

For a Case Fact with `is_fieldgroup=true`:

1. Call `get_fieldgroup_schema(field_group_keys=[<casefact guid>])`.
2. Use only returned column GUID keys and data types.
3. Read and preserve the current `fieldGroupValues`. The tool replaces the complete row collection for that field; never send only a partial row update.
4. Show the full resulting row collection and obtain explicit confirmation before calling `update_casefact` with `{"fieldGroupValues": [...]}`.
5. Stop if the field-group schema is missing or the current rows cannot be represented without loss.

## Work with Document Facts

1. Resolve the document and verify that it belongs to the intended case. Read that case with `get_case_context` and do not write facts when the case is archived or read-only.
2. Call `get_document_facts(document_id)` for current values.
3. Always call `get_document_fact_schema(document_id)` before a write. Use the exact returned field label or key, type, `allowed_values`, and `group` flag.
4. Stop for `group=true`; the exposed create and update tools support only single-value Document Facts.
5. Use `create_document_facts` only for schema-defined fields that are currently absent.
6. Use `update_document_facts` only for fields that already exist, with labels or keys exactly as returned by `get_document_facts`.
7. If the stored value already equals the requested value, make no write.
8. Treat each mapping as all-or-nothing: an unknown, grouped, already-present, or invalid field rejects the complete request. Do not mix creates and updates in one call.

## Confirm, write, and verify

Before `update_casefact` or `update_document_facts`, show the old value, new value, target case or document, schema field, and scope, then obtain explicit confirmation unless the latest user instruction already states that exact change. For creates, summarize the exact new fields and target.

Call each write once. Separate Case-Fact and Document-Fact calls are not one transaction: execute them in the confirmed order, verify each result, and stop the remaining writes after a failure while reporting any partial success. After an error or timeout, read the facts again before retrying. After success, re-read with `get_case_context` or `get_document_facts` and report the stored value, target ID, field label, and field key.

Referenced files: 1

View saved version →

---
name: june-prepare-correspondence
description: Draft or send controlled outgoing correspondence from a JUNE case and its filed documents. Use when a user asks to prepare or send an email or beA dispatch, select case attachments, resolve an eligible case participant's address, or start JUNE's outgoing-message and dispatch-check workflow.
---

# Prepare JUNE correspondence

Treat dispatch as an external, irreversible action. Never send to a guessed address, use documents from another case, or invent recipient, sender, or provider identifiers.

## Resolve the case and attachments

1. Resolve the case with `get_case_by_reference`, then call `get_case_context`. Stop if the case is archived or read-only instead of attempting a dispatch.
2. Select attachments from `get_all_documents_for_case`, `get_documents_by_ids`, or `azure_search`.
3. Verify every selected document belongs to the resolved case. Keep the first document as the master unless the user designates another one.

## Resolve the recipient and address

1. Select an active entry from `get_case_context.case.participants`. Retain its `id` as the participant ID and its `contact_id` as the recipient contact ID.
2. Call `get_contact(contact_id)` for the full contact. Read the available `emailAddresses` from that result; the case context intentionally does not include them.
3. If starting with `search_contacts`, call `get_contact` for the chosen match and verify that its contact ID occurs among the selected case's participants. A contact search result alone is not an eligible recipient.
4. If the contact is not yet a case participant, stop. Offer `add_case_participant` only when the user asks to add the contact, and resolve the role with `get_value_list("Roles")`.
5. If no E-mail address is stored, stop. Never substitute an address supplied outside the selected contact record.
6. If several addresses are stored, show them and ask the user to choose the exact destination.
7. Pass the chosen address as both `email` and `send_to` unless the user explicitly selects two different addresses from that same eligible participant. The server validates both fields independently.

## Resolve sender and channel

1. Use the case's `clerk_id` from `get_case_context` or the authenticated caller ID from `whoami`; no other sender ID is permitted.
2. For this tool contract, use provider type 2 for E-mail and provider type 1 for beA.
3. Draft subject and body in the user's language. Do not add unsupported factual or legal assertions.

## Confirmation boundary

If the user asks only to prepare or draft correspondence, return the draft and do not call `process_dispatch_document`.

Immediately before an actual send, show:

- case reference
- channel
- participant and contact ID
- recipient name and exact destination address
- subject and complete body
- document IDs, filenames, master document, and attachment order
- sender identity

Obtain explicit confirmation of that complete summary. An earlier general request to prepare correspondence is not permission to send.

## Send and report

Call `process_dispatch_document` once after confirmation. The tool starts the actual dispatch and creates the outgoing-message record before it attempts to create the later dispatch-check task. The check task is not a pre-send approval gate.

Never retry automatically after a timeout or ambiguous response. Inspect `get_outgoing_messages_for_case` and `get_tasks_for_case` first because the message may already have been dispatched even when task creation failed.

Report dispatch status, outgoing-message or dispatch ID, check-task status and ID, and any manual review still required. If validation rejects a recipient, address, sender, or attachment, stop and correct the verified JUNE record rather than bypassing the check.

Referenced files: 1

View saved version →

---
name: june-research-case
description: Research and summarize a legal matter in JUNE without changing data. Use when a user asks to find a case, inspect its context, documents, Case Facts, Document Facts, deadlines, appointments, tasks, notes, or messages, compare case records, or answer a case-related question from JUNE evidence.
---

# Research a JUNE case

Use JUNE as the source of truth and keep this workflow read-only.

## Find the case

1. Use `get_case_by_reference` when the user supplies a case reference.
2. Use `get_recent_cases` for a recent matter, `search_cases_by_casefact` for a known structured fact, or `azure_search` for a content search.
3. When more than one case matches, show the distinguishing reference, title, and parties and ask the user to choose. Never guess a case ID.

## Build the evidence

1. Start with `get_case_context` for the selected case.
2. Fetch only the records needed for the question:
   - documents: `get_all_documents_for_case`, then `get_documents_by_ids` or `get_document_content`
   - semantic document passages: `document_vector_search`
   - deadlines, appointments, tasks, notes, and messages: use the corresponding `get_*_for_case` tool
3. Page through long result sets when the answer depends on completeness.

## Interpret facts through their schemas

Treat Case Facts and Document Facts as different systems.

- For Case Facts, read values from `get_case_context`. Load `get_casefact_schema` once with the case's `mandate_id` and once with `mandate_id=-1` for global fields. If an entry has `is_fieldgroup=true`, call `get_fieldgroup_schema` with that field's GUID key before interpreting its rows.
- For a cross-mandate schema search, use `get_all_casefact_schemas`; use `list_mandates` to resolve a named mandate.
- For Document Facts, call `get_document_facts` for current values. Call `get_document_fact_schema(document_id)` when the answer depends on field type, allowed values, grouped status, or fields that are defined but currently empty.

Use schema labels for presentation and retain GUID keys or field keys for verification. Distinguish returned facts from interpretation. Do not invent missing dates, parties, amounts, field meanings, or legal conclusions.

## Respond

Answer in the user's language. Lead with the requested conclusion, then list the JUNE records supporting it. Include the case reference and useful record IDs or returned deep links so the user can verify the result. Minimize unnecessary personal data.

Do not call write tools in this skill. If the user asks to change facts, use `$june-manage-facts`; for other changes use the appropriate maintenance, document-creation, or correspondence workflow.

Referenced files: 1