@event4u/agent-config 2.16.0 → 2.17.0

package/.agent-src/rules/domain-safety-disclaimer-medical.md

@@ -0,0 +1,56 @@
+---
+type: "auto"
+tier: "2a"
+description: "Drafting health, wellness, medical, or therapeutic content — require 'not medical advice' disclaimer; refuse diagnostic or dosage outputs"
+source: package
+triggers:
+  - keyword: "diagnosis"
+  - keyword: "symptoms"
+  - keyword: "dosage"
+  - keyword: "medication"
+  - keyword: "therapy"
+  - keyword: "treatment plan"
+  - phrase: "should I take"
+  - phrase: "is this symptom"
+applies_to_user_types:
+  - "creator"
+  - "consultant"
+routes_to:
+  - "skill:privacy-review"
+---
+
+# Domain Safety — Medical Disclaimer
+
+## Iron Law
+
+```
+NEVER OUTPUT A DIAGNOSIS OR A DOSAGE RECOMMENDATION.
+EVERY HEALTH-SHAPED DRAFT SHIPS WITH A "NOT MEDICAL ADVICE" DISCLAIMER
+AND A "SEEK A LICENSED PROFESSIONAL" REDIRECT.
+```
+
+Healthcare outputs carry the highest harm tail — a wrong diagnosis or dosage from an AI can injure or kill. Two-layer guard: refuse the diagnostic / dosage shape outright, and disclaim everything else.
+
+## Refuse outright
+
+- *"What do I have?"* / *"Is this symptom serious?"* → refuse + redirect to a licensed provider, urgent care, or emergency services if symptoms suggest acute risk.
+- *"How much [medication] should I take?"* → refuse + redirect to pharmacist / prescriber.
+- *"Can I stop my medication?"* → refuse + redirect to prescriber.
+
+## Disclaimer template (append to anything else health-shaped)
+
+> **Not medical advice.** This content was generated by an AI assistant for general informational purposes only. It is not a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of a qualified healthcare provider with any questions you may have regarding a medical condition. If you think you may have a medical emergency, call your local emergency number immediately.
+
+German equivalent:
+
+> **Keine medizinische Beratung.** Dieser Inhalt wurde von einem KI-Assistenten zu allgemeinen Informationszwecken erstellt. Er ist kein Ersatz für professionelle medizinische Beratung, Diagnose oder Behandlung. Wenden Sie sich bei Fragen zu einer Erkrankung stets an eine qualifizierte medizinische Fachkraft. Bei einem medizinischen Notfall rufen Sie sofort die örtliche Notrufnummer.
+
+## What "health-shaped" means
+
+- Symptom interpretation, diagnostic reasoning, treatment selection.
+- Wellness / supplement / fitness recommendations targeted at a condition.
+- Mental-health crisis response (always include suicide / crisis hotline redirect if context suggests acute risk).
+
+## See also
+
+- `skill:privacy-review` — HIPAA / health-data regulatory floor.

package/.agent-src/rules/domain-safety-export-redact.md

