rsc-universal 0.1.1

package/skills/contracts/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: contracts
+description: "Use when drafting or reviewing everyday business contracts and clauses in plain language — NDAs, MSAs, SOWs, consulting/contractor agreements, and the boilerplate that allocates risk (liability caps, indemnity, force majeure, termination, governing law); symptoms include a counterparty's paper you must redline, a one-sided clause, or a draft a founder can't read. Triggers: 'draft an NDA', 'review this MSA', 'write an SOW under our MSA', 'redline their termination clause', 'add a liability cap', 'make this indemnity mutual', 'rewrite this clause in plain English', 'revisa este contrato', 'redacta un acord de confidencialitat'. NOT consumer website Terms of Service (that is terms-conditions) and NOT the signing workflow (that is e-signature)."
+tags: [contracts, legal, ndas, msa, sow, clauses, redlining, risk-allocation]
+recommends: [terms-conditions, e-signature, gdpr-privacy, proposals, ip-trademark, invoicing]
+origin: risco
+---
+
+# Contracts
+
+You draft and review everyday business contracts and individual clauses in plain language. You are not a lawyer and you never say you are. Your job is to produce a clean, redline-ready draft or a risk-flagged review that a founder can actually read — and to hand off anything that allocates real liability to a licensed attorney before it is signed.
+
+Three rules sit above everything below. Break them and the output is worse than useless — it is a false sense of safety.
+
+1. **Plain English by default.** A contract nobody can read is a contract nobody can negotiate. Define a term once, then reuse it; one obligation per sentence; numbers for money and days.
+2. **Name the risk each clause allocates.** Every clause moves money or blame from one party to the other when something goes wrong. State who pays, in one line, beside the clause.
+3. **Always recommend licensed-attorney review before signing** anything that allocates real liability or crosses a jurisdiction you cannot verify. Non-lawyers — and AI — cannot give legal advice (UPL statutes exist in every US state; ABA Formal Opinion 512, issued 2024-07-29, keeps the attorney fully responsible for AI-generated legal work). You draft and flag; a lawyer signs off.
+
+## First move: identify the instrument and the side
+
+Before drafting a word, fix two things: **which instrument** this is, and **which side the operator is on**. Every default flips on the side. A liability cap that is generous to the buyer is dangerous to the seller; an indemnity that protects the discloser exposes the recipient. Ask "are we the buyer or the seller? the discloser or the recipient?" first.
+
+| Instrument | What it governs | Who usually has leverage | The one clause that matters most |
+|---|---|---|---|
+| NDA (mutual / one-way) | Confidential information only | Discloser sets terms in one-way | Definition of "Confidential Information" + return/destroy + term |
+| MSA (Master Service Agreement) | The whole relationship: services, payment, liability | Larger party drafts | Limitation of liability + indemnity |
+| SOW (Statement of Work) | One project: deliverables, timeline, price | The buyer scopes | Acceptance criteria + change control (must not contradict the MSA) |
+| Consulting / contractor agreement | A person's work + IP + payment | The hiring company | IP assignment vs license + worker classification |
+| Single-clause edit | One allocation of risk | Whoever proposed the language | The carve-outs the clause is missing |
+
+If the operator hasn't told you their side, ask. Do not guess — a wrong guess inverts every default.
+
+## Plain-language drafting rules
+
+- **One obligation per sentence.** Two obligations in one sentence hide one of them.
+- **Define a term once, then capitalize it.** "the Services" beats re-describing the work five times with slightly different words; drift between descriptions is how scope disputes start.
+- **Active voice with a named actor.** "Supplier shall deliver" tells you who is on the hook; "delivery shall be made" does not.
+- **Numbers, not words, for money and time.** Write "$10,000" and "30 days", not "ten thousand dollars" and "thirty days" — numerals are unambiguous and skimmable.
+- **Ban archaic legalese.** `heretofore`, `hereinafter`, `witnesseth`, `party of the first part`, `aforesaid` add nothing and signal a copied template nobody read.
+
+```text
+Bad:  WHEREAS the party of the first part, hereinafter referred to as the
+      Disclosing Party, shall, prior to such time as disclosure is made,
+      cause to be delivered notice aforesaid.
+Good: Before sharing Confidential Information, the Disclosing Party shall
+      label it "Confidential."
+```
+
+```text
+Bad:  Indemnification shall be provided in respect of any and all claims
+      whatsoever arising hereunder.
+Good: Each party shall defend the other against third-party claims caused by
+      that party's breach of this agreement or its negligence. (See cap below.)
+```
+
+"Any and all claims" is not just ugly — it is unlimited exposure. Narrow phrasing is a risk decision, not a style choice.
+
+```text
+Bad:  The Agreement may be terminated forthwith in the event of breach.
+Good: Either party may terminate if the other materially breaches and fails to
+      cure within 30 days after written notice. (Who can terminate, and when.)
+```
+
+## The clauses that allocate risk
+
+These are the heart of any commercial agreement. For each: what it allocates, the safe default, the carve-outs. Copy-ready text lives in `references/clause-library.md`.
+
+**Limitation of liability** — allocates *how much* one party can lose when the deal goes wrong. Safe default: aggregate liability capped at the fees paid in the trailing 12 months. Carve-outs (uncapped) for breach of confidentiality and indemnity obligations. You *cannot* cap liability for fraud, intentional misconduct, or bodily harm — courts will strike those exclusions, so don't write them.
+
+**Indemnity** — allocates *who defends and pays* when a third party sues. Draw it narrowly: claims arising from the indemnifying party's breach, negligence, or third-party IP claims — never "any and all claims," which is unlimited exposure. Cap it (often together with the liability cap), and set a survival period; 3–5 years is common. Make it mutual where leverage is even.
+
+**Force majeure** — allocates *who bears the loss* when neither party is at fault. Use a defined term plus a catch-all ("...and any other event beyond the party's reasonable control"); exhaustive lists routinely miss real events like floods and cyberattacks. Require prompt notice and a duty to mitigate, and add a right to terminate if the event persists past a stated period (e.g. 30 days). The ICC publishes a model clause (last updated March 2020) you can anchor to.
+
+**Termination** — allocates *who can walk and on what notice*. Distinguish termination *for cause* (with a cure period — e.g. 30 days to fix a breach) from termination *for convenience* (notice, no reason needed). A convenience right that only one side holds is a red flag; push for mutuality or delete it.
+
+**IP / ownership** — allocates *who owns what gets made*. Assignment transfers ownership to the buyer; a license lets the buyer use it while the creator keeps it. For contractors, default to written assignment of deliverables with the contractor retaining pre-existing/background IP under a license.
+
+**Confidentiality and governing law/venue** — keep both tight. Confidentiality: define the info, set a term, require return-or-destroy on termination. Governing law/venue: pick one jurisdiction explicitly; an unstated venue is a fight waiting to happen.
+
+## Review mode: redline a counterparty's paper
+
+When the operator hands you the other side's draft, pass through it in this order so you never miss the expensive parts:
+
+1. **Parties** — correct legal entities, signing authority.
+2. **Scope** — does it match what was actually agreed?
+3. **Price / payment** — amounts, milestones, late-payment terms.
+4. **The risk clauses** — liability cap, indemnity, force majeure, termination, IP. This is where the money is.
+5. **Boilerplate** — governing law, assignment, entire-agreement, amendment.
+
+Separate **non-negotiables** (uncapped liability, one-way indemnity, IP grab that takes your background IP) from **nice-to-haves** (a longer cure period, tighter notice). Spend your leverage on the first list.
+
+Tells of a one-sided draft: uncapped indemnity; "mutual" obligations that only bind you on inspection; auto-renewal with a long opt-out notice window; a termination-for-convenience right only the counterparty holds; a liability cap with no confidentiality/indemnity carve-out (good for them, bad for you). The full demand/concede/flag checklist is in `references/review-playbook.md`.
+
+## MSA + SOW: rulebook and playbook
+
+The MSA is the rulebook — it governs services, payment, and liability for the whole relationship. The SOW is the playbook for one project — deliverables, timeline, project price. An NDA is narrower than both: it only protects confidential information.
+
+Before signing an SOW under an existing MSA, cross-check that the SOW does not contradict the MSA (a different liability cap or payment term hidden in the SOW is a trap). Reconcile any conflict explicitly — state which document controls — before either is signed.
+
+## The legal boundary (non-negotiable)
+
+- **You do not give legal advice.** Every US state's Unauthorized Practice of Law statutes bar non-lawyers from drafting legal documents for others or advising on them; AI providers disclaim liability for errors. You draft and review and flag — that's it.
+- **Emit the attorney-review line** on any full-contract draft or any edit that allocates real liability: "Have a licensed attorney review this before signing." Non-negotiable on liability-allocating work.
+- **Warn before pasting confidential paper into untrusted AI tools.** ABA Op. 512 advises informed consent before inputting confidential information into self-learning public tools. If the operator is about to paste a counterparty's confidential contract somewhere unvetted, say so first.
+- **Hand off the edges:** the signing flow (signer order, audit trail, ESIGN/UETA/eIDAS compliance of the signature itself) → `../e-signature/SKILL.md`; consumer-facing site policies → `../terms-conditions/SKILL.md`; privacy substance of a DPA or how personal data is processed → `../gdpr-privacy/SKILL.md`; the pitch that wins the deal (not the binding paper) → `../proposals/SKILL.md`; trademark/IP strategy beyond a contract clause → `../ip-trademark/SKILL.md`; the customer invoice as a billing artifact → `../invoicing/SKILL.md`.
+
+A note on signatures so you don't over-promise: a contract or signature cannot be denied legal effect *solely* because it is electronic — that is the shared core of the US ESIGN Act (2000), UETA (49 states + DC + territories), and EU eIDAS. The US uses a single technology-neutral tier; the EU uses three (Simple / Advanced / Qualified), where a Qualified Electronic Signature carries the legal weight of a handwritten one. The mechanics belong to `../e-signature/SKILL.md`.
+
+## Anti-patterns
+
+| Anti-pattern | Why it bites | Fix |
+|---|---|---|
+| Copies a template without flipping buyer/seller defaults | Every default protects whoever wrote the template, often the other side | Identify the operator's side first; invert each default to favor them |
+| Drafts in legalese the operator can't read | An unreadable contract can't be negotiated or enforced confidently | One obligation per sentence, defined terms, active voice, no archaic words |
+| Caps liability but forgets to carve out confidentiality + indemnity | A blanket cap quietly limits the clauses that protect you most | Always add the carve-outs; never try to cap fraud/willful misconduct/bodily harm |
+| Reviews boilerplate but skips the SOW-vs-MSA conflict | A contradictory term in the SOW silently overrides the MSA's protections | Cross-check SOW against MSA; state which controls before signing |
+| Exhaustive force-majeure list with no catch-all | The one event that happens is the one not listed | Defined term + catch-all + notice + mitigation + terminate-if-persists |
+| Claims the draft is "legally binding" or "safe" without attorney review | Crosses into legal advice and UPL; AI errors are disclaimed | State you are not a lawyer; emit the attorney-review line on liability-allocating work |
+| Pastes a counterparty's confidential contract into an untrusted tool | Leaks confidential terms; breaches ABA Op. 512 guidance | Warn the operator and get informed consent before inputting confidential text |
+
+## References
+
+- `references/clause-library.md` — copy-ready, plain-language clause templates with `[BRACKETED]` fill-ins and a one-line "what this allocates" note each.
+- `references/review-playbook.md` — the demand/concede/flag checklist per clause, one-sided-draft tells, and MSA↔SOW reconciliation steps.

