Menu
Publish, revise, inspect, export, and troubleshoot DataClaw artifacts. Use when a report, dashboard, chart, profile, model card, or living-report note should become a secure, versioned, shareable artifact through dataclaw-artifacts.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Author and publish bespoke analytical reports from validated findings, bounded aggregate evidence, methodology, caveats, and an evidence ledger. Use for final reports, report-like dashboards, interactive analytical briefings, or redesigning existing report HTML; the creative author owns all unspecified story, prose, layout, and visual decisions.
Use Dataclaw tools for governed data science and analytics work. Includes tools for interacting with data, running jupyter notebooks, proposing, updating and reviewing analytical plans, experiment tracking, training machine learning models, and generating reports.
Estimate and defend causal effects inside the Dataclaw data-science workflow by choosing an identification strategy, stating the estimand, testing design-specific assumptions, quantifying uncertainty, and refusing unsupported causal claims. Use for impact analysis, policy or treatment effects, difference-in-differences, matching or weighting, instrumental variables, regression discontinuity, synthetic controls, interrupted time series, mediation questions, and observational “does X cause Y?” requests.
Design, analyze, or audit randomized experiments inside the Dataclaw data-science workflow with a defensible randomization unit, power and duration, pre-registered outcomes, assignment and exposure checks, sequential and multiplicity control, and uncertainty at the assignment level. Use for A/B and multivariate tests, cluster or geo experiments, switchbacks, holdouts, factorial designs, non-inferiority, uplift and heterogeneous-treatment analyses, experiment readouts, and sample-size planning.
Build reproducible, leakage-safe model inputs inside the Dataclaw data-science workflow by defining prediction-time availability, excluding identifiers, fitting transforms within folds, cross-fitting target-derived features, handling temporal and grouped data correctly, and versioning feature lineage. Use for tabular, temporal, categorical, text, geospatial, nested, interaction, aggregation, embedding, selection, and dimensionality-reduction features used by predictive, forecasting, causal, uplift, or segmentation models.
Build, evaluate, calibrate, and operationalize supervised prediction models inside the Dataclaw data-science workflow with leakage-safe validation, decision-aligned metrics and thresholds, honest baselines, subgroup and shift checks, uncertainty, and deployment monitoring. Use for classification, regression, ranking, propensity or risk scores, churn and fraud prediction, lead scoring, probability calibration, model comparison, model cards, and audits of existing predictive systems.
| name | artifacts |
| description | Publish, revise, inspect, export, and troubleshoot DataClaw artifacts. Use when a report, dashboard, chart, profile, model card, or living-report note should become a secure, versioned, shareable artifact through dataclaw-artifacts. |
| tags | ["artifacts","reporting","dashboards","visualization","publishing"] |
Related skills: report_design (composes the report this skill publishes).
Use this skill whenever the final visual or written deliverable should be a DataClaw artifact: reports, dashboards, chart pages, data profile reports, model cards, stakeholder exports, and living-report notes.
This skill owns artifact lifecycle behavior. For content and layout, also fetch:
report_design for final report authorship, evidence review, and quality gatesvisualization only when analysis-time charting or evidence preparation is neededstructured_eda, sql_analyst, or a modeling playbook such as
predictive_modeling when the artifact is evidence from those workflowsThe notebook computes, report_design authors, and artifacts publish. Do not leave the
final deliverable as a loose workspace HTML file, App-panel state, long chat
answer, or raw chart collection.
The durable UI surface is the inline published-artifact card plus the right
panel Artifact Library/living report. Treat /app/:sessionId as a legacy
compatibility scratch view for loose visual outputs, not as a final handoff.
The handcrafted report author may create a report-specific visual system. Do not retrofit its output to a fixed component library. Preserve the required host contrast tokens, evidence metadata, CSP, safety constraints, and receipt.
Use publish_artifact for a standalone report, dashboard, chart page, profile,
or model card. Use report_note for interpretation, decisions, rationale, and
course changes in the living report. Pass plan_step_id when available; names
are display labels. A major published artifact should also be linked or
summarized in the living report.
For EDA findings, record_eda_finding is the living-report entry. Do not add a
separate report_note for the same finding just to satisfy the living-report
habit; use report_note only for non-EDA interpretation, decisions, rationale,
and course changes that are not already captured by the EDA ledger.
Use the canonical tool names in this skill: publish_artifact,
read_artifact, list_artifacts, export_artifact, delete_artifact, and
report_note. If the runtime exposes only plugin-prefixed aliases such as
dataclaw_publish_artifact, use the visible alias with the same arguments.
If artifact tools are unavailable, still build the canonical workspace HTML
source and report that artifact publication is unavailable. Do not claim an
artifact_id, version, URL, export, or living-report note that did not happen.
source_path over inline html.
The source should be self-contained authored or typed report HTML that has
passed the appropriate report flow.report_publish(report_path=..., storyboard_path=...) and inspect its
receipt, quality, and runtime-smoke result. Then check for remote assets,
iframe/object/embed/base tags, raw datasets, fetch/XHR/WebSocket calls, inline
event handlers, and oversized
published/exported payloads. Fix obvious issues before calling the tool.publish_artifact(title, description?, source_path?, html?, report_receipt_path?, artifact_id?, label?, base_version?)
with exactly one of source_path or html. For report-builder HTML (typed
section metadata), pass the receipt_path returned by report_publish or
keep its default sibling <report>.publish.json; publication verifies the
receipt against the exact HTML bytes and rejects stale or analytically blocked
reports.{artifact_id, version, session_id, url}.
Mention the artifact title and version briefly; the UI renders the same
version inline and in the Artifact Library.When the user asks for a change to an existing artifact:
read_artifact(artifact_id, version?).report_design_report; do not edit
generated HTML as the source of truth. For a generic non-report artifact,
make the smallest safe source edit.report_publish for report-builder HTML, then call
publish_artifact with the same artifact_id and the base_version
you edited from.Do not create a new artifact for normal revisions of the same report/dashboard.
When the user asks for an export, call
export_artifact(artifact_id, version?). Expect a result with
download_url, filename, and bytes; do not fabricate export links. Artifact
open/source/export/delete operations are session-scoped, so use the current
session context and do not copy an artifact id into another session's handoff.
Artifacts are hostile-content-safe by default. Follow these rules:
script src, link href, or remote img src.../ paths to reach outside the
report's workspace.<iframe>, <object>, <embed>, or <base>.onclick; use addEventListener.window.open, location = ...,
location.assign(...), or location.replace(...).<a href> links may exist, but artifact runtime must escape
them through the parent/open-in-tab affordance; do not attach custom link
handlers.If validation fails, fix once and retry. If it fails again, surface the machine-readable error to the user instead of silently looping.
publish_artifact(
title="Customer Retention Dashboard",
description="KPI and segment-level view of repeat purchase behavior.",
source_path="reports/customer-retention.html",
label="initial-dashboard",
)
current = read_artifact(artifact_id="art-3f9c21ab")
# edit the canonical source path, then:
publish_artifact(
title="Customer Retention Dashboard",
source_path="reports/customer-retention.html",
artifact_id="art-3f9c21ab",
base_version=current["version"],
label="heatmap-revision",
)
Use report_note(page, markdown, plan_step_id?) for interpretation, rationale,
direction changes, or decisions that hooks cannot infer.
Good notes are short and evidence-linked:
If only a step name is available, include it as human context and do not invent a step id. Living-report attribution should travel by id, not by name.
Use the right panel to inspect artifact library state, versions, and living report status. Use chat/tool calls to publish, revise, delete, export, or add living-report notes.
Before closing an artifact-producing step:
artifact_id are known