insight

HISTORICAL redirect — the in-process analytics HTTP contract rig this skill documented was retired; do not use this skill to write tests. Analytics HTTP contract coverage lives in tests/stand/api/ (use stand-api-test); seeded-bronze → served-metric specs live in tests/datapath/metrics/<class>/ (use metric-test). This stub exists only so old references resolve.

Audit dbt models and connector configurations against the data-flow conventions in .cf-studio/config/rules/architecture.md. Verifies engine=ReplacingMergeTree, order_by=['unique_key'], silver delete+insert, read-time dedup of every RMT read (FINAL/QUALIFY/LIMIT 1 BY/union_by_tag), unique_key formula, bronze→RMT promotion, ephemeral usage for Rust-owned tables, and Airbyte append-only sync mode. Reports deviations with file paths and line numbers.

Create, test, validate, and deploy Insight Connectors. Supports both nocode (declarative YAML) and CDK (Python) connector types. Commands: /connector create <name>, /connector test <name>, /connector schema <name>, /connector deploy <name>, /connector validate <name>.

Drive the Insight web UI in a real browser to see, verify, explore, or capture evidence from any stand — a local compose or kind install, or a shared remote one. Use this whenever the task means LOOKING at the dashboard rather than reading its code: 'check the IC page', 'is that chart still broken', 'screenshot the metrics drilldown', 'reproduce it in the UI', 'grab evidence for a bug', 'open the stand and look at X', 'exercise every option in this screen', 'find the download limit', or any UI defect you are about to file. Read it BEFORE launching a browser at any remote stand, because the Entra-plus-passkey ones cannot be logged into from a browser you launched, and the wrong acquisition move costs the user a login they cannot complete. Also read it before reporting a wrong number as a UI defect: the data that decides it is captured here. The `playwright-cli` skill owns the commands and this skill owns getting an authenticated browser, exploring what is on screen, and capturing evidence someone can act on — it hands the issue itself to `file-bug-insight`, and `scope-feature-tests` plans coverage on paper where this drives the stand in front of you.

File an Insight defect as a GitHub issue in constructorfabric/insight — triage against existing issues, gather evidence, collect what the reproduction produced, draft a report that reads in under a minute, confirm, create, and verify the metadata landed. Prefer this over the general `file-bug` skill for anything in the Insight product — dashboards, metrics, connectors, dbt, ClickHouse, identity, the Helm install — since it carries the medallion evidence walk, the reproduction-data discipline and the live board IDs; the general skill is the router, and it owns a Constructor *platform* defect that belongs in YouTrack. It reports OBSERVATIONS ONLY — no investigation, no root-cause analysis, no naming the file or layer to fix; that is the assignee's job. Use whenever the user asks to file/report/raise/log a bug, ticket, defect or issue, and trigger PROACTIVELY once an investigation has converged on 'this is broken and should be recorded' — don't wait for the words 'file a bug'. Also fires on 'log this', 'report it', 'this is broken, make a ticket', 'turn this into an issue', 'we should file two bugs for X and Y'. The repo is PUBLIC, so the default flow is draft → confirm → create and the body must be scrubbed of internal detail.

Operate the Insight compose stand and run the deployed-stand suite in tests/stand/ — bring it up (`./dev-compose.sh test-stand up`), seed it, aim a run at it (local or remote), read what it was seeded with, and triage the failures that are the stand rather than the product. Use whenever a task means running, re-seeding, pointing, or debugging the stand: 'bring the stand up', 'run the stand tests', 'test-stand up failed', 'why did collection abort', 'UsageError: stand manifest unusable', 'these tests all skipped', 'the login loops', 'scratch rows survived the run', 'point the suite at another stand', 'what personas does the stand have'. This is the environment skill; stand-api-test and stand-ui-test own the test code, stand-scenarios owns what to test, and drive-ui owns driving a browser at a stand by hand.

Author and validate a metric spec for the data-path suite (tests/datapath/metrics/<class>/<name>.test.yaml fixture + test_<name>.py module, run against a compose test-stand instance). Use when asked to write/scaffold/validate a test for a metric, seed bronze data for a test, add a fixture for a dashboard metric, or check a spec. Covers schemas/, templates/, $ref+sibling composition, bronze records with duplicates, account bindings, POST /v1/metric-results, and the assertion helpers (row/equals/contains, one/some over a view, approx).

Drive a browser from the command line with the `playwright-cli` binary — open pages, snapshot the accessibility tree, click and type by ref, read network and console, manage sessions, cookies, storage state, tracing and video — and run or debug Node/TypeScript Playwright Test projects (`npx playwright test`, attach-to-paused-page, spec-driven plan/generate/heal). Use for interactive browser work at a prompt: exploring a page, validating a locator before committing it, inspecting element attributes, reproducing a UI bug, or debugging a `.spec.ts` run. NOT for authoring this repository's committed browser tests — this repo contains no `.spec.ts` Playwright specs at all; its browser journeys are pytest + pytest-playwright under tests/stand/ui/, run with uv, and belong to stand-ui-test. For getting an authenticated browser onto an Insight stand and capturing evidence, drive-ui owns the acquisition and this skill owns the commands.