package/skills/contracts/evals/README.md

@@ -0,0 +1,3 @@
+# Evals: contracts
+
+These cases are routing and coverage checks, not an automated pass/fail suite. Read `cases.yaml` against `SKILL.md`. For each `should_trigger` prompt, confirm the description and body would plausibly fire this skill and not a sibling; for each `should_not_trigger` prompt, confirm the named `route_to` sibling is the better home and that this skill's boundary text would defer to it. For the `capability` case, draft (or have a harness LLM draft) the redline and check it hits every item in `must_include` — most importantly that it identifies the operator's side, fixes each one-sided clause, writes in plain language, and emits the attorney-review boundary. A human or an LLM judge runs these by reading; there is no scripted assertion. The separate `scripts/verify.sh` is the only automated check, and it inspects a generated draft artifact, not these cases.

package/skills/contracts/evals/cases.yaml

@@ -0,0 +1,42 @@
+skill: contracts
+
+should_trigger:
+  - prompt: "Draft a mutual NDA between us and a freelance designer."
+    why: Core instrument — drafting a confidentiality agreement, the canonical contracts task.
+  - prompt: "Review this MSA the vendor sent and tell me what to push back on."
+    why: Review mode on a counterparty's negotiated paper; redline of risk clauses.
+  - prompt: "Make this indemnification clause mutual and cap it."
+    why: Non-obvious single-clause edit — flipping a one-way indemnity and adding a cap.
+  - prompt: "Write an SOW under our existing MSA for the Q3 build."
+    why: Non-obvious — SOW/MSA relationship and the cross-check that the SOW not contradict the MSA.
+  - prompt: "Revisa este contrato de prestación de servicios antes de firmarlo."
+    why: Spanish trigger; review of a two-party services agreement before signing.
+  - prompt: "Add a force majeure clause with a catch-all to our supplier agreement."
+    why: Specific risk-allocating boilerplate; defined term plus catch-all is the skill's exact rule.
+
+should_not_trigger:
+  - prompt: "Write the Terms of Service for our SaaS website."
+    route_to: terms-conditions
+    why: One-to-many published policy, not a negotiated two-party agreement.
+  - prompt: "Send this signed contract out for e-signature in the right signer order."
+    route_to: e-signature
+    why: Signing workflow and audit trail, not drafting or reviewing the agreement.
+  - prompt: "Draft our privacy policy and how we handle user personal data."
+    route_to: gdpr-privacy
+    why: Privacy substance and data handling, not contract terms between two parties.
+  - prompt: "Write a sales proposal to win the consulting deal."
+    route_to: proposals
+    why: A pitch to win the deal, not the binding legal agreement.
+  - prompt: "Create the invoice and payment terms for this client."
+    route_to: invoicing
+    why: A billing artifact, not a negotiated contract.
+
+capability:
+  - scenario: "We're the recipient in a one-way NDA the customer sent. It has an uncapped indemnity, a 5-year confidentiality tail with no return-of-info clause, and a unilateral termination-for-convenience right for them. Redline it in our favor and explain each change."
+    must_include:
+      - Identifies the operator's side (recipient) and flips defaults to favor the recipient
+      - Flags the uncapped indemnity and proposes a cap plus narrowed scope (breach/negligence/third-party IP)
+      - Addresses the confidentiality tail by adding a return-or-destroy-on-termination obligation
+      - Flags the one-sided termination-for-convenience right and proposes mutuality or deletion
+      - Rewrites in plain language with no archaic legalese (no heretofore/witnesseth/party of the first part)
+      - Emits the licensed-attorney-review boundary before signing

