Skip to main content

codexkit-contract-intake-router

Standardize incoming legal or commercial contract requests into request type, missing information, priority, and review queue. Use when the work is intake routing and request cleanup. Do not use for clause interpretation, negotiation strategy, or legal advice on the agreement itself.

Source facts

Repository
hoavdc/CodexKit
Last source activity
March 22, 2026 at 17:03
Detected SKILL.md language
English
Stars
26
Forks
12

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
codexkit-contract-intake-router
description
Standardize incoming legal or commercial contract requests into request type, missing information, priority, and review queue. Use when the work is intake routing and request cleanup. Do not use for clause interpretation, negotiation strategy, or legal advice on the agreement itself.
version
1.0.0
category
automation
# Contract Intake Router ## Purpose Clean up contract intake so legal review starts with the right information. ## When to use - requests arrive through email or chat with inconsistent detail - legal ops needs a clearer intake queue - the team wants to separate routing from legal analysis ## When not to use - the task is clause review or negotiation advice - the request needs legal judgment on risk allocation ## Inputs - intake requests or copied request list - requester, counterparty, deadline, and agreement type if available - routing rules if known ## Procedure 1. Normalize each request into request type, urgency, and owner. 2. Flag missing counterparty, deadline, or document context. 3. Separate routine routing from likely escalation items. 4. Group requests by review lane where possible. 5. End with missing-information follow-ups and next queue actions. ## Output - intake queue - missing information list - suggested routing lane - escalation candidates ## Definition of done - requests are easier to route than when they arrived - missing information is explicit - the output avoids pretending to be legal analysis ## Examples - "Clean up this legal inbox into request type, priority, and missing info." - "Turn these contract asks into a structured intake queue for legal ops." ## Quality Criteria - [ ] Trigger conditions and input requirements are unambiguous - [ ] Each automated step produces a verifiable output - [ ] Error handling and fallback paths are defined - [ ] Manual override points are documented ## Verification (4C) | Check | Question | |-------|----------| | **Correctness** | Does the workflow produce the expected output for the defined inputs? | | **Completeness** | Are all trigger conditions, edge cases, and error paths handled? | | **Context-fit** | Is the automation appropriate for the frequency and criticality of this task? | | **Consequence** | If this ran unattended and failed silently, what would the downstream impact be? | ## Edge Cases - **Input format varies unexpectedly** — Add a normalization step at entry. Alert the operator on format mismatches. - **Downstream system is unavailable** — Queue the output and retry with exponential backoff. Alert after N failures. - **Partial execution completes** — Ensure idempotency — re-running from the start produces the same result without duplication. ## Changelog - v1.0.0 — Initial release
View on GitHub