[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JW0KTW2XEVEDWNF24YAFK2":3,"skill-same:01M6JW0KTW2XEVEDWNF24YAFK2":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6JW0KTW2XEVEDWNF24YAFK2","mental-model-mismatch-and-onboarding",null,"Use this skill when designing onboarding, when diagnosing why users keep getting confused, when migrating users from one product convention to another, or when the system genuinely differs from familiar comparable products. Trigger when the user mentions \"users don't get it,\" \"we keep getting the same support tickets,\" or \"this is a new pattern they need to learn.\" Sub-aspect of `mental-model`; read that first.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fmental-model-mismatch-and-onboarding\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"onboarding","mental model mismatch and onboarding","mental model","model","pattern","new","when","it","keep","users","tickets","trigger","get","support","use","user","read","system","why","first","product","learn","2026-11-10 10:12:30",false,"---\nname: mental-model-mismatch-and-onboarding\ndescription: 'Use this skill when designing onboarding, when diagnosing why users keep getting confused, when migrating users from one product convention to another, or when the system genuinely differs from familiar comparable products. Trigger when the user mentions \"users don''t get it,\" \"we keep getting the same support tickets,\" or \"this is a new pattern they need to learn.\" Sub-aspect of `mental-model`; read that first.'\n---\n\n# Mental-model mismatches and onboarding\n\nWhen the user's mental model and the system's actual behavior diverge, three things can be done: change the system to match the user's model; change the user's model through onboarding and teaching; or surface the divergence so the user knows when their model doesn't apply.\n\n## Diagnosing mismatches\n\nCommon signals of mental-model mismatch:\n\n- **Repeated support tickets** about the same misunderstanding (\"Why doesn't X work?\" when X works fine — the user's expectation didn't match).\n- **Drop-off at the same flow step** (the user reached this step expecting one thing; got another; left).\n- **High undo \u002F cancel rate** at a particular action.\n- **Forum \u002F community questions** asking how to do things the system doesn't actually do.\n- **Negative reviews** mentioning unmet expectations.\n\nEach pattern points to a divergence between user model and system reality. The fix depends on which side to change.\n\n## Three fix strategies\n\n### 1. Change the system\n\nIf the user's model is reasonable and many users share it, change the system to match. Often this is also the simpler design.\n\nExample: users expect \"save\" to commit immediately. If your system actually queues the save for later, either make save immediate or rename the action to reflect the actual behavior.\n\n### 2. Teach the model\n\nIf the system's behavior is genuinely better and users can learn it, invest in onboarding.\n\nExamples:\n- Anti-lock brakes required teaching: \"brake firmly, steer; don't pump.\" Manufacturer campaigns and driver-ed material taught the new model.\n- Spreadsheets taught a new computing model in the early 1980s; once learned, transferable.\n- Modal editors (vim) require learning that \"modes\" exist; users who learn become extremely productive.\n\nOnboarding that teaches a model:\n- **Walks the user through** the first task with explicit guidance.\n- **Provides explanation in context** — not a separate tutorial page.\n- **Shows the system's state** as actions happen, so the user observes the model.\n- **Uses progressive disclosure** of complexity over time.\n\n### 3. Surface the divergence\n\nWhen the system genuinely differs and you can't (or shouldn't) change the system, surface the difference at the moment it matters.\n\nExamples:\n- A \"soft-deleted\" item shows \"Deleted (recoverable for 30 days)\" — surfaces the system's actual model.\n- A subscription cancellation shows \"Canceled — access continues until [date]\" — surfaces what canceled actually means.\n- A search that ranks by relevance (not chronologically) shows \"Sorted by relevance\" — explains the unexpected order.\n\nThe point is to expose the divergence at the moment of the action, not buried in documentation.\n\n## Onboarding patterns that teach mental models\n\n### Guided first task\n\nWalk the user through their first concrete task — not \"here's a tour\" but \"let's create your first project.\"\n\n```html\n\u003Caside class=\"onboarding-guide\">\n  \u003Ch3>Let's create your first project\u003C\u002Fh3>\n  \u003Cp>1. Click the + button at the top right →\u003C\u002Fp>\n  \u003C!-- The new-project button is highlighted; the user clicks; next step appears -->\n\u003C\u002Faside>\n```\n\nActive practice teaches the interaction model better than passive watching.\n\n### Inline explanation at the moment of action\n\nWhen the user encounters a feature whose model differs from common expectations, explain in line:\n\n```html\n\u003Cdiv class=\"field\">\n  \u003Clabel for=\"visibility\">Project visibility\u003C\u002Flabel>\n  \u003Cselect id=\"visibility\">\n    \u003Coption value=\"private\">Private (default)\u003C\u002Foption>\n    \u003Coption value=\"team\">Team\u003C\u002Foption>\n    \u003Coption value=\"public\">Public\u003C\u002Foption>\n  \u003C\u002Fselect>\n  \u003Cp class=\"hint\">\n    Private = only you. Team = everyone in your workspace. Public = anyone with the link.\n  \u003C\u002Fp>\n\u003C\u002Fdiv>\n```\n\nThe explanation prevents knowledge mistakes by surfacing the actual model.\n\n### Progressive complexity\n\nDon't expose every feature on day one. Reveal them as the user encounters surfaces where they apply. The user's interaction model grows with their need.\n\n### \"What's new\" surfaces\n\nWhen you ship a feature whose model users wouldn't predict from prior versions, announce explicitly. A \"what's new in v2\" panel that explains how the new feature works, with brief examples, prevents widespread misunderstanding.\n\n## Anti-patterns\n\n- **Tour-only onboarding.** Walk the user through a passive demo. They forget within hours; their interaction model isn't reinforced.\n- **Documentation-as-onboarding.** \"If you have questions, see the help center.\" Most users don't.\n- **Hidden divergences.** A system that differs from expectation but doesn't say so. Users assume; produce errors.\n- **Over-explanation in normal flows.** If you have to constantly explain how things work, the design isn't matching mental models well; redesign rather than over-tutorialize.\n\n## Heuristics\n\n1. **The \"first surprise\" diagnostic.** Watch a new user. Where do they say \"huh, that's not what I expected\"? Each surprise is a mental-model mismatch — fix the system or the surfaced model.\n2. **The support-ticket pattern audit.** Cluster recent support tickets by the misunderstanding behind them. Patterns reveal mismatches.\n3. **The cancel-rate signal.** Steps with high cancel rates often mean users reached them with the wrong expectation. Investigate.\n\n## Related sub-skills\n\n- **`mental-model`** (parent).\n- **`mental-model-system-vs-interaction`** — distinguishing the two model types.\n- **`expectation-effect`** — mental models *are* the user's expectations.\n- **`affordance`** — affordance teaches interaction models at the per-element level.\n- **`mimicry`** — borrowing familiar patterns leverages existing models.\n","# Mental-model mismatches and onboarding\n\nWhen the user's mental model and the system's actual behavior diverge, three things can be done: change the system to match the user's model; change the user's model through onboarding and teaching; or surface the divergence so the user knows when their model doesn't apply.\n\n## Diagnosing mismatches\n\nCommon signals of mental-model mismatch:\n\n- **Repeated support tickets** about the same misunderstanding (\"Why doesn't X work?\" when X works fine — the user's expectation didn't match).\n- **Drop-off at the same flow step** (the user reached this step expecting one thing; got another; left).\n- **High undo \u002F cancel rate** at a particular action.\n- **Forum \u002F community questions** asking how to do things the system doesn't actually do.\n- **Negative reviews** mentioning unmet expectations.\n\nEach pattern points to a divergence between user model and system reality. The fix depends on which side to change.\n\n## Three fix strategies\n\n### 1. Change the system\n\nIf the user's model is reasonable and many users share it, change the system to match. Often this is also the simpler design.\n\nExample: users expect \"save\" to commit immediately. If your system actually queues the save for later, either make save immediate or rename the action to reflect the actual behavior.\n\n### 2. Teach the model\n\nIf the system's behavior is genuinely better and users can learn it, invest in onboarding.\n\nExamples:\n- Anti-lock brakes required teaching: \"brake firmly, steer; don't pump.\" Manufacturer campaigns and driver-ed material taught the new model.\n- Spreadsheets taught a new computing model in the early 1980s; once learned, transferable.\n- Modal editors (vim) require learning that \"modes\" exist; users who learn become extremely productive.\n\nOnboarding that teaches a model:\n- **Walks the user through** the first task with explicit guidance.\n- **Provides explanation in context** — not a separate tutorial page.\n- **Shows the system's state** as actions happen, so the user observes the model.\n- **Uses progressive disclosure** of complexity over time.\n\n### 3. Surface the divergence\n\nWhen the system genuinely differs and you can't (or shouldn't) change the system, surface the difference at the moment it matters.\n\nExamples:\n- A \"soft-deleted\" item shows \"Deleted (recoverable for 30 days)\" — surfaces the system's actual model.\n- A subscription cancellation shows \"Canceled — access continues until [date]\" — surfaces what canceled actually means.\n- A search that ranks by relevance (not chronologically) shows \"Sorted by relevance\" — explains the unexpected order.\n\nThe point is to expose the divergence at the moment of the action, not buried in documentation.\n\n## Onboarding patterns that teach mental models\n\n### Guided first task\n\nWalk the user through their first concrete task — not \"here's a tour\" but \"let's create your first project.\"\n\n```html\n\u003Caside class=\"onboarding-guide\">\n  \u003Ch3>Let's create your first project\u003C\u002Fh3>\n  \u003Cp>1. Click the + button at the top right →\u003C\u002Fp>\n  \u003C!-- The new-project button is highlighted; the user clicks; next step appears -->\n\u003C\u002Faside>\n```\n\nActive practice teaches the interaction model better than passive watching.\n\n### Inline explanation at the moment of action\n\nWhen the user encounters a feature whose model differs from common expectations, explain in line:\n\n```html\n\u003Cdiv class=\"field\">\n  \u003Clabel for=\"visibility\">Project visibility\u003C\u002Flabel>\n  \u003Cselect id=\"visibility\">\n    \u003Coption value=\"private\">Private (default)\u003C\u002Foption>\n    \u003Coption value=\"team\">Team\u003C\u002Foption>\n    \u003Coption value=\"public\">Public\u003C\u002Foption>\n  \u003C\u002Fselect>\n  \u003Cp class=\"hint\">\n    Private = only you. Team = everyone in your workspace. Public = anyone with the link.\n  \u003C\u002Fp>\n\u003C\u002Fdiv>\n```\n\nThe explanation prevents knowledge mistakes by surfacing the actual model.\n\n### Progressive complexity\n\nDon't expose every feature on day one. Reveal them as the user encounters surfaces where they apply. The user's interaction model grows with their need.\n\n### \"What's new\" surfaces\n\nWhen you ship a feature whose model users wouldn't predict from prior versions, announce explicitly. A \"what's new in v2\" panel that explains how the new feature works, with brief examples, prevents widespread misunderstanding.\n\n## Anti-patterns\n\n- **Tour-only onboarding.** Walk the user through a passive demo. They forget within hours; their interaction model isn't reinforced.\n- **Documentation-as-onboarding.** \"If you have questions, see the help center.\" Most users don't.\n- **Hidden divergences.** A system that differs from expectation but doesn't say so. Users assume; produce errors.\n- **Over-explanation in normal flows.** If you have to constantly explain how things work, the design isn't matching mental models well; redesign rather than over-tutorialize.\n\n## Heuristics\n\n1. **The \"first surprise\" diagnostic.** Watch a new user. Where do they say \"huh, that's not what I expected\"? Each surprise is a mental-model mismatch — fix the system or the surfaced model.\n2. **The support-ticket pattern audit.** Cluster recent support tickets by the misunderstanding behind them. Patterns reveal mismatches.\n3. **The cancel-rate signal.** Steps with high cancel rates often mean users reached them with the wrong expectation. Investigate.\n\n## Related sub-skills\n\n- **`mental-model`** (parent).\n- **`mental-model-system-vs-interaction`** — distinguishing the two model types.\n- **`expectation-effect`** — mental models *are* the user's expectations.\n- **`affordance`** — affordance teaches interaction models at the per-element level.\n- **`mimicry`** — borrowing familiar patterns leverages existing models.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fmental-model-mismatch-and-onboarding",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill mental-model-mismatch-and-onboarding",{"tool":67,"command":68},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill mental-model-mismatch-and-onboarding",{"tool":70,"command":71},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill mental-model-mismatch-and-onboarding","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fmental-model-mismatch-and-onboarding\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fonboarding-patterns.md","REFERENCE","参考文档",2025,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fmental-model-mismatch-and-onboarding\u002Freferences\u002Fonboarding-patterns.md",[82,90,97,104,130,155],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":89},"01M746ZWACVKMZ1BJXJZHYJSSX","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 \u002Fmigrate-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.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":89},"01M746ZPTAX1Q0FBKAB1CYND7E","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.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":89},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> 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 \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":46},"01M716A6ETNB9B1SQ3GXZC75VR","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.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[111,112,113,114,115,116,117,118,119,120,121,30,122,123,124,125,126,127,128,129],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":46},"01M716A3J2W5SENSE9VGMXB375","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.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[137,138,139,125,140,141,142,143,144,145,146,147,148,149,116,150,151,152,153,154],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":172,"publishedAt":46},"01M715T3RR4BAYSR57HPPTJ0PF","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.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[161,166,169],{"categoryNo":162,"categoryName":163,"taxonomyType":164,"taxonomyTypeDesc":165},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":167,"categoryName":168,"taxonomyType":164,"taxonomyTypeDesc":165},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":170,"categoryName":171,"taxonomyType":164,"taxonomyTypeDesc":165},"01JBSEEDCAT000000000000010","后端与接口",[157,173,174,175,176,177,178,151,179,117,180,181,182,183,30,184,185,186,187,188],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]