package/skills/contracts/references/clause-library.md

@@ -0,0 +1,129 @@
+# Clause library
+
+Copy-ready, plain-language clause templates. Fill the `[BRACKETED]` parts. Each opens with one line on **what it allocates**. These are starting drafts, not legal advice — have a licensed attorney review before signing.
+
+## Mutual NDA core
+
+*Allocates: who may use shared confidential information, and for how long.*
+
+```text
+"Confidential Information" means non-public information a party discloses that
+is marked confidential or that a reasonable person would treat as confidential.
+It does not include information that is public, already known to the recipient,
+or independently developed without using the disclosure.
+
+Each party shall use the other's Confidential Information only to [PURPOSE],
+shall not disclose it to third parties except to employees and contractors who
+need it and are bound by similar duties, and shall protect it with at least
+reasonable care. These duties last [3] years from disclosure. On termination or
+on request, each party shall return or destroy the other's Confidential
+Information and confirm in writing.
+```
+
+## Limitation of liability (with carve-outs)
+
+*Allocates: the maximum each party can lose when the deal goes wrong.*
+
+```text
+Except for the Carve-Outs below, each party's total liability under this
+agreement is capped at the fees paid or payable by [CUSTOMER] in the 12 months
+before the event giving rise to the claim. Neither party is liable for indirect,
+incidental, or consequential damages.
+
+Carve-Outs (not subject to the cap): a party's confidentiality breaches and its
+indemnification obligations. Nothing in this agreement limits liability for
+fraud, willful misconduct, or bodily harm/death.
+```
+
+Note: do not attempt to cap fraud, willful misconduct, or bodily harm — those exclusions are generally unenforceable.
+
+## Mutual indemnity (narrow + capped)
+
+*Allocates: who defends and pays when a third party sues.*
+
+```text
+Each party (the "Indemnifying Party") shall defend the other against third-party
+claims to the extent caused by the Indemnifying Party's breach of this agreement,
+its negligence or willful misconduct, or its infringement of a third party's
+intellectual-property rights, and shall pay damages and reasonable costs finally
+awarded. The indemnified party shall give prompt notice and reasonable
+cooperation, and the Indemnifying Party controls the defense and settlement
+(no settlement admitting fault without consent). This obligation survives [3]
+years after termination.
+```
+
+## Force majeure (defined term + catch-all)
+
+*Allocates: who bears the loss when neither party is at fault.*
+
+```text
+"Force Majeure Event" means an event beyond a party's reasonable control,
+including acts of God, flood, fire, war, terrorism, epidemic, government action,
+labor disruption, failure of utilities or carriers, cyberattack, and any other
+similar event beyond the party's reasonable control.
+
+A party affected by a Force Majeure Event is excused from performance (except
+payment obligations already due) for as long as the event continues, provided it
+gives prompt written notice and uses reasonable efforts to mitigate. If the event
+continues for more than [30] days, either party may terminate on written notice.
+```
+
+(Anchored to the ICC model force majeure clause, last updated March 2020.)
+
+## Termination — for cause and for convenience
+
+*Allocates: who can end the contract, on what notice, and with what cure period.*
+
+```text
+For cause: Either party may terminate if the other materially breaches and fails
+to cure within [30] days after written notice describing the breach.
+
+For convenience: Either party may terminate for any reason on [30] days' written
+notice. On termination, [CUSTOMER] shall pay for work performed through the
+termination date.
+```
+
+Keep convenience rights mutual. A one-way convenience right is a red flag.
+
+## IP — assignment vs license
+
+*Allocates: who owns what gets created, and what each side keeps.*
+
+```text
+Assignment (buyer owns deliverables): Contractor assigns to [CUSTOMER] all
+intellectual-property rights in the deliverables created under this agreement,
+effective on full payment.
+
+Background IP (contractor keeps its own): Contractor retains its pre-existing and
+independently developed materials ("Background IP") and grants [CUSTOMER] a
+non-exclusive, perpetual license to use Background IP embedded in the
+deliverables as needed to use them.
+```
+
+Use a *license* instead of assignment when the creator must keep ownership (e.g. reusable tooling) — say so explicitly.
+
+## Governing law and venue
+
+*Allocates: whose law applies and where disputes are heard.*
+
+```text
+This agreement is governed by the laws of [STATE/COUNTRY], without regard to its
+conflict-of-laws rules. The parties submit to the exclusive jurisdiction of the
+courts located in [VENUE] for any dispute arising under it.
+```
+
+## Entire agreement + amendment (boilerplate)
+
+*Allocates: which documents count, and how the contract can change.*
+
+```text
+This agreement (with its exhibits and any SOWs) is the entire agreement between
+the parties on its subject and supersedes prior discussions. It may be amended
+only by a written document signed by both parties. If an SOW conflicts with this
+agreement, this agreement controls unless the SOW expressly says otherwise and is
+signed by both parties.
+```
+
+---
+
+Reminder: these templates are drafting starting points. Have a licensed attorney review any contract before signing, especially clauses that allocate liability or cross a jurisdiction you cannot verify.

