Before generating a workbook, an agent needs to decide what the dashboard is for. I tested Adam Mico's open-source Tableau Dashboard Blueprint Skill with the Antigravity CLI to explore that step.
The experiment produced a technical specification and an interactive HTML prototype. It was a design test, not proof of a completed Tableau workbook.
What the Skill helped make explicit
The design identified a sales-manager audience, a short review window, KPI hierarchy and a restrained filter set. It also described the layout and the charts that would answer the intended questions.
The technical specification included container hierarchy and calculation definitions. The HTML prototype made the proposed arrangement easier to review before implementation. In the original experiment, simulated regional filtering updated the prototype KPIs.
Those are different outputs with different purposes: the specification tells a builder what to implement; the prototype lets someone inspect the proposed experience.
Where cwtwb fits
My next-step proposal in the original post was to connect the design workflow to cwtwb. That was a plan at the time, and I am preserving that distinction here.
A useful future workflow would take an agreed specification, construct a Tableau workbook through the SDK and compare the result with the intended design. It would still need to check the real data and calculations separately from the prototype.
For Datacooper, this suggests a practical product direction: help users move from a business question to an inspectable build specification and an editable artifact. The paid MCP is planned around that broader task.
Credit and references:
Originally shared in this LinkedIn post.
Explore cwtwb on GitHub, the case replication repository and Datacooper.
Top comments (0)