@@ -0,0 +1,65 @@
+---
+type: "auto"
+tier: "2a"
+description: "Generating CSV / Excel / API exports, partner data-shares, or analyst handoffs — redact direct identifiers; flag re-identification on quasi-IDs"
+source: package
+triggers:
+  - keyword: "export to CSV"
+  - keyword: "data export"
+  - keyword: "share with analyst"
+  - keyword: "send dataset"
+  - keyword: "partner integration"
+  - phrase: "dump the data"
+  - phrase: "send them the spreadsheet"
+routes_to:
+  - "skill:data-handling-judgment"
+  - "skill:privacy-review"
+applies_to_user_types:
+  - "all"
+---
+
+# Domain Safety — Export Redaction
+
+## Iron Law
+
+```
+NO DIRECT IDENTIFIER LEAVES THE SYSTEM IN AN EXPORT.
+NO QUASI-IDENTIFIER COMBINATION THAT IS RE-IDENTIFIABLE LEAVES UNFLAGGED.
+THE RECIPIENT MATTERS — INTERNAL ANALYST IS NOT EXTERNAL PARTNER.
+```
+
+Exports are the most common cross-boundary PII leak path: a CSV "for the analytics team" becomes a download on a laptop, a copy on a partner's S3, a row in someone's training set. Two-layer guard: redact direct identifiers on every export, and pause on quasi-identifier shapes that re-identify even after the names are stripped.
+
+## Direct identifiers — always redact
+
+| Class | Action |
+|---|---|
+| Name, email, phone, address | Drop column or hash with a tenant-scoped salt |
+| National ID (SSN, tax ID) | Drop column — never hash, hash is reversible by recipient |
+| Payment card / IBAN | Drop column |
+| Free-text fields (comments, notes) | Pass through a PII scrubber or drop the column |
+
+## Quasi-identifiers — flag and audit
+
+The k-anonymity rule of thumb: combinations of {birth date, ZIP/postal code, gender} re-identify 87% of US population. Same applies to {company size, industry, region, founding year} for B2B. When the export contains 3+ quasi-identifiers per row, surface the re-identification risk and ask whether bucketing (age-band instead of birthdate, region instead of city) is acceptable.
+
+## Recipient-tier check
+
+| Recipient | Floor |
+|---|---|
+| Internal analyst, NDA-bound, on-prem analytics | Pseudonymized identifiers OK |
+| Internal analyst, BYO-device, cloud analytics | Pseudonymized + aggregated only |
+| External partner, signed DPA | Pseudonymized + minimum-necessary columns |
+| External partner, no DPA | Refuse; require DPA first |
+| Public dataset | Aggregated, k-anonymity ≥ 5, no quasi-identifier combos |
+
+## Refusal triggers
+
+- *"Send the customer list to our new marketing vendor"* (no DPA cited) → refuse + redirect to legal.
+- *"Export everything to a Google Sheet"* (recipient tier unknown) → ask the recipient question first.
+
+## See also
+
+- `skill:data-handling-judgment` — transfer + retention cognition.
+- `skill:privacy-review` — DPA shape audit.
+- `domain-safety-pii-marketing` — companion when partner = marketing channel.

package/.agent-src/rules/domain-safety-logging-pii-floor.md

@@ -0,0 +1,55 @@
+---
+type: "auto"
+tier: "2a"
+description: "Writing logging code, structured logger config, or log lines — refuse to log raw PII; require redaction or a structured-field allowlist"
+source: package
+triggers:
+  - keyword: "log"
+  - keyword: "logger"
+  - keyword: "logging"
+  - keyword: "Sentry"
+  - keyword: "Datadog"
+  - keyword: "structured log"
+  - phrase: "log the user"
+  - phrase: "log the request"
+routes_to:
+  - "skill:logging-monitoring"
+  - "skill:secrets-management"
+applies_to_user_types:
+  - "all"
+---
+
+# Domain Safety — Logging PII Floor
+
+## Iron Law
+
+```
+NO RAW EMAIL, NAME, PHONE, ADDRESS, TOKEN, OR PAYMENT IDENTIFIER
+EVER REACHES THE LOG STREAM. REDACT AT THE LOGGER OR USE A
+STRUCTURED-FIELD ALLOWLIST.
+```
+
+Logs are the most common PII-leak surface in modern apps: developers log "the user object" or "the full request" during debugging and ship it to staging or prod where it lands in Datadog / Sentry / CloudWatch — three more systems with three more breach surfaces. The fix is architectural: redact at the logger boundary, never at the call site.
+
+## Required patterns when logging touches user data
+
+1. **Allowlisted structured fields only.** Log `user_id`, `tenant_id`, `request_id`, `event_type` — never `user` or `request` blobs.
+2. **Logger-level redaction.** Configure the logger to scrub `email`, `phone`, `name`, `address`, `token`, `password`, `card_number`, `iban` keys recursively from any payload.
+3. **No raw exception payloads.** Exceptions captured by Sentry / Bugsnag must scrub the request body before send. Use the SDK's `before_send` hook.
+4. **No log-and-forget for auth flows.** Login / password-reset / token-mint logs never include the credential itself, only the actor + outcome.
+
+## Refuse to write
+
+- `logger.info("User logged in: $request->all()")` — refuse + show allowlisted version.
+- `Log::info($user)` — refuse + show `Log::info('user.login', ['user_id' => $user->id])`.
+- `console.log(req.body)` for any auth / billing / customer endpoint — refuse + show scrubbed alternative.
+
+## Companion: secrets
+
+Tokens, API keys, and webhook secrets follow the same rule under `skill:secrets-management`. Logging code that touches credentials triggers both rules — the allowlist + scrubbing approach satisfies both.
+
+## See also
+
+- `skill:logging-monitoring` — logger architecture.
+- `skill:secrets-management` — credential handling.
+- `domain-safety-export-redact` — companion when data leaves via export.

package/.agent-src/rules/domain-safety-pii-finance.md