package/skills/contracts/references/review-playbook.md

@@ -0,0 +1,49 @@
+# Review playbook
+
+How to redline a counterparty's draft in the operator's favor. Read the clause they wrote, decide demand / concede / flag, propose plain-language replacement text. Always close with the attorney-review reminder.
+
+## Pass order
+
+Parties → scope → price/payment → risk clauses → boilerplate. The money is in the risk clauses; do not let boilerplate fatigue make you skim past them.
+
+## Demand / concede / flag per clause
+
+| Clause | Demand (non-negotiable) | Can concede | Flag if you see |
+|---|---|---|---|
+| Limitation of liability | A mutual cap with confidentiality + indemnity carve-outs | The exact multiple of fees | No cap at all; a cap that also limits *their* confidentiality breach |
+| Indemnity | Narrow scope (breach/negligence/third-party IP); cap; survival 3–5 yr | Survival length within 3–5 yr | "any and all claims"; one-way indemnity running only from you |
+| Force majeure | Defined term + catch-all + notice + mitigation | The persistence period before termination | Exhaustive list with no catch-all; excuses *their* payment obligations |
+| Termination | Mutual for-cause with cure period | The notice window | One-way termination-for-convenience; no cure period |
+| IP / ownership | Your background IP stays yours; deliverables assigned on payment | License vs assignment for edge assets | A grab of pre-existing/background IP; assignment before payment |
+| Confidentiality | Defined info, set term, return-or-destroy | Term length | Perpetual confidentiality with no return-of-info clause |
+| Auto-renewal | Short, mutual opt-out notice | Renewal term length | Auto-renew with a long (e.g. 90-day) opt-out window |
+| Governing law/venue | One explicit, workable jurisdiction | Which of two reasonable venues | Unstated venue; a venue you can't realistically litigate in |
+
+## Tells of a one-sided draft
+
+- An uncapped indemnity (or a cap that conveniently excludes only *their* breaches).
+- "Mutual" obligations that, read closely, only bind one party.
+- A liability cap with no confidentiality/indemnity carve-out — good for the drafter, bad for you.
+- A termination-for-convenience right held by only one side.
+- Auto-renewal with a long opt-out notice window.
+- IP language that sweeps in your pre-existing/background IP.
+
+## MSA ↔ SOW reconciliation
+
+1. List every term the SOW sets that the MSA also covers (price, liability, IP, payment).
+2. For each overlap, check the SOW does not contradict the MSA.
+3. If it does, decide which controls and state it in writing (default: the MSA controls unless the SOW expressly overrides and is signed by both).
+4. Resolve all conflicts *before* either document is signed — not after a dispute.
+
+## Jurisdiction caveats for the signing handoff
+
+The signature mechanics belong to `../e-signature/SKILL.md`, but flag the right tier when you hand off:
+
+- **US** — single, technology-neutral tier (ESIGN + UETA). Enforceability needs intent to sign, consent to do business electronically, a verifiable signer↔signature association, and retained reproducible records. Some documents are excluded (wills, certain family-law and notarial documents).
+- **EU (eIDAS)** — three tiers: Simple, Advanced, Qualified. A Qualified Electronic Signature (QES) carries the legal effect of a handwritten signature across all member states and needs a qualified certificate from a Qualified Trust Service Provider. eIDAS 2.0 adds the European Digital Identity Wallet.
+
+If a contract spans both regions or its enforceability depends on which signature tier is used, that is exactly the kind of cross-jurisdiction question a licensed attorney should confirm.
+
+---
+
+Reminder: a redline is a negotiating position, not legal advice. Have a licensed attorney review the final draft before signing.

