interactive-field-guide — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited interactive-field-guide (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The default output is a self-contained HTML file (~110KB) with sidebar nav, full-text ⌘K search, click-to-expand drawers, a clickable SVG ecosystem map, a 2×2 strategic positioning matrix, and structured analysis across up to 22 parts.
Alternative output: a concise markdown research brief (when the user explicitly requests "brief", "markdown summary", or chooses brief at the end of Discovery mode).
Quality bar: Every fact must have a [Source: X] citation. Every judgment must be falsifiable. Every report must include explicit counter-consensus framing. Matches Net Interest, Stratechery, and CB Insights research standards.
Operating principle: this skill is a suite, not a single tool. It supports 6 operational modes and 7 analytical personas. Always resolve mode + persona + output format BEFORE generating.
Outputs are designed for sharing. Treat every artifact as something the user might forward to a colleague, post publicly, or use in a stakeholder presentation. They must be free of any conversation-participant's personal context (see Critical Rule 7).
Before doing anything, classify the user's request along three dimensions.
| User intent / trigger phrases | Mode |
|---|---|
| "analyze X", "research X", "make a field guide on X", "study X" | Generate (default) |
| "help me think through X first", "do a discovery on X", "research dialogue", "before we generate" | Discovery |
| "review my analysis", "critique this report", "find weaknesses in X" + user provides existing analysis | Critique |
| "update my [old report]", "refresh with latest data", "let's revisit X", "复盘 my X report" + reference to prior guide | Refresh |
| "compare X and Y", "X vs Y", "head-to-head on X / Y" | Compare |
| "expand part [topic]", "deep dive on [specific subsection]", "drill into [topic from prior guide]" | Drill-down |
| User signal | Persona |
|---|---|
| (default for stocks / public companies) | Tier 2 Investor |
| (default for industry / sector analyses) | Industry Strategist |
| "as CEO", "founder POV", "operator view" | CEO |
| "venture investor", "early-stage VC", "fund-returner perspective" | Tier 1 Investor |
| "technical view", "engineer POV", "architecture analysis" | Engineer / Builder |
| "as competitor", "if I were [rival]", "adversarial view" | Competitor |
| "what could kill this", "disruption risk", "5-year obsolescence scan" | Disruption Scout |
Default: HTML field guide (interactive, 110KB).
Override to markdown research brief when:
Proceed immediately and announce when:
In this case, briefly tell the user: "Got it — running [mode] on [topic] with [persona] lens, output as [format]. Proceeding." Then execute. The user can interrupt if you've misread their intent.
Ask one concise clarifying question and WAIT for response when:
Phrase the question as a single short ask: "To make sure I read this right — [specific clarifying question]?" Wait for the user's reply before proceeding.
Do not invent a function call name (e.g. avoid "AskUserQuestion()"). Just ask in plain text.
Read references/modes.md and find the section for the resolved mode. Each mode has its own multi-step workflow with specific dialogue patterns, output format, and validation rules.
Read references/personas.md and find the section for the resolved persona. Each persona defines:
Note: personas describe the LENS, not specific section numbers. Map the persona's emphasis topics onto whatever 22-part structure is current in references/structure.md.
For modes producing HTML output (Generate / Refresh / Compare / Drill-down), load:
references/structure.md — 22-part menu with skip rules by topic typereferences/content-strategy.md — sourcing standards (Tier 1-3), counter-consensus framework, falsifiability rulesreferences/data-schemas.md — JS object schemas + component HTML patternsreferences/pitfalls.md — known pitfalls + 9-check validation script (includes Template Wiring, Personalization Leakage, Accordion Double-binding)For modes producing markdown output (Critique, Discovery brief-only), load only:
references/content-strategy.mdreferences/pitfalls.mdFollow the mode's workflow step by step. Apply the persona's lens at each judgment point. Use `assets/template.html` as the rendering base for HTML outputs — surgically replace pre-populated content; do NOT rebuild from scratch (see Critical Rule 6 below).
For HTML outputs: run the 11-check validation script from references/pitfalls.md. Iterate up to 3 times to fix issues. Only deliver after passing all 11 checks.
Mandatory visibility: output the 11-check results as a visible code block in the response to the user, in the form:
=== 11-check validation results ===
1. Template instruction strip: ✓
2. Placeholder strip: ✓
...
11. Reverse grep (HTML→JS): ✓
=== Result: 11/11 passed, OK to deliver ===The visibility requirement (Rule 10a) prevents silent skipping — if the validation block is missing from the response, the user knows something was bypassed.
The 11 checks cover:
vm sandbox to catch TypeError / ReferenceError / infinite loops at script initPlus Rule 10 production contract: ≥15 Parts, 5 hard-floor interactions working, TOC visible (sidebar + top-nav + progress-bar), continuous Roman numerals, Part Coverage Audit present.
For markdown outputs (Critique, brief): self-review against content-strategy.md standards — every claim sourced, every judgment falsifiable, counter-consensus angle present. Also run personalization leakage check (#8).
Detect the runtime environment and write the output appropriately:
Filename convention:
<topic-slug>-field-guide.html (or .md for brief)<topic-slug>-field-guide-refresh-<YYYY-MM-DD>.html<topic-A>-vs-<topic-B>-comparison.html<topic-slug>-critique.mdFilename must NOT contain personal names (no klay-bytedance.html, no for-klay-nvidia.html). Use the analysis subject only.
Output location:
/mnt/user-data/outputs/ available): save there and use the platform's native file presentation.Always tell the user the exact file path where the output was saved, formatted as plain text (e.g. Saved to /Users/you/projects/xyz/nvidia-field-guide.html). The user needs this to open or share the file.
After delivery, briefly summarize:
This skill produces research frameworks with falsifiable signals, sourced facts, and structured Bull / Bear analyses. It is not personalized investment advice and does not replace a licensed financial advisor.
Operational rules:
This boundary applies to all modes and personas, including Tier 2 Investor (which is the most prone to crossing it).
assets/template.html as the rendering base. NEVER build HTML from scratch, even when the template's pre-populated content is on a topic unrelated to the current task. The template's CSS variables (--bg, --bg-card, --ink, --accent, --gold, --rule, --good, --bad, --bg-2), toolbar button IDs (searchBtn, glossaryBtn, darkBtn), TOC structure (with class="toc-link" on every <a> inside <nav class="toc">), JS button bindings, modal class conventions (.show), dark mode target (body.dark), and sidebar nav scaffold are all load-bearing — removing or rewiring any of them produces a black-and-white skeleton output without the warm-beige + brick-red palette and without working interactivity.The correct approach: open assets/template.html and surgically replace the pre-populated content (Mastercard / fintech sample data) with your target topic's content. Preserve every `<style>` block, every `id="..."` attribute on toolbar buttons, every `class="..."` attribute on TOC links, every CSS variable definition, and the entire JS scaffold. If the surgical edit feels overwhelming because the template has too much unrelated content, you are still required to do it surgically — rebuilding from scratch is forbidden.
The 9-check validation script in pitfalls.md includes a Template Wiring Integrity check (Check #7) that will catch failures of this rule. If Check #7 fails, you have rebuilt instead of edited — go back and start over from a fresh copy of assets/template.html.
❌ FORBIDDEN in any HTML or markdown output:
for-klay-nvidia.html)✅ The skill DOES have access to the user's profile (name, company, projects) through Claude.ai memory or similar context — but must not use it in output. That information is for shaping the conversation and asking clarifying questions, not for embedding in the artifact.
✅ The ONLY exception: when the user explicitly requests user-side framing in the prompt itself. Examples that authorize personal context:
Without explicit user direction, all output should be generic and reusable across users. The skill is open-source; outputs may be downloaded, shared, archived publicly.
Footer convention: use generic format only.
Generated with Interactive Field Guide · [date] · [persona] lens · [N] parts由 Interactive Field Guide 生成 · [date] · [persona] 视角 · [N] partsValidation: pitfalls.md Check #8 detects common leakage patterns.
Specifically: .accordion-header must have one addEventListener('click', ...) registration, not two. The same applies to .tab-button, .modal-close, etc.
Validation: pitfalls.md Check #9 detects multiple click handlers on the same component class.
template.html ships with 7 additional components beyond the original constellation + matrix-2x2 + drawer scaffold:stack-tier (expandable 3-tier industry stack)entity-card (clickable card grid with tier color)tab-strip + tab-panel-deep + player-panel (head-to-head deep tabs, e.g. Visa/MC/Amex)synthesis (dark counter-consensus zone wrapper)counter-box (inline counter-consensus highlight)uncertain-yellow / uncertain-red (inline confidence markers)trigger (IF × THEN falsifiability box)These live in template.html's <style> block after the /* v3.1 ADDITIONS */ comment. They are non-default — only render them when the content warrants the visual treatment (e.g. Part I uses stack-tier because it has a layered value chain; Part II uses entity-card because it has timeline events worth pointing at; not every report needs all 7).
Compatibility with Rule 8 (Component event handler integrity): these components use distinct class names (.stack-tier, .tab-btn, etc.) that don't collide with the v3.0.2 Check #9 patterns (.accordion-header, .tab-button). Each new component still requires exactly one click handler per element — see the JS binding comments inside template.html for the canonical patterns.
See references/data-schemas.md "v3.1 新增组件 schema" section for full HTML templates, JS bindings, and a "组件选择决策树" (decision tree) mapping content intent → component choice. The first reference implementation is the Stablecoin × Agent Pay field guide v3.1 — its part-by-part component breakdown is documented at the end of data-schemas.md.
(a) Self-validation before HTML delivery, with mandatory visible output. Run pitfalls.md's full 11-check validation script before emitting any HTML. Output the validation results as a visible code block in the response so the user can see ✓/✗ for each check. Zero ✗ tolerated. If any check fails, fix and re-validate before delivery. The visibility requirement prevents silent skipping — if Claude omits the validation output, the user knows something is off.
(b) Part completeness — minimum 15 active Parts by default. A field guide with only 5–8 Parts feels incomplete and is treated by users as a degraded deliverable, regardless of content quality per Part. Default behavior: render at least 15 of the 22 Parts. The default 15-Part set:
PART I 第一性原理 / 核心定义
PART II 数据可信度 / 来源分级
PART III 5 项核心条件 / 横向对比
PART IV 锚点案例（公司或事件深度拆解）
PART V 5 大子板块 / 细分赛道
PART VI 横向对比表（玩家原型 × 维度）
PART VII Constellation Map（SVG 生态图）
PART VIII 2×2 战略象限
PART IX 死亡 vs 成功（counter-thesis 案例库）
PART X 趋势时间线（90 天 / 12 个月）
PART XI 8 大评估维度 ⭐
PART XII 5 大根本分歧 / counter-consensus
PART XIII 未来 12 月变量
PART XIV 综合判断 + 90 天行动
PART XV 术语 + 来源索引When the user enters via Generate mode without specifying Parts: default to all 15. When the user enters via Discovery mode: must ask the Part-selection question in the 5-question dialogue ("Of the 22 available analytical Parts, which subset do you want for this report? Default is the 15 listed below. You can drop or add."). See modes.md Mode 2 for the canonical Discovery flow.
The 7 non-default Parts (only render when explicit user request or strong content fit): Part 10 (Talent / resource heatmap), Part 12 (Death-cause donut chart), Part 13 (DD pillars), Part 15 (Exit / M&A strategy), Part 16 (Cold-start / GTM kickoff), Part 18 (GTM strategy library), Part 19 (Validation method grid).
Public vs private company default comparison rule (raised by user 2026-05-27):
(c) Dynamic interactions are mandatory — five hard-floor interactions must work. Regardless of which v3.1 components Claude chooses to render, these five interactions must be present and functional in every HTML field guide:
id="part-N" section)data-id references)#tabContainer IDs in JS)If any one of these five is broken, the report is undeliverable. Validate via Check #10 (runtime execution) — see pitfalls.md.
Component coverage scales with Part count (v3.1.0 Rule 9 opt-in → v3.1.1 opt-out for ≥10 Parts): for any report rendering ≥10 Parts, all 7 v3.1 components default to "use" unless the specific content actively conflicts. The v3.1.0 default "only render when warranted" causes under-use in long reports — Rule 10c overrides that default for high-coverage reports.
(d) Table of Contents must be visible by default. A 110–200 KB HTML field guide without a visible TOC is unreadable. Three mandatory TOC elements per HTML field guide:
var(--accent)). Reference implementation: see the Nexar field guide example for the canonical scroll-progress + sidebar + top-nav triple layout.No exceptions. "User can scroll" is not a substitute for a TOC.
(e) Part numbering must be continuous Roman numerals. Display Part numbers as PART I, PART II, PART III, ..., PART XV (uppercase Roman numerals, space after "PART", em-dash or middle-dot separator before the title). This is the canonical Nexar field guide pattern.
Critical: render numbers continuously even when the underlying 22-Part library has gaps. If the report uses the default 15 Parts (which skips library Parts #10, #12, #13, #15, #16, #18, #19 from the 22-Part master list), the rendered Parts must still display as PART I through PART XV — not as "PART 1, PART 2, ..., PART 9, PART 11, PART 14, PART 17, PART 20, PART 21, PART 22". Library Part numbers are internal metadata, never user-facing.
Mapping is preserved in the Part Coverage Audit table (Rule 10f): each row shows both the rendered Roman numeral and the library Part ID, e.g. "PART X · 趋势时间线 (library #11)".
Anchor IDs in HTML: use sequential id="part-1" through id="part-15" to match the rendered Roman numerals — not the library Part IDs. This keeps the HTML semantics aligned with what users see.
(f) Part Coverage Audit persists across format transitions and document changes. A dedicated "Part Coverage Audit · Methodology Transparency" (or "22-Part 覆盖审计 · 方法论透明度") section must appear immediately before the footer in every HTML field guide. Required columns:
When upgrading from a markdown research brief to HTML: the audit table from the brief MUST be carried over and updated for any status changes (e.g. Part 7 Constellation Map: ❌ in markdown brief because "SVG cannot render in markdown" → ✅ in HTML because SVG is now feasible).
Rationale: This audit is the user's "trust contract" with the skill. Skipping Parts without explanation triggers anxiety ("did Claude miss something important?"). The audit eliminates anxiety by making every skip decision transparent and justifiable. This was explicitly raised by an external user in May 2026 ("为什么有时候输出的信息/数据不全面或者为什么不是 22 个板块都有，会省略一部分？") — Rule 10f is the structural response.
See references/modes.md for full workflows.
Core lenses (highest-frequency use):
Advanced lenses (specialist use):
See references/personas.md for each persona's full lens definition.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.