Claude Skill

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

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download navinspire-ia-navin-navin_skills_studio-html-report-e9c73a3.zip · 4 KB
Part of navinspire-ia/navin — 182 skills

Install

skills CLI npx skills add https://github.com/Navinspire-ia/navin/tree/main/navin/skills/studio-html-report
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install navinspire-ia-navin@llmmart
Git 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; 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:

<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.

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.

No comments yet.

Reviews (0)

No reviews yet.

Related