Interactive Field Guide

Interactive Field Guide Skill

What this skill produces

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

---

Step 0 — Resolve operation parameters

Before doing anything, classify the user's request along three dimensions.

0a. Detect mode (what kind of operation)

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

0b. Detect persona (analytical lens)

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

0c. Detect output format

Default: HTML field guide (interactive, 110KB).

Override to markdown research brief when:

• User explicitly says "brief", "markdown summary", "just the research foundation", "no HTML"
• User chose "brief only" at the end of Discovery dialogue
• Critique mode (always markdown; HTML doesn't apply)

0d. Decide: proceed immediately, or ask first?

Proceed immediately and announce when:

• Mode is clearly stated or strongly implied
• Persona is the topic-type default (Tier 2 for stocks, Industry Strategist for sectors)
• Output format is HTML (default)
• Topic is concrete (specific company, industry, ecosystem)

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:

• Mode is ambiguous between Generate and Discovery
• User said "compare" but only named one entity
• User said "refresh" but didn't provide the prior report
• User said "drill into [vague subsection]" with no parent guide referenced
• Persona is unusual for the topic type (e.g. CEO persona on a public company they don't run)

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.

---

Step 1 — Load mode workflow

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.

Step 2 — Load persona lens

Read references/personas.md and find the section for the resolved persona. Each persona defines:

• Obsessive questions the analysis must answer
• Prioritized source tiers
• Topical emphasis (which themes to expand vs compress)
• Tone and rhetorical framing

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.

Step 3 — Load shared references

For modes producing HTML output (Generate / Refresh / Compare / Drill-down), load:

• references/structure.md — 22-part menu with skip rules by topic type
• references/content-strategy.md — sourcing standards (Tier 1-3), counter-consensus framework, falsifiability rules
• references/data-schemas.md — JS object schemas + component HTML patterns
• references/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.md
• references/pitfalls.md

Step 4 — Execute workflow

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

Step 5 — Validate

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:

1. Template instruction strip
2. Placeholder strip
3. JS validity (static syntax)
4. ID consistency (CNNODES / data-id / DETAILDATA)
5. Constellation count
6. Sidebar consistency
7. Template wiring integrity (added v3.0.1)
8. Personalization leakage (added v3.0.2)
9. Accordion event handler integrity (added v3.0.2)

• 9b. JS ↔ HTML ID matching (added v3.1.1): zero orphan IDs

1. Runtime execution sanity (added v3.1.1): use node vm sandbox to catch TypeError / ReferenceError / infinite loops at script init
2. Reverse grep — HTML→JS (added v3.1.1): when removing HTML elements, verify no remaining JS reference to that ID/class

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

Step 6 — Deliver (cross-platform)

Detect the runtime environment and write the output appropriately:

Filename convention:

• Generate / Discovery / Drill-down: -field-guide.html (or .md for brief)
• Refresh: -field-guide-refresh-.html
• Compare: -vs--comparison.html
• Critique: -critique.md

Filename must NOT contain personal names (no klay-bytedance.html, no for-klay-nvidia.html). Use the analysis subject only.

Output location:

• If running in Claude.ai / Claude Desktop (sandboxed environment with /mnt/user-data/outputs/ available): save there and use the platform's native file presentation.
• If running in Claude Code / Codex CLI / Gemini CLI / Cursor / other agent CLIs: save to the current working directory.
• If neither is detectable: ask the user where to save, or default to current directory and tell them the absolute path.

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:

• Mode + persona + output format used
• 1-2 most material findings
• For Refresh: top 3 changes since prior version
• For Compare: strongest divergence between the entities
• For Critique: highest-priority fix
• Suggested next step (e.g. after Generate, suggest Critique to find weaknesses, or Drill-down on an interesting disagreement)

---

Boundary — what this skill is NOT

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:

• Frame outputs as analytical artifacts, not buy/sell recommendations.
• For HTML outputs, include a small footer disclaimer: "This is a research framework, not personalized investment advice. Consult a licensed advisor before acting."
• For markdown outputs, include the same disclaimer at the bottom.
• If a user asks "should I buy X" directly, reframe rather than answer: "I'll generate a research framework with explicit Bull/Bear scenarios and falsifiability triggers — you can use that to make your own decision."

This boundary applies to all modes and personas, including Tier 2 Investor (which is the most prone to crossing it).

---

Critical execution rules (apply to every mode)

1. Never invent attributions. If you don't have a real source, omit the claim. Don't write "[Source: company filing]" without the actual filing.
2. Falsifiability is not optional. Every judgment section must end with: "If [observable event] happens by [date], this view is wrong."
3. Counter-consensus is the spine. A field guide without a counter-consensus angle is just a Wikipedia summary. Refuse to generate without one — instead, ask the user to identify the angle, or run web search to surface candidate angles.
4. State the persona's lens explicitly in every output, briefly: "Analyzed through [persona] lens — emphasizing [their topical priorities]."
5. No greenwashing in scoring. When using 1-10 scoring (e.g. 8-pillar DD), include low scores. A report where everything scores 8+ is a red flag and should be re-scored more honestly.

1. Template integrity is non-negotiable. ALWAYS use 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 ` inside ), 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 ` 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.

1. Personalization leakage guard. Outputs are research artifacts intended for sharing across teams, organizations, and the open internet. They must be free of any conversation-participant's personal context unless the user explicitly requested otherwise.

❌ FORBIDDEN in any HTML or markdown output:

• Footer text like "Generated for [name]", "为 [name] 编写", "Built for [name]", "Created for [name]"
• Body text that volunteers user-side relevance: "对 [user's company] 含义", "[user's company] parallels", "implications for your [user's startup]"
• Any user-side proper nouns (the user's name, their company, their startup, their employer) in any part of the output
• Filename containing personal names (e.g. 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:

• "How does this relate to my work at [Company X]?"
• "What are the implications for [my startup]?"
• "I'm a [role] at [company] — analyze this from that POV"

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.

• English: Generated with Interactive Field Guide · [date] · [persona] lens · [N] parts
• 中文: 由 Interactive Field Guide 生成 · [date] · [persona] 视角 · [N] parts

Validation: pitfalls.md Check #8 detects common leakage patterns.

1. Component event handler integrity. Interactive components (accordion, tabs, modals, drawers) must have exactly one click handler bound per element. Double-binding causes click toggle race conditions where the first click opens then immediately closes the component — making it appear non-functional.

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.

1. Component library — beyond the default template scaffold. As of v3.1.0 (2026-05-26), 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 ` 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

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: klaywang24
• Source: klaywang24/interactive-field-guide-skill
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.