Post-merge cleanup: whitespace, doc sync, canonical skill names, root CLAUDE.md (#33)
Cleanup pass following the CoCounsel merge (#4) and Lexis removal (#5): - Normalize whitespace and JSON indentation across plugin metadata files - Sync marketplace.json with plugin.json (ip-legal description, Courtroom5 title field) - Add missing ai-inventory and invention-intake rows to README skill reference - Replace stale short-form skill names in customize/cold-start SKILL.md prose with canonical directory names across 11 plugins (same bug class as the /setup -> /cold-start-interview QA fix) - Fix FYY -> FYI typo and a phantom WebFetch claim in launch-radar docs - Address review findings: line-wrapped /check-claims, /renewals-due -> /renewal-tracker, stale /setup in references/, agent.yaml comment contradiction, redundant 'intake intake' - Add root CLAUDE.md with validation conventions (claude plugin validate, I1-I11 invariants, frontmatter requirements) and a marketplace.json description + $schema No behavioral changes. claude plugin validate passes clean.
This commit is contained in:
Tobin South
GitHub
parent
9cecd91b0f
commit
4d55f53962
35 changed files with 207 additions and 70 deletions
|
|
@ -1,5 +1,7 @@
|
|||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "claude-for-legal",
|
||||
"description": "Reference agents, skills, and data connectors for the legal workflows we see most — in-house commercial, privacy, product, corporate, employment, litigation, regulatory, AI governance, IP, and the learning side of the practice (law school clinics and students).",
|
||||
"owner": {
|
||||
"name": "Anthropic"
|
||||
},
|
||||
|
|
@ -95,7 +97,7 @@
|
|||
{
|
||||
"name": "ip-legal",
|
||||
"source": "./ip-legal",
|
||||
"description": "Runs first-pass trademark clearance and freedom-to-operate triage, drafts and triages cease-and-desist letters and DMCA takedowns (send and respond), checks open source compliance, reviews IP clauses, and tracks registrations and renewal deadlines.",
|
||||
"description": "Runs first-pass trademark clearance and freedom-to-operate triage, screens invention disclosures for initial patentability, drafts and triages cease-and-desist letters and DMCA takedowns (send and respond), checks open source compliance, reviews IP clauses, and tracks registrations and renewal deadlines.",
|
||||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
|
|
|
|||
130
CLAUDE.md
Normal file
130
CLAUDE.md
Normal file
|
|
@ -0,0 +1,130 @@
|
|||
# CLAUDE.md
|
||||
|
||||
Guidance for working on this repo. `claude-for-legal` is a Claude Code plugin
|
||||
marketplace — twelve first-party legal plugins, one vendor plugin, and five
|
||||
managed-agent cookbooks. Most work here is editing prompt content (skills,
|
||||
agents, hooks), plugin metadata, or cookbook config — not application code.
|
||||
|
||||
## Layout
|
||||
|
||||
```
|
||||
.claude-plugin/marketplace.json # the marketplace manifest — one entry per plugin
|
||||
<plugin>/ # 12 first-party plugins (commercial-legal, privacy-legal, ...)
|
||||
.claude-plugin/plugin.json # plugin manifest (name, version, description, author)
|
||||
.mcp.json # MCP servers the plugin connects to
|
||||
CLAUDE.md # practice-profile TEMPLATE (see "Plugin CLAUDE.md" below)
|
||||
README.md # per-plugin docs
|
||||
skills/<name>/SKILL.md # one skill per directory
|
||||
agents/<name>.md # subagent definitions
|
||||
hooks/hooks.json # hook config (most plugins ship an empty stub)
|
||||
.gitignore
|
||||
external_plugins/<vendor>/ # vendor-maintained plugins (CoCounsel)
|
||||
managed-agent-cookbooks/<name>/ # CMA agent.yaml + subagents/ + steering-examples.json
|
||||
scripts/ # validate.py, lint-tool-scope.py, orchestrate.py,
|
||||
# deploy-managed-agent.sh, test-cookbooks.sh
|
||||
references/ # shared templates (company-profile, dashboard)
|
||||
```
|
||||
|
||||
## Validation — run before opening a PR
|
||||
|
||||
This repo follows the same conventions `anthropics/claude-plugins-official`
|
||||
enforces in CI. Run the equivalent checks locally:
|
||||
|
||||
```bash
|
||||
# 1. Marketplace + per-plugin schema validation (source of truth)
|
||||
claude plugin validate .claude-plugin/marketplace.json
|
||||
for d in */; do [ -f "$d/.claude-plugin/plugin.json" ] && claude plugin validate "$d"; done
|
||||
claude plugin validate external_plugins/cocounsel-legal
|
||||
|
||||
# 2. Cookbook tool-scope lint (orchestrators must not over-grant tools)
|
||||
python3 scripts/lint-tool-scope.py
|
||||
|
||||
# 3. JSON/YAML sanity
|
||||
python3 -c "import json,glob; [json.load(open(f)) for f in glob.glob('**/*.json', recursive=True)]"
|
||||
```
|
||||
|
||||
### Marketplace invariants (I1–I11)
|
||||
|
||||
`claude-plugins-official` layers these on top of the schema check. They apply
|
||||
here too — the ones most likely to trip a contributor:
|
||||
|
||||
- **I1** — `plugins[]` should be alpha-sorted by name (case-insensitive).
|
||||
*Currently a known warning: the array is in a curated display order. If you
|
||||
add a plugin, ask before re-sorting the whole array.*
|
||||
- **I2** — no duplicate plugin names.
|
||||
- **I3** — `description` 10–2000 chars, no leading/trailing whitespace.
|
||||
- **I8** — every vendored `source` (`"./<dir>"`) must point at a directory that
|
||||
contains `.claude-plugin/plugin.json`.
|
||||
- **I9** — `source` paths/URLs must contain no shell metacharacters or `..`.
|
||||
- **I10** — no hidden Unicode (zero-width chars, bidi controls) in
|
||||
`name`/`description`.
|
||||
- **I11** — `name` must match `^[a-z0-9][a-z0-9-]{1,63}$`.
|
||||
|
||||
### Frontmatter requirements
|
||||
|
||||
Every `agents/*.md` needs `name` and `description`. Every
|
||||
`skills/<name>/SKILL.md` needs `description`. Every `commands/*.md` needs
|
||||
`description`. Multi-line descriptions use `>` block scalars and that's fine —
|
||||
`claude plugin validate` parses them correctly.
|
||||
|
||||
## Conventions
|
||||
|
||||
### Keep `marketplace.json` in sync with `plugin.json`
|
||||
|
||||
For first-party plugins, `marketplace.json`'s `name`, `description`, and
|
||||
`author` should match the plugin's own `.claude-plugin/plugin.json` field for
|
||||
field. If you change a plugin's description in one place, change it in the
|
||||
other.
|
||||
|
||||
### Skill names in prose must be canonical
|
||||
|
||||
When a `SKILL.md` (especially `customize` or `cold-start-interview`) tells the
|
||||
user "run `/foo`," `foo` must be the actual `skills/<foo>/` directory name.
|
||||
Short forms like `/triage` for `/use-case-triage` look right in prose but are
|
||||
dead commands — the user types them and nothing happens. Refs to Claude Code
|
||||
built-ins (`/mcp`, `/plugin`) and to other plugins (`/<other-plugin>:<skill>`)
|
||||
are fine.
|
||||
|
||||
### Plugin CLAUDE.md is a template, not project context
|
||||
|
||||
Each `<plugin>/CLAUDE.md` is a practice-profile template that the
|
||||
`cold-start-interview` skill copies to `~/.claude/plugins/config/claude-for-legal/<plugin>/CLAUDE.md`
|
||||
on the user's machine. It is *not* loaded as project context when the plugin is
|
||||
installed — `claude plugin validate` warns about this and the warning is
|
||||
expected. Don't "fix" it by moving the content into a skill.
|
||||
|
||||
### `external_plugins/` is vendor-maintained
|
||||
|
||||
Plugins under `external_plugins/` are built and maintained by the vendor
|
||||
(README.md has the policy). Don't change vendor-authored content without
|
||||
checking with them first; whitespace normalization and formatting are usually
|
||||
fine since the vendor lands changes via PR rather than mirroring a fork.
|
||||
|
||||
### Formatting
|
||||
|
||||
- 2-space indent in all JSON and `.mcp.json` files.
|
||||
- Final newline at end of every text file.
|
||||
- No trailing whitespace.
|
||||
- Markdown tables: pipe-aligned columns are nice but not required; just keep
|
||||
the column count consistent.
|
||||
|
||||
## Cookbooks
|
||||
|
||||
Each `managed-agent-cookbooks/<name>/` has `agent.yaml` (the orchestrator),
|
||||
`subagents/*.yaml` (the leaves), `steering-examples.json`, and `README.md`. Two
|
||||
rules that `scripts/lint-tool-scope.py` enforces:
|
||||
|
||||
1. The orchestrator gets local-only tools (`read`, `grep`, `glob`,
|
||||
`agent_toolset`); MCP and write tools belong to specific subagent leaves.
|
||||
2. The README's security table and the `agent.yaml` comments must match what
|
||||
the YAML actually grants. Don't claim a tool a subagent doesn't have.
|
||||
|
||||
## Things to leave alone
|
||||
|
||||
- Per-plugin `.gitignore` files differ slightly across plugins. Probably
|
||||
intentional; ask before unifying.
|
||||
- `hooks/hooks.json` is missing in two plugins. Hooks are optional; the missing
|
||||
files are not a bug.
|
||||
- `references/` lives only at repo root and is not shipped inside any plugin
|
||||
directory. Several plugin `CLAUDE.md` templates reference it as if it were —
|
||||
that's a known gap, not a thing to silently move.
|
||||
|
|
@ -150,7 +150,7 @@ managed-agent-cookbooks/ # Claude Managed Agent cookbooks — one dir per sched
|
|||
launch-radar/
|
||||
reg-monitor/
|
||||
renewal-watcher/
|
||||
scripts/ # deploy-managed-agent.sh · validate.py · orchestrate.py · lint-tool-scope.py
|
||||
scripts/ # deploy-managed-agent.sh · validate.py · orchestrate.py · lint-tool-scope.py · test-cookbooks.sh
|
||||
.claude-plugin/
|
||||
marketplace.json # plugin registry
|
||||
```
|
||||
|
|
@ -361,6 +361,7 @@ The full map across all plugins. The cold-start interview is the first thing to
|
|||
| Command | Skill | What it does |
|
||||
|---|---|---|
|
||||
| `/ai-governance-legal:cold-start-interview` | cold-start-interview | Cold-start — learns your AI governance practice |
|
||||
| `/ai-governance-legal:ai-inventory` | ai-inventory | EU AI Act per-system inventory — track each system's role and risk tier |
|
||||
| `/ai-governance-legal:use-case-triage` | use-case-triage | Classify AI use case — approved, conditional, or no |
|
||||
| `/ai-governance-legal:aia-generation` | aia-generation | Run an AI impact assessment in house format |
|
||||
| `/ai-governance-legal:vendor-ai-review` | vendor-ai-review | Review vendor AI terms against governance positions |
|
||||
|
|
@ -465,6 +466,7 @@ The full map across all plugins. The cold-start interview is the first thing to
|
|||
| `/ip-legal:cold-start-interview` | cold-start-interview | Cold-start — learn your IP practice and posture |
|
||||
| `/ip-legal:clearance` | clearance | Trademark clearance first pass — knockout + similar marks |
|
||||
| `/ip-legal:fto-triage` | fto-triage | Freedom-to-operate triage, not an FTO opinion |
|
||||
| `/ip-legal:invention-intake` | invention-intake | Invention disclosure first-pass screen — novelty, obviousness, §101, bar dates |
|
||||
| `/ip-legal:cease-desist` | cease-desist | Draft a C&D or triage one you received |
|
||||
| `/ip-legal:takedown` | takedown | DMCA notice, response triage, or §512(g) counter-notice |
|
||||
| `/ip-legal:infringement-triage` | infringement-triage | Infringement triage across all four IP rights |
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@ positions and house style.
|
|||
| Command | Does |
|
||||
|---|---|
|
||||
| `/ai-governance-legal:cold-start-interview` | Cold-start interview — writes your practice profile |
|
||||
| `/ai-governance-legal:ai-inventory [list \| add \| edit \| classify \| show]` | Manage the EU AI Act per-system inventory — track each system's role and risk tier |
|
||||
| `/ai-governance-legal:use-case-triage [use case]` | Classify a use case against your registry (approved / conditional / never) |
|
||||
| `/ai-governance-legal:aia-generation [use case]` | Run an AI impact assessment (AIA) in your house style |
|
||||
| `/ai-governance-legal:vendor-ai-review [vendor/file]` | Review a vendor AI agreement against your positions |
|
||||
|
|
@ -45,6 +46,7 @@ positions and house style.
|
|||
| Skill | Purpose |
|
||||
|---|---|
|
||||
| **cold-start-interview** | Writes `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` from interview + seed docs |
|
||||
| **ai-inventory** | EU AI Act per-system inventory — role (provider, deployer, importer, distributor, authorized rep, product manufacturer) and risk tier per system |
|
||||
| **use-case-triage** | Classifies use cases against the registry; flags missing assessments |
|
||||
| **aia-generation** | AI impact assessment (AIA) in house format |
|
||||
| **vendor-ai-review** | AI-specific vendor contract review against governance positions |
|
||||
|
|
|
|||
|
|
@ -269,7 +269,7 @@ that's where to go deep first.
|
|||
### Part 2: Regulatory footprint (2-3 min)
|
||||
|
||||
> Which regulations are actually on your radar? I don't want to assume — tell me
|
||||
> what's real for you. (This feeds /gap-check and /policy-monitor — the gap analysis diffs new regulations against your stated scope, and policy-monitor only watches regimes you've marked in scope.)
|
||||
> what's real for you. (This feeds /reg-gap-analysis and /policy-monitor — the gap analysis diffs new regulations against your stated scope, and policy-monitor only watches regimes you've marked in scope.)
|
||||
|
||||
**Do not assume any regulation applies. Ask the user which regimes they think apply, then research the AI-specific regulations currently in effect or pending in the jurisdictions where the company operates, deploys AI, or has affected parties. This landscape changes quickly — verify currency.**
|
||||
|
||||
|
|
@ -336,7 +336,7 @@ walk through each one.
|
|||
|
||||
**The red lines question:**
|
||||
> "What's the use case that's an automatic no — the thing someone could propose
|
||||
> and you'd stop them immediately without needing to think about it?" (This feeds /triage — the skill checks proposed AI use cases against these red lines before doing anything else, and flags anything on the list as automatic stop.)
|
||||
> and you'd stop them immediately without needing to think about it?" (This feeds /use-case-triage — the skill checks proposed AI use cases against these red lines before doing anything else, and flags anything on the list as automatic stop.)
|
||||
|
||||
Common categories to probe if they're slow: biometric data, emotion detection,
|
||||
political/religious inference, fully automated adverse decisions affecting employment
|
||||
|
|
@ -360,7 +360,7 @@ or credit, uses involving children.
|
|||
|
||||
**Escalation:**
|
||||
|
||||
> "When a review finds something that needs someone more senior to sign off — a vendor AI agreement with training-on-data or liability issues, an AI use case that doesn't fit your registry, a regulatory gap that needs a decision, or a call above your authority — who does that go to? Give me a name or a role (the GC, the Chief Privacy Officer, your boss), or say 'I decide myself.' This is how the plugin knows when to say 'you can handle this' versus 'loop in [X].' (This feeds every skill's routing logic — /triage, /review-vendor-ai, and /gap-check all check the escalation matrix before telling you to hand something up.)"
|
||||
> "When a review finds something that needs someone more senior to sign off — a vendor AI agreement with training-on-data or liability issues, an AI use case that doesn't fit your registry, a regulatory gap that needs a decision, or a call above your authority — who does that go to? Give me a name or a role (the GC, the Chief Privacy Officer, your boss), or say 'I decide myself.' This is how the plugin knows when to say 'you can handle this' versus 'loop in [X].' (This feeds every skill's routing logic — /use-case-triage, /vendor-ai-review, and /reg-gap-analysis all check the escalation matrix before telling you to hand something up.)"
|
||||
|
||||
Also ask:
|
||||
- Has anything been escalated to the board or C-suite over AI in the last year?
|
||||
|
|
@ -374,7 +374,7 @@ Also ask:
|
|||
### Part 5: Seed documents (3-4 min)
|
||||
|
||||
> "I want to see what you actually have. Tell me which of these exist, and share
|
||||
> what you can. (The AI policy feeds /policy-monitor drift detection; the prior impact assessment becomes the /aia-generation template; the vendor agreements become the starting playbook for /review-vendor-ai.)"
|
||||
> what you can. (The AI policy feeds /policy-monitor drift detection; the prior impact assessment becomes the /aia-generation template; the vendor agreements become the starting playbook for /vendor-ai-review.)"
|
||||
>
|
||||
> 1. **AI or acceptable use policy.** Your internal or public-facing policy on how
|
||||
> AI can and can't be used. This tells me your committed positions.
|
||||
|
|
|
|||
|
|
@ -70,9 +70,9 @@ cold-start interview and without hand-editing YAML.
|
|||
conditional rather than approved, surface more AIA follow-ups, and
|
||||
recommend more conservative vendor AI redlines."
|
||||
- *Adding an escalation contact:* "Every skill that routes escalations
|
||||
(`/triage`, `/review-vendor-ai`, `/gap-check`) will now include this
|
||||
(`/use-case-triage`, `/vendor-ai-review`, `/reg-gap-analysis`) will now include this
|
||||
contact on the relevant risk bands."
|
||||
- *New use case registry entry:* "`/triage` will match against this entry
|
||||
- *New use case registry entry:* "`/use-case-triage` will match against this entry
|
||||
on its next run. Existing AIAs aren't rewritten — re-run them if you want
|
||||
the new posture reflected."
|
||||
|
||||
|
|
@ -92,7 +92,7 @@ cold-start interview and without hand-editing YAML.
|
|||
|
||||
- **Never delete a section.** If the user wants to "remove" something, set it
|
||||
to `[Not configured]` and explain what that means for the plugin's behavior.
|
||||
("Removing your escalation chain means `/triage` will flag escalation-worthy
|
||||
("Removing your escalation chain means `/use-case-triage` will flag escalation-worthy
|
||||
items but won't route them to a specific person.")
|
||||
- **Flag internal inconsistency.** If the change would make the profile
|
||||
inconsistent (e.g., risk posture aggressive + escalation "everything goes to
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ Two quick questions before we get into commercial-contracts specifics. These sha
|
|||
|
||||
#### Who's using this?
|
||||
|
||||
> Who'll be using this plugin day to day? (This feeds the work-product header on every /review, /amendment-history, and /renewals-due output — lawyer gets "PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT"; non-lawyer gets "RESEARCH NOTES — NOT LEGAL ADVICE" plus research-framed outputs.)
|
||||
> Who'll be using this plugin day to day? (This feeds the work-product header on every /review, /amendment-history, and /renewal-tracker output — lawyer gets "PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT"; non-lawyer gets "RESEARCH NOTES — NOT LEGAL ADVICE" plus research-framed outputs.)
|
||||
>
|
||||
> 1. **Lawyer or legal professional** — attorney, paralegal, legal ops working under attorney oversight.
|
||||
> 2. **Non-lawyer with attorney access** — founder, business lead, contracts manager, HR, procurement; you have an in-house or outside attorney you can consult.
|
||||
|
|
@ -347,7 +347,7 @@ If they don't have one: proceed with the questions below.
|
|||
|
||||
**Approval levels**
|
||||
|
||||
> When a review finds something that needs someone more senior to sign off — a term that's above playbook (a higher LoL cap, an indemnity structure outside your fallbacks), a risk that needs a second opinion, or a decision that's above your authority — who does that go to? Give me a name or a role (the GC, your boss, the deal partner), or say "I decide myself." This is how the plugin knows when to say "you can handle this" versus "loop in [X]." (This feeds /escalate — the skill drafts the escalation ask using this matrix, and /review uses it to decide whether a flagged term lands in your lane or somebody else's.)
|
||||
> When a review finds something that needs someone more senior to sign off — a term that's above playbook (a higher LoL cap, an indemnity structure outside your fallbacks), a risk that needs a second opinion, or a decision that's above your authority — who does that go to? Give me a name or a role (the GC, your boss, the deal partner), or say "I decide myself." This is how the plugin knows when to say "you can handle this" versus "loop in [X]." (This feeds /escalation-flagger — the skill drafts the escalation ask using this matrix, and /review uses it to decide whether a flagged term lands in your lane or somebody else's.)
|
||||
|
||||
**Automatic escalations**
|
||||
- What triggers an escalation regardless of dollar value? (Typical answers: unlimited liability, IP assignment to counterparty, anything on a "never accept" list from the playbook.)
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ cold-start interview and without hand-editing YAML.
|
|||
anything above 6 months as a deviation; existing deal-debrief entries
|
||||
stay as logged."
|
||||
- *New escalation approver:* "Any redline exceeding your own authority
|
||||
will now route to this approver — `/escalate` will include them by
|
||||
will now route to this approver — `/escalation-flagger` will include them by
|
||||
default for the matching risk band."
|
||||
- *Risk posture middle → aggressive:* "I'll accept more vendor-friendly
|
||||
positions without flagging them and shift the `[review]` bar higher."
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -6,4 +6,4 @@
|
|||
"name": "Thomson Reuters",
|
||||
"email": "cocounselsupport@tr.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
{
|
||||
"mcpServers": {
|
||||
"cocounsel-legal": {
|
||||
"type": "http",
|
||||
"url": "https://legal-mcp.thomsonreuters.com/mcp",
|
||||
"oauth": {
|
||||
"clientId": "QCgP4IGN5JiLqXRHxiAVr3wu1ySo2nQx"
|
||||
}
|
||||
}
|
||||
"mcpServers": {
|
||||
"cocounsel-legal": {
|
||||
"type": "http",
|
||||
"url": "https://legal-mcp.thomsonreuters.com/mcp",
|
||||
"oauth": {
|
||||
"clientId": "QCgP4IGN5JiLqXRHxiAVr3wu1ySo2nQx"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ CoCounsel Legal brings Westlaw Deep Research into Claude for CoCounsel Legal sub
|
|||
|
||||
## Example use cases
|
||||
|
||||
1. Research how California courts have treated non-compete agreements for executive employees since 2020.
|
||||
1. Research how California courts have treated non-compete agreements for executive employees since 2020.
|
||||
2. I asked you to research California non-competes earlier. Can you now retrieve the full report?
|
||||
3. Follow up on that research: how does Texas law differ on executive non-competes for the same period?
|
||||
|
||||
|
|
@ -43,4 +43,4 @@ Any questions answerable from caselaw, statutes, regulations, administrative mat
|
|||
### Links
|
||||
|
||||
- **Documentation:** https://legal-mcp.thomsonreuters.com/docs/connector-guide
|
||||
- **Support:** cocounselsupport@tr.com
|
||||
- **Support:** cocounselsupport@tr.com
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -58,13 +58,13 @@ hand-editing YAML.
|
|||
what changes downstream, confirm, write it to the config.
|
||||
|
||||
Examples:
|
||||
- *Adding a new class:* "`/outline` will scaffold a new outline for this
|
||||
- *Adding a new class:* "`/outline-builder` will scaffold a new outline for this
|
||||
class. `/flashcards` will add a new subject bucket. `/cold-call-prep`
|
||||
will ask for a seat and a topic when you invoke it for this class."
|
||||
- *Learning style Socratic → summary-first:* "`/drill` won't ask you to
|
||||
- *Learning style Socratic → summary-first:* "`/socratic-drill` won't ask you to
|
||||
answer first — it'll present the rule and example, then quiz you on
|
||||
application."
|
||||
- *Adding a bar subject:* "`/bar-prep` will include this subject in
|
||||
- *Adding a bar subject:* "`/bar-prep-questions` will include this subject in
|
||||
rotation and weight it higher if you mark it weak."
|
||||
|
||||
5. **Close.**
|
||||
|
|
@ -81,7 +81,7 @@ hand-editing YAML.
|
|||
inconsistent (e.g., "summary-first" learning style + "maximum pushback"
|
||||
Socratic setting), flag the tension.
|
||||
- **Flag guardrail degradation.** The "no rewriting your writing" rule on
|
||||
`/write` and `/irac` is load-bearing — the value of the skill is
|
||||
`/legal-writing` and `/irac-practice` is load-bearing — the value of the skill is
|
||||
structural feedback, not ghost-writing. If the user asks to turn that off,
|
||||
confirm they understand that the plugin will not write their work for
|
||||
them.
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,11 +43,11 @@ whole cold-start interview and without hand-editing YAML.
|
|||
community skills from
|
||||
- **Update preferences** — check cadence (daily / weekly / on demand),
|
||||
notification channel (Slack / in-session), auto-update vs. prompt
|
||||
- **QA strictness** — how aggressively `/qa` flags issues on a candidate
|
||||
- **QA strictness** — how aggressively `/skills-qa` flags issues on a candidate
|
||||
skill before install (lenient / middle / strict), and which
|
||||
failure-mode checks are on
|
||||
- **Skill install defaults** — install scope (user / project), whether
|
||||
to run `/qa` automatically before install
|
||||
to run `/skills-qa` automatically before install
|
||||
- **Integrations** — Slack / document storage status, fallbacks
|
||||
|
||||
3. **Ask what they want to change.**
|
||||
|
|
@ -59,9 +59,9 @@ whole cold-start interview and without hand-editing YAML.
|
|||
what changes downstream, confirm, write it to the config.
|
||||
|
||||
Examples:
|
||||
- *Adding a new watched registry:* "`/browse` will search this registry
|
||||
alongside the existing ones. `/update` will check it on its next run."
|
||||
- *QA strictness strict → middle:* "`/qa` will report the same findings
|
||||
- *Adding a new watched registry:* "`/registry-browser` will search this registry
|
||||
alongside the existing ones. `/auto-updater` will check it on its next run."
|
||||
- *QA strictness strict → middle:* "`/skills-qa` will report the same findings
|
||||
but not block install on the medium band unless you confirm."
|
||||
- *Auto-update on → off:* "The hub will prompt you before applying
|
||||
updates instead of applying them automatically."
|
||||
|
|
@ -88,7 +88,7 @@ whole cold-start interview and without hand-editing YAML.
|
|||
profile that doesn't match any installed plugin), flag the tension.
|
||||
- **Flag guardrail degradation.** The Legal Skill Design Framework checks
|
||||
(nine design parameters, three legal failure modes, trust-surface check)
|
||||
are what `/qa` exists to run — turning them off defeats the point. If the
|
||||
are what `/skills-qa` exists to run — turning them off defeats the point. If the
|
||||
user wants to lower strictness, recommend the middle band rather than
|
||||
disabling the check.
|
||||
- **One change at a time.** Don't re-ask the whole interview.
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -21,7 +21,8 @@
|
|||
"Courtroom5": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.courtroom5.com",
|
||||
"description": "Courtroom5 — jurisdiction-aware guidance for self-represented litigants: case intake, deadline calculations, procedural next steps"
|
||||
"title": "Courtroom5",
|
||||
"description": "Courtroom5 — jurisdiction-aware guidance for self-represented litigants: case intake, deadline calculations, procedural next steps."
|
||||
},
|
||||
"Descrybe": {
|
||||
"type": "http",
|
||||
|
|
|
|||
|
|
@ -62,11 +62,11 @@ re-running the whole cold-start interview and without hand-editing YAML.
|
|||
what changes downstream, confirm, write it to the config.
|
||||
|
||||
Examples:
|
||||
- *Adding a new practice area:* "`/intake` will route matters of this
|
||||
- *Adding a new practice area:* "`/client-intake` will route matters of this
|
||||
type through the new template. `/draft`, `/memo`, and `/client-letter`
|
||||
will use the practice-area prompts. `/research-start` will add the
|
||||
corresponding Westlaw search terms."
|
||||
- *Supervision style informal → formal review queue:* "`/queue` becomes
|
||||
- *Supervision style informal → formal review queue:* "`/supervisor-review-queue` becomes
|
||||
active — student output will land there for supervisor sign-off before
|
||||
it goes to the client."
|
||||
- *New semester rollover:* "I'll archive the prior semester's active
|
||||
|
|
@ -82,7 +82,7 @@ re-running the whole cold-start interview and without hand-editing YAML.
|
|||
|
||||
- **Never delete a section.** If the user wants to "drop" a practice area,
|
||||
offer to mark it `[Archived]` and explain that archiving keeps case
|
||||
history accessible but hides the template from `/intake` routing.
|
||||
history accessible but hides the template from `/client-intake` routing.
|
||||
- **Flag internal inconsistency.** If the change would make the profile
|
||||
inconsistent (e.g., formal review queue on + informal supervision note;
|
||||
or practice area on + no jurisdiction rules configured), flag the
|
||||
|
|
@ -90,7 +90,7 @@ re-running the whole cold-start interview and without hand-editing YAML.
|
|||
- **Flag guardrail degradation.** These are load-bearing and should not be
|
||||
removed: the "NOT final work product" framing on `/draft`, plain-language
|
||||
standards on client-facing outputs, "does NOT decide case acceptance" on
|
||||
`/intake`, "NOT substantive advice" on `/client-letter`, and the
|
||||
`/client-intake`, "NOT substantive advice" on `/client-letter`, and the
|
||||
scaffold-not-analysis framing on `/memo`. These exist because students
|
||||
ship work product — if the safeguards go, the risk of student work
|
||||
reaching a client without supervisor review goes up. Confirm the
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ cold-start interview and without hand-editing YAML.
|
|||
what changes downstream, confirm, write it to the config.
|
||||
|
||||
Examples:
|
||||
- *Side mixed → defense-only:* "`/new-matter` intake will stop asking the
|
||||
- *Side mixed → defense-only:* "`/matter-intake` will stop asking the
|
||||
plaintiff-side questions. `/demand-draft` will still work for
|
||||
defense-side pre-suit demands but the starting frame will be different."
|
||||
- *Risk calibration tightening high-risk threshold:* "More inbound
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Tracker tickets are untrusted input. A product manager can put arbitrary text in
|
|||
| Tier | Touches untrusted tracker content? | Tools | Connectors |
|
||||
|---|---|---|---|
|
||||
| **`tracker-reader`** | **Yes** | `Read`, `Grep` only | Linear, Jira (atlassian), Asana (read-only) |
|
||||
| `risk-classifier` / Orchestrator | No | `Read`, `Grep`, `Glob`, `WebFetch`, `Agent` | Orchestrator only: Linear / Jira / Asana / Drive (read-only) |
|
||||
| `risk-classifier` / Orchestrator | No | `Read`, `Grep`, `Glob`, `Agent` | Orchestrator only: Linear / Jira / Asana / Drive (read-only) |
|
||||
| **`memo-writer`** (Write-holder) | No | `Read`, `Write`, `Edit` | None |
|
||||
|
||||
`tracker-reader` returns a length-capped, schema-validated JSON list of launches. `risk-classifier` has no MCP and no network; it works from the validated list plus the user's calibration file. `memo-writer` is the only worker with Write, and produces `./out/launch-radar-<date>.md`. The orchestrator holds no Write and never parses raw ticket bodies itself.
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ system:
|
|||
informed by this memo. Do not soften that framing in the memo.
|
||||
|
||||
tools:
|
||||
# Orchestrator is scoped to local-only tools; MCP and web_fetch are held by
|
||||
# the subagent leaves (see callable_agents).
|
||||
# Orchestrator is scoped to local-only tools; MCP is held by the
|
||||
# subagent leaves (see callable_agents).
|
||||
- type: agent_toolset_20260401
|
||||
default_config: { enabled: false }
|
||||
configs:
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ system:
|
|||
You receive the validated feed-item list from the feed-reader. You classify
|
||||
each item against the deploying team's watchlist and materiality threshold
|
||||
(read from the regulatory-legal configuration on disk — regulators
|
||||
watched, policy-area tags, and the "always material / review-worthy / FYY"
|
||||
watched, policy-area tags, and the "always material / review-worthy / FYI"
|
||||
tiers).
|
||||
|
||||
For each item, emit exactly one classification:
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -63,10 +63,10 @@ cold-start interview and without hand-editing YAML.
|
|||
what changes downstream, confirm, write it to the config.
|
||||
|
||||
Examples:
|
||||
- *Sub-processor notice 30 days → 14 days:* "`/review-dpa` will now flag
|
||||
- *Sub-processor notice 30 days → 14 days:* "`/dpa-review` will now flag
|
||||
anything shorter than 14 days as a deviation. Existing DPAs stay as
|
||||
logged."
|
||||
- *New DSAR exemption in the playbook:* "`/draft-dsar` will surface this
|
||||
- *New DSAR exemption in the playbook:* "`/dsar-response` will surface this
|
||||
exemption in the assessment step where the facts match."
|
||||
- *Risk posture middle → conservative:* "I'll flag more activities for
|
||||
PIA escalation, recommend stricter SCC clauses, and be more
|
||||
|
|
@ -95,7 +95,7 @@ cold-start interview and without hand-editing YAML.
|
|||
tension.
|
||||
- **Flag guardrail degradation.** The `[review]` flag, source attribution
|
||||
tags, `[verify]` tags on cited regulations, and the DPIA-trigger
|
||||
mandatory-check on `/triage` are load-bearing — do not remove. If
|
||||
mandatory-check on `/use-case-triage` are load-bearing — do not remove. If
|
||||
statutory DSAR timelines are adjusted below the regulatory minimum,
|
||||
refuse and explain why.
|
||||
- **One change at a time.** Don't re-ask the whole interview.
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -62,12 +62,12 @@ cold-start interview and without hand-editing YAML.
|
|||
|
||||
Examples:
|
||||
- *Risk calibration tightening "fine" → "needs a real look" for a
|
||||
pattern:* "`/triage` and `/launch-review` will start flagging this
|
||||
pattern:* "`/is-this-a-problem` and `/launch-review` will start flagging this
|
||||
pattern. Existing reviews stay as written; re-run if you want the new
|
||||
posture applied."
|
||||
- *New launch-review category:* "`/launch-review` will add a section for
|
||||
this category. `/is-this-a-problem` will pattern-match it in triage."
|
||||
- *Marketing claims posture tightening:* "`/check-claims` will flag more
|
||||
- *Marketing claims posture tightening:* "`/marketing-claims-review` will flag more
|
||||
language as needing substantiation or reframing."
|
||||
|
||||
5. **For shared-profile changes** (company name, industry, jurisdictions,
|
||||
|
|
@ -93,6 +93,6 @@ cold-start interview and without hand-editing YAML.
|
|||
launch requires GC sign-off"), flag the tension.
|
||||
- **Flag guardrail degradation.** The `[review]` flag, source attribution
|
||||
tags, and `[verify]` tags on cited regulations are load-bearing — do not
|
||||
remove. The substantiation requirement on claims is the thing `/check-
|
||||
claims` exists for; weakening it defeats the skill.
|
||||
remove. The substantiation requirement on claims is the thing
|
||||
`/marketing-claims-review` exists for; weakening it defeats the skill.
|
||||
- **One change at a time.** Don't re-ask the whole interview.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Company Profile
|
||||
|
||||
*Shared by all Claude for Legal plugins. The first plugin you set up writes this; the rest read it.
|
||||
Edit directly or re-run any plugin's `/setup` to update.*
|
||||
Edit directly or re-run any plugin's `/cold-start-interview` to update.*
|
||||
|
||||
**Practice setting:** [Solo/small firm | Midsize/large firm | In-house | Government/legal aid/clinic]
|
||||
**Name:** [Company or firm name]
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@
|
|||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,11 +43,11 @@ without hand-editing YAML.
|
|||
to each, owner per policy
|
||||
- **Materiality threshold** — when a regulatory change rises to
|
||||
"notable" vs. "report" vs. "digest only"; how this threshold filters
|
||||
`/watch` output
|
||||
`/reg-feed-watcher` output
|
||||
- **Gap response process** — who triages, SLA per severity, downstream
|
||||
owners (policy, product, training)
|
||||
- **Feed configuration** — regulator feeds, Thomson Reuters
|
||||
connectors, cadence of the `/watch` sweep, digest channel
|
||||
connectors, cadence of the `/reg-feed-watcher` sweep, digest channel
|
||||
- **People** — regulatory counsel, policy owners, comment drafter,
|
||||
escalation chain
|
||||
- **Workflow** — matter workspaces, open gaps tracker, comment deadline
|
||||
|
|
@ -64,13 +64,13 @@ without hand-editing YAML.
|
|||
what changes downstream, confirm, write it to the config.
|
||||
|
||||
Examples:
|
||||
- *Adding a regulator to the watchlist:* "`/watch` will sweep this
|
||||
regulator on its next run. `/diff` will accept inputs from this
|
||||
- *Adding a regulator to the watchlist:* "`/reg-feed-watcher` will sweep this
|
||||
regulator on its next run. `/policy-diff` will accept inputs from this
|
||||
regulator's rulemaking feed."
|
||||
- *Tightening materiality threshold:* "`/watch` digest will be
|
||||
- *Tightening materiality threshold:* "`/reg-feed-watcher` digest will be
|
||||
shorter — items below the new threshold will drop from the weekly
|
||||
digest but stay searchable."
|
||||
- *New policy added to the library:* "`/diff` will include this policy
|
||||
- *New policy added to the library:* "`/policy-diff` will include this policy
|
||||
when matching new rules against the library. The comment tracker
|
||||
will tag comments affecting this policy."
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue