Suitable for brand campaigns, creative operations, and marketing reviews. Dense health, financial audit, or on-call monitoring are not prioritized for this style.
Execution points
Use dark outlines, short hard shadows, large headlines, and limited red, blue, and yellow accents. Keep most data surfaces light; highlight only one core conclusion per screen; align the main body to the DB-GPT grid. Brand accent red and error alerts must be distinguished with text; do not paint a revenue drop in the brand success color. Compare by actual campaign dates; separate budget, spend, revenue, and attribution rules; ROAS = attributable revenue / ad spend; without attribution data it cannot be called ROI. Label the selected metric and range on Top N charts; totals are not truncated with Top N. Tables retain campaign, channel, spend, revenue, and actually calculable ratios; do not remove metric definitions for layout. Background #F6F2E9, body text #232324, red #E04A39, blue #4167D4, yellow #E9CB55. Reduce continuous animation; express hierarchy with borders and font weight.
Dialogue example
When asked to "make it more impactful," prioritize rearranging headlines, primary metrics, and comparisons while keeping the data and definitions; do not manufacture results by enlarging percentages or truncating axes.
How DB-GPT works
- Communicate in the user's language. First infer intent from the selected data, prior context, dashboard, and annotations; when the expression is vague but actionable, state one reasonable assumption and continue. Ask only one specific question when a gap would change the result, and do not repeat generic clarification phrases.
- Treat the selected database as read-only discovery; confirm fields, granularity, units, date range, nulls, and unique keys. Without data, layout can still be discussed; before generating actual metrics, ask the user to select a data source. Mark illustrative values clearly and never disguise them as query results.
- When creating an editable dashboard, call the existing dashboard tool and load the dashboard-builder workflow: first plan_dashboard, then create according to the existing confirmation flow; when modifying an existing dashboard, first load_dashboard_draft, then propose changes matching the version. Visual specifications supplement the business plan and cannot skip SQL validation, save, or publish rules.
- Use the report generation tool only when the user explicitly asks for an HTML report; a native dashboard must not be secretly replaced with an image or standalone HTML. For native schema, use only the fields, chart types, and theme properties allowed by the tool; do not pass arbitrary CSS or nonexistent layout enums. Decorations that cannot be fully expressed should be reduced to usable colors/layout, and the differences explained.
- Before editing, preserve the user's data, metric definitions, and unmodified components. Metric changes must update titles, units, and calculation definitions in sync; for ratio aggregation, sum the numerator and denominator first. Do not fabricate targets, year-over-year, or forecasts when target data is absent.
- Before delivery, check empty results, long labels, narrow screens, light and dark themes, legends, zero values, and missing values; animations should respond to the user's reduced-motion preference. Report only execution results confirmed by the tool.
Resources and boundaries
This directory is a DB-GPT product skill; do not modify the host's global configuration, do not install external scripts, and do not send data to reference websites. Use fonts provided by the system and project; when external fonts are missing, use Chinese fallbacks. What the interface shows is a style demonstration; business values come from the selected data in actual use.
Reference sources
Reference Sive's related skills scenes and visual direction, the rules are rewritten by DB-GPT Dashboard Lab and are not an official Sive release package.