@event4u/agent-config 7.0.2 → 7.2.0

package/dist/agent-src/skills/design-review/SKILL.md

@@ -36,6 +36,12 @@ A **live preview URL** is required for testing.
 
 ## Procedure: Design review
 
+1. **Inspect the PR and preview** — Read the PR description, diff, and identify changed components/pages; capture a baseline screenshot of the preview URL.
+2. **Walk the interactions** — Run Phase 1; cover hover/focus/active/disabled, keyboard, loading, and form error states.
+3. **Cover responsiveness, polish, a11y, robustness** — Run Phases 2–5 in order; record findings per phase.
+4. **Audit code-health and content** — Run Phases 6–7; check tokens, dead styles, copy, console warnings.
+5. **Verify and report** — Consolidate findings in the report structure; classify each as Blocker / High / Medium / Nit before posting.
+
 ### Phase 0: Preparation
 
 - Read PR description and git diff.
@@ -110,6 +116,61 @@ Test at three viewports:
 - No placeholder text left in production.
 - Check browser console for JavaScript errors or warnings.
 
+## Reviewer posture
+
+**Approval is earned, not assumed. Default to flagging.**
+
+A design review is a skeptic's pass. The default verdict for every element
+is "this needs to justify itself" — not "this is probably fine." Approve
+explicitly when you have examined the evidence and found it sound.
+
+This posture prevents the failure of "nothing to report" reviews that miss
+real issues because the reviewer defaulted to charitable assumptions.
+
+## Subtraction-first remedial hierarchy
+
+When a finding warrants a remediation recommendation, prefer in this order:
+
+1. **Delete** — remove the element, animation, pattern, or copy entirely
+2. **Reduce** — make it smaller, shorter, subtler, less frequent
+3. **Fix the specific issue** — change easing, origin, duration, contrast, font
+4. **Make it interruptible** (for motion) — switch to transition/spring
+5. **Move to GPU** (for motion) — animate only transform/opacity
+6. **Polish** — the lowest-leverage fix; only if the above don't apply
+
+*"Delete the animation" is always the first option to consider, even before
+suggesting a different easing curve.* The same applies to decorative elements,
+excessive copy, and redundant UI chrome.
+
+## Before / After / Why output format
+
+When reporting a finding with a specific remediation, use this table format:
+
+| Field | Content |
+|---|---|
+| **Before** | The current state (quote the code, value, or describe the pattern) |
+| **After** | The corrected state (specific value or alternative) |
+| **Why** | The mechanism: why is Before wrong and After better? (one sentence, states the principle) |
+
+**Wrong format** (do not use):
+```
+Before:
+  button { transition: all 0.3s ease; }
+After:
+  button { transition: transform 0.2s ease-out, opacity 0.2s ease-out; }
+```
+
+**Right format:**
+
+| | |
+|---|---|
+| **Before** | `transition: all 0.3s ease` |
+| **After** | `transition: transform 0.2s ease-out, opacity 0.2s ease-out` |
+| **Why** | `transition: all` animates layout properties on every state change, causing browser reflow; enumerate only the properties that move. |
+
+The Why column carries the reasoning — it's the part that teaches the developer
+and prevents the same finding from recurring.
+
 ## Communication principles
 
 ### Problems over prescriptions
@@ -224,6 +285,28 @@ This is especially useful when the user provides a screenshot or Figma export as
 - The model tends to suggest accessibility improvements that break the existing design system.
 - "Best practice" is not always the right choice — sometimes "good enough" ships faster.
 
