[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-openai-build-dashboard":3,"mdc-gcr279-key":36,"related-repo-openai-build-dashboard":704,"related-org-openai-build-dashboard":817},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":25,"repoUrl":26,"updatedAt":27,"license":28,"forks":29,"topics":30,"repo":31,"sourceUrl":34,"mdContent":35},"build-dashboard","build interactive analytical dashboards","Build source-backed dashboards for monitoring performance, exploring drivers, or acting on product and business metrics. Use when the task needs a dashboard, scorecard, or monitoring view with clear metrics, filters, source definitions, and QA.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"openai","OpenAI","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fopenai.png",[12,16,19,22],{"name":13,"slug":14,"type":15},"Performance","performance","tag",{"name":17,"slug":18,"type":15},"Dashboards","dashboards",{"name":20,"slug":21,"type":15},"Data Visualization","data-visualization",{"name":23,"slug":24,"type":15},"Analytics","analytics",427,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Frole-specific-plugins","2026-07-01T07:54:55.927642",null,65,[],{"repoUrl":26,"stars":25,"forks":29,"topics":32,"description":33},[],"Role-specific Codex plugin templates","https:\u002F\u002Fgithub.com\u002Fopenai\u002Frole-specific-plugins\u002Ftree\u002FHEAD\u002Fplugins\u002Fdata-analytics\u002Fskills\u002Fbuild-dashboard","---\nname: build-dashboard\ndescription: \"Build source-backed dashboards for monitoring performance, exploring drivers, or acting on product and business metrics. Use when the task needs a dashboard, scorecard, or monitoring view with clear metrics, filters, source definitions, and QA.\"\n---\n\n## Related Skills\n\nUse $create-data-context only when the dashboard work explicitly asks to save data context or create, update, inspect, or repair a semantic layer.\n\nUse $analyze-data-quality when dashboard metrics disagree or source freshness, grain, joins, or definitions could affect trust.\n\n# Dashboard Building\n\nUse this skill when the user needs a dashboard rather than a report, notebook-only analysis, spreadsheet, or transient chat summary. A good dashboard is summary-first, chart-led, scannable, and organized around what the audience needs to monitor, understand, or act on.\n\nClarify with the user when a missing input would materially change the dashboard brief, analysis, or recommendation. Otherwise make a reasonable assumption, state it, and proceed.\n\nThis skill owns the dashboard brief, delivery-mode selection, metric definitions, source expectations, layout logic, dashboard QA, and handoff. Delivery-specific mechanics belong in the selected dashboard specification.\n\n## Skill Configuration\n\n### Runtime Delivery Routing\n\nIf `surface = chatgpt_web` and `mode = work_mode` are both positively identified, do not select the Data Analytics MCP artifact app and do not load its dashboard specification. If `mode = work_mode` is positive and `surface` is unknown or otherwise not positively `codex_desktop`, apply the same non-MCP delivery rule for safety. Use a connected BI destination when the user selected one or it clearly owns the requested dashboard; otherwise build portable HTML. Use Streamlit only when the user explicitly asks for it. MCP servers and other callable tools remain valid data sources.\n\n### Source Discovery And Verification\n\nUse the relevant semantic layer as a starting map, not a boundary.\n\n1. **Explore all possible sources.** Search every connected or provided source that could contain task-relevant data or change the interpretation. Within each structured-data source, run fresh catalog or metadata discovery for relevant schemas, datasets, tables, views, models, and metrics. Known sources, tables, dashboards, and semantic mappings are starting points, not stopping points.\n2. **Compare duplicates and conflicts.** When sources overlap or disagree, compare ownership, freshness, definition, grain, coverage, and directness. Use the best authoritative source, or combine complementary sources when needed. Note material conflicts, explain why the selected source or sources control the answer, and verify selected data through live reads before concluding.\n\n### Source Access Guardrail\n\nBefore querying sources, building artifacts, or drawing conclusions, determine whether the answer requires a specific source of truth.\n\nIf a required source is unavailable, stop that path. Tell the user what source is needed, ask them to make it available or provide a reviewed fallback, and do not treat weaker substitutes as equivalent.\n\nIf the missing source is only optional enrichment, continue with the strongest available evidence and label the gap when it materially affects the answer.\n\n## Workflow\n\n### 1. Define The Dashboard Brief\n\nUnderstand who will use the dashboard, what they need to measure or monitor, which metrics matter, what surface it should live in, and what constraints could change the build.\n\nClarify only the inputs that materially affect the dashboard, such as the primary audience, measurement goal, metric scope, delivery surface, refresh expectations, required filters, access constraints, or sharing needs. Decide whether the dashboard is mainly for status monitoring, recurring operating review, or analytical exploration, because that changes the layout, filter design, and validation bar.\n\nUse $gather-business-context when dashboard purpose, metric definitions, operating context, audience expectations, or existing dashboard conventions are not clear enough to design the dashboard well.\n\n### 2. Select The Delivery Surface\n\nPick the first delivery surface that fits the user's need and available access. If the user specifies the destination or surface, use that instead of the default order.\n\nFor positively identified web Work Mode, or any positive Work Mode signal without a positive Codex desktop surface, use this order:\n\n1. Use a connected BI tool when the user selected it or it clearly owns the destination.\n2. Otherwise use HTML for the dashboard handoff.\n\nDo not choose the MCP artifact app in Work Mode without a positive Codex desktop surface, even if its tools are visible. For all other environments, use the default order below:\n\n1. Use a connected BI tool by default. Use the BI surface identified from the current request, current-run context, or explicit user preference; if none is specified, look for an available connected BI solution before choosing another surface.\n2. Use the MCP artifact app when a connected BI build is unavailable, too heavy for the request, or the user needs a compact in-Codex analytical dashboard.\n3. Use HTML when BI and MCP are not suitable and the user needs a portable static dashboard.\n\nUse Streamlit only when the user explicitly asks for it or an existing Streamlit app must be changed.\n\nRead the matching specification before building:\n\n- `..\u002F..\u002Fsrc\u002Fanalytics-app-core.md` for shared MCP artifact mechanics, source safety, runtime behavior, and validation helpers.\n- `specifications\u002Fbi-platform-dashboard.md` for BI platform dashboards.\n- `specifications\u002Fmcp-artifact-dashboard.md` for dashboards rendered by the MCP artifact app.\n- `specifications\u002Fhtml-dashboard.md` for portable static HTML dashboards.\n- `specifications\u002Fstreamlit-dashboard.md` for Streamlit dashboards.\n\n### 3. Gather And Validate The Data\n\nDo the data work in this order:\n\n- **Find the source path before rendering.** Source discovery is part of dashboard building, not optional enrichment. Identify the source path for the core dashboard metrics. Use `~~structured_data` when the dashboard needs data from a warehouse or another structured data source. Use context lanes such as `~~company_docs`, `~~team_communication`, or `~~dashboards_or_bi` when the dashboard needs business meaning, source-of-truth guidance, metric definitions, or requirements that are not captured in structured data alone.\n- **Use durable dashboard data.** Validate the data before wiring it into the dashboard. Keep final extracts compact and aggregated unless a bounded detail table is part of the dashboard's purpose. Avoid final dashboards that depend on scratch or temporary tables.\n- **Validate trust.** For straightforward dashboards, confirm the source, grain, freshness, and basic reconciliation needed to trust the displayed metrics. Use $analyze-data-quality when data trust is a material risk, such as a new source, recent backfill, complex join, or surprising result.\n- **Resolve time and context anchors.** Before selecting metrics, establish any date anchor, comparison window, latest complete data date, source coverage, or authoritative artifact needed to shape the dashboard, such as a launch date, incident window, or campaign period. Use $gather-business-context when the prompt does not provide it. If still unclear, ask only when it would materially change the dashboard; otherwise state the assumption and shape queries around it.\n- **Stop if source-backed data is unavailable.** Do not render dashboards from fallback, sample, scratch, or partially blocked data unless the user explicitly asked for a mockup. If the core dashboard data is not available, stop the build path and tell the user what source or access is needed. Do not claim a dashboard was created from real data when the source path is missing.\n\n### 4. Define The Metric Model\n\n**Select the metrics.**\n\nWhen selecting dashboard metrics, classify the measurement object and choose a balanced metric model for that object. Do not use a fixed checklist. Identify which metric families are decision-relevant and which are intentionally out of scope.\n\nConsider these metric families as prompts, not required sections:\n\n- Reach: who or what is using the thing, eligible population, penetration, activation, adoption, coverage.\n- Volume: events, usage, transactions, sessions, requests, units, throughput, frequency.\n- Value: revenue, cost, margin, savings, conversion, retention value, productivity, business outcome.\n- Quality: success, failure, reliability, latency, satisfaction, correctness, safety, support burden.\n- Depth: repeat usage, intensity, feature mix, workflow completion, productionization, maturity, lifecycle stage.\n- Mix: segment, customer type, geography, channel, model\u002Fproduct\u002Fversion, plan, use case, cohort.\n- Movement: trend, growth, seasonality, pre\u002Fpost change, benchmark, target, forecast, leading indicators.\n- Risk and constraints: data coverage, source freshness, known blind spots, capacity, compliance, operational limits.\n\n**Build breadth without flattening the dashboard.**\n\nBuild enough metric breadth to cover every family that is relevant to the dashboard's measurement object and decision. Keep the default view hierarchical rather than exhaustive: lead with the primary outcome and the highest-signal drivers, then use sections, tabs, filters, detail tables, or supporting views for additional relevant metrics. A selected family can be represented by one or many KPIs, drivers, guardrails, or breakdowns, depending on what the user needs to monitor or diagnose.\n\nMap the selected families into dashboard roles before building: hero metrics for the default view, diagnostic metrics for movement and breakdowns, guardrails for interpretation, and detail metrics for lookup or follow-up.\n\nLet the decision determine the number of hero metric cards. Do not pad or truncate the set to four—or any preferred count. Give each card one distinct, decision-relevant headline metric. Use chips only for short comparison context tied directly to that headline, such as its prior-period value, target, or delta; move independent secondary measures into their own cards, charts, tables, narrative, or detail views. Keep coherent cards in the same strip; odd counts are valid because the artifact renderer balances rows responsively.\n\n**Escalate when metric design is the hard part.**\n\nInvoke $design-kpis when this baseline metric-family pass is not enough, such as when the dashboard needs a deeper metric framework, target-setting, formal KPI tradeoff analysis, or clearer definitions than this workflow can safely infer. Pass the dashboard brief, business context, source context, existing metric definitions, and constraints so the recommended metrics fit the audience and use case.\n\n**Keep the data model consistent.**\n\nBuild from a reusable compact data model where possible instead of many slightly different tile queries. Keep date logic, filters, dimensions, and metric definitions consistent across cards, charts, and tables so numbers reconcile. Reuse shared metric definitions from the selected tool or semantic layer when available.\n\n### 5. Design The Dashboard Layout\n\nMake the default view useful before the viewer interacts. Arrange the dashboard from summary to detail: lead with the key status or primary KPI context, follow with movement over time, then show the breakdowns that explain the pattern, and put detail tables lower on the page when lookup or operational follow-up is needed.\n\nUse global filters only when they materially update the dashboard-wide view. Prefer a few high-signal controls over a dense filter panel. Keep dashboards visual-heavy and neutral: short labels, direct metric names, sparse annotations, and minimal explanatory text on the main canvas. Use human-readable short date form in visible labels and freshness text; keep ISO timestamps for machine-readable source metadata.\n\nPrefer human-readable short date forms in visible labels and tooltips unless the dashboard needs timestamps for operational precision.\n\n### 6. Choose The Right Charts\n\nUse $visualize-data when the dashboard needs chart selection, visual encoding, or chart polish. This skill should define what each chart needs to communicate; $visualize-data handles the detailed visual design.\n\nChoose the simplest visual that answers the viewer's question. Use a chart when it makes the pattern easier to understand than text or a table.\n\nPut metrics in the same chart only when comparing them directly makes sense. Otherwise, split them into separate charts, KPI cards, or tables.\n\nUse the selected dashboard specification for exact schema, renderer, and interaction requirements.\n\n### 7. Build And Validate In The Selected Surface\n\nBuild in the selected surface using its native patterns. Before handoff, check that the dashboard opens cleanly, filters work, charts render, numbers reconcile, access is handled clearly, and performance is acceptable.\n\nRecord the source or query path when it would be hard to rediscover later.\n\n### 8. Hand Off The Dashboard\n\nInclude the dashboard link or local artifact path, source or access caveats, and any remaining sharing or operational steps. Keep routine check details in support artifacts. Do not list internal checks in the user-facing handoff unless a check failed, was unavailable, or produced a user-relevant caveat. For MCP artifact dashboards, follow the validation and render handoff rules in `specifications\u002Fmcp-artifact-dashboard.md`.\n\n## Dashboard Quality Bar\n\nBefore handoff, make sure the dashboard is usable as a measurement surface:\n\n- The default view answers the primary audience question before the viewer interacts.\n- Filters are few, meaningful, and work across the surfaces they claim to control.\n- Cards, charts, and tables reconcile unless differences are clearly labeled.\n- Charts answer clear questions with compatible metrics.\n- Tables support lookup, comparison, or operational follow-up after the chart-led summary.\n- The metric set is broad enough for the measurement object: it covers the relevant families with primary outcomes, important drivers, guardrails, and supporting breakdowns while keeping the default view usable.\n- KPI cards are precisely defined: business-defined metrics include enough visible or nearby context for a reader to understand what is counted, over what window, and under what denominator or eligibility rule.\n- Source freshness, access limits, and caveats are visible where they matter.\n- The layout, labels, and performance work for the selected delivery mode.\n- The selected dashboard specification's validation and render rules were followed.\n",{"data":37,"body":38},{"name":4,"description":6},{"type":39,"children":40},"root",[41,50,56,61,68,73,78,83,89,96,141,147,152,178,184,189,194,199,205,211,216,221,226,232,237,242,255,260,278,283,288,347,353,358,443,449,457,462,467,510,518,523,528,533,541,546,554,559,565,570,575,580,586,591,596,601,606,612,617,622,628,640,646,651],{"type":42,"tag":43,"props":44,"children":46},"element","h2",{"id":45},"related-skills",[47],{"type":48,"value":49},"text","Related Skills",{"type":42,"tag":51,"props":52,"children":53},"p",{},[54],{"type":48,"value":55},"Use $create-data-context only when the dashboard work explicitly asks to save data context or create, update, inspect, or repair a semantic layer.",{"type":42,"tag":51,"props":57,"children":58},{},[59],{"type":48,"value":60},"Use $analyze-data-quality when dashboard metrics disagree or source freshness, grain, joins, or definitions could affect trust.",{"type":42,"tag":62,"props":63,"children":65},"h1",{"id":64},"dashboard-building",[66],{"type":48,"value":67},"Dashboard Building",{"type":42,"tag":51,"props":69,"children":70},{},[71],{"type":48,"value":72},"Use this skill when the user needs a dashboard rather than a report, notebook-only analysis, spreadsheet, or transient chat summary. A good dashboard is summary-first, chart-led, scannable, and organized around what the audience needs to monitor, understand, or act on.",{"type":42,"tag":51,"props":74,"children":75},{},[76],{"type":48,"value":77},"Clarify with the user when a missing input would materially change the dashboard brief, analysis, or recommendation. Otherwise make a reasonable assumption, state it, and proceed.",{"type":42,"tag":51,"props":79,"children":80},{},[81],{"type":48,"value":82},"This skill owns the dashboard brief, delivery-mode selection, metric definitions, source expectations, layout logic, dashboard QA, and handoff. Delivery-specific mechanics belong in the selected dashboard specification.",{"type":42,"tag":43,"props":84,"children":86},{"id":85},"skill-configuration",[87],{"type":48,"value":88},"Skill Configuration",{"type":42,"tag":90,"props":91,"children":93},"h3",{"id":92},"runtime-delivery-routing",[94],{"type":48,"value":95},"Runtime Delivery Routing",{"type":42,"tag":51,"props":97,"children":98},{},[99,101,108,110,116,118,123,125,131,133,139],{"type":48,"value":100},"If ",{"type":42,"tag":102,"props":103,"children":105},"code",{"className":104},[],[106],{"type":48,"value":107},"surface = chatgpt_web",{"type":48,"value":109}," and ",{"type":42,"tag":102,"props":111,"children":113},{"className":112},[],[114],{"type":48,"value":115},"mode = work_mode",{"type":48,"value":117}," are both positively identified, do not select the Data Analytics MCP artifact app and do not load its dashboard specification. If ",{"type":42,"tag":102,"props":119,"children":121},{"className":120},[],[122],{"type":48,"value":115},{"type":48,"value":124}," is positive and ",{"type":42,"tag":102,"props":126,"children":128},{"className":127},[],[129],{"type":48,"value":130},"surface",{"type":48,"value":132}," is unknown or otherwise not positively ",{"type":42,"tag":102,"props":134,"children":136},{"className":135},[],[137],{"type":48,"value":138},"codex_desktop",{"type":48,"value":140},", apply the same non-MCP delivery rule for safety. Use a connected BI destination when the user selected one or it clearly owns the requested dashboard; otherwise build portable HTML. Use Streamlit only when the user explicitly asks for it. MCP servers and other callable tools remain valid data sources.",{"type":42,"tag":90,"props":142,"children":144},{"id":143},"source-discovery-and-verification",[145],{"type":48,"value":146},"Source Discovery And Verification",{"type":42,"tag":51,"props":148,"children":149},{},[150],{"type":48,"value":151},"Use the relevant semantic layer as a starting map, not a boundary.",{"type":42,"tag":153,"props":154,"children":155},"ol",{},[156,168],{"type":42,"tag":157,"props":158,"children":159},"li",{},[160,166],{"type":42,"tag":161,"props":162,"children":163},"strong",{},[164],{"type":48,"value":165},"Explore all possible sources.",{"type":48,"value":167}," Search every connected or provided source that could contain task-relevant data or change the interpretation. Within each structured-data source, run fresh catalog or metadata discovery for relevant schemas, datasets, tables, views, models, and metrics. Known sources, tables, dashboards, and semantic mappings are starting points, not stopping points.",{"type":42,"tag":157,"props":169,"children":170},{},[171,176],{"type":42,"tag":161,"props":172,"children":173},{},[174],{"type":48,"value":175},"Compare duplicates and conflicts.",{"type":48,"value":177}," When sources overlap or disagree, compare ownership, freshness, definition, grain, coverage, and directness. Use the best authoritative source, or combine complementary sources when needed. Note material conflicts, explain why the selected source or sources control the answer, and verify selected data through live reads before concluding.",{"type":42,"tag":90,"props":179,"children":181},{"id":180},"source-access-guardrail",[182],{"type":48,"value":183},"Source Access Guardrail",{"type":42,"tag":51,"props":185,"children":186},{},[187],{"type":48,"value":188},"Before querying sources, building artifacts, or drawing conclusions, determine whether the answer requires a specific source of truth.",{"type":42,"tag":51,"props":190,"children":191},{},[192],{"type":48,"value":193},"If a required source is unavailable, stop that path. Tell the user what source is needed, ask them to make it available or provide a reviewed fallback, and do not treat weaker substitutes as equivalent.",{"type":42,"tag":51,"props":195,"children":196},{},[197],{"type":48,"value":198},"If the missing source is only optional enrichment, continue with the strongest available evidence and label the gap when it materially affects the answer.",{"type":42,"tag":43,"props":200,"children":202},{"id":201},"workflow",[203],{"type":48,"value":204},"Workflow",{"type":42,"tag":90,"props":206,"children":208},{"id":207},"_1-define-the-dashboard-brief",[209],{"type":48,"value":210},"1. Define The Dashboard Brief",{"type":42,"tag":51,"props":212,"children":213},{},[214],{"type":48,"value":215},"Understand who will use the dashboard, what they need to measure or monitor, which metrics matter, what surface it should live in, and what constraints could change the build.",{"type":42,"tag":51,"props":217,"children":218},{},[219],{"type":48,"value":220},"Clarify only the inputs that materially affect the dashboard, such as the primary audience, measurement goal, metric scope, delivery surface, refresh expectations, required filters, access constraints, or sharing needs. Decide whether the dashboard is mainly for status monitoring, recurring operating review, or analytical exploration, because that changes the layout, filter design, and validation bar.",{"type":42,"tag":51,"props":222,"children":223},{},[224],{"type":48,"value":225},"Use $gather-business-context when dashboard purpose, metric definitions, operating context, audience expectations, or existing dashboard conventions are not clear enough to design the dashboard well.",{"type":42,"tag":90,"props":227,"children":229},{"id":228},"_2-select-the-delivery-surface",[230],{"type":48,"value":231},"2. Select The Delivery Surface",{"type":42,"tag":51,"props":233,"children":234},{},[235],{"type":48,"value":236},"Pick the first delivery surface that fits the user's need and available access. If the user specifies the destination or surface, use that instead of the default order.",{"type":42,"tag":51,"props":238,"children":239},{},[240],{"type":48,"value":241},"For positively identified web Work Mode, or any positive Work Mode signal without a positive Codex desktop surface, use this order:",{"type":42,"tag":153,"props":243,"children":244},{},[245,250],{"type":42,"tag":157,"props":246,"children":247},{},[248],{"type":48,"value":249},"Use a connected BI tool when the user selected it or it clearly owns the destination.",{"type":42,"tag":157,"props":251,"children":252},{},[253],{"type":48,"value":254},"Otherwise use HTML for the dashboard handoff.",{"type":42,"tag":51,"props":256,"children":257},{},[258],{"type":48,"value":259},"Do not choose the MCP artifact app in Work Mode without a positive Codex desktop surface, even if its tools are visible. For all other environments, use the default order below:",{"type":42,"tag":153,"props":261,"children":262},{},[263,268,273],{"type":42,"tag":157,"props":264,"children":265},{},[266],{"type":48,"value":267},"Use a connected BI tool by default. Use the BI surface identified from the current request, current-run context, or explicit user preference; if none is specified, look for an available connected BI solution before choosing another surface.",{"type":42,"tag":157,"props":269,"children":270},{},[271],{"type":48,"value":272},"Use the MCP artifact app when a connected BI build is unavailable, too heavy for the request, or the user needs a compact in-Codex analytical dashboard.",{"type":42,"tag":157,"props":274,"children":275},{},[276],{"type":48,"value":277},"Use HTML when BI and MCP are not suitable and the user needs a portable static dashboard.",{"type":42,"tag":51,"props":279,"children":280},{},[281],{"type":48,"value":282},"Use Streamlit only when the user explicitly asks for it or an existing Streamlit app must be changed.",{"type":42,"tag":51,"props":284,"children":285},{},[286],{"type":48,"value":287},"Read the matching specification before building:",{"type":42,"tag":289,"props":290,"children":291},"ul",{},[292,303,314,325,336],{"type":42,"tag":157,"props":293,"children":294},{},[295,301],{"type":42,"tag":102,"props":296,"children":298},{"className":297},[],[299],{"type":48,"value":300},"..\u002F..\u002Fsrc\u002Fanalytics-app-core.md",{"type":48,"value":302}," for shared MCP artifact mechanics, source safety, runtime behavior, and validation helpers.",{"type":42,"tag":157,"props":304,"children":305},{},[306,312],{"type":42,"tag":102,"props":307,"children":309},{"className":308},[],[310],{"type":48,"value":311},"specifications\u002Fbi-platform-dashboard.md",{"type":48,"value":313}," for BI platform dashboards.",{"type":42,"tag":157,"props":315,"children":316},{},[317,323],{"type":42,"tag":102,"props":318,"children":320},{"className":319},[],[321],{"type":48,"value":322},"specifications\u002Fmcp-artifact-dashboard.md",{"type":48,"value":324}," for dashboards rendered by the MCP artifact app.",{"type":42,"tag":157,"props":326,"children":327},{},[328,334],{"type":42,"tag":102,"props":329,"children":331},{"className":330},[],[332],{"type":48,"value":333},"specifications\u002Fhtml-dashboard.md",{"type":48,"value":335}," for portable static HTML dashboards.",{"type":42,"tag":157,"props":337,"children":338},{},[339,345],{"type":42,"tag":102,"props":340,"children":342},{"className":341},[],[343],{"type":48,"value":344},"specifications\u002Fstreamlit-dashboard.md",{"type":48,"value":346}," for Streamlit dashboards.",{"type":42,"tag":90,"props":348,"children":350},{"id":349},"_3-gather-and-validate-the-data",[351],{"type":48,"value":352},"3. Gather And Validate The Data",{"type":42,"tag":51,"props":354,"children":355},{},[356],{"type":48,"value":357},"Do the data work in this order:",{"type":42,"tag":289,"props":359,"children":360},{},[361,403,413,423,433],{"type":42,"tag":157,"props":362,"children":363},{},[364,369,371,377,379,385,387,393,395,401],{"type":42,"tag":161,"props":365,"children":366},{},[367],{"type":48,"value":368},"Find the source path before rendering.",{"type":48,"value":370}," Source discovery is part of dashboard building, not optional enrichment. Identify the source path for the core dashboard metrics. Use ",{"type":42,"tag":102,"props":372,"children":374},{"className":373},[],[375],{"type":48,"value":376},"~~structured_data",{"type":48,"value":378}," when the dashboard needs data from a warehouse or another structured data source. Use context lanes such as ",{"type":42,"tag":102,"props":380,"children":382},{"className":381},[],[383],{"type":48,"value":384},"~~company_docs",{"type":48,"value":386},", ",{"type":42,"tag":102,"props":388,"children":390},{"className":389},[],[391],{"type":48,"value":392},"~~team_communication",{"type":48,"value":394},", or ",{"type":42,"tag":102,"props":396,"children":398},{"className":397},[],[399],{"type":48,"value":400},"~~dashboards_or_bi",{"type":48,"value":402}," when the dashboard needs business meaning, source-of-truth guidance, metric definitions, or requirements that are not captured in structured data alone.",{"type":42,"tag":157,"props":404,"children":405},{},[406,411],{"type":42,"tag":161,"props":407,"children":408},{},[409],{"type":48,"value":410},"Use durable dashboard data.",{"type":48,"value":412}," Validate the data before wiring it into the dashboard. Keep final extracts compact and aggregated unless a bounded detail table is part of the dashboard's purpose. Avoid final dashboards that depend on scratch or temporary tables.",{"type":42,"tag":157,"props":414,"children":415},{},[416,421],{"type":42,"tag":161,"props":417,"children":418},{},[419],{"type":48,"value":420},"Validate trust.",{"type":48,"value":422}," For straightforward dashboards, confirm the source, grain, freshness, and basic reconciliation needed to trust the displayed metrics. Use $analyze-data-quality when data trust is a material risk, such as a new source, recent backfill, complex join, or surprising result.",{"type":42,"tag":157,"props":424,"children":425},{},[426,431],{"type":42,"tag":161,"props":427,"children":428},{},[429],{"type":48,"value":430},"Resolve time and context anchors.",{"type":48,"value":432}," Before selecting metrics, establish any date anchor, comparison window, latest complete data date, source coverage, or authoritative artifact needed to shape the dashboard, such as a launch date, incident window, or campaign period. Use $gather-business-context when the prompt does not provide it. If still unclear, ask only when it would materially change the dashboard; otherwise state the assumption and shape queries around it.",{"type":42,"tag":157,"props":434,"children":435},{},[436,441],{"type":42,"tag":161,"props":437,"children":438},{},[439],{"type":48,"value":440},"Stop if source-backed data is unavailable.",{"type":48,"value":442}," Do not render dashboards from fallback, sample, scratch, or partially blocked data unless the user explicitly asked for a mockup. If the core dashboard data is not available, stop the build path and tell the user what source or access is needed. Do not claim a dashboard was created from real data when the source path is missing.",{"type":42,"tag":90,"props":444,"children":446},{"id":445},"_4-define-the-metric-model",[447],{"type":48,"value":448},"4. Define The Metric Model",{"type":42,"tag":51,"props":450,"children":451},{},[452],{"type":42,"tag":161,"props":453,"children":454},{},[455],{"type":48,"value":456},"Select the metrics.",{"type":42,"tag":51,"props":458,"children":459},{},[460],{"type":48,"value":461},"When selecting dashboard metrics, classify the measurement object and choose a balanced metric model for that object. Do not use a fixed checklist. Identify which metric families are decision-relevant and which are intentionally out of scope.",{"type":42,"tag":51,"props":463,"children":464},{},[465],{"type":48,"value":466},"Consider these metric families as prompts, not required sections:",{"type":42,"tag":289,"props":468,"children":469},{},[470,475,480,485,490,495,500,505],{"type":42,"tag":157,"props":471,"children":472},{},[473],{"type":48,"value":474},"Reach: who or what is using the thing, eligible population, penetration, activation, adoption, coverage.",{"type":42,"tag":157,"props":476,"children":477},{},[478],{"type":48,"value":479},"Volume: events, usage, transactions, sessions, requests, units, throughput, frequency.",{"type":42,"tag":157,"props":481,"children":482},{},[483],{"type":48,"value":484},"Value: revenue, cost, margin, savings, conversion, retention value, productivity, business outcome.",{"type":42,"tag":157,"props":486,"children":487},{},[488],{"type":48,"value":489},"Quality: success, failure, reliability, latency, satisfaction, correctness, safety, support burden.",{"type":42,"tag":157,"props":491,"children":492},{},[493],{"type":48,"value":494},"Depth: repeat usage, intensity, feature mix, workflow completion, productionization, maturity, lifecycle stage.",{"type":42,"tag":157,"props":496,"children":497},{},[498],{"type":48,"value":499},"Mix: segment, customer type, geography, channel, model\u002Fproduct\u002Fversion, plan, use case, cohort.",{"type":42,"tag":157,"props":501,"children":502},{},[503],{"type":48,"value":504},"Movement: trend, growth, seasonality, pre\u002Fpost change, benchmark, target, forecast, leading indicators.",{"type":42,"tag":157,"props":506,"children":507},{},[508],{"type":48,"value":509},"Risk and constraints: data coverage, source freshness, known blind spots, capacity, compliance, operational limits.",{"type":42,"tag":51,"props":511,"children":512},{},[513],{"type":42,"tag":161,"props":514,"children":515},{},[516],{"type":48,"value":517},"Build breadth without flattening the dashboard.",{"type":42,"tag":51,"props":519,"children":520},{},[521],{"type":48,"value":522},"Build enough metric breadth to cover every family that is relevant to the dashboard's measurement object and decision. Keep the default view hierarchical rather than exhaustive: lead with the primary outcome and the highest-signal drivers, then use sections, tabs, filters, detail tables, or supporting views for additional relevant metrics. A selected family can be represented by one or many KPIs, drivers, guardrails, or breakdowns, depending on what the user needs to monitor or diagnose.",{"type":42,"tag":51,"props":524,"children":525},{},[526],{"type":48,"value":527},"Map the selected families into dashboard roles before building: hero metrics for the default view, diagnostic metrics for movement and breakdowns, guardrails for interpretation, and detail metrics for lookup or follow-up.",{"type":42,"tag":51,"props":529,"children":530},{},[531],{"type":48,"value":532},"Let the decision determine the number of hero metric cards. Do not pad or truncate the set to four—or any preferred count. Give each card one distinct, decision-relevant headline metric. Use chips only for short comparison context tied directly to that headline, such as its prior-period value, target, or delta; move independent secondary measures into their own cards, charts, tables, narrative, or detail views. Keep coherent cards in the same strip; odd counts are valid because the artifact renderer balances rows responsively.",{"type":42,"tag":51,"props":534,"children":535},{},[536],{"type":42,"tag":161,"props":537,"children":538},{},[539],{"type":48,"value":540},"Escalate when metric design is the hard part.",{"type":42,"tag":51,"props":542,"children":543},{},[544],{"type":48,"value":545},"Invoke $design-kpis when this baseline metric-family pass is not enough, such as when the dashboard needs a deeper metric framework, target-setting, formal KPI tradeoff analysis, or clearer definitions than this workflow can safely infer. Pass the dashboard brief, business context, source context, existing metric definitions, and constraints so the recommended metrics fit the audience and use case.",{"type":42,"tag":51,"props":547,"children":548},{},[549],{"type":42,"tag":161,"props":550,"children":551},{},[552],{"type":48,"value":553},"Keep the data model consistent.",{"type":42,"tag":51,"props":555,"children":556},{},[557],{"type":48,"value":558},"Build from a reusable compact data model where possible instead of many slightly different tile queries. Keep date logic, filters, dimensions, and metric definitions consistent across cards, charts, and tables so numbers reconcile. Reuse shared metric definitions from the selected tool or semantic layer when available.",{"type":42,"tag":90,"props":560,"children":562},{"id":561},"_5-design-the-dashboard-layout",[563],{"type":48,"value":564},"5. Design The Dashboard Layout",{"type":42,"tag":51,"props":566,"children":567},{},[568],{"type":48,"value":569},"Make the default view useful before the viewer interacts. Arrange the dashboard from summary to detail: lead with the key status or primary KPI context, follow with movement over time, then show the breakdowns that explain the pattern, and put detail tables lower on the page when lookup or operational follow-up is needed.",{"type":42,"tag":51,"props":571,"children":572},{},[573],{"type":48,"value":574},"Use global filters only when they materially update the dashboard-wide view. Prefer a few high-signal controls over a dense filter panel. Keep dashboards visual-heavy and neutral: short labels, direct metric names, sparse annotations, and minimal explanatory text on the main canvas. Use human-readable short date form in visible labels and freshness text; keep ISO timestamps for machine-readable source metadata.",{"type":42,"tag":51,"props":576,"children":577},{},[578],{"type":48,"value":579},"Prefer human-readable short date forms in visible labels and tooltips unless the dashboard needs timestamps for operational precision.",{"type":42,"tag":90,"props":581,"children":583},{"id":582},"_6-choose-the-right-charts",[584],{"type":48,"value":585},"6. Choose The Right Charts",{"type":42,"tag":51,"props":587,"children":588},{},[589],{"type":48,"value":590},"Use $visualize-data when the dashboard needs chart selection, visual encoding, or chart polish. This skill should define what each chart needs to communicate; $visualize-data handles the detailed visual design.",{"type":42,"tag":51,"props":592,"children":593},{},[594],{"type":48,"value":595},"Choose the simplest visual that answers the viewer's question. Use a chart when it makes the pattern easier to understand than text or a table.",{"type":42,"tag":51,"props":597,"children":598},{},[599],{"type":48,"value":600},"Put metrics in the same chart only when comparing them directly makes sense. Otherwise, split them into separate charts, KPI cards, or tables.",{"type":42,"tag":51,"props":602,"children":603},{},[604],{"type":48,"value":605},"Use the selected dashboard specification for exact schema, renderer, and interaction requirements.",{"type":42,"tag":90,"props":607,"children":609},{"id":608},"_7-build-and-validate-in-the-selected-surface",[610],{"type":48,"value":611},"7. Build And Validate In The Selected Surface",{"type":42,"tag":51,"props":613,"children":614},{},[615],{"type":48,"value":616},"Build in the selected surface using its native patterns. Before handoff, check that the dashboard opens cleanly, filters work, charts render, numbers reconcile, access is handled clearly, and performance is acceptable.",{"type":42,"tag":51,"props":618,"children":619},{},[620],{"type":48,"value":621},"Record the source or query path when it would be hard to rediscover later.",{"type":42,"tag":90,"props":623,"children":625},{"id":624},"_8-hand-off-the-dashboard",[626],{"type":48,"value":627},"8. Hand Off The Dashboard",{"type":42,"tag":51,"props":629,"children":630},{},[631,633,638],{"type":48,"value":632},"Include the dashboard link or local artifact path, source or access caveats, and any remaining sharing or operational steps. Keep routine check details in support artifacts. Do not list internal checks in the user-facing handoff unless a check failed, was unavailable, or produced a user-relevant caveat. For MCP artifact dashboards, follow the validation and render handoff rules in ",{"type":42,"tag":102,"props":634,"children":636},{"className":635},[],[637],{"type":48,"value":322},{"type":48,"value":639},".",{"type":42,"tag":43,"props":641,"children":643},{"id":642},"dashboard-quality-bar",[644],{"type":48,"value":645},"Dashboard Quality Bar",{"type":42,"tag":51,"props":647,"children":648},{},[649],{"type":48,"value":650},"Before handoff, make sure the dashboard is usable as a measurement surface:",{"type":42,"tag":289,"props":652,"children":653},{},[654,659,664,669,674,679,684,689,694,699],{"type":42,"tag":157,"props":655,"children":656},{},[657],{"type":48,"value":658},"The default view answers the primary audience question before the viewer interacts.",{"type":42,"tag":157,"props":660,"children":661},{},[662],{"type":48,"value":663},"Filters are few, meaningful, and work across the surfaces they claim to control.",{"type":42,"tag":157,"props":665,"children":666},{},[667],{"type":48,"value":668},"Cards, charts, and tables reconcile unless differences are clearly labeled.",{"type":42,"tag":157,"props":670,"children":671},{},[672],{"type":48,"value":673},"Charts answer clear questions with compatible metrics.",{"type":42,"tag":157,"props":675,"children":676},{},[677],{"type":48,"value":678},"Tables support lookup, comparison, or operational follow-up after the chart-led summary.",{"type":42,"tag":157,"props":680,"children":681},{},[682],{"type":48,"value":683},"The metric set is broad enough for the measurement object: it covers the relevant families with primary outcomes, important drivers, guardrails, and supporting breakdowns while keeping the default view usable.",{"type":42,"tag":157,"props":685,"children":686},{},[687],{"type":48,"value":688},"KPI cards are precisely defined: business-defined metrics include enough visible or nearby context for a reader to understand what is counted, over what window, and under what denominator or eligibility rule.",{"type":42,"tag":157,"props":690,"children":691},{},[692],{"type":48,"value":693},"Source freshness, access limits, and caveats are visible where they matter.",{"type":42,"tag":157,"props":695,"children":696},{},[697],{"type":48,"value":698},"The layout, labels, and performance work for the selected delivery mode.",{"type":42,"tag":157,"props":700,"children":701},{},[702],{"type":48,"value":703},"The selected dashboard specification's validation and render rules were followed.",{"items":705,"total":816},[706,723,739,752,768,784,801],{"slug":707,"name":707,"fn":708,"description":709,"org":710,"tags":711,"stars":25,"repoUrl":26,"updatedAt":722},"analyze-account-signals","analyze account signals for sales intelligence","Use when the user wants to know what changed with one account, monitor an owner portfolio or watchlist, or rank accounts needing attention from recent evidence. Produce an evidence-backed account brief or bounded watchlist summary with recommended actions.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[712,713,716,719],{"name":23,"slug":24,"type":15},{"name":714,"slug":715,"type":15},"CRM","crm",{"name":717,"slug":718,"type":15},"Research","research",{"name":720,"slug":721,"type":15},"Sales","sales","2026-07-01T07:54:11.79288",{"slug":724,"name":724,"fn":725,"description":726,"org":727,"tags":728,"stars":25,"repoUrl":26,"updatedAt":738},"analyze-data-quality","assess data quality for analysis","Assess whether structured data, query results, dashboards, or analytical evidence are trustworthy enough to use. Use when the task is to check data quality, reconcile conflicting sources or metric definitions, or decide whether evidence is safe to cite.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[729,732,735],{"name":730,"slug":731,"type":15},"Audit","audit",{"name":733,"slug":734,"type":15},"Data Engineering","data-engineering",{"name":736,"slug":737,"type":15},"Data Quality","data-quality","2026-07-01T07:55:01.146961",{"slug":740,"name":740,"fn":741,"description":742,"org":743,"tags":744,"stars":25,"repoUrl":26,"updatedAt":751},"answers-ask-user-input","request missing context from users","Use when a small amount of missing context would materially improve the answer and tappable options plus a free-text answer can gather it efficiently.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[745,748],{"name":746,"slug":747,"type":15},"Communications","communications",{"name":749,"slug":750,"type":15},"Productivity","productivity","2026-07-14T05:43:36.096323",{"slug":753,"name":753,"fn":754,"description":755,"org":756,"tags":757,"stars":25,"repoUrl":26,"updatedAt":767},"apollo","prospect and enrich leads with Apollo","Use only when a focused Sales workflow has selected a present and connected Apollo connector, or the user explicitly asks for Apollo prospecting, enrichment, Company Details, records, sequences, or outbound planning. Apply Apollo v2-specific behavior only after verifying app version 2.0.0 or later.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[758,760,763,766],{"name":759,"slug":753,"type":15},"Apollo",{"name":761,"slug":762,"type":15},"Lead Enrichment","lead-enrichment",{"name":764,"slug":765,"type":15},"Prospecting","prospecting",{"name":720,"slug":721,"type":15},"2026-07-14T05:43:34.800076",{"slug":731,"name":731,"fn":769,"description":770,"org":771,"tags":772,"stars":25,"repoUrl":26,"updatedAt":783},"audit product flows and user journeys","Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings inline from that evidence. Use Figma only when the user explicitly asks for a board. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[773,774,777,780],{"name":730,"slug":731,"type":15},{"name":775,"slug":776,"type":15},"Design","design",{"name":778,"slug":779,"type":15},"Product Management","product-management",{"name":781,"slug":782,"type":15},"UX Design","ux-design","2026-07-01T07:54:30.613428",{"slug":785,"name":785,"fn":786,"description":787,"org":788,"tags":789,"stars":25,"repoUrl":26,"updatedAt":800},"build-business-case","build customer-led business cases and ROI","Review commercial proposals and build customer-led business cases, ROI or value models, pricing or investment rationales, executive summaries, and customer-ready value stories tied to a customer, workflow, initiative, or decision.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[790,793,796,799],{"name":791,"slug":792,"type":15},"Content Creation","content-creation",{"name":794,"slug":795,"type":15},"Finance","finance",{"name":797,"slug":798,"type":15},"Financial Modeling","financial-modeling",{"name":720,"slug":721,"type":15},"2026-07-01T07:54:02.779003",{"slug":802,"name":802,"fn":803,"description":804,"org":805,"tags":806,"stars":25,"repoUrl":26,"updatedAt":815},"build-competitive-brief","build competitive briefs and battlecards","Use when the user wants a competitor or vendor comparison, market-landscape analysis, battlecard, objection package, positioning brief, or account-specific competitive view. Produce an evidence-backed comparison, guidance, and brief, using supplied materials, connected research, and public evidence when appropriate.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[807,810,813,814],{"name":808,"slug":809,"type":15},"Competitive Intelligence","competitive-intelligence",{"name":811,"slug":812,"type":15},"Marketing","marketing",{"name":717,"slug":718,"type":15},{"name":720,"slug":721,"type":15},"2026-07-01T07:54:13.073252",43,{"items":818,"total":1019},[819,840,863,880,896,915,932,946,962,976,988,1003],{"slug":820,"name":820,"fn":821,"description":822,"org":823,"tags":824,"stars":837,"repoUrl":838,"updatedAt":839},"prior-auth-packet-builder","build healthcare prior authorization packets","Build a concise prior authorization packet from local case files and payer policy docs.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[825,828,831,834],{"name":826,"slug":827,"type":15},"Documents","documents",{"name":829,"slug":830,"type":15},"Healthcare","healthcare",{"name":832,"slug":833,"type":15},"Insurance","insurance",{"name":835,"slug":836,"type":15},"Regulatory Compliance","regulatory-compliance",28169,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fopenai-agents-python","2026-04-16T05:11:39.180399",{"slug":841,"name":841,"fn":842,"description":843,"org":844,"tags":845,"stars":860,"repoUrl":861,"updatedAt":862},"aspnet-core","build ASP.NET Core web applications","Build, review, refactor, or architect ASP.NET Core web applications using current official guidance for .NET web development. Use when working on Blazor Web Apps, Razor Pages, MVC, Minimal APIs, controller-based Web APIs, SignalR, gRPC, middleware, dependency injection, configuration, authentication, authorization, testing, performance, deployment, or ASP.NET Core upgrades.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[846,849,851,854,857],{"name":847,"slug":848,"type":15},".NET","dotnet",{"name":850,"slug":841,"type":15},"ASP.NET Core",{"name":852,"slug":853,"type":15},"Blazor","blazor",{"name":855,"slug":856,"type":15},"C#","csharp",{"name":858,"slug":859,"type":15},"Web Development","web-development",23787,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fskills","2026-04-12T05:07:02.819491",{"slug":864,"name":864,"fn":865,"description":866,"org":867,"tags":868,"stars":860,"repoUrl":861,"updatedAt":879},"chatgpt-apps","build ChatGPT Apps SDK applications","Build, scaffold, refactor, and troubleshoot ChatGPT Apps SDK applications that combine an MCP server and widget UI. Use when Codex needs to design tools, register UI resources, wire the MCP Apps bridge or ChatGPT compatibility APIs, apply Apps SDK metadata or CSP or domain settings, or produce a docs-aligned project scaffold. Prefer a docs-first workflow by invoking the openai-docs skill or OpenAI developer docs MCP tools before generating code.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[869,872,875,878],{"name":870,"slug":871,"type":15},"Apps SDK","apps-sdk",{"name":873,"slug":874,"type":15},"ChatGPT","chatgpt",{"name":876,"slug":877,"type":15},"MCP","mcp",{"name":9,"slug":8,"type":15},"2026-04-12T05:07:05.468097",{"slug":881,"name":881,"fn":882,"description":883,"org":884,"tags":885,"stars":860,"repoUrl":861,"updatedAt":895},"cli-creator","build CLIs from API docs","Build a composable CLI for Codex from API docs, an OpenAPI spec, existing curl examples, an SDK, a web app, an admin tool, or a local script. Use when the user wants Codex to create a command-line tool that can run from any repo, expose composable read\u002Fwrite commands, return stable JSON, manage auth, and pair with a companion skill.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[886,889,892],{"name":887,"slug":888,"type":15},"API Development","api-development",{"name":890,"slug":891,"type":15},"CLI","cli",{"name":893,"slug":894,"type":15},"Codex","codex","2026-04-12T05:07:04.132762",{"slug":897,"name":897,"fn":898,"description":899,"org":900,"tags":901,"stars":860,"repoUrl":861,"updatedAt":914},"cloudflare-deploy","deploy projects to Cloudflare","Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[902,905,908,911],{"name":903,"slug":904,"type":15},"Cloudflare","cloudflare",{"name":906,"slug":907,"type":15},"Cloudflare Pages","cloudflare-pages",{"name":909,"slug":910,"type":15},"Cloudflare Workers","cloudflare-workers",{"name":912,"slug":913,"type":15},"Deployment","deployment","2026-04-12T05:07:14.275118",{"slug":916,"name":916,"fn":917,"description":918,"org":919,"tags":920,"stars":860,"repoUrl":861,"updatedAt":931},"define-goal","define and set measurable project goals","Help the user define a concrete, measurable goal before starting work, especially when they ask to use the goal tool, create a goal, set an objective, clarify success criteria, or turn a fuzzy intention into a quantitative outcome. Use this skill for goal creation and goal refinement only; it does not manage durable snapshots, decision logs, or long-running execution artifacts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[921,922,925,928],{"name":749,"slug":750,"type":15},{"name":923,"slug":924,"type":15},"Project Management","project-management",{"name":926,"slug":927,"type":15},"Strategy","strategy",{"name":929,"slug":930,"type":15},"Task Management","task-management","2026-05-23T06:17:16.870838",{"slug":933,"name":933,"fn":934,"description":935,"org":936,"tags":937,"stars":860,"repoUrl":861,"updatedAt":945},"figma","translate Figma designs into code","Use the Figma MCP server to fetch design context, screenshots, variables, and assets from Figma, and to translate Figma nodes into production code. Trigger when a task involves Figma URLs, node IDs, design-to-code implementation, or Figma MCP setup and troubleshooting.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[938,939,941,944],{"name":775,"slug":776,"type":15},{"name":940,"slug":933,"type":15},"Figma",{"name":942,"slug":943,"type":15},"Frontend","frontend",{"name":876,"slug":877,"type":15},"2026-04-12T05:06:47.939943",{"slug":947,"name":947,"fn":948,"description":949,"org":950,"tags":951,"stars":860,"repoUrl":861,"updatedAt":961},"figma-code-connect-components","connect Figma designs to code components","Connects Figma design components to code components using Code Connect mapping tools. Use when user says \"code connect\", \"connect this component to code\", \"map this component\", \"link component to code\", \"create code connect mapping\", or wants to establish mappings between Figma designs and code implementations. For canvas writes via `use_figma`, use `figma-use`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[952,953,956,957,958],{"name":775,"slug":776,"type":15},{"name":954,"slug":955,"type":15},"Design System","design-system",{"name":940,"slug":933,"type":15},{"name":942,"slug":943,"type":15},{"name":959,"slug":960,"type":15},"UI Components","ui-components","2026-05-10T05:59:52.971881",{"slug":963,"name":963,"fn":964,"description":965,"org":966,"tags":967,"stars":860,"repoUrl":861,"updatedAt":975},"figma-create-design-system-rules","generate design system rules from Figma","Generates custom design system rules for the user's codebase. Use when user says \"create design system rules\", \"generate rules for my project\", \"set up design rules\", \"customize design system guidelines\", or wants to establish project-specific conventions for Figma-to-code workflows. Requires Figma MCP server connection.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[968,969,970,973,974],{"name":775,"slug":776,"type":15},{"name":954,"slug":955,"type":15},{"name":971,"slug":972,"type":15},"Documentation","documentation",{"name":940,"slug":933,"type":15},{"name":942,"slug":943,"type":15},"2026-05-16T06:07:47.821474",{"slug":977,"name":977,"fn":978,"description":979,"org":980,"tags":981,"stars":860,"repoUrl":861,"updatedAt":987},"figma-implement-design","translate Figma designs into application code","Translates Figma designs into production-ready application code with 1:1 visual fidelity. Use when implementing UI code from Figma files, when user mentions \"implement design\", \"generate code\", \"implement component\", provides Figma URLs, or asks to build components matching Figma specs. For Figma canvas writes via `use_figma`, use `figma-use`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[982,983,984,985,986],{"name":775,"slug":776,"type":15},{"name":940,"slug":933,"type":15},{"name":942,"slug":943,"type":15},{"name":959,"slug":960,"type":15},{"name":858,"slug":859,"type":15},"2026-05-16T06:07:40.583615",{"slug":989,"name":989,"fn":990,"description":991,"org":992,"tags":993,"stars":860,"repoUrl":861,"updatedAt":1002},"hatch-pet","create animated pets for Codex","Create, repair, validate, visually QA, and package Codex-compatible animated pets and pet spritesheets from character art, generated images, company or prospect brand cues, or visual references. Use when a user wants a lightweight-worker Codex pet workflow, a non-pixel custom pet style, a prospect or company mascot pet, or a full 8x9 animated pet atlas with transparent unused cells, QA contact sheets, and pet.json packaging. This skill composes the installed $imagegen system skill for visual generation and uses bundled scripts for deterministic spritesheet assembly.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[994,997,998,1001],{"name":995,"slug":996,"type":15},"Animation","animation",{"name":893,"slug":894,"type":15},{"name":999,"slug":1000,"type":15},"Creative","creative",{"name":775,"slug":776,"type":15},"2026-05-02T05:31:48.48485",{"slug":1004,"name":1004,"fn":1005,"description":1006,"org":1007,"tags":1008,"stars":860,"repoUrl":861,"updatedAt":1018},"imagegen","generate and edit raster images","Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG\u002Fvector\u002Fcode-native assets, extending an established icon or logo system, or building the visual directly in HTML\u002FCSS\u002Fcanvas.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1009,1010,1011,1014,1017],{"name":999,"slug":1000,"type":15},{"name":775,"slug":776,"type":15},{"name":1012,"slug":1013,"type":15},"Image Generation","image-generation",{"name":1015,"slug":1016,"type":15},"Images","images",{"name":9,"slug":8,"type":15},"2026-05-15T06:23:24.312127",675]