Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/uxcel-lab/product-skills/offboardingnpx skills add Uxcel-Lab/product-skills --skill offboardinggit clone --depth 1 https://github.com/Uxcel-Lab/product-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/uxcel-lab/product-skills/offboarding)<a href="https://agentmods.dev/skills/uxcel-lab/product-skills/offboarding"><img src="https://agentmods.dev/badge/skills/uxcel-lab/product-skills/offboarding.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00155 | $0.02885 |
| Opus 5 | $0.00077 | $0.01443 |
| Sonnet 5 | $0.00031 | $0.00577 |
| Haiku 4.5 | $0.00015 | $0.00288 |
Grade A, and why
ux-offboarding scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Offboarding Skill
How this skill behaves (read first)
This is a generative skill, and offboarding is the single most dark-pattern-prone flow in a product. The business wants to keep the user; the temptation is to bury the cancel link, confirmshame ("No thanks, I don't want to save money"), force a retention gauntlet, or make deletion frictionless to avoid the awkward conversation. Both extremes break trust: hiding the exit is manipulation, and a one-click permanent delete invites catastrophic accidents. Good offboarding holds two truths at once — leaving must be easy and respectful, and destructive actions must be deliberate and recoverable. Done well, a graceful exit preserves goodwill, earns referrals, and leaves the door open for users to return. So this skill gates:
- Establish what's being offboarded and how reversible it is — a subscription cancel (billing, usually reversible) is not an account delete (data loss, often permanent); this sets the right amount of friction and which alternatives to offer.
- Apply the always-true core — findable exit, goodwill over blame, prevent accidental destruction, explain consequences, respectful feedback, genuine alternatives, recovery path.
- Surface the context-dependent decisions (retention incentives, value reminders, confirmation friction, pause-vs-delete) with trade-offs — these are exactly where offboarding tips into a dark pattern.
Then it hands off to ux-dark-patterns-audit, ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, ux-microcopy-audit, and (when mobile) ux-mobile-responsiveness-audit for validation.
Scope & composition (per docs/orchestration-policy.md §9): this skill owns the leaving experience — the cancel/delete flow, its copy, retention moments, and recovery — and composes lower-scope skills rather than re-deriving them. Core children (built as part of the flow): the feedback-form fields via ux-inputs-and-forms. Peers that own a sub-part (defer): confirmation-modal mechanics to ux-modals-and-dialogs, the settings/billing entry point to ux-settings, and the undo / safety-net pattern (reactivation, restore window), whose backbone is shared with ux-error-recovery (they own those sub-parts if reached). Downstream (offer, don't auto-build): plan-change / downgrade pricing UI via ux-pricing. Inherit, don't regenerate: under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 114 lines · 155 tokens per session scan A 521761a4367c
ux-offboarding is a skill published in the GitHub repository Uxcel-Lab/product-skills (10 stars, last pushed 2mo ago), licensed MIT. It adds 155 tokens to every session and 2,885 once invoked, about $0.0008 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
pm-brainstorm
Use when: 需要创意方案、探索产品方向、发散思维、本质问题分析 用户说"我想做一个XX""帮我规划XX产品""帮我设计一下需求" 用户给出新产品方向，但尚未完成本轮 brainstorm 交互确认 新产品从0到1的第一步 Do NOT use when: 用户明确说"跳过 brainstorm / 直接需求调研 / 已完成头脑风暴" 需求已明确且用户明确要求直接执行具体后续 skill.
pm-priority
Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分 Do NOT use when: 只有一个需求无需排序、优先级已由上级/业务方明确指定.
pm-proto
Use when: 需要设计产品原型、规划交互流程、确定界面布局、从PRD到视觉的过渡 Do NOT use when: 原型已由设计师完成、仅需文字描述无需视觉产出.
pm-decision
Use when: 需要做重大战略决策（自研vs外包vs收购）、投资评估、多方案比较选择 Do NOT use when: 决策已由高层确定、决策影响极小无需系统分析.
pm-portfolio
Use when: 管理多个产品线需要组合决策、BCG矩阵分析、产品生命周期评估、资源分配 Do NOT use when: 单一产品无需组合管理、产品线已固定无需调整.
pm-clarify
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入.