@event4u/agent-config 2.7.0 → 2.9.0

package/.agent-src/skills/content-funnel-design/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: content-funnel-design
+description: "Use when mapping funnel-stage to content shape — conversion-pathway, content-as-system, leverage-point selection. Triggers on 'design our content funnel', 'why does mid-funnel leak'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment, channel-stage, funnel-stage]
+---
+
+# content-funnel-design
+
+## When to use
+
+- A team has content but no funnel — each asset is shaped to its author's preference, not to the funnel stage the audience is in.
+- The cadence (`editorial-calendar`) is locked but one funnel stage is leaking and there is no content shape that would catch it.
+- A new ICP requires re-mapping content shapes per stage because the previous mapping was inherited from a previous segment.
+
+Do NOT use to plan publishing cadence (route to `editorial-calendar`),
+diagnose quantitative drop-off (route to `funnel-analysis`), or
+draft the asset itself (downstream of this skill).
+
+## Cognition cluster
+
+- **Mental model 14 — Meadows leverage points.** Some funnel stages
+  are *parameters* (small change, small ripple) and some are
+  *structure* (small change, system-wide ripple). The content
+  funnel design is the discipline of placing the heaviest content
+  investment at the structural leverage point, not the parameter
+  one. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 14.
+- **Mental model 6 — Theory of constraints.** The slow funnel stage
+  caps the whole pipeline. Adding content elsewhere does not loosen
+  the constraint. See `mental-models.md` § 6.
+- **Mental model 16 — Leading vs. lagging indicators.** Time-to-
+  proof (asset → activation question) is leading; pipeline lift is
+  lagging. The funnel design is gated on leading signals, not on
+  the lagging ones the board sees a quarter later. See
+  `mental-models.md` § 16.
+- **Context-spine — funnel-stage + channel-stage + customer-segment
+  + product.** Read **funnel-stage** for which stage owns each
+  content shape, **channel-stage** for where the audience meets
+  the asset, **customer-segment** for whose questions the asset
+  answers, and **product** for the proofs the asset can actually
+  back. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inherit the funnel diagnosis
+
+Identify the leaking stage from
+[`funnel-analysis`](../funnel-analysis/SKILL.md) and the cadence
+classification from [`editorial-calendar`](../editorial-calendar/SKILL.md).
+The content funnel design is a *response* to a diagnosed leak —
+without the diagnosis, content investment is uniform and the
+constraint stays where it is.
+
+### Step 1: Analyze the inherited shapes
+
+Review existing assets stage-by-stage. For each, identify *shape*
+(awareness explainer, comparison, deep-dive, demo, case study,
+calculator, onboarding walkthrough) and *whose question* it
+answers. The output is a stage × shape grid with current investment
+weight. Most teams discover their grid is bottom-heavy or
+middle-empty.
+
+### Step 2: Place the leverage-point bet
+
+The leverage point is the **structural** stage, not the leaking
+one. (The leaking stage is the *symptom*; the leverage point is
+where the design choice ripples.) Often: mid-funnel proof is the
+leverage point when the leak is decision-stage, because mid-funnel
+proof loads the decision-stage call with conviction. Name the
+leverage point explicitly; document why it is structural, not
+parameter.
+
+### Step 3: Map shape per funnel stage
+
+For each funnel stage in the spine slot, lock the load-bearing
+content shape:
+
+- *Top — awareness:* one explainer per segment-question that earned
+  pull last quarter (Pareto cut from `editorial-calendar`).
+- *Mid — consideration:* one comparison or deep-dive per
+  load-bearing proof from the message stack.
+- *Bottom — decision:* one calculator, demo, or reference quote per
+  audience-matrix cell that signals economic-buyer fear.
+- *Activation:* one onboarding walkthrough keyed to the first
+  switch-event the customer faces.
+
+### Step 4: Design the conversion pathway
+
+A pathway is **two assets in sequence** that an audience plausibly
+walks. For each pathway, name the *first-asset → second-asset*
+edge and the question the second answers that the first surfaced.
+Pathways without a credible edge are wishful inventory, not a
+funnel.
+
+### Step 5: Validate against constraint and leverage
+
+Validate the design on three checks:
+
+1. **Constraint coverage.** Verify the leaking stage from
+   `funnel-analysis` has a shape designed for it — not just *more*
+   content, but the shape the audience asks for at that stage.
+2. **Leverage-point investment.** Verify the heaviest authoring
+   investment lands at the leverage point, not at the leak.
+3. **Pathway plausibility.** Walk three of the designed pathways
+   end-to-end with the audience-matrix lens. Verify each second
+   asset earns the click; if it requires a buyer leap, the pathway
+   is fiction.
+
+### Step 6: Hand back
+
+Hand the artefacts to [`editorial-calendar`](../editorial-calendar/SKILL.md)
+for cadence assignment, to [`funnel-analysis`](../funnel-analysis/SKILL.md)
+for a re-diagnosis four weeks after launch, and to
+[`activation-design`](../activation-design/SKILL.md) for the
+activation-stage handoff.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The unit of work is the funnel-stage × content-shape grid, not a single asset.
+- A diagnosed funnel leak needs a content shape, not more authoring volume.
+- The team is investing uniformly across stages instead of at the leverage point.
+
+**WHEN NOT to use this**
+
+- Planning publishing cadence and content-debt management — route to [`editorial-calendar`](../editorial-calendar/SKILL.md).
+- Quantitative funnel-stage diagnostics and leak detection — route to [`funnel-analysis`](../funnel-analysis/SKILL.md).
+- Activation-event selection inside the product — route to [`activation-design`](../activation-design/SKILL.md).
+- Drafting the asset copy itself — out of scope; downstream of this skill.
+
+## When the agent should load this
+
+- "Mid-funnel leaks — design the content funnel to fix it."
+- "Map our content shapes to the funnel stages for the new ICP."
+- "Was ist unser Leverage-Point in der Content-Funnel?"
+- "Build conversion pathways from top-of-funnel to decision."
+- "Why is content investment uniform across stages?"
+
+## Output
+
+1. **`stage-shape-grid.md`** — stage × shape matrix, current investment vs. designed investment, leverage-point cell marked.
+2. **`conversion-pathways.md`** — one row per pathway: first-asset → second-asset edge, question the second asset earns, audience-matrix cell it serves.
+3. **`leverage-point-rationale.md`** — named leverage stage, *why structural, not parameter* argument, and the leading-indicator threshold the design will be re-checked against.
+
+## Gotcha
+
+- The leaking stage is rarely the leverage stage; treating them as identical concentrates content where it does not move the constraint.
+- "More mid-funnel content" is not a design — it is volume. The shape and the question both have to land.
+- Pathways are usually fictional on the first draft because the second asset assumes a buyer leap. Walk them.
+
+## Do NOT
+
+- Do NOT prescribe channel-specific tactics (subject lines, ad placements, video specs) — channel ownership is downstream and out of scope.
+- Do NOT design uniformly across stages; uniform design encodes uniform leverage, which is leverage-blindness.
+- Do NOT skip Step 0 — content funnel without a funnel diagnosis is content-as-impulse with extra steps.
+
+## Runnable example
+
+Mid-market HR analytics, funnel-analysis diagnosed mid-funnel leak (decision-stage conversion is fine, but mid-funnel disqualifies before reaching it):
+
+- Stage-shape grid — top: 2 awareness explainers (current); mid: 0 comparison deep-dives (gap); bottom: 3 ROI calculators (over-invested).
+- Leverage point — *mid-funnel proof*, because the decision-stage call is starved of conviction; structural ripple.
+- Pathway — *"How HR directors lose 7 hours per board-quarter"* (top) → *"Cohort-retention deep-dive vs. spreadsheet rebuild"* (mid) → *ROI calculator* (decision).
+- Hand-off → `editorial-calendar` re-allocates campaign weight to mid-funnel; `funnel-analysis` re-diagnoses at week 4.