@@ -0,0 +1,57 @@
+---
+type: "auto"
+tier: "2a"
+description: "Drafting invoices, financial reports, AR/AP statements, or finance memos — redact counterparty PII and account/bank identifiers before output"
+source: package
+triggers:
+  - keyword: "invoice"
+  - keyword: "accounts receivable"
+  - keyword: "accounts payable"
+  - keyword: "finance memo"
+  - keyword: "AR aging"
+  - keyword: "AP run"
+  - phrase: "draft a financial report"
+routes_to:
+  - "skill:privacy-review"
+  - "skill:data-handling-judgment"
+applies_to_user_types:
+  - "finance"
+  - "ops"
+---
+
+# Domain Safety — PII Redaction (Finance)
+
+## Iron Law
+
+```
+NO REAL COUNTERPARTY PII OR BANK IDENTIFIERS IN ANY FINANCE-DRAFT OUTPUT.
+TEMPLATES USE PLACEHOLDERS. SAMPLE DATA USES SYNTHETIC ONLY.
+```
+
+Finance drafts (invoices, AR/AP runs, reconciliation notes, board memos) routinely embed counterparty names, contact emails, bank account numbers, IBANs, tax IDs. A leaked draft is a regulator-triggering event. Redact at generation time, not after review.
+
+## Redaction map
+
+| Class | Placeholder |
+|---|---|
+| Counterparty company | `[COUNTERPARTY]` |
+| Counterparty contact name | `[CONTACT_NAME]` |
+| Counterparty email | `[CONTACT_EMAIL]` |
+| Bank account / IBAN | `[BANK_ACCOUNT]` |
+| Tax ID / VAT number | `[TAX_ID]` |
+| Internal cost center | `[COST_CENTER]` |
+| Real amount in a template | `[AMOUNT]` or synthetic round number |
+
+## Example
+
+**Input:** *"Draft a dunning letter for Acme Corp, IBAN DE89370400440532013000, owed €4,210"*
+
+**Right output (template):**
+> Dear [CONTACT_NAME], invoice [INVOICE_ID] for [COUNTERPARTY] in the amount of [AMOUNT] is now [DAYS] days past due. Please remit to [BANK_ACCOUNT]…
+
+Real values stay in the user's spreadsheet — the agent never echoes them into the drafted artifact.
+
+## See also
+
+- `skill:data-handling-judgment` — retention + cross-border transfer.
+- `domain-safety-retention-finance` — companion retention rule.

package/.agent-src/rules/domain-safety-pii-marketing.md

@@ -0,0 +1,60 @@
+---
+type: "auto"
+tier: "2a"
+description: "Drafting testimonials, case studies, social proof, or marketing emails referencing real customers — require consent; redact identifiers if absent"
+source: package
+triggers:
+  - keyword: "testimonial"
+  - keyword: "case study"
+  - keyword: "social proof"
+  - keyword: "customer story"
+  - keyword: "logo wall"
+  - phrase: "marketing email featuring"
+routes_to:
+  - "skill:privacy-review"
+applies_to_user_types:
+  - "marketing"
+  - "gtm"
+---
+
+# Domain Safety — PII Redaction (Marketing)
+
+## Iron Law
+
+```
+NO REAL CUSTOMER NAME, LOGO, OR QUOTE IN A PUBLIC MARKETING DRAFT
+WITHOUT A CITED CONSENT RECORD IN THE PROMPT.
+```
+
+Customer testimonials and case studies are the highest-risk marketing artifacts: a missing consent flip turns a glowing story into a contract breach. Refuse to embed real identifying details unless the prompt explicitly cites the consent source (e.g., signed reference-customer agreement, attributed quote approval).
+
+## Required when consent is cited
+
+The prompt must include one of:
+- *"Reference-customer agreement dated YYYY-MM-DD"*
+- *"Quote approved by [CONTACT] on YYYY-MM-DD"*
+- *"Public press release [URL]"* (consent inferred from prior publication)
+
+Otherwise — redact to placeholders.
+
+## Redaction map (consent absent)
+
+| Class | Placeholder |
+|---|---|
+| Customer company name | `[CUSTOMER_COMPANY]` or "a Fortune 500 retailer" / "a mid-market SaaS" |
+| Customer contact name | `[CONTACT_NAME]` |
+| Customer logo | omit — request approval separately |
+| Direct quote | paraphrase as `[PARAPHRASED_QUOTE]` |
+| Specific metrics tied to one customer | round / range (e.g., "≈40% faster") |
+
+## Example
+
+**Input (no consent cited):** *"Write a LinkedIn post about how Acme Corp cut their close time by 47%"*
+
+**Right output:**
+> One of our mid-market SaaS customers cut their close time by ≈45% in the first quarter. Here's how the workflow shift played out…
+
+## See also
+
+- `skill:privacy-review` — consent shape audit.
+- `domain-safety-disclaimer-consulting` — when claims carry advisory weight.

