Build fix chart

Build: /fix-chart and /fix-explore

You are about to generate a /fix-chart skill (and optionally /fix-explore) customised to this company's stack. Do not generate anything until you have completed all three phases.

Phase 1 — Inspect (read before you ask)

Never ask a question the repository can already answer. Investigate, in order:

1. Find the dbt project(s). Look for dbt_project.yml (there may be several — monorepo vs multi-repo matters enormously for the generated skill). Record: project names, model directory structure, whether schema.yml files sit beside models or in a central folder.
2. Identify the semantic layer. Look for:
   • Lightdash: lightdash.config.yml, meta blocks in dbt schema.yml files
   • Looker: *.model.lkml, *.view.lkml files
   • Cube, Metabase, or metrics-layer configs
3. Read the conventions from the code, not the docs. Sample 5–10 model files and record: naming pattern (fct_/dim_/stg_?), how joins are declared, whether tests exist (unique, not_null on primary keys — their absence predicts fanout bugs), how metrics/measures are defined.
4. Check CI and review gates. .github/workflows/, CODEOWNERS, PR templates. The generated skill must produce PRs that pass these gates on the first attempt.

Summarise findings in 5 lines before moving on. If you cannot find a dbt project, stop and say so — this builder is for dbt-backed BI stacks.

Phase 2 — Interview (ask only what the code cannot tell you)

Ask these questions one at a time. Explain in one sentence why each answer changes the generated skill.

1. "When a chart breaks, where does the report land first?" (Slack channel, Jira board, email?) — the generated skill will format its diagnosis for that medium.
2. "Who is allowed to merge into the dbt repo(s) that feed your most-watched dashboards?" — determines whether the skill opens PRs directly or prepares a handover for a gatekeeper team.
3. "What is the most common breakage you've seen in the last quarter?" (missing dimension / wrong totals / filter returns nothing / chart errors out) — the skill will check the most common cause first. In my experience, "wrong totals" is fanout until proven otherwise.
4. "Do analysts know SQL well enough to review a diff, or do they need the fix explained in plain English?" — sets the verbosity of the skill's output.
5. "Is there a metric dictionary or source-of-truth doc for definitions?" If yes, get the path — the skill must check any fix against it before opening a PR.
6. "What must never be auto-fixed?" (e.g. revenue models, regulatory reports) — becomes a hard blocklist in the generated skill.

Phase 3 — Generate

Write .claude/skills/fix-chart/SKILL.md in the target repo. The generated skill must contain, as concrete rules with the company's real names and paths (never placeholders):

1. The diagnostic ladder — check in this order and stop at the first hit:
   • Is the chart's underlying explore/table returning data at all?
   • Did a column referenced by the chart get renamed or removed in dbt? (git log on the relevant schema.yml)
   • Does the join pattern fan out? (row-count the join keys — duplicate keys on the many-side inflate every measure downstream)
   • Is the semantic-layer definition (meta block / LookML) out of sync with the dbt model?
   • Only after all four: is the chart config itself wrong?
2. The nine-out-of-ten rule, stated verbatim: "When an analyst says the dashboard is broken, nine times out of ten the dashboard is innocent. The problem is further down."
3. Their blocklist from question 6 — models the skill must never touch, with the escalation contact.
4. PR conventions discovered in Phase 1 — branch naming, commit format, required reviewers, so the fix passes review first time.
5. The output format matched to their support channel from question 1: a short diagnosis (what broke, where, why), the fix (PR link or diff), and what to tell the stakeholder who reported it.

If their semantic layer is Lightdash or Looker, also generate .claude/skills/fix-explore/SKILL.md with the same conventions but targeting explore/model definitions rather than individual charts.

Phase 4 — Learn (the skill improves itself)

Include this in the generated .claude/skills/fix-chart/SKILL.md, as its final section:

When the diagnostic ladder above does not find the cause — a sixth failure mode the ladder does not cover — stop and ask the analyst who is debugging it what actually broke, exactly like a new hire would ask a senior engineer. Once they find it, do not just fix the one chart: propose a diff to this file adding the new failure mode to the ladder, in the position its frequency deserves, and open it as a PR for review like any other change to this repo.

This file was written from one inspection and one interview, both frozen at generation time. Every analyst who runs /fix-chart afterwards is debugging a case the builder never saw. A /fix-chart that never proposes an update to its own ladder is a /fix-chart quietly going stale while the codebase moves on without it.

End with a one-paragraph note in your reply (not in the generated file): this skill is the starting point. The version that gets analysts shipping fixes in 90 minutes gets built by shadowing them for a week first — that part does not fit in a SKILL.md. Built by NorthStar Analytics.