package/.agent-src/skills/contracts-cognition/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: contracts-cognition
+description: "Use when reading a contract for risk and constraint — clause shape, redline priority, what the contract actually binds. Triggers on 'review this contract', 'what does this MSA constrain'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [regulatory-regime, customer-segment, org-stage]
+---
+
+# contracts-cognition
+
+## When to use
+
+- A draft MSA / DPA / SOW / vendor contract / partner agreement lands and a non-lawyer needs to read it for *what it actually constrains*, *which clauses carry real risk*, and *what to redline first*.
+- An existing contract is being renegotiated; the question is *which clauses are now misshapen* given current scale, regulatory regime, or customer mix.
+- A new customer contract triggers obligations (SLA, indemnity, audit, data-handling) that need to be sized against operational capacity before signing.
+
+Do NOT use as a substitute for actual legal counsel (this skill produces the *non-lawyer cognition* that prepares the conversation with counsel, not the legal opinion), for privacy-specific review (route to `privacy-review` (P6); this skill composes P6 for data clauses), or for contract management software / e-signature operations.
+
+## Cognition cluster
+
+- **Mental model 28 — Inversion.** *"What would force us to invoke this clause? What would force the counterparty to invoke it?"* Inversion surfaces which clauses are dormant boilerplate vs which are loaded triggers. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28.
+- **Mental model 21 — Second-order thinking.** Each clause has a second-order shape: indemnity caps interact with insurance coverage; SLAs interact with operating-cost; auto-renewal interacts with switching cost. Reading clauses in isolation misses the load-bearing combinations. See `mental-models.md` § 21.
+- **Mental model 26 — Optionality.** Each clause either preserves or forecloses future choices (terminate-for-convenience preserves; auto-renewal forecloses; exclusivity forecloses; MFN forecloses). The cost of a clause is the optionality it removes. See `mental-models.md` § 26.
+- **Context-spine — regulatory-regime + customer-segment + org-stage.** Read **regulatory-regime** (J1) for floor-bound clauses (GDPR DPA terms, HIPAA BAA, SOC 2 audit). Read **customer-segment** for risk sizing (enterprise SLA terms ≠ SMB SLA terms). Read **org-stage** for what's affordable (early-stage = avoid uncapped indemnities; growth = can absorb tighter SLAs).
+
+## Procedure
+
+### Step 0: Frame the contract by intent
+
+Two questions before reading clauses:
+
+1. *What outcome are we trying to enable?* (sell to enterprise, integrate vendor, partner co-sell, license IP).
+2. *What outcomes are we trying to prevent?* (unbounded liability, lock-in, IP leakage, audit ambush, payment risk).
+
+Without intent, every clause looks equally important. With intent, 80 % of clauses are background and 20 % are load-bearing.
+
+### Step 1: Identify the load-bearing clause families
+
+Five families carry most real risk for non-lawyers:
+
+1. **Liability & indemnity** — caps, carve-outs, IP indemnity, mutual vs one-way. Uncapped indemnity is the canonical trap.
+2. **Term, renewal, termination** — auto-renewal, notice windows, termination-for-convenience vs for-cause, data-return obligations.
+3. **Data & privacy** — DPA, sub-processors, data location, breach notification, retention, deletion. Compose `privacy-review` (P6) for the deep read.
+4. **IP & confidentiality** — work-product ownership, license grants, confidentiality term, residual-knowledge clauses.
+5. **Commercial mechanics** — payment terms, MFN, exclusivity, change-of-control, audit rights.
+
+Other clauses (governing law, force majeure, severability, notices) are usually boilerplate; flag deviations but don't lead with them.
+
+### Step 2: Inspect each load-bearing family
+
+For each family, read three things:
+
+1. **The clause as written** — what does it literally say.
+2. **The clause invoked** — *"under what scenario does this clause fire?"*
+3. **The clause's tail risk** — *"what's the worst-case if it fires?"*
+
+A clause whose tail risk is bounded and small = accept. Bounded and large = redline to reduce. Unbounded = redline to cap or refuse.
+
+### Step 3: Run the inversion check
+
+For each load-bearing clause, ask:
+
+1. *"Would we sign this if the counterparty had 10× our leverage?"* Reveals which clauses we tolerate because of relationship, not because they're fair.
+2. *"What would we want if we were the counterparty?"* Reveals which clauses are mutual vs one-way unfairly.
+3. *"What scenario makes this clause matter in 18 months?"* If no scenario, the clause is dormant; if a plausible scenario exists, prioritize the redline.
+
+### Step 4: Build the redline priority list
+
+Rank redlines by:
+
+1. **Tail-risk size** — uncapped > capped-large > capped-small.
+2. **Probability of invocation** — high-likelihood clauses (auto-renewal, payment terms) outrank low-likelihood (force majeure).
+3. **Asymmetry** — one-way clauses where the counterparty bears no symmetric risk.
+4. **Optionality cost** — clauses that foreclose future moves (exclusivity, MFN, change-of-control restrictions).
+
+Top 3–5 redlines = the negotiation; everything else is acceptable or backlog.
+
+### Step 5: Validate the read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Family coverage** — confirm each of the five load-bearing families was inspected (Step 2); silent skips mean the contract was not read, only skimmed.
+2. **Tail-risk sizing** — assert every top-5 redline has a named worst-case scenario and a named cap / carve-out / refusal-shape ask; un-sized redlines fail.
+3. **Counsel handoff** — check that the contract-cognition note explicitly flags which clauses need legal counsel review vs which are commercial / operational decisions; this skill does not replace counsel.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the contract-cognition note
+
+Produce the contract-cognition artifact for the negotiation lead (founder, sales lead, ops lead) and for counsel. The artifact is the non-lawyer cognition that prepares the conversation with counsel, not the legal opinion.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Reading a draft MSA / DPA / SOW / vendor / partner contract for risk and constraint.
+- Renegotiating an existing contract at a new scale or under a new regulatory regime.
+- Sizing customer-contract obligations against operational capacity.
+
+**WHEN NOT to use this**
+
+- Privacy-specific deep read — route to [`privacy-review`](../privacy-review/SKILL.md) (P6); this skill composes P6 for data clauses.
+- Data-classification / retention judgment — route to [`data-handling-judgment`](../data-handling-judgment/SKILL.md) (P7).
+- Build-vs-buy / partner-vs-vendor decision shape — route to [`build-buy-partner`](../build-buy-partner/SKILL.md) (P1); P1 outputs the *whether*, this skill outputs the *what to redline*.
+- Actual legal opinion — route to qualified counsel; this skill prepares the cognition for the counsel conversation, not replaces it.
+
+## When the agent should load this
+
+- "Review this MSA."
+- "What does this DPA actually bind us to?"
+- "Which clauses do we redline first?"
+- "Is this contract safe to sign?"
+- "Lies mir den Vertrag durch."
+
+## Output
+
+1. **`contract-frame.md`** — intent (what to enable / prevent), counterparty leverage read, regulatory-regime context.
+2. **`load-bearing-clauses.md`** — five families × clause-as-written + invocation scenario + tail risk per clause.
+3. **`redline-priority.md`** — top 3–5 redlines ranked by tail-risk × probability × asymmetry × optionality cost; named asks per redline.
+4. **`counsel-handoff.md`** — explicit list of clauses that need legal counsel review vs commercial / operational decisions.
+
+## Gotcha
+
+- Uncapped indemnity is the silent killer. If the cap is missing or excludes major risk categories (IP, data breach), it's the first redline.
+- Auto-renewal with short notice windows compounds across years — calendar the notice window the day the contract is signed.
+- "Industry-standard" is a marketing word, not a legal one. Push for the specific cap / term / carve-out.
+- Mutual NDAs that look symmetric often aren't — confidentiality term, residual-knowledge, and remedy clauses skew one-way silently.
+
+## Do NOT
+
+- Do NOT issue legal opinions; this skill prepares cognition for counsel, not replaces counsel.
+- Do NOT collapse all clauses into one list; the five families carry the real risk, treat them differently.
+- Do NOT skip the inversion check — clauses that look fine in our shoes often look terrible in the counterparty's.
+
+## Runnable example
+
+Growth-stage SaaS, customer is Fortune-500 enterprise, MSA draft from customer's legal.
+
+- Step 0 — Intent: enable enterprise deal, prevent uncapped liability + audit ambush + data-handling overreach.
+- Step 1 — Identify families: liability (mutual indemnity, uncapped on IP); term (3-year auto-renew, 90-day notice); data (DPA references but no DPA attached); IP (work-product ownership unclear for integration scripts); commercial (MFN clause buried in pricing schedule).
+- Step 2 — Inspect: uncapped IP indemnity → tail risk = bet-the-company (uncapped patent claim). Auto-renewal 3-year → tail risk = $1.2M locked in if missed notice. MFN → tail risk = forecloses bundle pricing across portfolio.
+- Step 3 — Inversion: would we sign this with 10× leverage? No. Symmetric? Indemnity is one-way; MFN is one-way.
+- Step 4 — Redline priority: (1) cap IP indemnity at 2× annual contract value with reasonable carve-outs; (2) reduce auto-renewal to 1 year, expand notice to 180 days; (3) strike MFN or limit to identical-SKU; (4) attach DPA before signing; (5) clarify integration-script IP ownership.
+- Step 5 — Validate: five families inspected; top-5 redlines sized with cap / refusal asks; counsel-handoff names IP indemnity + MFN as counsel-led, auto-renewal as commercial-led. Pass.
+- Step 6 — Emit contract-cognition note for negotiation lead; route IP indemnity + MFN to counsel; sales lead negotiates auto-renewal and DPA attachment.

