{"id":19960,"plugin_id":"plugins_6aa118e4284081918b44f45b58d06de6","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:15:58.489Z","digest":"e73ed18272b4288cd59b8e32e81161b5f451e30f6135d767ca5be2c386c26c43","against":null,"payload":{"name":"new-matter","description":"Open a litigation matter through a human-confirmed intake that records the parties, role, side, forum, engagement and authority, conflicts posture, emergency dates, preservation posture, status, stable identifiers, and field-level provenance. Use when a new dispute, claim, subpoena, regulatory inquiry, investigation, or pre-suit threat needs a controlled matter record and a handoff to organize-case-docs.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":278},{"relative_path":"references/first-matter-setup.md","size_in_bytes":4554},{"relative_path":"references/matter-record-template.md","size_in_bytes":4464},{"relative_path":"references/preservation-at-intake.md","size_in_bytes":6015}],"skill_md_contents":"---\nname: new-matter\ndescription: >-\n  Open a litigation matter through a human-confirmed intake that records the\n  parties, role, side, forum, engagement and authority, conflicts posture,\n  emergency dates, preservation posture, status, stable identifiers, and\n  field-level provenance. Use when a new dispute, claim, subpoena, regulatory\n  inquiry, investigation, or pre-suit threat needs a controlled matter record\n  and a handoff to organize-case-docs.\n---\n\n# New Matter\n\n## Outcome and boundaries\n\nCreate a reviewable matter record and a clear next-step handoff. This skill organizes what the human supplies; it does not decide whether a conflict exists, establish representation, give a merits opinion, compute a legal deadline, issue a legal hold, contact anyone, send or file anything, calendar an event, or mutate an external system. Any authorized read-only retrieval is a source lookup, not a clearance or other decision.\n\nThe record is an intake and routing artifact, not a pleading, legal opinion, conflict certificate, engagement letter, preservation notice, or merits assessment. Unknown, disputed, and unverified facts remain visible.\n\nOnly confirmed `[new-matter]` entries in `lqplaybook.md` may shape this work. Never read `lqprofile.md` during intake and never write either file; the scribe owns journey updates. A preference revealed during intake may be proposed as an exact `[new-matter]` line, but it affects future work only after the user explicitly confirms it. Never put client-confidential facts into a playbook or journey record.\n\n## Tool and source cascade\n\nUse the host's available local file and document-reading capability first. If a user-authorized matter-management, document, or legal-process system is available, use it only for the narrow read the user approved and preserve its returned receipt or locator. Durable writes stay in the user-designated workspace; if an external store is the only available destination, return the approved record as unsaved unless the user separately authorizes that external write. If a capability is unavailable, continue with user-provided files and mark the missing source; never claim that a configured integration was checked merely because it is listed.\n\n## Intake posture\n\nAsk no more than three focused questions in one turn, then wait. Reuse answers and documents already supplied in this session, but do not infer missing representation, party identity, side, forum, conflict status, deadline, or preservation facts from tone, filenames, or ambient context.\n\nIf the request is only “open a matter” without enough information to identify the engagement, begin with the smallest useful batch:\n\n1. Who is the client or represented entity, who are the known opposing or affected parties, and what happened in one or two sentences?\n2. What is our role and side, and what court, tribunal, regulator, arbitration forum, or pre-suit setting is involved?\n3. Is there an emergency date, a human-asserted conflicts posture, or a preservation concern that must be visible now?\n\nIf the user supplies a complete intake, do not repeat these questions. Ask only for the gaps that would change routing or safety.\n\n### Workspace defaults and first use\n\nPerform a read-only architecture check only in the current workspace, a matter root the user identifies, or a host-selected matter root whose scope is visible. Look for an index, stable-ID marker or convention, matter-record template, workspace README, recognizable folder pattern, source manifest, or matter-management record. Report `architecture_check: found | not-found | ambiguous | unavailable`; a failed, inaccessible, or unclear check is not `not-found`.\n\nIf a usable architecture is found, summarize its markers and offer to use it while preserving its paths, identifiers, naming, and access boundaries. Do not create a parallel layout or migrate it merely because it differs from the packaged recommendation. If the result is ambiguous or unavailable, show the candidates or access gap and ask the user; do not guess.\n\nIf the check is `not-found`, or the user says this is their first matter and no architecture is known, offer to create the minimum reusable defaults before saving. Read [first-matter-setup.md](references/first-matter-setup.md) only if the user accepts that offer or asks to customize setup. A standalone matter record remains available if the user declines. Reusable behavioral preferences still require confirmed `[new-matter]` playbook entries; workspace defaults never become an ambient firm profile.\n\n## Step 1: Establish the source boundary and check for a possible duplicate\n\nUse, in order:\n\n1. Facts and files the user supplies in this session.\n2. A matter index or workspace the user explicitly identifies for a read-only duplicate check.\n3. A user-named source system, only if the host can actually retrieve the requested record.\n\nAssign each supplied source a stable source ID such as `SRC-001`. Record its human-readable locator, source kind, and what fields it supports. A source that cannot be opened is still recorded as `unreadable` or `unavailable`; it is not silently treated as absent.\n\nNormalize the proposed title and principal party names only to search for possible duplicates. If an existing record could be the same engagement, show the candidate and ask whether to update it or create a distinct matter. Do not silently merge, overwrite, or create a second record. A duplicate search that was not run is recorded as `duplicate_check: not-run`, not as “no duplicate.”\n\n## Step 2: Capture identity and parties\n\nRecord exact names as supplied, along with the role each entity or person plays:\n\n- Matter title used by the team.\n- Client or represented entity, including the internal business unit if applicable.\n- Opposing, adverse, responding, investigated, issuing, or otherwise affected parties.\n- Known counsel, insurer, regulator, court, agency, or arbitrator.\n- Case, docket, claim, investigation, subpoena, or reference number if supplied.\n- How the matter arrived: complaint, demand, subpoena, regulatory inquiry, internal report, investigation, or pre-suit threat.\n- One-sentence factual description, limited to what the user or a supplied source states.\n\nKeep entity names distinct. Do not collapse a parent, subsidiary, affiliate, officer, insurer, or counsel into “the other side.” If an entity's relationship is unclear, record it as `relationship: unknown` and ask a focused question.\n\n## Step 3: Capture role, side, and forum\n\nRecord the human-selected values; do not infer them from the caption alone:\n\n- **Representation role:** `plaintiff | claimant | defendant | respondent | subpoena-recipient | investigated-party | witness | neutral-third-party | other | unknown`.\n- **Side:** `claimant-side | defense-side | neutral-third-party | mixed | unknown`.\n- **Forum:** `court | arbitration | regulator | administrative | internal-investigation | pre-suit | unknown`.\n- **Jurisdiction and venue:** exact court, tribunal, agency, governing jurisdiction, and venue when supplied.\n- **Governing law:** only if supplied or identified in a source; do not treat the forum as the governing law.\n- **Procedural posture and stage:** `inquiry | threatened | active | stayed | resolved | closed | unknown`, plus `pre-suit | pleadings | discovery | dispositive-motion | trial | appeal | regulatory | investigation | unknown`.\n\nStore the basis for each choice as `user_asserted`, `source_stated`, `derived-pending-confirmation`, or `unknown`. A derived role or side is a prompt for confirmation, never a confirmed field.\n\n## Step 4: Record conflicts and engagement as human-verified assertions\n\nThis skill records a conflicts posture; it does not run a conflicts search. Use exactly one of:\n\n`cleared | pending | not-run | waived | unknown`\n\nFor every value, capture:\n\n- The person's or team's assertion, in concise words.\n- `verified_by` and `verified_at`, if supplied.\n- `method` as the human describes it, such as firm system, client list, outside counsel, or informal review.\n- Names and entity variants checked, including known affiliates, adverse counsel, and key witnesses when supplied.\n- Scope, limitations, and any exception or waiver reference.\n- Source IDs supporting the assertion.\n\nNever convert absence of a conflict note into `cleared`. Never report that a database, firm system, or connector was queried unless the host actually returned a result. If the user says “cleared,” record `status: cleared`, `basis: user_asserted`, and the assertion metadata; do not upgrade it to a system-verified result.\n\nRecord engagement separately from conflicts:\n\n- `not-engaged | proposed | signed | declined | unknown`.\n- Client or represented entity, scope, effective date, and termination or expiry if supplied.\n- Outside counsel or internal legal team, lead, and contact details if supplied.\n- Who may instruct counsel, sign a communication, approve a settlement, authorize spend, or make an emergency decision.\n- Any authority limit, reservation, or required escalation, with its source and confirmation state.\n\n“Counsel named” is not the same as “engaged,” and “engaged” is not the same as “authorized to settle or act.” Keep those fields separate.\n\n## Step 5: Screen emergency dates without inventing law\n\nAsk for dates that could change the immediate route:\n\n- Date received, served, discovered, or escalated.\n- Any response, objection, cure, hearing, filing, production, interview, appeal, or preservation deadline.\n- Source-stated date, time, and time zone.\n- Whether the date is legal, procedural, contractual, business, or unknown.\n- Whether an extension, tolling agreement, or human calculation has been confirmed.\n\nDo not calculate a deadline from a rule, service date, business-day convention, or time zone unless the user supplies the calculation or separately authorizes a current authority check. Preserve both the source-stated date and any human-provided calculation.\n\nFor an intake as of a known date, record the as-of date and use these workflow labels only:\n\n- `overdue` — the supplied date has passed.\n- `imminent` — the supplied date is within seven calendar days.\n- `near-term` — the supplied date is eight to thirty calendar days away.\n- `future` — the supplied date is more than thirty calendar days away.\n- `unknown` — the date or comparison basis is incomplete.\n\nAn overdue or imminent item gets a visible `URGENT — HUMAN REVIEW NOW` flag, the source and uncertainty, and a recommendation to contact qualified counsel or the official source promptly. The flag does not send, file, calendar, extend, or otherwise execute anything.\n\n## Step 6: Record preservation posture\n\nAsk the human to state whether a preservation duty or concern has been identified. Record the answer and its basis rather than deciding the legal question:\n\n- `not-assessed | not-triggered-asserted | anticipated-asserted | hold-requested | hold-issued | released | unknown`.\n- Triggering event and date.\n- Hold owner, notice date, scope, custodians, systems, date range, and refresh or release information if supplied.\n- Known gaps, including inaccessible systems, missing custodians, auto-delete concerns, or unclear ownership.\n- Source IDs supporting each field.\n\nFor a new litigation matter, subpoena, investigation, or credible pre-suit threat, remind the user to raise promptly with the client or responsible legal team whether counsel has assessed the preservation trigger and whether reasonable steps have been taken to identify and preserve potentially relevant information. Do not imply that opening a matter proves a duty arose or that a litigation-hold notice alone satisfies it.\n\nIf preservation posture is `not-assessed`, `hold-requested`, unknown, incomplete, disputed, or urgent, read [preservation-at-intake.md](references/preservation-at-intake.md) and surface the gap prominently. For a U.S. federal civil matter, offer a focused preservation-planning handoff to `document-discovery`. For another forum, offer forum-specific preservation research and planning, using `regulatory` to retrieve controlling official text when appropriate; do not treat the federal workflow as controlling. Do not issue, release, or modify a hold from this skill.\n\n## Step 7: Capture status and immediate routing\n\nStatus is a human-verified assertion, not a machine inference. Record:\n\n- `status`: `inquiry | threatened | active | stayed | resolved | closed | unknown`.\n- `status_basis`: `user_asserted | source_stated | derived-pending-confirmation | unknown`.\n- `status_verified_by`, `status_verified_at`, and `status_source_ids` when supplied.\n- Current stage, immediate decision or need, next known date, and responsible human if supplied.\n- Related matters and the reason for each relationship, without reading across them unless the user explicitly authorizes that review.\n\nIf the user has not made a status call, use `unknown` or `inquiry` only with an explicit rationale such as “initial intake only”; do not silently label a matter active because a document exists.\n\n## Step 8: Build the stable record and provenance ledger\n\nUse the template in [matter-record-template.md](references/matter-record-template.md). The record must contain:\n\n- A stable `matter_id` assigned once after the user accepts the proposed identity. It may use a user-approved slug and collision-safe suffix, but it must never be regenerated from a later title edit or reused for a different matter.\n- `record_version`, `record_state`, creation date, last-updated date, and the approver for the current version.\n- Field-level provenance: each material field points to one or more source IDs and states whether it is `user_asserted`, `source_stated`, `derived-pending-confirmation`, or `unknown`.\n- A complete list of open questions, blockers, unavailable sources, and human decisions still required.\n- The exact action boundary: what this skill prepared and what it did not do.\n\nDo not store credentials, access tokens, hidden prompts, or unrelated client matters. Keep source locators relative or user-provided where possible, and preserve original source wording when a status, conflicts, authority, or date assertion matters.\n\n## Step 9: Preview before writing\n\nBefore any durable write, show:\n\n1. The proposed `matter_id`, title, and record state.\n2. The role, side, forum, status, conflicts posture, engagement, authority, emergency dates, and preservation posture.\n3. Open questions, possible duplicates, unavailable sources, and every field marked derived or unknown.\n4. The proposed handoff to `organize-case-docs`, including the source IDs and requested outputs.\n5. A plain statement that no conflict search, legal hold, calendar entry, contact, filing, service, upload, or other external action has occurred.\n\nAsk for an unambiguous approval of both the displayed record and its save destination, or for an edit or pause. Ordinary language such as “looks good, save that record there” is sufficient; praise or a request to continue that does not clearly authorize the displayed save is not.\n\nIf the user does not approve, return the preview and do not write. If the host cannot write to the user-designated location, return the complete record in the template format and say that it remains unsaved.\n\n## Step 10: Save and hand off\n\nAfter explicit approval, write only the approved record to the user-designated matter workspace. Do not overwrite an existing record without an explicit update instruction and a versioned diff. If the user's canonical matter store is external, do not write to it unless the user separately authorizes that external action; return the approved record as unsaved instead. Re-read the saved bytes if the host permits and report the path or locator, record version, stable ID, and any write limitation.\n\nDo not automatically start another skill. Offer an explicit handoff to `organize-case-docs` with:\n\n- `matter_id` and record version.\n- Approved source IDs and their locators.\n- Requested outputs, such as document inventory, chronology, issue framework, claim/element chart, or source-gap report.\n- Privilege, confidentiality, disclosed-document, or use restrictions the human supplied.\n- Unresolved questions and inaccessible sources.\n- A statement that `organize-case-docs` must independently apply its own source, privilege, and approval gates.\n\nIf no documents were supplied, the handoff says `awaiting sources`; it does not invite the next skill to invent a corpus or infer facts.\n\n## Output contract\n\nThe terminal response contains:\n\n- `Intake result`: `preview-ready | saved | paused | blocked-on-information | write-unavailable`.\n- Stable `matter_id` and `record_version` when assigned.\n- A one-screen summary of identity, role/side/forum, status, conflicts assertion, engagement/authority, urgency, and preservation.\n- Open questions and blockers, with source IDs where relevant.\n- Architecture-check result and the existing or proposed workspace convention, if any.\n- The exact save path or an explicit unsaved notice.\n- Handoff details for `organize-case-docs`.\n- External actions not taken.\n\n## Guardrails\n\n- Never certify conflicts, representation, authority, preservation, status, or deadline accuracy on the skill's own judgment.\n- Never turn a missing field into a reassuring default. Use `unknown`, `not-run`, `pending`, or `not-assessed`.\n- Never compute or quote a legal deadline without a supplied source or a separately verified authority record.\n- Never merge matters, cross-read another matter, or reuse an ID without explicit human direction.\n- Never issue or release a legal hold, contact counsel or a party, create a calendar event, send or file a document, or upload source material.\n- Keep the human's role, side, forum, and authority choices distinct; do not flatten them into a generic “client matter.”\n- Treat a possible duplicate, an overdue/imminent date, an unresolved conflict, and a preservation gap as visible blockers or warnings, not silent routing decisions.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}