# Studio HTML Report

> Studio / GTM reports are interactive Three.js UIs opened with open_preview (UI, not PDF). Expert Review / Security / Debug stay a self-contained HTML file in File Preview (no JavaScript). Use after RiskLens, SEO, Marketing, Leads, Ads, Montage, Meeting, Scraping, Review, Security, or Debug.

- Skill: `navinspire-ia/studio-html-report` (Agent Skill)
- Install (CLI): `npx skillmds@latest add navinspire-ia/studio-html-report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/navinspire-ia/studio-html-report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: Navinspire-ia (https://skillmd.com/u/navinspire-ia)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/navinspire-ia/studio-html-report

---


# Studio / expert HTML report

Two tracks. Pick the one that matches the mission. Never put Three.js on a
PPT or Word page.

## File naming

| Mission | Report file / app |
|---|---|
| RiskLens | `risklens-report-[YYYYMMDD-HHMMSS]` |
| SEO | `seo-report-[YYYYMMDD-HHMMSS]` |
| Marketing (`/campaign`) | `marketing-report-[YYYYMMDD-HHMMSS]` |
| Montage | `montage-report-[YYYYMMDD-HHMMSS]` |
| Ads | `ads-report-[YYYYMMDD-HHMMSS]` |
| Leads | `leads-report-[YYYYMMDD-HHMMSS]` |
| Scraping | `scrape-report-[YYYYMMDD-HHMMSS]` |
| Meeting | `meeting-report-[YYYYMMDD-HHMMSS]` |
| Review (`/inspect`) | `review-report-[YYYYMMDD-HHMMSS].html` |
| Security (`/fortify`) | `security-report-[YYYYMMDD-HHMMSS].html` |
| Debug (`/debug`) | `debug-report-[YYYYMMDD-HHMMSS].html` |

Also keep working files in native formats next to it when useful: `.md`, `.csv`,
`.xlsx`, `.json`, images, etc. The report is the **summary surface**, not a
replacement for data files.

---

## Track A - Studio / GTM UI (convert UI, not PDF)

Missions: RiskLens, SEO, Marketing, Montage, Ads, Leads, Meeting, Scraping.

The report is an **interactive UI**. Do not design for Export PDF. File Preview
print is not the close path.

### Stack (required)

Vite + React + one official DS (MUI / Fluent / Carbon) + `framer-motion` +
`three` + `@react-three/fiber` + `@react-three/drei`. Follow `ui-ux-pro-max`
and `make-interfaces-feel-better`.

Before the scene:

```bash
python3 "$SEARCH" "<report theme> spatial dashboard" --stack threejs
```

Use the drei helpers the search returns: OrbitControls (damping), Environment,
ContactShadows, PresentationControls when the hero is a product. Optional
`@react-three/postprocessing` only if that hero needs bloom.

### Scene quality (required)

- One R3F Canvas / one renderer; `pixelRatio` capped at 2; antialias at construct
- PBR materials + AmbientLight + DirectionalLight (never a black unlit mesh)
- shadowMap on; cast/receive on the hero and the ground
- FOV 45-75; explicit camera position + lookAt
- Designed object or environment the user can read, HTML overlay for the report
- `prefers-reduced-motion`: freeze the scene, show the still
- Canvas `role="img"` and a real aria-label
- Never wallpaper particles, never a blank canvas, never GSAP/Spline/Lottie spam

### Layout (overlay on the scene)

1. **Header** - mission name, report title, subject / scope / path, timestamp
2. **Executive summary** - 3-6 bullets or short cards (what matters first)
3. **Body sections** - one clear section per theme; working controls only
4. **Deliverables** - table: file path | format | what it contains. Only what the
   user asked for; render scripts, scrapers and intermediates live under
   `build/` and never appear in this table
5. **Footer** - generated by Navin, timestamp, short disclaimer if needed

### After writing

Start the app and call `open_preview` (web). Click the primary nav yourself.
Do not paste the full HTML into chat. Do not close with Export PDF.

---

## Track B - Expert File Preview report (no JavaScript)

Missions: Review (`/inspect`), Security (`/fortify`), Debug (`/debug`).

File Preview sandboxes scripts - **no JS interactivity**. Self-contained file:
all CSS inline in a style block. No external fonts, no javascript, no CDNs.

For Review / Security / Debug tool reports (`code_review` report,
`security_scan` write_report, `debug_repair` report), File Preview opens
automatically in the WebUI. Otherwise call `open_file_preview` on the HTML
path immediately (Download HTML). Print CSS is optional. PDF is not the
design target. Do not paste the full HTML into chat.

### Layout

1. **Header** - mission name, report title, subject / scope / path, timestamp
2. **Executive summary** - 3-6 bullets or short cards (what matters first);
   for Review/Security/Debug: severity counters (Critical / High / Medium / Low)
3. **Body sections** - one clear section per theme
4. **Remediation plan (Review / Security / Debug)** - numbered choices the user
   can pick in chat (`Start with #1`, `#2`, …). Each choice: title, severity,
   effort (S/M/L), risk if delayed, first concrete step
5. **Deliverables** - table: file path | format | what it contains. Only what the
   user asked for; render scripts, scrapers and intermediates live under
   `build/` and never appear in this table
6. **Footer** - generated by Navin, timestamp, short disclaimer if needed

### Finding cards (Review / Security / Debug) - required

For **every** confirmed finding, render a card with:

