Skip to main content
ClaudeWave
Skill1.3k repo starsupdated 3d ago

ai-disclosure-policy

Decide when and how your product and communications must (or should) label AI-generated content, and write the disclosure policy — surface-by-surface rules, exact label wording, and the review trigger for regulations like the EU AI Act's transparency obligations. Use when asked 'do we have to label AI content', 'write our AI disclosure policy', 'are we covered for the AI Act', or when marketing/support/product start shipping AI-generated output. Produces a disclosure policy with a per-surface matrix and ready-to-use label copy. Not legal advice.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/ai-disclosure-policy && cp -r /tmp/ai-disclosure-policy/exports/openclaw/ai-disclosure-policy ~/.claude/skills/ai-disclosure-policy
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# AI Disclosure Policy Skill

Every company now ships AI-generated content somewhere — support replies,
marketing images, chatbot conversations, synthetic voices — and most have no
rule for when to say so. Meanwhile transparency regulation is arriving (the EU
AI Act's transparency obligations for chatbots, synthetic media, and deepfakes
being the headline example, with obligations phasing in through 2026–2027), and
the trust cost of an *undisclosed* AI surface being discovered is higher than
the disclosure ever was. This skill produces the policy: what you label, where,
in what words — with the honest line that final regulatory judgment belongs to
your lawyer, and this document is what makes that conversation short.

## What This Skill Produces

- A **surface inventory**: every place AI-generated content reaches users or
  the public, with today's disclosure state
- A **disclosure matrix**: per surface — required (regulatory), expected
  (platform/industry norm), or chosen (trust) — with the reasoning
- **Label copy** ready to ship: UI strings, footer lines, image/video marks,
  chatbot self-identification wording
- The **review triggers**: what changes (new surface, new market, new
  regulation phase) forces a policy re-read, and who owns it

## Required Inputs

Ask for (if not already provided):
- Where AI output ships today or soon: chatbots, support, marketing content,
  images/video/voice, code, docs — and which are fully automated vs
  human-reviewed
- Markets served (EU exposure changes obligations) and industry (regulated
  sectors add rules)
- Existing policy fragments ([[ai-usage-policy]] covers internal use — this
  skill covers outward disclosure; link them, don't duplicate)
- Risk posture: minimum-compliance or trust-differentiator

## Process

1. **Inventory before policy.** List every AI-touching surface, then the ones
   the user forgot: auto-generated email, AI-assisted support macros, synthetic
   voices on calls, generated product imagery, auto-summaries in the product.
   For each: fully-AI, AI-drafted-human-approved, or AI-assisted — the
   disclosure answer differs by degree of human control.
2. **Sort into required / expected / chosen.** Required: where a regulation
   plausibly applies — chatbots that could be mistaken for humans, synthetic
   media, emotionally targeted content (flag these for counsel; cite the
   regulation family, not invented article numbers). Expected: platform rules
   and industry norms (ad platforms, app stores increasingly require labels).
   Chosen: where labeling is optional but discovery-risk or brand values argue
   for it. State the reasoning per row — a policy without reasons decays.
3. **Write labels people won't hate.** Honest, short, non-groveling:
   "AI-assisted, human-reviewed" beats a paragraph of throat-clearing. Chatbots
   self-identify at conversation start, not in a footer. Human-approved content
   can say so — the disclosure spectrum has two ends.
4. **Decide the edge cases explicitly**: AI-drafted-human-edited text (the big
   one — set a threshold and say it), internal content that leaks, user-facing
   personalization, A/B tests of the labels themselves (don't).
5. **Wire the triggers.** New surface, new market, automation-degree change,
   regulation phase-in dates → named owner re-reviews. Policy without a
   re-review trigger is a screenshot, not a policy.

## Output Format

```
## Where AI ships today
| Surface | Degree (full / drafted / assisted) | Disclosed today? |

## Disclosure matrix
| Surface | Required / Expected / Chosen | Reasoning | Label |

## Label copy (ready to ship)
[Exact strings per surface type]

## Edge-case rulings
[The threshold decisions, stated plainly]

## Review triggers & ownership
[What forces a re-read, who owns it, standing counsel questions]
```

## Quality Checks

- [ ] The inventory surfaced at least one AI surface the user didn't list
- [ ] Every matrix row carries reasoning; "required" rows name the regulation
      family and carry the flag-for-counsel marker — no invented article
      citations
- [ ] Label copy is shippable as-is: short, honest, located where users
      actually are (chatbot labels at the top, not the terms page)
- [ ] The AI-drafted-human-edited threshold is decided, not deferred
- [ ] The not-legal-advice line is present and the counsel-question list makes
      the legal review cheap

## Anti-Patterns

- [ ] Do not assert specific legal conclusions ("Article X requires you to…")
      — identify plausibly-applicable obligations and route to counsel
- [ ] Do not write labels as apologies — disclosure done confidently is a
      trust feature
- [ ] Do not produce one blanket rule; the matrix exists because a support
      macro and a synthetic voice are different obligations
- [ ] Do not duplicate [[ai-usage-policy]] — internal use rules live there;
      this is outward-facing disclosure
ai-ethics-reviewSkill

Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.

ai-product-canvasSkill

Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.

design-handoff-briefSkill

Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.

experiment-designerSkill

Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.

multi-source-signal-synthesiserSkill

Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.

data-analysis-standardSkill

Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.

product-health-analysisSkill

Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.

retention-analysisSkill

Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.