trust-audit

name	trust-audit
description	Audit whether a product feels trustworthy or unsafe — covering permissions, privacy, billing, file mutation, and silent-failure surfaces.
display_name	Trust Audit
brand_color	#059669
local_only	false
group	Product & Launch
usage	/trust-audit:run
summary	Find the moments your product feels sketchy — surprise charges, scary permissions, silent failures — and close the trust gaps.
favorite	true
default_prompt	Audit this product or feature for trust risks: permissions, privacy, billing, surprise mutations, and anything that feels creepy or unsafe.

Trust Audit

Use this skill to answer the question beneath many launch failures: “Will a normal user feel safe, respected, and in control?”

A trust audit is not a security review. It is a perception-and-reality review of the places where users feel:

• watched
• tricked
• over-charged
• surprised by file or data changes
• unsure what the product is really doing
• trapped when something goes wrong

When to Use

Use this skill when reviewing:

• onboarding or first-run flows
• permission prompts and explanations
• privacy and AI data flows
• billing, credits, trials, renewals, or BYOK setups
• features that rename, move, delete, sync, upload, or otherwise mutate user data
• products where “creepy”, “shady”, or “I don’t trust it” would be fatal

Core Principle

Trust breaks when there is a mismatch between:

1. what the user thinks will happen
2. what actually happens
3. how reversible and well-explained it feels

Audit both the reality and the vibe. A technically defensible flow can still feel shady.

Step 1: Gather the trust surface

Read enough context to map:

• target user
• product promise
• first-run flow
• permissions requested
• what data leaves the device
• what files or records get changed
• billing or credit mechanics
• failure and recovery paths

Then summarize in 5-10 bullets:

• what the user believes they are agreeing to
• what the product actually does
• where a mismatch might exist

Step 2: Inspect the five trust surfaces

Evaluate each of these explicitly.

1. Consent and comprehension

Ask:

• Does the user understand what they are enabling?
• Is important information explained before the scary system prompt or pricing moment?
• Is consent meaningful, or buried behind momentum?

2. Data and privacy reality

Ask:

• What leaves the machine?
• What is stored, for how long, and by whom?
• Is there any “surprise cloud” moment?
• Would a privacy-sensitive user feel misled if they learned the full data path later?

3. File and state safety

Ask:

• Does the product modify user files or important state?
• Could it break organization, aliases, scripts, expectations, or downstream workflows?
• Is there a visible, believable undo or recovery story?

4. Billing and fairness

Ask:

• Could a user reasonably feel tricked on price, credits, quotas, renewals, or provider costs?
• Is the distinction between app purchase, subscription, AI usage, and BYOK painfully clear?
• Would a user say “wait, I thought this was included”?

5. Degraded-mode honesty

Ask:

• When the product is partially broken, does it look healthy anyway?
• Does the user understand whether it is paused, misconfigured, rate-limited, offline, blocked, or waiting?
• Could the product silently fail in a way that makes the user blame themselves?

Step 3: Generate trust failures

Produce 6-12 concrete trust risks. For each, include:

• Trust failure — one sentence
• What the user expected
• What actually happens
• Why it feels bad — creepy, deceptive, careless, destructive, unfair, etc.
• Likely reaction — support email, uninstall, refund, bad review, internal IT rejection, etc.
• Severity — low/medium/high
• Trust fracture type — consent / privacy / pricing / file safety / silent failure / recovery
• Repair move — the most direct product or copy change

Step 4: Distinguish vibes from actual danger

Split findings into:

• Trust theater — looks scary but is mostly messaging / framing
• Real trust hazard — real risk, real surprise, or real damage

Do not flatten them together.

Step 5: Present the audit

Use this format:

# Trust Audit: [Product / Feature]

## Executive Read
- Biggest trust risk:
- Most likely “creepy” interpretation:
- Most likely “I got tricked” interpretation:
- Most dangerous file/data surprise:

## Trust Surface Map
- Consent:
- Data flow:
- File/state mutation:
- Billing:
- Degraded-mode honesty:

## High-Risk Trust Failures

### 1. [Title]
**Trust failure:**
**What the user expected:**
**What actually happens:**
**Why this feels bad:**
**Likely reaction:**
**Type:**
**Repair move:**

## Medium-Risk Trust Failures
...

## Trust Theater vs Real Hazard
- Trust theater:
- Real hazard:

## Copy / UX Fixes to Make Immediately
1. [ ]
2. [ ]
3. [ ]

## The Sentence Users Might Say
> “[one-sentence trust-damaging story]”

Success Criteria

The audit is complete when it identifies:

• what the user thinks is happening
• where that belief is wrong or incomplete
• which mismatch will feel worst
• which fix most increases user trust fastest