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
Install
npx skills add https://github.com/Navinspire-ia/navin/tree/main/navin/skills/studio-html-report
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install navinspire-ia-navin@llmmart
git clone https://github.com/Navinspire-ia/navin.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole navinspire-ia/navin collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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:
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;
pixelRatiocapped 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)
- Header - mission name, report title, subject / scope / path, timestamp
- Executive summary - 3-6 bullets or short cards (what matters first)
- Body sections - one clear section per theme; working controls only
- 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 - 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
- Header - mission name, report title, subject / scope / path, timestamp
- Executive summary - 3-6 bullets or short cards (what matters first); for Review/Security/Debug: severity counters (Critical / High / Medium / Low)
- Body sections - one clear section per theme
- 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 - 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 - 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:
<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,
#0d1117background, wrap long lines - Tables: readable zebra or row separators; wrap long URLs
- Print-friendly:
@media printwith 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.
Files (navin)
-
SKILL.md 10.3 KB
--- name: studio-html-report description: > 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. metadata: {"navin":{"emoji":"📄","category":"documents","requires":{}}} --- # 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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.