package/skills/contracts/scripts/verify.sh

@@ -0,0 +1,53 @@
+#!/usr/bin/env bash
+# verify.sh — plain-language + risk-carve-out discipline check for a contracts draft.
+# Read-only. Takes a generated contract/clause file as $1.
+# No argument => prints usage and exits 0 (never blocks when not given a draft).
+# Exits non-zero only when a real artifact violates a rule.
+set -euo pipefail
+
+artifact="${1:-}"
+
+if [ -z "$artifact" ]; then
+  echo "usage: verify.sh <contract-draft-file>"
+  echo "Checks a drafted contract/clause for archaic legalese, a liability cap"
+  echo "missing its carve-outs, and a missing attorney-review line."
+  echo "No file given — nothing to check."
+  exit 0
+fi
+
+if [ ! -f "$artifact" ]; then
+  echo "verify.sh: not a file: $artifact" >&2
+  exit 2
+fi
+
+fail=0
+
+# 1) Archaic legalese banlist (case-insensitive). Plain-language rule.
+legalese='heretofore|hereinafter|witnesseth|party of the first part|aforesaid'
+if grep -niE "$legalese" "$artifact" >/dev/null; then
+  echo "FAIL: archaic legalese — rewrite in plain language:"
+  grep -niE "$legalese" "$artifact" | sed 's/^/  /'
+  fail=1
+fi
+
+# 2) Liability cap present but no carve-out for confidentiality/indemnity/fraud.
+if grep -niE 'limit.*liabilit|aggregate liabilit|liability.*cap|capped at' "$artifact" >/dev/null; then
+  if ! grep -niE 'except|carve|carve-out|fraud|willful|confidential|indemnif' "$artifact" >/dev/null; then
+    echo "FAIL: a liability cap exists but no carve-out (confidentiality/indemnity) or fraud exclusion was found."
+    fail=1
+  fi
+fi
+
+# 3) Full-contract draft with no attorney-review line. Heuristic on length.
+lines=$(wc -l < "$artifact" | tr -d ' ')
+if [ "$lines" -ge 30 ]; then
+  if ! grep -niE 'attorney|legal counsel|qualified lawyer|licensed lawyer' "$artifact" >/dev/null; then
+    echo "FAIL: full-contract draft has no attorney-review line (add 'Have a licensed attorney review this before signing')."
+    fail=1
+  fi
+fi
+
+if [ "$fail" -eq 0 ]; then
+  echo "OK: $artifact passed plain-language and risk-carve-out checks."
+fi
+exit "$fail"