Write the body of a pull request in constructorfabric/insight — the shape a reviewer can decide from in under 30 seconds: bold inline labels for Why / What changed / Out of scope / Verified, a bold-led line per decision the diff cannot show, screenshots for anything visual, and a word cap per block so a three-line fix does not read as a document. Use whenever a PR body is being written or rewritten: 'write the PR description', 'open a PR for this branch', 'the description is too long', 'update the PR body', or right before `gh pr create` and before marking a draft ready. Also use when reviewing someone's description for what it is missing. The repo is PUBLIC and AGENTS.md bans production-derived information from PR bodies, so every number in a description comes from a local stand, a fixture, or a test run. It owns the prose only — `file-bug-insight` owns issues, `drive-ui` owns capturing the screenshots this skill asks for.

Run an exploratory quality pass over a change that has ALREADY merged in constructorfabric/insight — research the diff, smoke it on a stand carrying that exact build, then execute a test plan across the five quality vectors (Efficiency, Reliability, Performance, Security, Versatility) and hand each surviving finding to file-bug-insight. Use for "test what just merged", "exploratory pass on #N", "check this change across the quality vectors", "we shipped X, go break it", or a QA sweep of a release candidate's new feature. NOT for planning tests before implementation (scope-feature-tests), NOT for writing the Testing section into an issue body (quality-vector-tests), NOT for validating a whole stand (insight-stand-validate), and NOT for confirming a known defect is fixed (verify-fix).

Write or revise vector-attributed tests for an Insight feature. Trace PRD FR/NFRs through the canonical FEATURE requirement references to scenarios and executable tests. Use when adding a Testing section or reviewing its vectors, test links, inherited obligations or coverage gaps; keep Acceptance Criteria in the kit's form.

Plan testing for an Insight feature: risk-ordered test groups, target suites, scope boundaries and an acceptance gate. Use when deciding QA coverage, test dimensions or a test subtask. Review agreed requirements and inspect implementation, data flow and existing tests to expose risks and specification disagreements. Keep output at test-group level; quality-vector-tests turns that scope into tracked scenarios in an issue or FEATURE artifact.

Write, fix, or review HTTP contract tests in tests/stand/api/ — the deployed-stand suite against a real gateway, real Keycloak sessions and real backend images. Covers the operation catalogue, which persona session to take, requires_seed markers, the scratch-resource policy, the hand-written vs generated response models, status-code discipline (identity 404 vs analytics 403 outside a scope, 400 vs 415 vs 422) and the endpoint coverage gate. Use when adding or changing anything under tests/stand/api/, closing a coverage-gate gap, or turning a stand-scenarios claim into an API case. For browser journeys use stand-ui-test. Seeded-bronze → served-metric specs are the data-path suite in tests/datapath/ (metric-test).

Turn docs/product/SCENARIOS.md into testable claims for the deployed-stand suite — QA scenario design for Insight. Pick a scenario (S-1…S-10), a persona (EXEC/LEAD/IC/ADMIN), an invariant (§5 rules 1-12) or an Appendix A question (A1…G4), ground it in the seeded roster, and emit claims with an oracle, a layer and a priority that stand-api-test / stand-ui-test can implement. Use when the task is deciding WHAT to test: 'what should we test for S-9', 'design e2e scenarios from the product doc', 'which product rules are unverified', 'is the IC boundary covered', 'plan coverage for the reach matrix', 'convert the scenarios doc into tests'. Not for writing test code — that is stand-api-test and stand-ui-test; for scoping tests from a GitHub issue or an unbuilt feature use scope-feature-tests instead.

Write, fix, or review the browser journeys in tests/stand/ui/ — Playwright (Python, sync API) against a deployed Insight stand with a real Keycloak sign-in. Covers the governing UI-vs-API rule and how to justify a browser test in writing, accessibility-first locators, the page-object/flows split, manifest-derived expectations, URL/deep-link validation, and real browser downloads. Use for any request to write, add, fix or review a committed browser test in this repository — 'add a Playwright test for X', 'the UI test is failing', 'turn this scenario into a browser journey', 'add a deep-link or download regression' — and for anything under tests/stand/ui/. For HTTP contract tests use stand-api-test; playwright-cli is for driving a browser interactively at a prompt and for Playwright's own CLI — reach for it only when nothing will be committed under tests/stand/ui/; drive-ui is for looking at a stand by hand.