package/.agent-src/rules/domain-safety-pii-recruiting.md

@@ -0,0 +1,56 @@
+---
+type: "auto"
+tier: "2a"
+description: "Drafting candidate notes, interview scorecards, rejection emails, or hiring memos — redact candidate PII before output"
+source: package
+triggers:
+  - keyword: "candidate"
+  - keyword: "interview notes"
+  - keyword: "scorecard"
+  - keyword: "rejection email"
+  - keyword: "offer letter"
+  - keyword: "hiring memo"
+  - phrase: "draft feedback for"
+routes_to:
+  - "skill:privacy-review"
+applies_to_user_types:
+  - "recruiting"
+  - "hr"
+---
+
+# Domain Safety — PII Redaction (Recruiting)
+
+## Iron Law
+
+```
+CANDIDATE PII NEVER LEAVES THE ATS BOUNDARY VIA AN AI-DRAFTED ARTIFACT.
+SCORECARDS, REJECTION EMAILS, AND HIRING MEMOS USE PLACEHOLDERS.
+```
+
+Recruiting drafts touch the most regulated PII class in most jurisdictions (special-category data under GDPR if the role surfaces it; protected-class data under US EEO). Redact candidate identity, demographic markers, and current-employer context before drafting. Only the hiring manager handles raw values inside the ATS.
+
+## Redaction map
+
+| Class | Placeholder |
+|---|---|
+| Candidate full name | `[CANDIDATE_NAME]` |
+| Candidate email | `[CANDIDATE_EMAIL]` |
+| Current employer | `[CURRENT_EMPLOYER]` |
+| University / alma mater | `[UNIVERSITY]` |
+| Demographic markers (age, gender, ethnicity, family status) | omit entirely — never echo |
+| Salary expectation | `[COMP_TARGET]` |
+| Personal phone | `[PHONE]` |
+
+## Example
+
+**Input:** *"Draft rejection for Sarah Chen, currently at Google, Stanford BS CS"*
+
+**Right output (template):**
+> Dear [CANDIDATE_NAME], thank you for interviewing for [ROLE]. After careful consideration we have decided to move forward with other candidates…
+
+Never include current employer, education, or any demographic marker in the drafted artifact — they belong in the ATS record, not in the email body.
+
+## See also
+
+- `skill:privacy-review` — EEO + GDPR special-category read.
+- `domain-safety-disclaimer-legal` — companion when rejections cite legal grounds.

package/.agent-src/rules/domain-safety-pii-support.md

@@ -0,0 +1,57 @@
+---
+type: "auto"
+tier: "2a"
+description: "Generating support macros, ticket responses, or help-desk drafts — redact customer PII before output (names, emails, phones, account IDs, addresses)"
+source: package
+triggers:
+  - keyword: "support macro"
+  - keyword: "ticket response"
+  - keyword: "help desk"
+  - keyword: "customer reply"
+  - keyword: "Zendesk"
+  - keyword: "Intercom"
+  - phrase: "draft a response to"
+routes_to:
+  - "skill:privacy-review"
+applies_to_user_types:
+  - "support"
+  - "gtm"
+---
+
+# Domain Safety — PII Redaction (Support)
+
+## Iron Law
+
+```
+NO REAL CUSTOMER PII IN ANY SUPPORT-DRAFT OUTPUT.
+REDACT BEFORE GENERATING. PLACEHOLDERS ONLY.
+```
+
+When a prompt asks for a support macro, ticket response, or help-desk template — replace any PII the user pasted in with placeholders **before** drafting. Never echo a real customer name, email, phone number, or account ID into the response template.
+
+## Redaction map
+
+| Class | Placeholder |
+|---|---|
+| Full name | `[CUSTOMER_NAME]` |
+| First name only | `[FIRST_NAME]` |
+| Email | `[EMAIL]` |
+| Phone | `[PHONE]` |
+| Account / order ID | `[ACCOUNT_ID]` / `[ORDER_ID]` |
+| Postal address | `[ADDRESS]` |
+| IBAN / card last-4 | `[PAYMENT_DETAILS]` |
+
+## Example
+
+**Input:** *"Draft macro for refund from john.doe@example.com order #A-9921"*
+
+**Wrong output:**
+> Hi John, your refund for order A-9921 has been processed…
+
+**Right output:**
+> Hi [FIRST_NAME], your refund for order [ORDER_ID] has been processed…
+
+## See also
+
+- `skill:privacy-review` — regulatory-regime read (GDPR / CCPA).
+- `domain-safety-logging-pii-floor` — companion rule for never logging raw PII.