package/.agent-src/skills/data-handling-judgment/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: data-handling-judgment
+description: "Use when classifying data, setting retention, judging cross-border transfer, or shaping DSR workflow. Triggers on 'how long do we keep this', 'can this data go to the US'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [regulatory-regime, customer-segment, product]
+---
+
+# data-handling-judgment
+
+## When to use
+
+- A data category needs classification (PII / PHI / financial / public / pseudonymous / aggregate) and downstream retention, access, and transfer rules depend on the classification.
+- A retention default is being set (or audited) and the question is *how long is defensible*, *how long is useful*, *how long is dangerous*.
+- A cross-border transfer is proposed (analytics in US, support in Philippines, backup in EU) and the transfer-mechanism + sub-processor obligations need a read.
+- A data-subject-rights (DSR) workflow is being designed: access, deletion, portability, correction, objection, automated-decision-objection.
+
+Do NOT use as a regulatory-regime delta read (route to `privacy-review` (P6); this skill composes P6 for the regime floor), for contract-clause depth (route to `contracts-cognition` (P5)), or for data-loss-prevention tool administration / classifier-engine configuration.
+
+## Cognition cluster
+
+- **Mental model 28 — Inversion.** *"If this data category leaked in this form, who would we have to notify and what would the headline read?"* The headline inversion forces honest classification ahead of operational convenience. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28.
+- **Mental model 1 — First principles.** Strip every retention claim to: *what purpose does keeping this another day serve, and whose risk does it grow?* Most retention defaults are inherited from the previous system, not chosen. See `mental-models.md` § 1.
+- **Mental model 26 — Optionality.** Aggressive retention preserves *analytical optionality* but forecloses *deletion optionality* and grows *breach optionality* for the attacker. Each retention choice is a trade. See `mental-models.md` § 26.
+- **Context-spine — regulatory-regime + customer-segment + product.** Read **regulatory-regime** (J1) for floor (GDPR storage-limitation principle; HIPAA retention minimums for medical records; financial-regulator retention mandates). Read **customer-segment** for whose data sets the floor. Read **product** for which features actually need the data.
+
+## Cross-wing handoff
+
+- Composes / cites J1 `regulatory-regime` for the floor read; this skill operationalises the regime obligations into classification / retention / transfer / DSR shape.
+- Composed by P6 `privacy-review` — privacy-review flags *that* a classification / retention / transfer issue exists, this skill produces the *operational answer*.
+- Hands off to Wing-2 ops skills for implementation (retention-job scheduling, DSR-runbook authoring) — this skill produces the policy shape, ops implements.
+
+## Procedure
+
+### Step 0: Bind the regime floor and the segment
+
+Read J1 `regulatory-regime` for the customer-segment in scope. Note which regime mandates a *minimum* retention (HIPAA medical records: typically 6+ years state-dependent; financial: SOX, regulatory varies) vs which mandates a *maximum* (GDPR storage-limitation; CCPA "necessary purpose"). Both floors and ceilings can apply simultaneously and create a window.
+
+### Step 1: Classify the data category
+
+For each data category in scope, assign a classification tier and rationale:
+
+1. **Public** — already public or designed for publication; no confidentiality obligation.
+2. **Internal** — company-confidential, not subject-specific; protected by trade-secret / commercial logic.
+3. **Pseudonymous** — keyed to subject but not directly identifying; classification depends on re-identifiability (the GDPR test).
+4. **PII** — directly identifying; subject to regime baseline.
+5. **Sensitive-PII** — special-category (GDPR Art. 9), CCPA "sensitive personal information", financial-account, gov-ID.
+6. **PHI / regulated** — HIPAA PHI, payment-card data (PCI), or sector-specific (children = COPPA, biometrics = state laws).
+
+Rationale per category cites *what makes it that tier*, not just the label. Mis-classification downward is the canonical risk.
+
+### Step 2: Set retention with explicit purpose binding
+
+For each data category × processing purpose, name:
+
+1. **Purpose** — why we keep it (operational, analytical, legal-hold, contractual, regulatory-mandate).
+2. **Retention** — how long for that purpose; named in calendar units, not "as needed".
+3. **End-state** — at expiry: hard-delete, anonymise, aggregate-only, archive-with-access-restriction.
+4. **Authority** — what makes the chosen retention defensible (regime mandate, contract obligation, documented operational need).
+
+Default "indefinite" retention is the failure mode. Every category needs an explicit end-state.
+
+### Step 3: Cross-border-transfer judgment
+
+For each transfer hop where data crosses a regime boundary:
+
+1. **Source regime** vs **destination regime** — which subjects, which categories.
+2. **Mechanism** — adequacy decision, SCC (with which version), BCR, derogation. Schrems-II-level transfer-impact assessment for transfers to non-adequate jurisdictions.
+3. **Government-access risk** — destination jurisdiction's surveillance regime and the supplementary-measures shape (encryption with key-control, pseudonymisation before transfer, contractual challenge).
+4. **Sub-processor chain** — every onward transfer is itself a transfer; map two hops deep, not one.
+
+A transfer without a named mechanism + supplementary measures (where required) = an unauthorised transfer.
+
+### Step 4: Data-subject-rights workflow shape
+
+For each regime × right (access, deletion, portability, correction, objection, automated-decision-objection), name:
+
+1. **Window** — regime-mandated response time (GDPR: 1 month; CCPA: 45 days; HIPAA: 30 days for access).
+2. **Owner** — named human / role responsible (not "the team").
+3. **Mechanism** — how the subject submits, how identity is verified, how the response is delivered, how denials are reasoned.
+4. **Edge cases** — joint-controller scenarios, third-party data within a subject's record, deletion-vs-legal-hold conflicts.
+
+DSR workflows that exist only as a generic support-inbox process fail under every regime. Force named owners and windows.
+
+### Step 5: Validate the data-handling read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Classification coverage** — confirm every in-scope data category has a tier + cited rationale; un-rationalised tiers are guesses and must be re-run.
+2. **Retention binding** — assert every category × purpose has a calendar-unit retention + named end-state + cited authority; "as needed" entries fail.
+3. **Transfer + DSR completeness** — check every cross-border hop has a mechanism + supplementary-measures read; every applicable regime × right has a named owner + window. Gaps are surfaced, not smoothed.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the data-handling-judgment artifact
+
+Produce the data-handling-judgment note for the feature owner, ops lead, and counsel. The artifact operationalises the regime floor into policy that ops can implement and counsel can sign off.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Classifying a new data category and setting downstream rules.
+- Setting / auditing retention defaults against regime and purpose.
+- Judging a cross-border-transfer mechanism + supplementary measures.
+- Designing a DSR workflow with named owners and windows.
+
+**WHEN NOT to use this**
+
+- Regime-floor regulatory delta read — route to [`privacy-review`](../privacy-review/SKILL.md) (P6); this skill composes P6.
+- Contract-clause redline depth — route to [`contracts-cognition`](../contracts-cognition/SKILL.md) (P5).
+- Regime-floor surface — route to `regulatory-regime` (J1); this skill operationalises J1, doesn't replace it.
+- DLP / classifier-engine tooling — out of scope.
+
+## When the agent should load this
+
+- "How do we classify this field?"
+- "How long do we keep this?"
+- "Can we send this to the US / India / wherever?"
+- "Design our DSR workflow."
+- "Wie lange dürfen wir Logs aufbewahren?"
+
+## Output
+
+1. **`classification-map.md`** — every in-scope data category × tier + cited rationale.
+2. **`retention-policy.md`** — category × purpose × retention × end-state × authority.
+3. **`transfer-register.md`** — cross-border hops × mechanism × supplementary measures × sub-processor chain (two-deep).
+4. **`dsr-workflow.md`** — regime × right × window × owner × mechanism × edge cases.
+
+## Gotcha
+
+- Pseudonymous ≠ anonymous. If re-identification is possible with reasonable means, it's still personal data under GDPR.
+- Retention defaults inherited from the previous system are usually wrong; treat every category as a fresh decision.
+- "Encryption in transit" is not a Schrems-II supplementary measure on its own; the question is who can access the keys in the destination jurisdiction.
+- Joint-controllership is silently common (analytics, embedded widgets); name the controller relationship explicitly per hop.
+
+## Do NOT
+
+- Do NOT issue privacy legal opinions; this skill produces operational policy, counsel signs it off.
+- Do NOT classify by least-conservative tier to avoid operational burden; mis-classification downward is the canonical regulator finding.
+- Do NOT set retention without a named end-state; "as needed" is not a retention.
+
+## Runnable example
+
+Series-B SaaS with EU + US customer mix, adding a customer-success analytics integration.
+
+- Step 0 — Regime floor: GDPR (EU subjects), CCPA (CA subset), no PHI. GDPR storage-limitation is the ceiling; no minimum-retention mandate applies.
+- Step 1 — Classify: account-id = pseudonymous (low re-id); email = PII; usage-event = PII (linked to email); free-text-feedback = PII + potentially sensitive (subjects may include health / political content). Aggregate cohort metrics = anonymous if k-anonymity ≥ 50.
+- Step 2 — Retention: usage-event for product-analytics = 18 months, hard-delete on expiry; usage-event for billing-dispute = 7 years (contractual + tax authority); free-text-feedback = 12 months, hard-delete; email-for-marketing = until consent withdrawn or 24 months inactive.
+- Step 3 — Transfer: analytics vendor in US (no adequacy), SCC 2021 module 2 + supplementary measures (pseudonymisation of free-text-feedback before transfer, key-control retained in EU). Sub-processor chain: vendor uses logging service in US-only; ok within SCC.
+- Step 4 — DSR: access (1 month, CS lead, in-app + verified-email submission); deletion (1 month, CS lead, soft-delete-then-hard-delete-30d unless legal-hold); portability (1 month, ops engineer, JSON export); objection-to-marketing (immediate, automated).
+- Step 5 — Validate: every category tier rationalised; every retention category × purpose has end-state + authority; transfer hops have SCC + supplementary measures; DSR rights have owners + windows. Pass.
+- Step 6 — Emit data-handling-judgment artifact; ops implements retention jobs and DSR runbook; counsel signs off on transfer-impact assessment.