+## Anti-slop scan
+
+During any design review, load
+[`docs/guidelines/design-antipatterns.md`](../../../docs/guidelines/design-antipatterns.md)
+as a reference. After the structured review phases, add an explicit
+**Anti-Slop Check** section to the review output:
+
+1. List any patterns from the catalog that appear in the reviewed UI (cite by
+   entry ID, e.g. V1, T2, C1).
+2. For each finding: note whether an override condition is in effect (if yes,
+   verify it is stated in the design brief; if not, flag as a finding).
+3. Run the AI-slop originality self-test on the overall aesthetic direction.
+   Report the result (pass / flag / fail) with one sentence of evidence.
+
+For the **objective quality floors** (WCAG contrast, font-size, line-length,
+reduced-motion, heading hierarchy, focus indicator), do NOT eyeball them —
+cite [`lint_design_quality`](../../../src/scripts/lint_design_quality.ts)
+output for the consumer project (Q1–Q6 in the catalog). The review owns the
+*subjective* anti-slop judgment (Visual / Typography / Color / Layout taste);
+the linter owns the *objective* floors; `accessibility-auditor` owns the WCAG
+*audit method*. Cite, don't re-derive.
+
 ## Do NOT
 
 - Do NOT skip accessibility testing — it's not optional.

package/dist/agent-src/skills/design-system-capture/SKILL.md

