@overscore/cli 0.11.12 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/templates/analysis/.claude/CLAUDE.md +4 -3
- package/templates/analysis/.claude/rules/report-components.md +6 -2
- package/templates/analysis/.claude/rules/report-html.md +32 -19
- package/templates/analysis/.claude/skills/customize-aesthetic/SKILL.md +57 -0
- package/templates/analysis/.claude/skills/start-analysis/SKILL.md +4 -7
- package/templates/analysis/.claude/skills/start-analysis/interview-template.md +6 -2
- package/templates/analysis/report.html +5 -2
package/package.json
CHANGED
|
@@ -99,7 +99,7 @@ npx @overscore/cli analysis publish
|
|
|
99
99
|
|
|
100
100
|
This uploads `report.html` and the entire bundle (this CLAUDE.md, `analysis-log.md`, the `.claude/` tree, etc.) to Overscore. The analysis becomes available at `https://<project>.overscore.dev/analysis/{{SLUG}}`. Re-publishing overwrites the previous version. **Always preview `report.html` in a browser and get the user's approval before publishing.**
|
|
101
101
|
|
|
102
|
-
|
|
102
|
+
**Immediately after the publish command exits successfully and you've shared the link**, invoke the **`save-knowledge`** skill. This is mandatory, not optional. Do not wait for the user to ask "save what we learned" — the debrief always runs after a successful publish. If nothing new came up this session, the skill will say so in one line and you're done.
|
|
103
103
|
|
|
104
104
|
## When the user wants to turn this into a dashboard
|
|
105
105
|
|
|
@@ -110,7 +110,8 @@ Analyses are static. If the user asks to "make this a real dashboard" or "turn t
|
|
|
110
110
|
The following files in `.claude/rules/` load automatically when you touch matching files — you don't need to read them now:
|
|
111
111
|
|
|
112
112
|
- **`sql-style.md`** — BigQuery dialect and SQL formatting (loads when editing SQL or `analysis-log.md`)
|
|
113
|
-
- **`report-html.md`** — Self-contained HTML rules
|
|
114
|
-
- **`report-components.md`** —
|
|
113
|
+
- **`report-html.md`** — Self-contained HTML rules (theme-agnostic) (loads when editing `report.html`)
|
|
114
|
+
- **`report-components.md`** — Optional copy-paste snippets in Overscore's dark theme; skip if your aesthetic differs (loads when editing `report.html`)
|
|
115
115
|
- **`analysis-methodology.md`** — Investigation loop, when to ask vs query (loads when editing `analysis-log.md`)
|
|
116
|
+
- **`.claude/skills/customize-aesthetic/SKILL.md`** — drives intentional aesthetic choices for the report
|
|
116
117
|
- **`knowledge/INDEX.md`** — Project knowledge base catalog (auto-loaded every session via @import above)
|
|
@@ -3,9 +3,13 @@ paths:
|
|
|
3
3
|
- "report.html"
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Report components —
|
|
6
|
+
# Report components — optional starter snippets
|
|
7
7
|
|
|
8
|
-
These are ready-made HTML/CSS/SVG components for `report.html
|
|
8
|
+
These are ready-made HTML/CSS/SVG components for `report.html` in **one specific aesthetic** — Overscore's dark theme (near-black background, white text, violet/blue/emerald/amber accents). They're useful when you want polished components fast and the analysis aesthetic happens to match.
|
|
9
|
+
|
|
10
|
+
**This file is not the rule for how reports should look.** If the analysis is going in a different direction (editorial print, high-contrast light, warm earth tones, terminal-dense, brand-matched, etc.), skip this file entirely — write components from scratch following the structural and information-design rules in `report-html.md` and `data-viz.md`.
|
|
11
|
+
|
|
12
|
+
Run the `customize-aesthetic` skill to pick a distinctive direction before writing the report. If that direction matches dark/violet, the snippets below give you a head start. Otherwise, they're just one example of how the parts can fit together.
|
|
9
13
|
|
|
10
14
|
---
|
|
11
15
|
|
|
@@ -9,21 +9,23 @@ paths:
|
|
|
9
9
|
|
|
10
10
|
## Hard rules
|
|
11
11
|
|
|
12
|
-
- **Inline all CSS.** No `<link rel="stylesheet">`, no Tailwind CDN, no Google Fonts. Use a single `<style>` block in the `<head>`.
|
|
12
|
+
- **Inline all CSS.** No `<link rel="stylesheet">`, no Tailwind CDN, no Google Fonts (or use a `data:` URI / system stack). Use a single `<style>` block in the `<head>`.
|
|
13
13
|
- **Bake the data into the HTML.** No `fetch()`, no `XMLHttpRequest`, no API calls. The numbers must be visible to anyone who opens the file with no logins, no tokens, no broken external dependencies.
|
|
14
14
|
- **Charts are inline.** Inline SVG is the safest option. Embedded base64 PNGs are OK. A self-contained chart library (Recharts/D3 from CDN) is acceptable **only if the data is already baked into the page** and the script tag is inline-loaded — but inline SVG is preferred because it survives indefinitely.
|
|
15
15
|
- **No `useQuery`, no `@overscore/client`, no React.** This is a static HTML file, not a React app.
|
|
16
16
|
|
|
17
|
-
##
|
|
17
|
+
## Aesthetic direction
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
This file does **not** prescribe a visual style. Pick one intentionally with the `customize-aesthetic` skill — analyses are share-once artifacts where distinctive design matters more than consistency.
|
|
20
20
|
|
|
21
|
-
|
|
22
|
-
- **
|
|
23
|
-
- **
|
|
24
|
-
- **
|
|
25
|
-
|
|
26
|
-
-
|
|
21
|
+
A polished report commits to:
|
|
22
|
+
- **A tone** (editorial print, high-contrast minimal, warm earth tones, terminal-dense, etc.)
|
|
23
|
+
- **Typography** (a specific display face + body face — not "system-ui" by default)
|
|
24
|
+
- **A palette** (named hex codes, one or two saturated accents, the rest muted)
|
|
25
|
+
|
|
26
|
+
If `this-analysis.md` has a `## Visual style` section, use it. Otherwise, run the `customize-aesthetic` skill before writing the report skeleton.
|
|
27
|
+
|
|
28
|
+
Avoid the AI default: `#0a0a0f` background, `rgba(255,255,255,0.6)` text, violet/blue accents on glassmorphic cards. It's recognizable as "generated."
|
|
27
29
|
|
|
28
30
|
## Structure
|
|
29
31
|
|
|
@@ -48,38 +50,49 @@ A good analysis report has these sections in order:
|
|
|
48
50
|
<title>The headline finding goes here</title>
|
|
49
51
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
50
52
|
<style>
|
|
53
|
+
:root {
|
|
54
|
+
/* Replace with palette from this-analysis.md ## Visual style */
|
|
55
|
+
--bg: #fafaf7;
|
|
56
|
+
--fg: #1a1a1a;
|
|
57
|
+
--muted: rgba(26,26,26,0.55);
|
|
58
|
+
--subtle: rgba(26,26,26,0.08);
|
|
59
|
+
--accent: #3a3a3a;
|
|
60
|
+
--card: rgba(0,0,0,0.02);
|
|
61
|
+
}
|
|
51
62
|
body {
|
|
52
|
-
background:
|
|
53
|
-
color:
|
|
54
|
-
font-family: -
|
|
63
|
+
background: var(--bg);
|
|
64
|
+
color: var(--fg);
|
|
65
|
+
font-family: ui-serif, Georgia, serif; /* Replace with your chosen face */
|
|
55
66
|
max-width: 900px;
|
|
56
67
|
margin: 0 auto;
|
|
57
68
|
padding: 4rem 2rem;
|
|
58
69
|
line-height: 1.6;
|
|
59
70
|
}
|
|
60
71
|
.card {
|
|
61
|
-
background:
|
|
62
|
-
border: 1px solid
|
|
63
|
-
border-radius:
|
|
72
|
+
background: var(--card);
|
|
73
|
+
border: 1px solid var(--subtle);
|
|
74
|
+
border-radius: 12px;
|
|
64
75
|
padding: 1.5rem;
|
|
65
76
|
margin: 1.5rem 0;
|
|
66
77
|
}
|
|
67
|
-
.kpi { font-size: 2.5rem; font-weight: 600; }
|
|
68
|
-
.label { color:
|
|
78
|
+
.kpi { font-size: 2.5rem; font-weight: 600; font-feature-settings: "tnum"; }
|
|
79
|
+
.label { color: var(--muted); font-size: 0.875rem; text-transform: uppercase; letter-spacing: 0.05em; }
|
|
69
80
|
h1, h2, h3 { font-weight: 600; }
|
|
70
81
|
h1 { font-size: 2rem; margin-bottom: 0.5rem; }
|
|
71
|
-
.footer { margin-top: 4rem; color:
|
|
82
|
+
.footer { margin-top: 4rem; color: var(--muted); font-size: 0.75rem; }
|
|
72
83
|
</style>
|
|
73
84
|
</head>
|
|
74
85
|
<body>
|
|
75
86
|
<h1>Headline finding here</h1>
|
|
76
|
-
<p style="color:
|
|
87
|
+
<p style="color: var(--muted);">Executive summary in 2-3 sentences.</p>
|
|
77
88
|
<!-- KPI cards, charts, conclusions, etc. -->
|
|
78
89
|
<div class="footer">Generated YYYY-MM-DD · {{TITLE}}</div>
|
|
79
90
|
</body>
|
|
80
91
|
</html>
|
|
81
92
|
```
|
|
82
93
|
|
|
94
|
+
The CSS variables are placeholders — replace them with the palette and fonts from `this-analysis.md`. The skeleton above is in a neutral editorial direction; pick what fits the analysis.
|
|
95
|
+
|
|
83
96
|
**Mobile responsiveness.** Reports are often opened on phones from Slack links. The skeleton's `max-width: 900px` and viewport meta tag handle the basics, but also:
|
|
84
97
|
- Use `clamp()` or media queries for KPI font sizes (`font-size: clamp(1.5rem, 5vw, 2.5rem)`) so they don't overflow on 375px screens.
|
|
85
98
|
- KPI card grids should wrap: `display: grid; grid-template-columns: repeat(auto-fit, minmax(140px, 1fr))`.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: customize-aesthetic
|
|
3
|
+
description: Drives intentional visual design choices for an Overscore analysis report. Use when the user wants a custom look, says "redesign this", "change the theme", "make it [adjective]", or when the start-analysis interview reaches the aesthetic step.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Customize aesthetic
|
|
7
|
+
|
|
8
|
+
Most AI-generated reports look the same — dark with violet accents, system fonts, glassmorphic cards, generic everything. Resist that default. A report that gets reopened weeks later commits to a specific aesthetic direction.
|
|
9
|
+
|
|
10
|
+
## When to invoke
|
|
11
|
+
|
|
12
|
+
- The user asks to "redesign", "restyle", "make it [adjective]", or says they don't like the current look
|
|
13
|
+
- The `start-analysis` interview has reached the aesthetic step
|
|
14
|
+
- The user describes a tone, brand, or reference ("like a McKinsey deck", "newspaper feel", "warm earth tones")
|
|
15
|
+
|
|
16
|
+
## What this skill does NOT change
|
|
17
|
+
|
|
18
|
+
The data visualization rules in `.claude/rules/data-viz.md` apply regardless of aesthetic:
|
|
19
|
+
- No pie charts, no 3D, no dual y-axes
|
|
20
|
+
- KPI cards with comparisons (green up, red down)
|
|
21
|
+
- 5-9 components max
|
|
22
|
+
- Bars start at zero
|
|
23
|
+
- Mobile-responsive at 375px
|
|
24
|
+
|
|
25
|
+
The report structural rules in `.claude/rules/report-html.md` also stand: inline CSS, baked data, no network calls, self-contained.
|
|
26
|
+
|
|
27
|
+
Aesthetic is the *visual treatment* — typography, palette, density, surface treatment. The *information design* and the *technical envelope* are both settled.
|
|
28
|
+
|
|
29
|
+
## How to choose a direction
|
|
30
|
+
|
|
31
|
+
Before changing any code, get clear answers to three things:
|
|
32
|
+
|
|
33
|
+
1. **Tone in one phrase** — "editorial print", "high-contrast minimal", "warm earth tones", "brutalist data", "Bloomberg terminal", "Notion clean", "Stripe modern". One phrase, not a list of adjectives.
|
|
34
|
+
2. **Typography** — serif/sans/mono? Display face? Body weight? Numbers in tabular figures? Don't accept "Inter" as an answer — that's the default that produces same-looking output. If the user shrugs, suggest a specific face that fits the tone (e.g., Söhne Mono for terminal, Fraunces for editorial).
|
|
35
|
+
3. **Palette** — one or two saturated accents, the rest muted. Pick *named* colors (paper white #fafaf7, ink charcoal #1a1a1a, terracotta #c45a3e) so they read as a system, not as defaults.
|
|
36
|
+
|
|
37
|
+
If the user can't answer, suggest 2-3 distinct directions with a one-line characterization each. Pick one before writing code.
|
|
38
|
+
|
|
39
|
+
## Common failure modes
|
|
40
|
+
|
|
41
|
+
- Reaching for `#0a0a0f` + white text as a "neutral" default — that's the AI default with the brand stripped off, not a distinct aesthetic
|
|
42
|
+
- Mixing two directions ("modern but also editorial") — pick one
|
|
43
|
+
- Adding glassmorphic blur and backdrop filters by default — that's 2023 SaaS, not a choice
|
|
44
|
+
|
|
45
|
+
## After picking a direction
|
|
46
|
+
|
|
47
|
+
Write the aesthetic decision to `this-analysis.md` under a `## Visual style` heading. Include:
|
|
48
|
+
- The tone phrase
|
|
49
|
+
- The typography choice (font families, key sizes)
|
|
50
|
+
- The palette (with hex codes)
|
|
51
|
+
- Any density and surface rules (spacing, borders)
|
|
52
|
+
|
|
53
|
+
This keeps future sessions consistent without re-deciding the same choices.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
Inspired by Anthropic's `frontend-design` skill (github.com/anthropics/claude-code, MIT-licensed) — adapted for Overscore's analysis report context.
|
|
@@ -1,11 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: start-analysis
|
|
3
3
|
description: Interviews the user before querying data at the start of a new Overscore analysis. Captures the real question, known tables, success criteria, hypotheses, time window, and data quirks, then writes this-analysis.md and proposes a query plan for approval. Use when this-analysis.md is empty, or when the user says "investigate", "look into", or "analyze" something for the first time.
|
|
4
|
-
allowed-tools:
|
|
5
|
-
- Read
|
|
6
|
-
- Write
|
|
7
|
-
- Edit
|
|
8
|
-
- Bash(npx @overscore/cli query run *)
|
|
9
4
|
---
|
|
10
5
|
|
|
11
6
|
# Starting an analysis the right way
|
|
@@ -22,7 +17,7 @@ This skill exists to make sure that conversation happens before any SQL runs.
|
|
|
22
17
|
|
|
23
18
|
Do NOT invoke this on a re-pull of an existing analysis with prior queries logged — that's a continuation, not a fresh start, and the prior log already has the context.
|
|
24
19
|
|
|
25
|
-
## The interview —
|
|
20
|
+
## The interview — 7 questions, 2 minutes
|
|
26
21
|
|
|
27
22
|
Read `interview-template.md` for the literal prompts. The interview covers:
|
|
28
23
|
|
|
@@ -32,8 +27,9 @@ Read `interview-template.md` for the literal prompts. The interview covers:
|
|
|
32
27
|
4. **Hypotheses** — ask the user for 1-3 things they suspect might be true. Even rough hypotheses give you a query plan to test against.
|
|
33
28
|
5. **Time window and filters** — ask what time range, what cohort, what to include/exclude. These are the most common sources of wasted queries when wrong.
|
|
34
29
|
6. **Anything else weird** — ask "is there anything I should know about this data?" Users usually surface 1-2 known quirks ("dates before 2024 are unreliable," "we have a test_user flag we exclude").
|
|
30
|
+
7. **Aesthetic direction for the final report** — ask if they have a tone in mind (editorial print, high-contrast minimal, warm earth tones, terminal-dense, brand-matched) or want you to pick one. Distinctive design matters more on share-once reports than on internal dashboards. If they name a direction, invoke the `customize-aesthetic` skill when you start `report.html`. If they're open, pick one yourself before writing the report — don't default to the AI dark+violet look.
|
|
35
31
|
|
|
36
|
-
Ask these one or two at a time conversationally — don't dump all
|
|
32
|
+
Ask these one or two at a time conversationally — don't dump all 7 at once like a form. The user will respond more openly to a real conversation.
|
|
37
33
|
|
|
38
34
|
## After the interview
|
|
39
35
|
|
|
@@ -47,6 +43,7 @@ Ask these one or two at a time conversationally — don't dump all 6 at once lik
|
|
|
47
43
|
- **Success Criteria** — quote the user on what "done" looks like
|
|
48
44
|
- **Time Window & Filters** — the date range, cohort, what to include/exclude
|
|
49
45
|
- **Known Quirks** — anything about the data the user flagged upfront
|
|
46
|
+
- **Visual style** (if the user named an aesthetic direction): tone phrase, typography, palette with hex codes. See the `customize-aesthetic` skill. Skip if not specified yet — fill in when you start the report.
|
|
50
47
|
|
|
51
48
|
This is the context file that loads automatically every future session. Don't skip it.
|
|
52
49
|
|
|
@@ -24,8 +24,12 @@ These are the literal questions to ask the user during the start-analysis interv
|
|
|
24
24
|
|
|
25
25
|
## 6. Anything weird about this data
|
|
26
26
|
|
|
27
|
-
>
|
|
27
|
+
> Is there anything about this data I should know upfront? Quirks, known issues, things that look suspicious but are actually fine, conventions you use? Those are the things that bite if I find out about them three queries in instead of right now.
|
|
28
|
+
|
|
29
|
+
## 7. Aesthetic direction for the report
|
|
30
|
+
|
|
31
|
+
> Last one — when we eventually write the report, any tone in mind? Examples: editorial print, high-contrast minimal, warm earth tones, terminal-dense, your company brand. If you have a reference (a deck, a blog post, an article you liked the look of), tell me. Or just say "pick one for me" and I'll commit to a distinctive direction. (We don't default to the generic AI dark-with-violet look — it reads as "generated.") You can answer this now or when we start the report; either is fine.
|
|
28
32
|
|
|
29
33
|
---
|
|
30
34
|
|
|
31
|
-
After all
|
|
35
|
+
After all 7 answers, summarize back what you heard and ask the user to confirm. Then write the initial entry in `analysis-log.md` and propose the query plan. If the user named an aesthetic direction, note it in `this-analysis.md` so it's ready when you start `report.html` (the `customize-aesthetic` skill will fire then).
|
|
@@ -5,9 +5,12 @@
|
|
|
5
5
|
<title>{{TITLE}}</title>
|
|
6
6
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
7
7
|
<style>
|
|
8
|
-
|
|
8
|
+
/* Starter — replace with the palette and fonts from this-analysis.md ## Visual style.
|
|
9
|
+
Don't default to the AI look (dark + violet + glassmorphic). Pick a distinctive
|
|
10
|
+
direction first; see the customize-aesthetic skill. */
|
|
11
|
+
body { font-family: ui-sans-serif, system-ui, sans-serif; padding: 4rem 2rem; max-width: 800px; margin: 0 auto; line-height: 1.6; }
|
|
9
12
|
h1 { font-weight: 600; }
|
|
10
|
-
p { color:
|
|
13
|
+
p { color: #555; }
|
|
11
14
|
</style>
|
|
12
15
|
</head>
|
|
13
16
|
<body>
|