feat(native.system): replace write-dashboard with build-dashboard - #26
Merged
datbth merged 3 commits intoJul 29, 2026
Merged
Conversation
… skill
Replaces the write-dashboard body with the merged build_dashboard skill
developed and evaluated in the staging3 workspace. Same slot, same
frontmatter name, so it takes over rather than competing.
Evidence, from a 64-run eval against the staging3 Copilot:
- the two skills were competing and write-dashboard won 53 of 64 runs.
The staging3 skill fired 0 times on precise intermediate/complex
prompts because its description carried an anti-trigger disclaiming
exactly those asks; when it did win it scored 14/18 correct vs 15/46
otherwise
- the anti-trigger is now cut on a different axis - "is a dashboard the
deliverable?" - rather than excluding facets of the dashboard job
- all 12 underspecified runs opened with a KPI row and closed with a
table, only the middle varying. The input checklist named the four
questions rather than asking for them, and the minimum output
prescribed the KPI-row frame outright. Both are gone: the reader's
job (monitoring, diagnosing, comparing, planning, looking up) is now
decided first, questions are derived and ranked, and the minimum is
stated as a quality bar rather than a shape
What the previous version contributed and this keeps: the block-type
vocabulary, the four ref: forms, the layout constructs, and the worked
example - now conforming to the skill's own prescriptions (1220 grid,
TabLayout, classic theme, no FilterBlock default, complete interactions).
Dropped from the previous version: "prefer the smallest set of blocks"
(conflicts with the completeness bar), interactions as optional, and the
standalone 107-line example that contradicted the layout conventions.
Not carried over: the @context: viz-reuse mechanism. The token was wrong
(the resource type is VizAml) and, more importantly, every @context:
occurrence in the product is an MCP tool parameter - a runtime hand-off
between tool calls, not something that resolves inside a saved page.aml.
It is also gated behind FT_REUSE_CONTEXT. The version on the
native-skills/write-dashboard branch still documents it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The skill's content is now the merged build_dashboard skill, so the identity should match. Repo convention is kebab-case folders with a matching frontmatter `name`, and the runtime normalises that to an underscored skill_id — so `build-dashboard` here surfaces to the agent as `build_dashboard`, the same way `write-dashboard` surfaced as `write_dashboard`. This removes the write-dashboard slot rather than shadowing it, so only one dashboard-building skill remains and the two no longer compete. Nothing else in the repo referenced the old name. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
thinhnguyentruong
marked this pull request as ready for review
July 29, 2026 09:54
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
datbth
reviewed
Jul 29, 2026
|
|
||
| * **The Schema above is the complete layout vocabulary** (`Dashboard`, `block`, `interactions`, `settings`, `theme`, `view` / `TabLayout` / `CanvasLayout`, `position: pos()`, `layer`, `mobile`). Use only the properties and constructs shown — never guess or invent one (e.g. there is no layout `margin`/`padding`/`gap`; spacing is pos()-driven). A bare top-level `view: CanvasLayout` and a `LinearLayout` are also valid AML, but this skill always wraps the canvas in a TabLayout for uniformity. If you believe you need something not shown here, confirm it with `search_docs` first. | ||
| * **Prefer a generated viz over a hand-written one** — hand-written viz AML is the biggest source of invalid output. | ||
| * **A chart doesn't filter itself; the dashboard's controls do.** The date filter sets the time window, Period Comparison the comparison period, the drill the grain, dimension filters the segmenting. Strip any viz-level `filter` and any baked-in period. |
Collaborator
There was a problem hiding this comment.
A chart doesn't filter itself
This is extreme and may hinder local filtering.
Might phrase this to be sth like "prefer dashboard controls for interactivity over static local chart filters"
Contributor
Author
There was a problem hiding this comment.
Applied, close to your wording.
Kept the concrete reason — a hard-coded date window ships empty, or goes stale once the viewer moves the control — and scoped the rule to time window / comparison period rather than filtering generally. A filter that defines what the chart is ("top 10 by revenue") explicitly stays.
Also softened the verify step, which was restating the strict version.
|
|
||
| ## Conventions | ||
|
|
||
| * **The Schema above is the complete layout vocabulary** (`Dashboard`, `block`, `interactions`, `settings`, `theme`, `view` / `TabLayout` / `CanvasLayout`, `position: pos()`, `layer`, `mobile`). Use only the properties and constructs shown — never guess or invent one (e.g. there is no layout `margin`/`padding`/`gap`; spacing is pos()-driven). A bare top-level `view: CanvasLayout` and a `LinearLayout` are also valid AML, but this skill always wraps the canvas in a TabLayout for uniformity. If you believe you need something not shown here, confirm it with `search_docs` first. |
Collaborator
There was a problem hiding this comment.
complete layout vocabulary
This means you/we would need to maintain this skill whenever releasing new features.
Alternatively, we could tell the AI to "double-check docs if needed" instead
Contributor
Author
There was a problem hiding this comment.
Applied — dropped the completeness claim. The list is now explicitly not exhaustive, the rule is "never invent a layout property", and anything beyond it goes to search_docs. So it no longer needs updating on every layout release.
Kept one concrete item — no layout margin/padding/gap, spacing is pos()-driven — since inventing those was a real failure and that fact does not drift.
| @@ -0,0 +1,232 @@ | |||
| --- | |||
| name: build-dashboard | |||
| description: Build or edit a Holistics canvas dashboard in AML (a `page.aml` file / `Dashboard {}` object) — assemble viz, text, and control blocks, lay them out, wire filter interactions, and set the theme. Use whenever you need to build a dashboard or report page, add or arrange blocks, edit a dashboard's text or section structure, or add dashboard-level filters. Typical phrasings: build a dashboard for X, create a new report page, make a dashboard showing X, add a chart or KPI or table to a dashboard, add a filter or date control, add a title or section header, edit the dashboard's intro text. Do NOT trigger for answering a data question on its own — a one-off query, chart, or analysis with no dashboard to put it on — or for editing models, datasets, or metric definitions, authoring a reusable custom chart type or a theme object, or restyling an existing dashboard's look. | |||
Contributor
Author
There was a problem hiding this comment.
Trimmed ~20%, same four-part structure.
Kept two phrasings on purpose: "add a chart or KPI or table to a dashboard" and "add a filter or date control" — the description this replaces under-triggered on exactly those asks. Can cut more if you want, but I would keep those two.
- description trimmed (~20% shorter), same four-part structure. Kept "chart, KPI, table" and "filter or date control" in the trigger surface deliberately — those phrasings are what the eval showed the previous description was losing on. - dropped the "complete layout vocabulary" claim. The list is now explicitly not exhaustive, so the skill no longer needs updating on every layout feature release; the don't-invent guardrail and the search_docs check stay, since inventing `margin`/`padding`/`gap` was a real failure. - softened the per-chart filter rule to a preference, per review. It now scopes to the actual failure — a hard-coded time window or comparison period ships empty or goes stale — and explicitly allows a filter that defines what the chart is (top 10, one segment). Also updated two places that restated the same rules: the verify step and the worked-example heading. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacks on #22, same as #23 and #24.
Replaces the
write-dashboardsystem skill with the mergedbuild_dashboardskill developed and evaluated in the staging3 workspace, and renames the slot tobuild-dashboard(surfaces to the agent asbuild_dashboard).Why
The two skills were competing. In a 64-run eval against the staging3 Copilot:
write_dashboardwon 53 of 64 runs. The staging3 skill fired 0 times on precise intermediate/complex prompts, because its description carried an anti-trigger disclaiming exactly those asks.Merging them into one skill removes the competition entirely; renaming the folder (rather than shadowing it) means there is no configuration in which both load.
What changed
Trigger. The anti-trigger is re-cut on a different axis — "is a dashboard the deliverable?" — instead of excluding facets of the dashboard job. Editing a chart/KPI/table on a dashboard and adding filters are now explicitly in scope; standalone data questions, model/dataset edits, custom chart types, and theming are out.
Shape follows the reader. All 12 underspecified eval runs opened with a KPI row and closed with a table, only the middle varying. Two causes: the input checklist named the four questions rather than asking for them, and the minimum output prescribed the KPI-row frame outright. Both are gone — the reader's job (monitoring / diagnosing / comparing / planning / looking up) is decided first, questions are derived and ranked, and the minimum is stated as a quality bar rather than a shape.
Kept from the previous version: the block-type vocabulary, the four
ref:forms, the layout constructs, and a worked example — now conforming to the skill's own prescriptions (1220 grid, TabLayout,classictheme, noFilterBlockdefault, completeinteractions).Dropped: "prefer the smallest set of blocks" (conflicts with the completeness bar),
interactionsas optional, and the standalone 107-line example that contradicted the layout conventions.Not carried over: the
@Context:viz-reuse mechanismThis feature is not available on production yet
Caveats
invocationandallow_switching_invocationhave no equivalent in SKILL.md and were dropped; the maintainer version history was dropped too, since unlike AML//comments it would be fed to the model.🤖 Generated with Claude Code