package/.agent-src/skills/deal-qualification-meddic/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: deal-qualification-meddic
+description: "Use when qualifying or disqualifying a single deal — MEDDIC slots with evidence, inversion test, disqualification heuristic. Triggers on 'is this deal real', 'should we walk away'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment]
+---
+
+# deal-qualification-meddic
+
+## When to use
+
+- A single deal needs a qualification call construction or a re-qualification mid-cycle — the deal is in pipeline but the team cannot answer *"who signs, on what criterion, against what pain, by when"* in writing.
+- Disqualification is overdue — a deal has slipped two stages or two quarters and the team is reluctant to walk, so resources are bleeding into a cell that should not be in pipeline.
+- A rep keeps reporting *"strong champion"* but the deal stalls — qualification needs to separate champion confidence from economic-buyer reality.
+
+Do NOT use to design pipeline stages (route to
+`pipeline-strategy`), construct the forecast call (route to
+`forecast-accuracy`), or build cross-deal pattern libraries (out of
+scope — this skill is single-deal qualification, one cycle).
+
+## Cognition cluster
+
+- **Mental model 30 — Inversion.** Do not ask *"why should this deal
+  close?"* — ask *"name the reason this deal will not close."* If no
+  answer survives, qualification is incomplete; if the answer is
+  load-bearing and the team has no countermeasure, disqualification
+  is the call. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 30.
+- **Mental model 9 — Hypothesis-driven thinking.** Each MEDDIC slot
+  is a hypothesis with falsification evidence. *"Mary is the
+  champion"* is a claim; *"Mary briefed two peers without us in the
+  room and reported back unprompted"* is evidence. Slots without
+  evidence are unfilled, regardless of rep confidence. See
+  `mental-models.md` § 9.
+- **Mental model 13 — Occam's razor.** When MEDDIC slots conflict,
+  the simpler explanation is usually right: *"the buyer does not
+  feel the pain on the same timeline we do"* beats *"procurement is
+  unusually slow this quarter"*. Pick the simpler explanation; it
+  changes the move. See `mental-models.md` § 13.
+- **Context-spine — product + customer-segment.** Read the
+  **product** slot for sellable scope (a deal asking for non-goal
+  scope is not qualified, it is mis-sold), and the
+  **customer-segment** slot for the segment's switch-event shape —
+  pain claims that do not match the segment's known switch events
+  are coaching opportunities, not qualifications. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Pull the deal record
+
+Latest call notes, last three buyer messages, named contacts and
+their org roles, current stage, age in stage, and the
+`stage-definitions.md` from `pipeline-strategy`. Without exit
+criteria you cannot test whether the deal earned its current stage.
+
+### Step 1: Walk the six MEDDIC slots with evidence
+
+For each slot, write the claim **plus** the evidence (a buyer
+artefact, a recording, a forwarded email, a board agenda) — not
+*"rep believes"*.
+
+1. **Metrics.** *"\<Buyer\> will measure \<our value\> as
+   \<quantified metric\> over \<window\>."* Evidence: buyer wrote
+   the metric or quoted it back unprompted.
+2. **Economic buyer.** *"\<Name, title\> signs the PO."* Evidence:
+   buyer-side org chart confirmed; the EB has met the team or
+   approved the project unblocked by the champion.
+3. **Decision criteria.** *"\<Buyer\> chooses on \<criteria\>, in
+   that order."* Evidence: criteria from the buyer's RFP, scorecard,
+   or written summary — not the rep's inference.
+4. **Decision process.** *"\<Steps and approvers\>, ending
+   \<date\>."* Evidence: a written timeline shared by the buyer.
+5. **Identify pain.** *"\<Pain\> costs \<\$\>/month;
+   business event \<X\> forces resolution by \<date\>."* Evidence:
+   buyer named the cost and the forcing event without prompting.
+6. **Champion.** *"\<Name\> sells internally without us in the
+   room; benefits if we win."* Evidence: champion forwarded an
+   internal email, briefed peers, or named the personal win.
+
+### Step 2: Inversion — name the reason this deal will not close
+
+Write the one sentence that, if true, kills the deal. If no
+sentence is true, the deal is qualified for its stage. If a sentence
+is true and there is no countermeasure planned, the deal moves to
+**disqualified-pending-evidence**.
+
+### Step 3: Run the disqualification heuristic
+
+Disqualify if any two of:
+
+1. Economic buyer is unnamed or never met the team after two cycles.
+2. No metric in writing after a discovery call and a follow-up.
+3. No forcing event — pain exists but resolution is *"someday"*.
+4. Champion cannot articulate the personal win when asked directly.
+
+Disqualification is not failure; it is recovered selling time.
+
+### Step 4: Set re-qualification triggers
+
+For slots still open, set the trigger and deadline: *"\<slot\>
+re-qualified when \<buyer artefact\> arrives by \<date\>."* If the
+date passes without the artefact, the slot reverts to unfilled and
+Step 3 runs again.
+
+### Step 5: Hand back
+
+Hand the MEDDIC card, the inversion sentence, and the re-qualification
+triggers to the rep for the next buyer interaction and to
+[`forecast-accuracy`](../forecast-accuracy/SKILL.md) for the
+forecast call. A deal with two or more unfilled MEDDIC slots cannot
+be **commit**, regardless of $ value or stage.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Qualifying or disqualifying a single deal one cycle at a time.
+- Building the MEDDIC card with falsifiable evidence per slot.
+
+**WHEN NOT to use this**
+
+- Designing or auditing pipeline stages — route to
+  [`pipeline-strategy`](../pipeline-strategy/SKILL.md).
+- Constructing the quarterly forecast call — route to
+  [`forecast-accuracy`](../forecast-accuracy/SKILL.md).
+- Diagnosing product-led signup → activation funnels — route to
+  [`funnel-analysis`](../funnel-analysis/SKILL.md).
+
+## When the agent should load this
+
+- "Qualify this deal — is it real?"
+- "Should we walk away from \<deal\>?"
+- "Why is this stuck in proposal for 60 days?"
+- "Was wissen wir wirklich über den Decision Process?"
+
+## Output
+
+1. **`meddic-card.md`** — six slots, one claim per slot with evidence link or quote. Unfilled slots flagged.
+2. **`inversion-sentence.md`** — the one reason this deal will not close; countermeasure (or *"none — disqualify"*).
+3. **`requalification-triggers.md`** — per-slot trigger + deadline + revert behaviour.
+
+## Gotcha
+
+- *"Strong champion"* without the personal-win sentence in writing is rep optimism, not qualification.
+- A metric the rep wrote on the buyer's behalf is a metric the buyer will not defend in procurement — it must come from the buyer or be quoted back unprompted.
+- Decision process *"once legal signs off"* is not a process; it is a hand-wave. Demand approvers, sequence, and dates.
+
+## Do NOT
+
+- Do NOT call a slot filled because *"the rep is sure"* — qualification is artefact-driven, not confidence-driven.
+- Do NOT keep a deal in **commit** with two or more unfilled slots regardless of size; size flatters, slots don't.
+- Do NOT skip disqualification because the deal is large — large deals with weak qualification miss louder.
+
+## Runnable example
+
+Mid-market deal, $ 180 k ACV, stuck at Proposal for 47 days.
+
+- MEDDIC card — **Metrics:** *"reduce ticket-handle-time by 30 %"* (buyer wrote it, ✓). **Economic buyer:** *"VP Support — never met"* (✗). **Decision criteria:** RFP scoring (✓). **Decision process:** *"procurement after legal — no dates"* (✗). **Pain:** *"reps overloaded — no forcing event"* (✗ — forcing event missing). **Champion:** *"Team lead Mary — personal win unclear"* (partial).
+- Inversion sentence — *"VP Support has not seen the value case and there is no forcing event; quarter rolls and the deal slides one more cycle."* Countermeasure: book VP-Support exec session within 10 days OR disqualify.
+- Disqualification heuristic — three slots unfilled → **disqualified-pending-evidence**; reverts to qualified only if exec session happens by deadline.
+- Hand-off — card + inversion + triggers → rep for VP-Support outreach; `forecast-accuracy` moves the deal out of **commit** until the slots fill.