| Field | Rule |
|---|---|
| Severity chip | Critical / High / Medium / Low / Info with color |
| Title | Short, specific |
| Location | `path/to/file.ext:LINE` (or hunk range) |
| Impact | What an attacker / user / system suffers |
| **Real example** | Mandatory proof - see below |
| Fix | Minimal concrete remediation |

**Real example** (pick what fits; at least one per finding):

- Vulnerable or buggy **code excerpt** (10-40 lines max, redact secrets)
- **Payload / PoC** (`' OR 1=1--`, XSS string, curl with headers)
- **HTTP request/response** snippet proving the flaw
- **Failing test / stack trace / scanner output** (trimmed)
- **Before → after** snippet for the recommended fix

Never fill with a generic OWASP paragraph and no project-specific proof.

### Remediation plan UI (no JavaScript)

Use numbered choice cards styled like selectable options:

```html
<section class="plan">
  <h2>Remediation plan - choose where to start</h2>
  <p class="hint">Reply in chat with the number, e.g. "Start with #1".</p>
  <article class="choice">
    <header><span class="num">#1</span> <span class="sev">Critical</span> Title</header>
    <p>Effort: S · Risk if delayed: …</p>
    <p>First step: …</p>
  </article>
  …
</section>
```

Order choices by severity × exploitability (or by dependency for Debug).
Do not auto-start fixes until the user picks a number (unless they already
asked for Auto-fix / fix everything).

### Roadmap & strategy (audits / Review / Security / Debug) - required

A remediation list alone is not a plan. After the choices, add a
**Roadmap** section with 3-4 phases, each rendered as a card:

| Phase | Horizon | Content rule |
|---|---|---|
| Phase 0 - Stabiliser | 24-72h | Only stop-the-bleeding items (exposed secrets, live exploits, data loss) |
| Phase 1 - Corriger | 1-2 semaines | Critical/High fixes, grouped by module so one owner can batch them |
| Phase 2 - Renforcer | 30-60 jours | Structural work: tests, CI gates, auth hardening, monitoring |
| Phase 3 - Exceller | Trimestre | Architecture debt, performance, design system, documentation |

Each phase must list: objective (one sentence), the numbered tasks it
contains (reference the remediation choice numbers), **effort in
person-days per task**, dependencies between tasks ("needs #3 first"),
and an **exit criterion** that is verifiable ("CI blocks merge when
tests fail", "gitleaks scan returns 0 findings"), not vague ("better
security").

Close the roadmap with a short **Strategy** block (5-10 lines of prose,
not bullets):

- Target state in one paragraph: what the project looks like when the
  roadmap is done, with 2-3 measurable KPIs (test coverage %, mean time
  to patch, Lighthouse score, error budget)
- Quick wins vs structural work: name which items buy the most risk
  reduction per day of effort and why
- Verification loop: how each fix is proven (test added, scanner re-run,
  CI gate) so regressions cannot silently return
- Top 2 risks of the plan itself (e.g. key rotation breaks a deploy,
  strict TS flags block the team) and the mitigation for each

Every recommendation in the report must be actionable as written: name
the exact file/command/config to change and what to change it to. "Add
rate limiting" is filler; "add slowapi Limiter on POST /api/auth/login,
5/min per IP, see snippet" is a recommendation.

### Visual system

- Prefer a clean dark report shell: background `#0a0e1a`, cards `#121826`,
  text `#e8eefc`, muted `#9aa8c7`, accent `#5b8cff`, success `#3ecf8e`,
  warning `#f0b429`, danger `#f07178`
- System UI / sans stack: `ui-sans-serif, system-ui, sans-serif`
- Generous spacing, 12-16px card radius, subtle 1px borders
- Severity / score chips with color, not emoji spam
- Code / PoC blocks: monospace, `#0d1117` background, wrap long lines
- Tables: readable zebra or row separators; wrap long URLs
- Print-friendly: `@media print` with white/black fallbacks so a print
  dialog stays legible if the user asks

### Content rules

- Specific numbers, URLs, paths, and code - no filler
- Mask secrets in examples (`sk-***`, password hashes truncated)
- Link workspace file paths as plain text paths (not `file://`)
- Keep the HTML under ~300 KB when possible so Preview is not truncated
- French or English to match the user brief

## Mission-specific emphasis

- **RiskLens** - synthesis (most likely / most dangerous / hidden assumption),
  failure cards, revised plan, checklist (Track A UI)
- **SEO** - impact-ordered findings, keyword clusters, content actions, schema
  / meta snippets when relevant (Track A UI)
- **Marketing** - message / persona, channel plan, asset inventory with paths
  (Track A UI)
- **Leads** - ICP snapshot, ranked accounts/people, signals, outreach next steps
  (source URLs mandatory) (Track A UI)
- **Ads** - evidence paths, kill/scale, no invented ROAS (Track A UI)
- **Scraping** - crawl stats, ok/error, export paths, sample rows (Track A UI)
- **Meeting** - decisions, owners, actions (Track A UI)
- **Review** - Approve / Request changes verdict; findings by layer
  (correctness, SQL/data, API, frontend, tests, perf); remediation choices
- **Security** - phase coverage (injection, front, authz, network, secrets,
  privacy); PoC per finding; hardening plan choices
- **Debug** - root-cause statement with evidence; related latent bugs; fix
  plan choices ordered by unblock value

## Chat close

Studio / GTM: three to six sentences max: headline result + the Preview UI
path + the other key file formats. Expert Review / Security / Debug: ask
which remediation number to start with.