Altinity · BorisTyshkevich · Jul 30, 2026 · Jul 30, 2026
@@ -0,0 +1 @@
+../skills
@@ -0,0 +1 @@
+../skills
@@ -0,0 +1 @@
+../skills
@@ -28,12 +28,10 @@
 /.wiki/
 
 # impeccable design skill — vendored dev tool + its local state; kept local, not in the repo
-/.claude/skills/impeccable/
+/skills/impeccable/
 /.impeccable/
-# Codex agent-skills mirror: ignore the vendored content, keep only the ship/ship-phase symlinks
-/.agents/skills/*
-!/.agents/skills/ship
-!/.agents/skills/ship-phase
+
+# .claude/skills, .codex/skills, .agents/skills are symlinks to /skills/ (checked in, see /skills/)
 
 # OS / editor
 .DS_Store

@@ -37,9 +37,13 @@ unattended mode, which has no gates but the last (see step 0).
 > mid-run. Inheriting these steps is not the same as being told to execute them. State the
 > boundary explicitly in every subagent prompt (no Edit/Write, no git/gh mutating commands, no
 > TaskCreate/TaskUpdate, no memory writes — return only the requested output), and prefer a
-> fresh non-`fork` agent for this kind of fan-out. **Steps 5–7 — reconcile, PR, and the merge
-> gate — are performed by this session only, never delegated.** After any batch of subagents
-> returns, verify with `git diff`, `git log`, and `gh pr list` before trusting a self-report.
+> fresh non-`fork` agent for this kind of fan-out. **Steps 5–8 — reconcile, PR, the post-PR
+> ChatGPT second opinion, and the merge gate — are performed by this session only, never
+> delegated.** The high-risk *plan*-stage `chatgpt-review` call in step 2
+> (`references/per-issue-cycle.md`) is different: it never touches git/gh, so a worker may run
+> it directly even in unattended mode — only the post-PR call in step 7 is session-only.
+> After any batch of subagents returns, verify with `git diff`, `git log`, and `gh pr list`
+> before trusting a self-report.
 
 ## 0 — Resolve the argument
 
@@ -52,8 +56,8 @@ unattended mode, which has no gates but the last (see step 0).
 
 Attended is always the default. **Unattended requires the literal word** — never infer it.
 
-For unattended, Read `references/unattended.md` now and follow it; it replaces steps 1, 6 and
-7 below and reuses steps 2–5 as the worker contract.
+For unattended, Read `references/unattended.md` now and follow it; it replaces steps 1, 6, 7
+and 8 below and reuses steps 2–5 as the worker contract.
 
 ## 1 — Orient, resolve the phase, set up the workspace
 
@@ -145,7 +149,25 @@ are held to — one source of truth, so the two paths cannot drift.
   final phase. Every earlier phase uses **`Part of #<ISSUE>`**.
 - Tick the checklist (gate, layers, deps, CHANGELOG, reconcile). Report the **PR URL**.
 
-## 7 — 🛑 Merge gate — STOP
+## 7 — Third-party review (ChatGPT)
+
+Invoke the `chatgpt-review` skill (`Skill` tool, `skill: "chatgpt-review"`) on the PR just
+opened in step 6, passing its number/URL as the argument. Read `chatgpt-review`'s own
+`SKILL.md` and follow it as written — it already covers gathering the diff, prompting
+ChatGPT, waiting for the full answer, and verifying every claim against the real repo before
+trusting it.
+
+- This is a **second opinion, not a gate** — a negative or contested verdict does not block
+  progress to step 8, but every claim you accept as real must be fixed here.
+- Apply real findings, commit (`fix(#<ISSUE>): address ChatGPT review feedback` or fold into
+  the PR's existing commits per the repo's amend policy), `npm test`, and `git push` before
+  moving on.
+- If `chatgpt-review` reports it couldn't reach ChatGPT (agent Chrome down, network denied),
+  don't block the ship on it — note the skip in the merge-gate summary (step 8) and continue.
+- Note what you verified vs. dismissed in the phase log / PR comment so the human at the merge
+  gate sees it, not just a silent pass.
+
+## 8 — 🛑 Merge gate — STOP
 
 Do **not** merge. Merging to `main` is a human call.
 

@@ -34,7 +34,19 @@ judge under-determined despite its acceptance criteria:
 1. **second opinion** — spawn a `Plan` subagent (`subagent_type: "Plan"`, read-only boundary
    stated) to independently stress the approach: seams, migration order, coverage strategy,
    rollback. Fold its critique into the plan;
-2. 🛑 **post the resulting plan and wait for approval** (I review on mobile).
+2. **third-party opinion** — invoke the `chatgpt-review` skill (`Skill` tool,
+   `skill: "chatgpt-review"`) on the plan itself, before any code exists. There is no diff yet,
+   so hand it the plan text plus enough issue/phase context to review cold (the phase contract,
+   the acceptance subset it claims, the files it intends to touch) and ask the same kind of
+   pointed question the skill asks of a diff: does this approach actually close the gap the
+   phase claims to close, is the seam/migration-order choice sound, is there a simpler design?
+   Open a **fresh tab** for this — never continue an earlier chatgpt.com conversation thread
+   into a new review, even though running several tabs in parallel is fine. Verify every claim
+   against the real repo (skill step 6) before folding it in — a second opinion, not a source of
+   truth, exactly like the post-PR case. Use the skill's paste-inline path, not its
+   point-at-GitHub path — this step must not post anything to GitHub, so it stays safe for a
+   worker to run directly in unattended mode too;
+3. 🛑 **post the resulting plan and wait for approval** (I review on mobile).
 
 Low-risk, well-specified work proceeds straight from the written plan with no approval gate.
 

@@ -6,7 +6,7 @@ Reached only via the literal word `unattended`:
 - `/ship 424,425,426 unattended` — several whole **issues**.
 
 Both are the same machine: a **unit** is a phase or an issue, and units run in dependency
-order. This file replaces `SKILL.md` steps 1, 6 and 7. Steps 2–5 stay exactly as written in
+order. This file replaces `SKILL.md` steps 1, 6, 7 and 8. Steps 2–5 stay exactly as written in
 `references/per-issue-cycle.md` — that is the worker contract, quoted, not paraphrased.
 
 You are the **coordinator**. You do not implement units yourself. You plan waves, spawn
@@ -69,7 +69,7 @@ The worker prompt must contain, explicitly:
 - **the mutation boundary**: Edit/Write + local `git commit` on its own branch only — **no
   push, no PR, no `gh` mutations, no issue edits, no phase-log writes, no memory writes, no
   `CHANGELOG.md` beyond its own entry, no TaskCreate/TaskUpdate**;
-- the instruction to follow `.claude/skills/ship/references/per-issue-cycle.md` steps 2–4 and
+- the instruction to follow `skills/ship/references/per-issue-cycle.md` steps 2–4 and
   the CHANGELOG part of 5 — **the phase log is yours, not the worker's**;
 - commit message `<type>(#<ISSUE>): <summary>` + the repo footer convention;
 - what to return: plan summary, files touched, test/build output tail, and the contract
@@ -107,6 +107,11 @@ agents on this repo have edited files despite an explicit report-only boundary.
 4. **One PR** (`gh pr create --base main`), body per the PR template, with one `Closes #<n>`
    line per fully completed issue (partially completed or skipped: `Part of #<n>`), a per-unit
    summary table, and the repo PR footer.
-5. 🛑 **Merge gate — the only stop.** Report: PR URL, per-unit status (shipped / skipped +
-   why), review findings applied, CI status. Do not merge.
-6. Friction → memory. The coordinator writes it, not a subagent.
+5. **Third-party review**: invoke the `chatgpt-review` skill on the PR just opened, per
+   `SKILL.md` step 7. A negative or contested verdict doesn't stop the line, but apply every
+   claim you verify as real, `npm test`, and push before continuing — this is coordinator work,
+   never delegated to a worker. If ChatGPT is unreachable, note the skip in the final report and
+   continue.
+6. 🛑 **Merge gate — the only stop.** Report: PR URL, per-unit status (shipped / skipped +
+   why), review findings applied (including the ChatGPT pass), CI status. Do not merge.
+7. Friction → memory. The coordinator writes it, not a subagent.
@@ -0,0 +1,155 @@
+---
+name: sql-browser-dashboard
+description: >
+  Build and publish Altinity SQL Browser-compatible business analytics dashboards as
+  PortableBundleV2 JSON through an Altinity MCP dynamic tool named save_dashboard.
+  Use when the user asks to create, assemble, save, publish, or share a SQL Browser
+  dashboard and the analytical SQL plus relevant result-column knowledge is already
+  available in the conversation or from another skill/tool. This skill owns Dashboard
+  composition, Presentation Specs, flow layout, bundle validation, and the final typed
+  save_dashboard call. It does not discover ClickHouse schemas, navigate databases,
+  design source data models, or execute analytical queries.
+---
+
+# SQL Browser Dashboard
+
+Create one SQL Browser Dashboard that communicates useful business insights, package it as one `PortableBundleV2`, validate it, and publish it through the Altinity MCP dynamic tool whose exact basename is `save_dashboard`.
+
+## Required boundaries
+
+- Use only already-known SQL and result-column information.
+- Do not inspect ClickHouse databases, tables, columns, or sample rows.
+- Do not call generic SQL execution tools to test or publish the Dashboard.
+- Do not invent unknown table or column names.
+- Do not use BentoClick's panel schema. Produce the SQL Browser schema described in [references/dashboard-authoring-profile.md](references/dashboard-authoring-profile.md).
+- Use the typed `save_dashboard` tool for the write. Do not fall back to `execute_query`, raw `INSERT`, HTTP, or shell clients.
+- Publish exactly one Dashboard per bundle.
+
+If the requested Dashboard lacks usable SQL or the output-column order needed by a positional chart, ask for that missing input or state that schema/query discovery must be completed outside this skill.
+
+## Load references selectively
+
+1. Read [references/dashboard-authoring-profile.md](references/dashboard-authoring-profile.md) before constructing the bundle.
+2. Read [references/panel-guide.md](references/panel-guide.md) for every panel type used.
+3. Read [references/save-dashboard-tool.md](references/save-dashboard-tool.md) immediately before publishing.
+4. Consult [references/example-dashboard.json](references/example-dashboard.json) when a complete minimal example is useful.
+5. Use [references/sql-browser-dashboard-authoring.schema.json](references/sql-browser-dashboard-authoring.schema.json) as the skill's supported authoring-profile schema. SQL Browser's production schemas remain authoritative.
+
+## Workflow
+
+### 1. Confirm the dashboard contract
+
+Determine from the conversation:
+
+- Dashboard title and business purpose.
+- Dashboard description or executive takeaway.
+- Available analytical queries.
+- Exact result-column order for `bar`, `hbar`, `line`, `area`, and `pie` panels.
+- Any ClickHouse parameters already present in SQL, written as `{name:Type}`.
+- Any supplied option-list SQL for those inferred variables.
+
+Do not restart database discovery. Ask only for data required to serialize the Dashboard correctly.
+
+### 2. Choose an insight structure
+
+Prefer a compact decision-oriented sequence:
+
+1. headline KPIs;
+2. trend or comparison;
+3. categorical breakdown;
+4. supporting detail table;
+5. optional explanatory Markdown.
+
+Avoid filling the page with redundant charts. Every tile must answer a distinct business question.
+
+### 3. Create saved queries
+
+Create one `SavedQueryV2` per distinct tile query.
+
+- Use unique, readable IDs containing only stable ASCII slug characters.
+- Preserve supplied SQL exactly except for clearly requested formatting corrections.
+- Set `specVersion` to `1`.
+- Set `spec.view` to `panel`.
+- Set `spec.name` and `spec.description` to business-readable text.
+- Set `spec.dashboard.role` to `panel`.
+- Configure only implemented panel types: `kpi`, `table`, `bar`, `hbar`, `line`, `area`, `pie`, `logs`, and `text`.
+- For chart panels, use zero-based result-column indexes. Never guess the projection order.
+- Use `fieldConfig.columns` to provide readable labels, units, decimal precision, descriptions, and missing-value text.
+
+Do not add unused Library queries. The bundle's query array must equal the Dashboard's exact query dependency closure.
+
+### 4. Create the Dashboard document
+
+Create one `DashboardDocumentV2`:
+
+- `documentVersion`: `2`.
+- `id`: stable dashboard slug, reused as the catalogue identity.
+- `title`: user-visible title.
+- `description`: concise purpose and intended audience.
+- `revision`: `1` for a newly authored Dashboard.
+- `tiles`: one tile per visual instance, in semantic reading order.
+- `layout`: `flow@1` using `report`, `columns-2`, or `columns-3`.
+- `variableConfigs`: include only supplied option SQL keyed by exact case-sensitive inferred variable name.
+
+Tile `queryId` values must resolve to bundled queries. Layout item keys must resolve to tile IDs.
+
+### 5. Create the portable bundle
+
+Create a top-level object with:
+
+- `$schema`: the SQL Browser PortableBundleV2 schema identifier;
+- `format`: `altinity-sql-browser/portable-bundle`;
+- `version`: `2`;
+- `exportedAt`: current RFC 3339 timestamp;
+- `metadata.name` and optional `metadata.description`;
+- `queries`: exact dependency closure;
+- `dashboards`: an array containing exactly one Dashboard.
+
+Never include credentials, hosts, session data, query results, caches, runtime variable values, tabs, drafts, or unrelated queries.
+
+### 6. Validate before publishing
+
+When code execution is available, write the candidate bundle to a temporary JSON file and run:
+
+```bash
+python scripts/validate_bundle.py candidate.json
+```
+
+Fix every reported error. The validator checks the supported authoring profile and important cross-resource semantics. It does not replace SQL Browser's production decoder.
+
+Without code execution, manually apply the checklist in [references/dashboard-authoring-profile.md](references/dashboard-authoring-profile.md).
+
+### 7. Publish once
+
+Locate the connected MCP tool whose exact basename is `save_dashboard`. Call it with one argument:
+
+```text
+payload = JSON-encoded PortableBundleV2
+```
+
+Call it only after the full bundle is complete and validated. Do not make one call per query or tile.
+
+Do not automatically retry after a timeout, transport interruption, or ambiguous MCP error because the insert may have committed. Ask the user to verify catalogue state before attempting another save.
+
+### 8. Report the result
+
+On confirmed success, report:
+
+- Dashboard title;
+- Dashboard ID;
+- query count;
+- tile count;
+- that it was published to the SQL Browser Dashboard catalogue.
+
+Do not claim a generated server version unless the tool response explicitly returns it.
+
+## Quality rules
+
+- Optimize for business comprehension, not feature demonstration.
+- Put the most decision-relevant information first.
+- Keep titles short and descriptions specific.
+- Use consistent units and precision.
+- Avoid pie charts for numerous categories or values requiring close comparison.
+- Prefer line/area for ordered time, bar/hbar for category comparison, KPI for a small one-row summary, and table for exact detail.
+- Keep Dashboard variables few, predictable, and directly useful.
+- Never publish a structurally invalid bundle merely to let the browser diagnose it later.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "SQL Browser Dashboard"
+  short_description: "Build and publish SQL Browser business dashboards"
+  brand_color: "#4F8CFF"