@@ -0,0 +1,234 @@
+---
+model_tier: inherit
+name: design-system-capture
+description: "Write and maintain DESIGN.md + PRODUCT.md — captures visual decisions and interaction patterns so design tasks stay consistent across sessions without re-scanning past work."
+domain: engineering
+personas:
+  - frontend-engineer
+workspaces:
+  - engineering
+packs:
+  - frontend-design
+token_budget_class: rich
+execution:
+  type: manual
+---
+
+# design-system-capture
+
+> Solves "design amnesia" — the failure mode where every AI design task
+> re-invents visual patterns (radius, shadows, motion, spacing) and
+> interaction patterns (destructive-action handling, optimistic UI, filter
+> persistence) because the agent has no cross-task memory of decisions
+> already made.
+>
+> **Boundary:** `brand-to-tokens` extracts *primitives* (colors, font
+> families → DTCG tokens). `existing-ui-audit` inventories *what exists*.
+> **This skill captures *usage decisions*:** "we use 8px radius for
+> elevated surfaces", "all destructive actions require typed confirmation".
+> They are complementary, not redundant.
+>
+> Gated by `tokens.rich_skills` in `.agent-settings.yml` (default `on`).
+> If `off`, skip rich context loading and work from brief alone.
+
+## Why this skill is rich
+
+DESIGN.md and PRODUCT.md serve as the project's design memory. To write
+useful capture documents and to read/apply them effectively, the agent
+needs full templates with worked examples showing what a well-structured
+DESIGN.md and PRODUCT.md look like in practice. A condensed version that
+says "write down your design decisions" produces documents too vague to
+be useful. The worked examples teach agents both the *vocabulary*
+(elevation, motion strategy, destructive-action policy) and the
+*specificity level* that makes these documents actionable across tasks.
+
+## When to use
+
+- Starting a new consumer project (initial capture, run once early)
+- After 2+ design tasks in the same project (update to capture what was decided)
+- When a subsequent design task produces inconsistent results (audit and reconcile)
+- Explicitly asked: "capture the design system", "write a DESIGN.md", "document our patterns"
+
+## The two documents
+
+### `DESIGN.md` — visual-system decisions
+
+Captures the *visual usage decisions* (not token primitives) that agents
+should apply consistently across all UI tasks in this project. Unlike
+`.tokens.json` (which records what a color value IS), DESIGN.md records
+*how and when to use it*.
+
+**Format:**
+
+```markdown
+# DESIGN.md — [Project name] visual system
+
+> AI-readable project design memory. Update after each design decision.
+> Last updated: [date]
+
+## Design philosophy
+One sentence: [density/formality/complexity philosophy]
+Example: "Information-dense dashboard; optimize for power users, not casual exploration."
+
+## Visual system
+
+### Elevation and radius
+- Elevated surfaces (modals, sheets, dropdowns): [X]px radius, [shadow-spec]
+- Inline elements (cards, chips): [X]px radius
+- Buttons: [X]px radius
+
+### Shadows
+- Elevated: [box-shadow value]
+- Floating (tooltips, popovers): [box-shadow value]
+- None (flat cards): [confirm]
+
+### Motion
+- Overlays and modals: [spring / easing spec + duration]
+- Micro-interactions (button feedback, toggles): [duration + easing]
+- Page transitions: [strategy or "none"]
+
+### Spacing
+- Base unit: [X]px
+- Card padding: [spec]
+- Section gap: [spec]
+- Tight grouping: [spec]
+
+### Color usage
+- Primary action: [token name]
+- Destructive: [token name]
+- Surface hierarchy: [primary bg → secondary bg → elevated bg]
+
+## Stack and conventions
+- CSS approach: [Tailwind / CSS modules / styled-components / etc.]
+- Component primitives: [shadcn / Radix / Headless UI / custom]
+- Icon system: [Phosphor / Heroicons / Lucide / etc.]
+```
+
+### `PRODUCT.md` — cross-feature interaction patterns
+
+Captures *interaction decisions* that should be consistent across features.
+Unlike a feature spec (which describes one feature), PRODUCT.md captures
+patterns that apply everywhere.
+
+**Format:**
+
+```markdown
+# PRODUCT.md — [Project name] interaction patterns
+
+> AI-readable cross-feature pattern memory. Update when a new pattern is established.
+> Last updated: [date]
+
+## Destructive actions
+Policy: [typed confirmation ("DELETE") / dialog with verb button / undo toast / etc.]
+Example: "All destructive actions require the user to type 'DELETE' or the resource name."
+
+## Mutation feedback
+Policy: [optimistic UI + inline undo / loading spinner / success toast / etc.]
+Undo window: [N seconds, or "not applicable"]
+Example: "Optimistic UI for all mutations; inline undo toast for 5 seconds, then commit."
+
+## Filter and sort persistence
+Policy: [URL params / localStorage / session / not persisted]
+Restore on load: [yes / no]
+
+## Empty states
+Approach: [illustration + CTA / text only / skeleton / etc.]
+Example: "Illustration + primary CTA for empty lists; text-only for zero-search-results."
+
+## Error handling
+Approach: [inline field errors / toast / error boundary / etc.]
+Network errors: [retry + message / fail fast / etc.]
+
+## Navigation and routing
+Pattern: [SPA / MPA / hybrid / etc.]
+Active state: [how active nav items are marked]
+
+## Mental model
+One sentence: [how the product conceptualizes itself to the user]
+Example: "Dashboard = control panel for power users, not an exploration space."
+```
+
+## Procedure
+
+### Step 1 — Assess what exists
+
+1. Check if `DESIGN.md` and `PRODUCT.md` already exist in the project root.
+2. If they exist: read both → skip to Step 3 (Update).
+3. If they don't exist: run `existing-ui-audit` (if not already done for this session) to inventory existing components, tokens, and conventions → proceed to Step 2.
+
+### Step 2 — Create (first run)
+
+1. **Extract visual decisions from the audit** (`state.ui_audit`): dominant
+   radius values, shadow patterns, spacing conventions, motion patterns.
+   Fill the DESIGN.md template above with the observed values. Mark
+   un-observed sections as `TBD`.
+2. **Extract interaction decisions from the codebase**: scan for delete
+   confirmation patterns, toast/feedback patterns, filter/URL persistence.
+   Fill the PRODUCT.md template. Mark un-observed sections as `TBD`.
+3. Write `DESIGN.md` and `PRODUCT.md` to the project root.
+4. Surface a one-paragraph summary: what was captured, what is still TBD,
+   and what action the user should take (review and correct the TBDs).
+
+### Step 3 — Update (subsequent runs)
+
+1. Read existing `DESIGN.md` and `PRODUCT.md`.
+2. Identify any decisions made in recent tasks that aren't yet captured
+   (e.g., a modal was built with 12px radius — add that to DESIGN.md).
+3. Correct any TBDs that are now resolved.
+4. Update the "Last updated" date.
+5. Output a diff summary: what changed and why.
+
+## How the design skills consume these documents
+
+When `DESIGN.md` or `PRODUCT.md` is present in the project root:
+
+- **`design-intelligence`** and **`fe-design`**: read DESIGN.md at the
+  start of any design task — use the captured decisions as project
+  constraints that override corpus suggestions.
+- **`ui-component-architect`**: read DESIGN.md for radius/shadow/motion
+  conventions before proposing any new component.
+- **`existing-ui-audit`**: when a full audit is impractical (large project),
+  read DESIGN.md as a proxy for "what this project's conventions are".
+
+The boundary from `brand-to-tokens`:
+- `.tokens.json` carries primitive values (gray-700 = #374151)
+- DESIGN.md carries usage decisions (elevated surfaces use 8px radius,
+  not 4px or 12px)
+Both are consumed together; DESIGN.md takes precedence for usage questions.
+
+## Gotcha
+
+- **Over-writing instead of diff-updating** — the most common failure.
+  Always read existing `DESIGN.md`/`PRODUCT.md` before writing; carry
+  all existing decisions forward and only add/correct. Losing prior
+  captured history is worse than capturing nothing.
+- **Copying tokens into DESIGN.md** — DESIGN.md is NOT a copy of
+  `.tokens.json`. It captures *usage decisions* ("8px radius on elevated
+  surfaces"), not primitive values ("gray-700 = #374151"). The
+  distinction is what makes DESIGN.md actionable.
+- **Capturing feature-specific behavior** — PRODUCT.md is for patterns
+  that repeat across 2+ features. A delete-confirmation pattern in one
+  form does NOT belong in PRODUCT.md until it appears in at least two
+  independent features.
+
+## Do NOT
+
+- Do NOT overwrite DESIGN.md/PRODUCT.md without first reading and diffing
+  the existing content — accumulated history is the value.
+- Do NOT make DESIGN.md a copy of `.tokens.json` — it captures decisions,
+  not token definitions.
+- Do NOT capture feature-specific behavior in PRODUCT.md — only patterns
+  that repeat across multiple features.
+- Do NOT mark a decision as captured without evidence from the actual codebase.
+
+## Output format
+
+On create:
+1. Write `DESIGN.md` to the project root with the extracted visual decisions.
+2. Write `PRODUCT.md` to the project root with the extracted interaction patterns.
+3. Surface a one-paragraph summary of what was captured and what is TBD.
+4. List any questions where the existing code is ambiguous.
+
+On update:
+1. Update both files with new decisions.
+2. Output a short diff: "Added: destructive-action policy. Updated: motion strategy (was TBD, now spring)."

package/dist/agent-src/skills/design-tokens/SKILL.md

@@ -132,4 +132,5 @@ four-operation split assigns to *rules/linters*, not the corpus).
 - [`design-intelligence`](../design-intelligence/SKILL.md) — grounded value selection.
 - [`tailwind-engineer`](../tailwind-engineer/SKILL.md) — utility-discipline consumer.
 - [`react-shadcn-ui`](../react-shadcn-ui/SKILL.md) — shadcn token conventions.
+- [`docs/guidelines/design-antipatterns.md`](../../../docs/guidelines/design-antipatterns.md) — when authoring the colour layer, avoid the C5 cream/sand default palette (OKLCH L 0.84–0.97, C < 0.06) and C1 purple/violet primaries unless the brand explicitly defines them; the `brand-consistency` rule validates emitted tokens against the active brand profile.
 - Tests: `tests/test_design_tokens_toolchain.py`.

package/dist/agent-src/skills/dpa-review/SKILL.md

@@ -0,0 +1,130 @@
+---
+model_tier: inherit
+name: dpa-review
+description: "Use when reviewing a DPA as controller or processor against GDPR Art. 28 — GREEN/YELLOW/RED gap frame, never a final call. Triggers on \"review this DPA\", \"check this DPA\"."
+status: active
+tier: senior
+council_depth: deep
+domain: process
+recommended_for_user_types: [legal]
+workspaces:
+  - legal-review-prep
+packs:
+  - legal-review-prep
+trust:
+  level: advisory
+install:
+  removable: true
+---
+
+# dpa-review
+
+## When to use
+
+- A counterparty sends a DPA (their paper or yours) and the question is *where the GDPR Art. 28 obligations are met, partial, or missing* — before an attorney spends time on it.
+- An existing processing relationship is being re-papered (new sub-processor chain, new transfer route, new scope) and the Art. 28 surface must be re-walked.
+- You need a structured gap frame and the open questions an attorney must resolve — not a redline and not a verdict.
+
+Do NOT use for clause-level redlining of a general contract (route to `contract-review`), for the regulatory-regime delta read in isolation (route to [`privacy-review`](../privacy-review/SKILL.md)), or for the classification / retention / transfer-mechanism operational surface (route to [`data-handling-judgment`](../data-handling-judgment/SKILL.md)). This skill walks the Art. 28 *agreement*; those skills produce the inputs it cites.
+
+## Procedure
+
+### Step 0: Establish jurisdiction and refuse if out of scope
+
+1. Read the DPA's governing-law / jurisdiction clause. Tag the output `Jurisdiction: EU` or `Jurisdiction: DE`.
+2. If the DPA is governed by a non-EU/DE regime with no GDPR nexus (e.g. a pure US state-privacy regime), **refuse the gap review**: say "consult licensed local counsel". Note as an open question that GDPR may still apply extraterritorially under Art. 3 (EU-established controller/processor, or offering to / monitoring EU data subjects) — for the attorney to confirm.
+3. No default positions ship. Read acceptable values (sub-processor notice window, audit frequency, liability cap, breach-notice deadline) from `legal-practice-profile`. Until configured, every such value is a `[configure]` placeholder in the output, not a guess.
+
+### Step 1: Fix the role — controller or processor
+
+The Art. 28 reading forks on which side you are.
+
+- **You are the controller** → you instruct. Read whether the agreement binds the *processor* to your instructions, confidentiality, security, sub-processor flow-down, assistance, deletion, and audit *rights for you*.
+- **You are the processor** → you are bound. Read whether the obligations imposed are deliverable as written (audit cadence you can sustain, deletion you can actually perform, sub-processor flow-down you can pass down).
+- **Joint / unclear** → flag it as the first open question; Art. 26 joint-controllership changes the frame.
+
+### Step 2: Walk the Art. 28(3) requirements as a checklist FLOOR (not ceiling)
+
+For each, assign GREEN (present + adequate) / YELLOW (present but weak/ambiguous) / RED (missing or contradicts Art. 28):
+
+1. **(a) Documented instructions** — processing only on the controller's documented instructions, incl. for transfers.
+2. **(b) Confidentiality** — persons authorised to process are under a confidentiality commitment.
+3. **(c) Security — Art. 32** — appropriate technical and organisational measures named (not "industry-standard" alone).
+4. **(d) Sub-processors** — prior authorisation (general or specific), notice of changes + objection right, and **flow-down** of equivalent Art. 28 terms.
+5. **(e) Data-subject-rights assistance** — processor assists the controller in responding to DSR requests.
+6. **(f) Breach + DPIA assistance — Art. 33/34/35/36** — breach-notification assistance with a deadline, plus assistance with DPIAs and prior consultation.
+7. **(g) Deletion / return** — at end of provision, delete or return all personal data + copies, at the controller's choice.
+8. **(h) Audit / inspection** — make available the information needed to demonstrate compliance + allow and contribute to audits/inspections.
+9. **International transfer — Chapter V** — any transfer outside the EEA has a valid mechanism (adequacy / SCCs with module + version / BCR) and, where required, supplementary measures. Schrems-II transfer-impact assessment is an open question, not a checkbox.
+
+The nine are the floor; flag anything beyond them that materially shifts risk (liability cap, indemnity, deletion-vs-legal-hold conflict).
+
+### Step 3: Frame the gaps and the open questions
+
+1. Produce the GREEN/YELLOW/RED frame, one line per Art. 28(3) item + transfers.
+2. For every YELLOW/RED, write the **open question an attorney must resolve** — not a redline. ("(d) names no objection window — is `[configure]` acceptable, or must a specific window be negotiated?")
+3. Surface any `[configure]` placeholder that blocked a GREEN/YELLOW/RED call.
+
+### Step 4: Emit the artifacts
+
+Produce `dpa-gap-frame.md` and `open-questions.md`. Each carries the `Jurisdiction:` tag and the attorney-review line. This skill does not opine; it prepares the attorney's review.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Reviewing a DPA against the GDPR Art. 28 surface, as controller or processor.
+- Producing a gap frame + attorney open-questions before counsel review.
+
+**WHEN NOT to use this**
+
+- General contract clause redlines (liability, IP, term, termination) — route to `contract-review`.
+- Which regime applies / regime delta read — route to [`privacy-review`](../privacy-review/SKILL.md).
+- Data classification, retention windows, transfer-mechanism + supplementary-measures operational shape — route to [`data-handling-judgment`](../data-handling-judgment/SKILL.md).
+- A binding legal conclusion — route to a licensed attorney; this skill never issues one.
+
+## When the agent should load this
+
+- "Kannst Du diese AVV / DPA gegen Art. 28 prüfen?"
+- "Ein Kunde hat seinen Auftragsverarbeitungsvertrag geschickt — wo sind die Lücken?"
+
+## Output
+
+1. **`dpa-gap-frame.md`** — `Jurisdiction:` tag; role (controller/processor); one GREEN/YELLOW/RED line per Art. 28(3)(a)–(h) + Chapter V transfers; the attorney-review line.
+2. **`open-questions.md`** — `Jurisdiction:` tag; one attorney-resolvable question per YELLOW/RED, plus every `[configure]` placeholder that blocked a call; the attorney-review line.
+
+## Gotcha
+
+- "Industry-standard security" satisfies neither Art. 28(3)(c) nor Art. 32 — the TOMs must be named; an unnamed measures clause is YELLOW at best, often RED.
+- Sub-processor flow-down is the silent RED: the agreement names sub-processors but never binds them to equivalent Art. 28 terms, so the chain leaks obligations.
+- The role fork is load-bearing — a processor-side review that reads the controller-side rights as if they were yours mis-frames every deliverability gap.
+- "Delete OR return" at the controller's choice is the requirement; a clause that hard-codes deletion (ignoring legal-hold) or hard-codes return is a gap, not a convenience.
+- A non-EU governing-law clause does not end the question — GDPR can still bite under Art. 3; refuse the gap review but hand the Art. 3 question to the attorney, never silently drop it.
+
+## Do NOT
+
+- Do NOT ship default values for notice windows, audit cadence, liability caps, or breach deadlines; read `legal-practice-profile` or emit `[configure]`.
+- Do NOT issue a final legal call, a clearance, or a "this DPA is fine" — GREEN is a triage signal, not a sign-off. Cite `legal-safety-floor`.
+- Do NOT review a DPA outside EU/DE scope as if it were in scope; refuse to gap-review and route to local counsel.
+- Do NOT drop the `Jurisdiction:` tag or the attorney-review line from any output.
+
+## Runnable example
+
+Processor-side review of a customer's DPA, governed by German law.
+
+- Step 0 — `Jurisdiction: DE`. In scope. `legal-practice-profile` not configured → notice window, audit cadence, breach deadline are `[configure]`.
+- Step 1 — Role = **processor** (we host the customer's SaaS data). Frame reads deliverability, not rights.
+- Step 2 — Art. 28(3) walk:
+  - (a) documented instructions — GREEN.
+  - (b) confidentiality — GREEN.
+  - (c) security / Art. 32 — YELLOW ("appropriate measures per industry standard"; no TOMs annex named).
+  - (d) sub-processors — RED (general authorisation granted, but **no flow-down** clause binding our sub-processors to equivalent terms, and objection window left blank = `[configure]`).
+  - (e) DSR assistance — GREEN.
+  - (f) breach assistance / Art. 33 — YELLOW (assistance promised, deadline blank = `[configure]`; can we meet the controller's own 72h clock?).
+  - (g) deletion / return — YELLOW (hard-codes deletion; no return option, no legal-hold carve-out).
+  - (h) audit — RED for us as processor (on-site audit "at any time, without notice" — not sustainable; cadence = `[configure]`).
+  - Chapter V transfers — RED (our logging sub-processor is US-based; no SCC module/version named; Schrems-II TIA = open question).
+- Step 3 — open questions, e.g.: *"(d) — add a flow-down clause and a `[configure]` objection window?"*; *"(h) — negotiate audit to `[configure]` cadence with notice?"*; *"Chapter V — which SCC module/version covers the US logging sub-processor, and is a TIA required?"*
+- Step 4 — emit `dpa-gap-frame.md` + `open-questions.md`, both tagged `Jurisdiction: DE` and carrying:
+
+> ⚠️ Attorney review required on material use. This is a draft for a licensed attorney, not legal advice and not a legal conclusion.

package/dist/agent-src/skills/dpa-review/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+    "skill": "dpa-review",
+    "last_eval": "2026-06-24",
+    "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers DE+EN phrasings for reviewing a Data Processing Agreement against GDPR Art. 28 (controller or processor). Should-not-trigger covers near-miss neighbours: NDA triage, generic contract review, privacy-regime read (privacy-review), legal triage.",
+    "queries": [
+        { "q": "review this DPA as processor against GDPR Art. 28", "trigger": true },
+        { "q": "check this data processing agreement, we're the controller", "trigger": true },
+        { "q": "der Kunde hat seine AVV geschickt — prüf die Art-28-Lücken", "trigger": true },
+        { "q": "gap-frame this processor agreement for sub-processor and audit clauses", "trigger": true },
+        { "q": "erfüllt dieser Auftragsverarbeitungsvertrag Art. 28 DSGVO?", "trigger": true },
+        { "q": "check this NDA — standard or not?", "trigger": false },
+        { "q": "review this vendor MSA clause-by-clause", "trigger": false },
+        { "q": "which privacy regime applies to us, GDPR or CCPA?", "trigger": false },
+        { "q": "is this a legal problem at all?", "trigger": false },
+        { "q": "set up our legal practice profile", "trigger": false }
+    ]
+}

package/dist/agent-src/skills/existing-ui-audit/SKILL.md

@@ -16,10 +16,10 @@ packs:
 > **Interplay:** this audit answers *what exists* (components, tokens,
 > primitives → `state.ui_audit`);
 > [`design-intelligence`](../design-intelligence/SKILL.md) answers *what to
-> build* (corpus-grounded style/token/typography/pattern selection).
-> Audit runs first; its reuse findings outrank corpus suggestions — never
-> let a grounded recommendation introduce a component the inventory
-> already covers.
+> build* (corpus-grounded style/token/typography/pattern selection for the
+> brief). Audit runs first, and its reuse findings outrank corpus
+> suggestions — never let a grounded recommendation introduce a new
+> component the inventory already covers.
 
 ## When to use
 
@@ -208,6 +208,17 @@ violations will surface as new findings on every run.
 - Greenfield is detected, not assumed — a project with one Blade layout and no components is still greenfield only if tokens AND design system markers AND components are all empty.
 - Re-running the skill on a stale state-file: cache by `(composer.json mtime, package.json mtime)`; if either changed, re-audit and overwrite.
 
+## Anti-slop cross-reference
+
+When the audit inventory reveals an existing aesthetic direction (dominant color
+scheme, border-radius convention, motion patterns), cross-check the findings
+against
+[`docs/guidelines/design-antipatterns.md`](../../../docs/guidelines/design-antipatterns.md).
+If the existing UI already uses a listed anti-pattern, surface it as a design-debt
+finding (separate from the reuse inventory) — flag by entry ID and severity. The
+next design step can then decide whether to continue the existing pattern (for
+consistency) or introduce a corrective direction change.
+
 ## Do NOT
 
 - Do NOT advance to `directives/ui/design.py` or `apply.py` if `state.ui_audit` is empty.