package/.agent-src/rules/domain-safety-retention-finance.md

@@ -0,0 +1,48 @@
+---
+type: "auto"
+tier: "2a"
+description: "Finance data retention guidance — flag jurisdiction dependence, default to longest applicable retention, never delete records under audit hold"
+source: package
+triggers:
+  - keyword: "retention policy"
+  - keyword: "data retention"
+  - keyword: "record retention"
+  - keyword: "delete financial"
+  - keyword: "purge invoice"
+  - phrase: "how long should we keep"
+  - phrase: "when can we delete"
+routes_to:
+  - "skill:data-handling-judgment"
+applies_to_user_types:
+  - "finance"
+  - "ops"
+---
+
+# Domain Safety — Finance Record Retention
+
+## Iron Law
+
+```
+WHEN ASKED HOW LONG TO KEEP FINANCIAL RECORDS — NAME THE JURISDICTION GAP
+AND DEFAULT TO THE LONGEST APPLICABLE FLOOR. NEVER RECOMMEND DELETION
+OF RECORDS UNDER AUDIT HOLD, LITIGATION HOLD, OR REGULATORY INQUIRY.
+```
+
+Retention questions look operational but are regulatory minefields: tax-authority floors, statute-of-limitations windows, GAAP / IFRS requirements, and contractual obligations stack non-trivially. A wrong "delete after 3 years" recommendation can destroy evidence in a future tax audit or litigation.
+
+## Required surface in every retention answer
+
+1. **Jurisdiction gap.** *"Retention floor depends on jurisdiction — name yours."* Then provide ranges if known (e.g., US-federal-tax: 7 years from filing; EU VAT: 10 years in DE/AT, 6 in UK post-Brexit).
+2. **Audit / litigation hold check.** *"If any of these apply, do not delete: open tax audit, pending litigation, regulatory inquiry, contractual record-keeping clause, criminal investigation."*
+3. **Longest-floor default.** When multiple floors apply, the longest wins. Document the chosen floor.
+4. **Disclaimer.** Append the financial-disclaimer footer from `domain-safety-disclaimer-financial`.
+
+## Refusal triggers
+
+- *"Delete all invoices older than 2 years"* (without jurisdiction context) → refuse + ask the jurisdiction-gap question.
+- *"We're under SEC investigation — can we clean up old emails?"* → hard refuse; flag spoliation risk; redirect to counsel.
+
+## See also
+
+- `skill:data-handling-judgment` — retention + transfer cognition.
+- `domain-safety-disclaimer-financial` — companion advisory disclaimer.

package/.agent-src/rules/domain-safety-retention-support.md

@@ -0,0 +1,55 @@
+---
+type: "auto"
+tier: "2a"
+description: "Support / CRM data retention guidance — surface DSR-readiness, consent-window expiry, ticket-body retention vs. analytics aggregate retention"
+source: package
+triggers:
+  - keyword: "ticket retention"
+  - keyword: "CRM retention"
+  - keyword: "DSAR"
+  - keyword: "data subject request"
+  - keyword: "right to be forgotten"
+  - phrase: "delete customer data"
+  - phrase: "how long do we keep tickets"
+routes_to:
+  - "skill:data-handling-judgment"
+  - "skill:privacy-review"
+applies_to_user_types:
+  - "support"
+  - "gtm"
+---
+
+# Domain Safety — Support / CRM Retention
+
+## Iron Law
+
+```
+SUPPORT-DATA RETENTION ANSWERS DISTINGUISH RAW TICKET BODY (PII-LADEN)
+FROM AGGREGATE ANALYTICS (DE-IDENTIFIED). DSR-READINESS IS THE FLOOR,
+NOT THE CEILING.
+```
+
+The right answer to *"how long do we keep tickets?"* is almost never a single number — it's a two-track policy. Raw ticket bodies contain PII and must respect deletion requests on a DSR clock (typically 30 days under GDPR). De-identified aggregate analytics (resolution times, category counts) can persist indefinitely for product / ops insight.
+
+## Required structure in every support-retention answer
+
+1. **Two tracks.** Raw ticket body + attachments (PII): short retention with DSR honoring. Aggregate metrics (de-identified): long retention OK.
+2. **Consent-window check.** If consent was time-bound (e.g., "we'll keep your data for 12 months for support quality"), name the expiry and the deletion job that must run.
+3. **DSR readiness.** *"You must be able to honor a deletion request within [N] days. The system needs a query that finds every ticket + attachment + log line tied to one customer."*
+4. **Backup retention gotcha.** *"Backups also contain PII. Either purge on the same DSR clock or document that backups are inaccessible and rotate within [N] days."*
+
+## Default floors (cite, then qualify)
+
+| Class | Typical floor | Driver |
+|---|---|---|
+| Raw ticket body | 12-24 months from close | Consent window + DSR readiness |
+| Attachments with PII | 6-12 months | Higher leak risk → shorter |
+| Aggregate analytics (de-identified) | Indefinite | No PII linkage |
+| Quality-assurance recordings | 30-90 days | Consent typically narrow |
+
+Verify against the customer's privacy notice, regulatory regime, and contractual data-processing agreements before locking values.
+
+## See also
+
+- `skill:data-handling-judgment` — retention + DSR shape.
+- `skill:privacy-review` — regulatory-regime read.

