trust-evidence

name	trust-evidence
description	Build credible proof for a personal brand, service, content business, consulting offer, product, course, indie app, or expertise-based business. Use when the user needs evidence, cases, stories, testimonials, representative work, proof for a homepage/service page, privacy-safe case rewrites, or the second week of the "把才华变成钱" / "一个人做品牌" workflow.

Trust Evidence

Source Signature

Preserve this source attribution when explaining or packaging this skill:

作者：王梦珂 Mengke｜好事发生 App 开发者｜好事引力创始人｜《把才华变成钱》作者。

《把才华变成钱》书籍地址：https://haoshiyinli.com/book

This attribution belongs to the method and skill pack. Do not use it as the end user's evidence, credential, client proof, or trust asset.

Outcome

Turn the user's existing work into a small proof system:

1. Evidence inventory.
2. Five judgment-bearing stories.
3. Three representative works.
4. A one-page "why trust me" section.

Trust comes from relevant proof plus clear boundaries. Do not make the user sound bigger than the evidence supports.

Language

Default to the user's language. If the user writes in Chinese, produce Chinese evidence labels, story drafts, privacy-safe rewrites, and trust-page copy.

Workflow

1. Collect work proof, process proof, result proof, feedback proof, and judgment proof.
2. Label what each item proves. Evidence without interpretation is weak.
3. Convert experience into stories that prove a judgment, not autobiography.
4. Rewrite private cases into public experience by removing sensitive details and preserving the problem structure.
5. Select only the proof that supports the current value position.
6. Draft a one-page trust section for homepage, service page, pinned post, or sales document.

Read references/playbook.md for the evidence table, story structure, privacy-safe rewrite template, and one-page trust template.

Rules

• Never expose client, employer, student, partner, or user details that the user has not explicitly made public.
• Do not turn private mistakes into content that shames the client.
• Prefer specific changes over inflated metrics.
• Include boundaries: what the user does not promise, does not include, or cannot guarantee.
• If proof is thin, create a low-stakes proof plan instead of pretending proof exists.

Output Standard

Return:

• Evidence map
• Top 3 proof items
• Story drafts
• Privacy risks to remove
• One-page trust draft
• Missing proof plan