b2b-trust-engineering
Engineer B2B buyer trust by reducing perceived risk, stacking relevant proof, simplifying next steps, and designing sales calls to confirm confidence rather than persuade from scratch. Use when qualified buyers take calls, request proposals, start trials, or show interest but then stall, ghost, choose safer incumbents, or hesitate because proof, certainty, process, or risk reversal is weak.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 1.6k
- Forks
- 474
01 前言 Front Matter
- name
- b2b-trust-engineering
- license
- MIT
- metadata
- { "tags": "b2b-sales,sales,trust,proof,closing", "version": "0.1.0", "category": "Marketing", "displayName": "B2B Trust Engineering" }
- description
- Engineer B2B buyer trust by reducing perceived risk, stacking relevant proof, simplifying next steps, and designing sales calls to confirm confidence rather than persuade from scratch. Use when qualified buyers take calls, request proposals, start trials, or show interest but then stall, ghost, choose safer incumbents, or hesitate because proof, certainty, process, or risk reversal is weak.
- compatibility
- Codex, Claude Code, and other Agent Skills-compatible clients.
03 SKILL.md 正文
B2B Trust Engineering
Use this skill when qualified buyers engage but do not take action. The goal is to make the buying decision feel safe by reducing risk, increasing relevant proof, and making next steps obvious.
Source Traceability
Primary source: Unf*ck Your Sales by Jakob Greenfeld, especially the "Trust", "Diagnostics", "The Confidence Fallacy", "The Persuasion Fallacy", "The Best Option Fallacy", "The 7-11-4 Law", and "Engineering Trust" sections.
Diagnostic Signals
Trust is likely the constraint when:
- Qualified buyers book calls, request proposals, or start trials but do not close.
- Prospects say the offer sounds good and then vanish.
- The buyer appears to need the outcome but still chooses an incumbent or no decision.
- The pitch relies on confidence, vision, or ROI claims without enough proof.
- The sales call tries to persuade instead of confirming what the buyer already believes.
Trust Check
Review the last 50 qualified opportunities where possible:
- How many closed?
- How many ghosted after meaningful engagement?
- How many stalled after a proposal or trial?
- What proof did buyers see before the call?
- What risks, ambiguities, or next-step friction remained?
If qualified close rate is weak or ghosting is high after engagement, treat trust as the likely constraint.
Workflow
1. Lead With Relevant Proof
Use proof that matches the buyer's world:
- Case studies tied to the same pain.
- Testimonials with specifics.
- Screenshots, dashboards, or before/after evidence.
- Logos or references that reduce perceived risk.
- Third-party mentions, referrals, podcasts, or credible appearances.
2. Remove Hidden Risk
Audit friction:
- Can the buyer understand the offer quickly?
- Is pricing or scope ambiguous?
- Are next steps explicit?
- Is implementation risk addressed?
- Is the downside named and handled?
Anything ambiguous increases risk.
3. Build Layered Familiarity
Create trust across multiple surfaces before the call:
- One-to-one outreach.
- Case studies or proof drops.
- Helpful content.
- Video or Loom walkthroughs.
- Social posts or founder presence.
- Third-party channels where buyers can see independent signals.
Use 7 hours, 11 touchpoints, and 4 platforms as an exposure target, not as a rigid law.
4. Design The Call To Confirm
Assume serious buyers arrive with a partial preference already formed.
On the call:
- Reflect the buyer's problem clearly.
- Map proof to their exact situation.
- Avoid over-explaining or adding complexity.
- Make the next step low-risk and obvious.
- Confirm decision criteria and approval path.
Output Format
# B2B Trust Plan
## Opportunity Pattern
- Qualified leads reviewed:
- Close rate:
- Ghost/stall pattern:
- Main risk signal:
## Proof Stack
| Buyer Fear | Proof Needed | Existing Asset | Gap |
|------------|--------------|----------------|-----|
## Risk Removal
- Offer clarity:
- Pricing/scope:
- Implementation:
- Next step:
- Approval path:
## Call Design
- Problem mirror:
- Proof to show:
- Risk to address:
- Next action:
Quality Bar
- Do not try to close with confidence when proof is missing.
- Do not treat buyer hesitation as a persuasion problem before checking risk.
- Do not overload buyers with detail when simpler proof would reduce risk.
- Do not ignore approval path, career risk, or incumbent safety.
- Make "yes" feel safer before making the upside sound bigger.
04 同仓库更多 Skills
migrate-to-e2e
Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for /migrate-to-e2e, "migrate our tests to e2e", "port these Maestro flows", "move our TesterArmy tests", or when a project has an e2e config and an older suite still running.
e2e
Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.
create-verification-skill
Generate a project-local verify-<app> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for /create-verification-skill, "make a verification skill for this repo", or when a project has no scripted way to prove UI behavior.
deja-search
deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.
deja-reflect
End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.
revid
Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.