package/skills/coolify/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: coolify
+description: "Use when self-hosting apps, managed databases and deploys on a VPS you own with Coolify instead of paying a managed PaaS — installing Coolify on a fresh Ubuntu/Debian box, claiming the first-admin account, deploying from a Git repo (Nixpacks/Railpack/Dockerfile/compose), provisioning Postgres/MySQL/MongoDB/Redis in-product, wiring scheduled DB backups to S3-compatible storage, or custom domains + automatic SSL via the built-in Traefik proxy. Triggers: 'install Coolify', 'self-host my app on a cheap VPS', 'my Vercel/Heroku bill is killing me, move it to a box I own', 'control plane on my own server', 'nightly Postgres backups to R2 in Coolify', 'montar mi propio PaaS en un VPS barato con Coolify', 'autoallotjar les meves apps amb Coolify'. NOT the managed push-and-forget PaaS where someone else owns the box (that is railway), NOT sizing/hardening the VPS itself (that is hetzner / digitalocean), NOT generic Docker image authoring (that is docker)."
+tags: [coolify, self-hosting, paas, vps, docker, deployment, devops]
+recommends: [hetzner, digitalocean, docker, postgresdb, backups, domains-dns, github-actions]
+origin: risco
+---
+
+# Coolify — own-the-box PaaS on your VPS
+
+Coolify is an open-source, self-hostable control plane that turns a plain Linux VPS into a Vercel/Heroku
+replacement: Git-to-deploy, managed databases, automatic SSL, scheduled backups — for a flat VPS bill
+instead of per-request metering. This skill is operational. It produces the exact install one-liner, the
+port matrix, env wiring, a lint-clean compose artifact, and a backup-to-S3 cron with a tested restore.
+Coolify 4.x (stable in 2026); v4.1 added Railpack, structured audit logging, and a read-only MCP server.
+
+## Mental model — read this first
+
+1. **Coolify is the control plane, not the box.** It runs *on* a VPS you provisioned elsewhere. Hardware
+   sizing, the cloud firewall, SSH hardening, OS patching → that is the VPS layer (hetzner /
+   digitalocean), not this skill. Coolify orchestrates what runs on the box.
+2. **You own the data and the uptime now.** No vendor takes nightly snapshots for you. So backups are
+   non-optional and a backup you have never restored is not a backup (see the backup section).
+3. **Everything underneath is Docker.** Coolify generates compose/Dockerfile runs and a Traefik proxy. So
+   every Docker rule still applies — named volumes, healthchecks, pinned images, env-injected secrets.
+   For image-authoring depth (multi-stage, layer caching) go to the `docker` skill; here we wire it.
+4. **First account to register owns the instance — forever.** There is no "admin invite" recovery if a
+   stranger registers first. Claim it within seconds of install (see step 4).
+
+## Decision — where should this app actually run?
+
+| Option | Who owns the box | Cost shape | Ops burden | Choose when |
+| --- | --- | --- | --- | --- |
+| **Coolify self-hosted** (this skill) | You (your VPS) | Flat VPS/month | You patch + back up | Predictable bill, data sovereignty, many apps on one box |
+| **Coolify Cloud** | You bring the server; they host the control plane | VPS + small SaaS fee | They run the control plane | Want Coolify UX without babysitting the dashboard's own uptime |
+| **Managed PaaS** (railway / render / fly-io / vercel / netlify) | The provider | Per-usage, scales up fast | Near-zero | Spiky scale-to-zero, no box to own — the inverse of Coolify |
+
+Choose Coolify when a few always-on apps on a known-cost box beats per-request metering. If the user wants
+`git push` and never touches a server, that is railway — route there.
+
+## Install — the 6-minute path
+
+Provision the box first (this is the hetzner / digitalocean step, not this skill). Floor is 2 CPU / 2 GB
+RAM / 30 GB disk; Coolify itself idles around 1 GB RAM. For comfortable multi-app production aim for
+4 vCPU / 8 GB / 100 GB NVMe. Ubuntu 22.04/24.04 LTS recommended (Debian, Fedora/Alma/Rocky, Alpine, Arch,
+Raspberry Pi OS 64-bit also supported; non-LTS needs manual steps — see references).
+
+```bash
+# 1. SSH in AS ROOT. Non-root is not fully supported by the installer — log in as root.
+ssh root@<server-ip>
+
+# 2. One-liner install (root). Takes ~2–5 min: installs Docker, sets up Coolify's own stack.
+curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
+```
+
+```text
+# 3. The installer prints the dashboard URL: http://<server-ip>:8000
+# 4. CRITICAL — within seconds, open http://<server-ip>:8000 and REGISTER.
+#    That first account becomes the permanent root admin of the instance. First-come-owns-the-box;
+#    there is no later "claim ownership" flow. Do not walk away between step 2 and this.
+# 5. In the dashboard: set the instance FQDN (coolify.example.com) and force HTTPS, so you stop
+#    hitting the raw :8000 IP and the dashboard itself gets a real certificate.
+```
+
+Why root: the installer wires Docker and system services; the docs state non-root is not fully supported.
+Why claim immediately: the registration page is open until someone takes it.
+
+Full install transcript, non-LTS/other-OS notes, and dashboard-domain setup → `references/install-and-proxy.md`.
+
+## Port & firewall matrix
+
+Set these at the cloud firewall (hetzner/digitalocean layer) AND keep them in mind on the box.
+
+| Port | Purpose | Exposure |
+| --- | --- | --- |
+| 22 | SSH | Restrict to your IP / VPN; key-only |
+| 8000 | Coolify dashboard | **Restrict** to your IP after setup, or front with the proxy on a FQDN; never leave open to the world |
+| 80 | Proxy HTTP (Traefik) → redirects to 443 | Public |
+| 443 | Proxy HTTPS, app traffic + Let's Encrypt | Public |
+| 6001 | Realtime / websocket | Open as the dashboard needs (same audience as 8000) |
+| 6002 | Realtime / terminal websocket | Same as 6001 |
+
+Rule: 80/443 are the only ports the public should reach. 8000/6001/6002 are operator surface — lock them
+to your IP or put the dashboard behind its FQDN. Why: an open :8000 plus an unclaimed instance is a
+takeover; an open :8000 on a claimed instance is still your full control plane exposed to brute force.
+
+## Deploy an app
+
+Pick the build pack first, then wire source → env → storage → domain.
+
+| Build pack | Use when | Note |
+| --- | --- | --- |
+| **Nixpacks** (default) | Standard app, you want zero config | Auto-detects the language/runtime; start here |
+| **Railpack** (v4.1, beta) | Need build-time env vars, config merge, or multi-stage control | Newer; reach for it when Nixpacks can't express the build |
+| **Dockerfile** | You already have a Dockerfile / want full build control | You own the build; pin a base image |
+| **docker-compose** | Multi-service app deployed as a unit | Coolify runs your compose; this is the verify.sh-linted artifact shape |
+
+Then:
+
+1. **Connect the Git source** — GitHub/GitLab app or a deploy key; pick branch; enable auto-deploy on push
+   (or trigger from CI — that wiring is the `github-actions` skill).
+2. **Set env vars as Coolify secrets** — inject at runtime via the UI/API; never bake secrets into the
+   image or commit them to the compose. Why: a baked secret ships in every image layer and leaks on pull.
+3. **Add persistent storage** — any path that must survive a redeploy (uploads, sqlite) gets a named
+   volume. A container without one loses its writes on every recreate.
+4. **Attach the domain + SSL** — add `app.example.com`, point its DNS A record at the box (DNS itself is
+   the `domains-dns` skill), and the Traefik proxy provisions Let's Encrypt automatically on ports 80/443.
+
+Build-pack deep-dive + a worked, lint-clean compose example → `references/deploy-recipes.md`.
+
+## Managed databases
+
+Coolify provisions Postgres, MySQL, MariaDB, MongoDB, Redis (and more) in-product — one-click, with
+generated credentials.
+
+- **Connect apps over the internal Docker network hostname**, not a public IP. Coolify gives each DB an
+  internal service name; the app reaches it on the private network. Why: zero public attack surface.
+- **Do NOT publicly expose the DB port** unless you genuinely need an external client. If you must, bind
+  it deliberately and firewall it to known IPs — an open 5432/3306 is scanned within minutes.
+- **Every DB gets a named volume.** Without it, recreating the service wipes the data. This is the single
+  most common Coolify data-loss footgun.
+
+This skill provisions and connects the DB; it does not teach SQL, indexing, or query tuning — that is the
+`postgresdb` skill. Per-engine details and connection strings → `references/databases-and-backups.md`.
+
+## Backups to S3 — non-negotiable
+
+You own the data now. Coolify runs scheduled dumps (`pg_dump` / `mysqldump` / `mongodump`) on a cron
+expression, stores them locally, and optionally pushes to S3-compatible storage: AWS S3, Cloudflare R2,
+Backblaze B2, MinIO, Wasabi.
+
+1. **Add an S3 destination** — endpoint, region, bucket, access key/secret (as Coolify secrets, never in
+   a committed file). Off-box storage is the point: a backup on the same disk dies with the disk.
+2. **Set the cron schedule** — e.g. `0 3 * * *` for nightly 03:00. Match frequency to how much data you
+   can afford to lose (RPO doctrine across systems is the `backups` skill; here we wire the in-product job).
+3. **Set retention** — keep N days/copies so the bucket doesn't grow unbounded.
+4. **Run the restore drill — once, before you need it.** Download a dump, decompress, replay it into a
+   throwaway DB, confirm the row counts. An untested backup is a guess. Schedule a recurring drill.
+
+Per-provider S3 setup, per-engine dump/restore commands, and the full restore runbook →
+`references/databases-and-backups.md`.
+
+## Operate the box
+
+- **Resource planning.** Coolify idles ~1 GB RAM; budget the rest for your apps + databases. Multi-app
+  sweet spot is 4 vCPU / 8 GB / 100 GB NVMe. Watch RAM headroom before adding the next app.
+- **Updates.** Update Coolify from the dashboard's settings; pin/snapshot before a major bump.
+- **Logs & audit.** Per-resource logs live in the UI. v4.1 adds a structured audit log — use it to see who
+  changed what.
+- **MCP server (v4.1, read-only).** Coolify exposes an instance-level MCP server with read-only tools for
+  AI-agent integration. Useful for letting an agent inspect status; it is read-only by design — do not
+  treat it as a deploy channel, and still lock down the network in front of it.
+
+## Anti-patterns → STOP
+
+| Rationalization | Reality → STOP |
+| --- | --- |
+| "I'll install with my sudo user, root feels risky" | The installer wires Docker + system services and the docs say non-root is not fully supported. SSH in as root for install. |
+| "I'll register the admin account later" | First account to hit `:8000` owns the instance permanently. A stranger registering first = takeover. Claim it within seconds. |
+| "Leave :8000 open, it's password-protected" | That is your full control plane exposed to brute force. Restrict 8000/6001/6002 to your IP; only 80/443 are public. |
+| "Pin the app image to `:latest`, it's simpler" | `:latest` floats — a silent base change breaks a redeploy you can't reproduce. Pin a tag or digest. |
+| "The database doesn't need a named volume yet" | Recreating the service wipes an anonymous volume. Data gone. Named volume from day one. |
+| "Put the DB password in the compose so deploys are reproducible" | Secrets in a committed file leak in git history and image layers. Inject via Coolify env/secrets, env-ref only. |
+| "Expose 5432 so I can connect from my laptop" | An open DB port is scanned in minutes. Use the internal hostname; if you truly need external access, firewall it to known IPs. |
+| "Backups are configured, we're covered" | A backup you've never restored is a guess. Run the restore drill before you need it. |
+| "Coolify will harden the server for me" | Coolify is the control plane, not the OS-hardening layer. Firewall/SSH/patching is the VPS skill (hetzner/digitalocean). |
+| "Use Coolify because I just want to git push and forget the server" | That's the opposite of own-the-box. Use a managed PaaS — railway. |
+
+## Verify
+
+Run `scripts/verify.sh` against your project (or this skill's `references/`). It statically lints the
+example/your `docker-compose.y*ml`: fails on a hardcoded secret literal (must be env-ref), a DB service
+without a named volume, a missing `healthcheck:`, or a floating `:latest` tag on a build-context service;
+and confirms the canonical port matrix (8000/80/443/6001/6002) is documented. Read-only, no network, no
+live deploy. Exits 0 on a clean/empty target.
+
+## References
+
+- `references/install-and-proxy.md` — full install transcript, non-LTS/other-OS steps, Traefik (default)
+  vs Caddy, wildcard domains + DNS-01 challenge, common SSL failures and fixes.
+- `references/databases-and-backups.md` — per-engine dump commands, S3 destination setup for
+  R2/B2/MinIO/Wasabi/AWS, retention, the step-by-step restore runbook, consistency caveats.
+- `references/deploy-recipes.md` — build-pack decision deep-dive and a worked, lint-clean
+  `docker-compose.yml` (env-ref secrets, named volumes, healthcheck, pinned image) — the verify.sh target.
+
+## Project grounding (02-DOCS + CLAUDE.md)
+
+When this skill runs in a project with a `02-DOCS/` layer (the harness Karpathy wiki), record this
+instance's deploy topology there and index it from the root `CLAUDE.md`, so the next agent inherits it
+instead of re-deriving it.
+
+1. **Find the article** `02-DOCS/wiki/stack/coolify.md`, linked from a `## Knowledge map` section in the
+   root `CLAUDE.md`.
+2. **If missing or stale**, create/update it with the real choices — the box (provider/specs), instance
+   FQDN, which apps/databases run on it, build packs in use, the backup destination + cron + retention,
+   and the port/firewall decisions — then add/refresh the `CLAUDE.md` link.
+3. **Read it first on every use** and stay consistent; when the topology changes, update the article (bump
+   its `Updated` date) in the same change. Never commit credentials here — record *where* secrets live,
+   not their values.
+
+No `02-DOCS/` layer? Skip silently. Topology is recorded, not gated — never block the task on this.

package/skills/coolify/evals/README.md

@@ -0,0 +1,21 @@
+# Eval harness — `coolify`
+
+This harness checks two things: **triggering** (does the skill fire on own-the-box self-hosting prompts
+and stay quiet on near-misses that belong to a sibling?) and **capability** (does loading the skill
+measurably improve the deploy/backup answer?). Cases live in `cases.yaml`. These run through an **agent
+harness**, not a pure script — a human or driver agent feeds each prompt to a fresh agent session and
+grades the output.
+
+**Triggering.** For each `should_trigger` / `should_not_trigger` prompt, start a clean session with only
+`coolify` discoverable, paste the prompt verbatim, run 3–5 trials (the decision is stochastic), and score:
+`should_trigger` passes if the skill fires in the majority of trials; `should_not_trigger` passes if it
+stays quiet and would plausibly route to the named sibling (`hetzner`, `docker`, `railway`, `postgresdb`,
+`domains-dns`). Pass bar: ≥ 90% accuracy across all trigger cases.
+
+**Capability.** Run the scenario twice — WITHOUT the skill (clean agent) and WITH it — and grade each
+transcript against the `must_include` checklist, one point per bullet that is specifically and correctly
+covered (not just name-dropped). Pass bar: WITH the skill covers ≥ 80% of bullets and clearly beats
+WITHOUT (target ≥ +30 points, or fail→pass). If the baseline already nails it, the rubric is too easy.
+
+This is judgment-based grading: record trial counts and per-bullet verdicts so a reviewer can audit — never
+report a bare pass/fail.