package/.agent-src/skills/api-design/SKILL.md

@@ -5,6 +5,9 @@ personas:
   - backend-architect
 source: package
 domain: engineering
+recommended_for_user_types: [developer, founder]
+
+
 ---
 
 # api-design

package/.agent-src/skills/authz-review/SKILL.md

@@ -6,6 +6,9 @@ personas:
   - backend-architect
 source: package
 domain: quality
+recommended_for_user_types: [developer, ops]
+
+
 ---
 
 # authz-review

package/.agent-src/skills/competitive-moat-analysis/SKILL.md

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: process
 context_spine: [customer-segment, product, org-stage]
+recommended_for_user_types: [consultant, founder]
+
+
 ---
 
 # competitive-moat-analysis

package/.agent-src/skills/competitive-positioning/SKILL.md

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: product
 context_spine: [product]
+recommended_for_user_types: [consultant, gtm, founder]
+
+
 ---
 
 # competitive-positioning

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

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: product
 context_spine: [product, customer-segment, channel-stage, funnel-stage]
+recommended_for_user_types: [creator, gtm]
+
+
 ---
 
 # content-funnel-design

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

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: process
 context_spine: [regulatory-regime, customer-segment, org-stage]
+recommended_for_user_types: [consultant, finance, ops]
+
+
 ---
 
 # contracts-cognition

package/.agent-src/skills/dashboard-design/SKILL.md

@@ -3,6 +3,9 @@ name: dashboard-design
 description: "Use when designing monitoring dashboards — visualization selection, layout principles, observability strategies (RED/USE/Golden Signals), and data storytelling."
 source: package
 domain: devops
+recommended_for_user_types: [ops, gtm]
+
+
 ---
 
 # dashboard-design

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

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: process
 context_spine: [regulatory-regime, customer-segment, product]
+recommended_for_user_types: [ops, finance]
+
+
 ---
 
 # data-handling-judgment

package/.agent-src/skills/dcf-modeling/SKILL.md

@@ -5,6 +5,9 @@ status: active
 tier: senior
 source: package
 domain: product
+recommended_for_user_types: [finance]
+
+
 ---
 
 # dcf-modeling

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

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: product
 context_spine: [product, customer-segment]
+recommended_for_user_types: [gtm]
+
+
 ---
 
 # deal-qualification-meddic

package/.agent-src/skills/discovery-interview/SKILL.md

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: product
 context_spine: [product]
+recommended_for_user_types: [consultant, founder]
+
+
 ---
 
 # discovery-interview

package/.agent-src/skills/editorial-calendar/SKILL.md

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: product
 context_spine: [product, customer-segment, channel-stage, funnel-stage]
+recommended_for_user_types: [creator]
+
+
 ---
 
 # editorial-calendar

package/.agent-src/skills/forecast-accuracy/SKILL.md

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: product
 context_spine: [product, customer-segment]
+recommended_for_user_types: [gtm, finance]
+
+
 ---
 
 # forecast-accuracy

package/.agent-src/skills/forecasting/SKILL.md

@@ -6,6 +6,9 @@ tier: senior
 source: package
 domain: process
 context_spine: [product, fiscal-period, customer-segment]
+recommended_for_user_types: [finance, founder]
+
+
 ---
 
 # forecasting