topic-explainer

Topic Explainer

When to use

Use this skill whenever the user asks to create an explainer, explainer page, or explainer dashboard for a topic. The output should be a polished, interactive HTML dashboard that explains the topic clearly for a business audience.

Use a clean, professional card-based design as the content model, but adapt the sections to fit the topic and content. Do not force every section into every dashboard.

Inputs

• Required: the topic to explain.
• Optional: target audience, organization/team context, preferred tone, source files/pages, and whether the dashboard should be saved as a SharePoint file or shown inline.
• If the topic needs current, enterprise, or document-specific information, retrieve or summarize the relevant content first. Do not invent source-specific claims.

Steps

1. Identify the explainer topic, audience, and main user need from the request.
2. Decide which sections fit the topic before building the dashboard. Use the strongest-fit sections only:
   • Always consider: hero/header, shortest version, core concept cards, active-detail panel, comparison table, use cases/examples, governance or watch-outs, and source notes.
   • Include a decision guide only when the topic asks users to choose between options, make a recommendation, follow a path, or decide “when to use what”.
   • Include a Without vs With section only when the topic naturally compares adopting a capability, method, or maturity step. Skip it for side-by-side product comparisons where it feels artificial.
   • Include a context overload / complexity explanation only when reusable instructions, knowledge context, complexity, or prompt burden is central to the topic.
   • Include implementation, rollout, adoption, governance, or operating model sections only when relevant.
3. If a section is skipped, rebalance the layout. Do not leave an empty adjacent panel. Expand the neighboring section to full width, replace the skipped section with a better-fit section, or use a single-column layout for that row.
4. Build the dashboard content around the selected sections. Common section options:
   • Hero/header with a short title, subtitle, and “shortest version”.
   • 3–5 core concept cards for the most important ideas in the topic.
   • Active concept detail panel containing: what it is, analogy, when to use it, example prompts/scenarios, and watch-outs.
   • Decision guide with practical questions and recommendations, when relevant.
   • Clear comparison table across the core concepts, platforms, methods, or options.
   • “Without vs with” section, only when it creates real explanatory value.
   • Topic-specific section such as channel selection, operating principles, adoption playbook, risks, anti-patterns, stakeholder map, maturity model, or examples.
   • Searchable use cases and examples by team, role, or scenario.
   • Governance notes, risks, or implementation considerations.
   • Source notes listing the sources or assumptions used.
5. Create the dashboard as standalone HTML/CSS/JavaScript rather than raw React unless the environment explicitly supports React build output.
6. Preserve a clean professional design spirit:
   • Clean card-based layout.
   • Interactive concept selection.
   • Search/filter for use cases where useful.
   • Professional, clear tone with plain-language explanations, analogies, practical examples, and clear distinctions between concepts, benefits, limitations, and governance.
7. Use this content schema when adapting the original code: