New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Interactive Product Tour

by rampstackco in rampstackco/claude-skills

Designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction.

MITAuto-check passed

Install Interactive Product Tour

skills CLI
$ npx skills add rampstackco/claude-skills --skill interactive-product-tour -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rampstackco/claude-skills interactive-product-tour --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rampstackco/claude-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/interactive-product-tour .claude/skills/interactive-product-tour && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
interactive-product-tour
GitHub stars
940
Token cost
~4.4k tokens
SKILL.md length
2,194 words
Files
11 (incl. references)
Skills in repo
103
Repo updated
First seen
Licence
MIT

At a glance

Designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction.

  • Works in 12 steps: The tour decision. Are tours the right… → Contextual-when-needed, not tooltip-spam… → Trigger logic sound. Event-based… → …
  • Tour architecture
  • SKILL.md covers What this skill covers, The tour decision: when tours…, Tooltip-spam vs one-and-done… and Trigger logic: event-based vs…, plus 8 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Interactive Product Tour is an agent skill from rampstackco/claude-skills. Designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction. Trigger logic, tour architecture, contextual placement, completion tracking. Honest about tooltip-spam (visual noise that users develop blindness to), one-and-done (help invisible at the moment of need), and contextual-when-needed (surfaces help at the moment friction occurs) patterns. Triggers on product tour, in-product tooltip, contextual help, walkthrough, feature tour, hint system, in-app…

Its SKILL.md is about 4.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 11 other files, including reference files (for example `README.md`, `references/common-tour-failures.md` and `references/completion-tracking-and-re-trigger.md`).

The repository describes itself as: Stack-agnostic Claude Skills covering the full website lifecycle: brand, design, content, SEO, dev, ops, growth, and research. Build, ship, audit, optimize. The licence is MIT.

When your agent uses it

  • Tour architecture
  • Contextual placement
  • Completion tracking
  • In-product tooltip

Example prompts

  • “/interactive-product-tour”

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. The tour decision. Are tours the right tool, or does documentation suffice?
  2. Contextual-when-needed, not tooltip-spam or one-and-done. Help surfaces at moments of friction.
  3. Trigger logic sound. Event-based primary, with time and state modulation.
  4. Tour architecture matches usage. Library of micro-tours preferred for most products.
  5. Contextual placement non-intrusive. Help findable when wanted, ignorable when not.
  6. Dismissal mechanics honest. Standard close, click-outside dismiss, no auto-dismiss before reading.
  7. Completion tracking instrumented. Per-user state, per-tour status.
  8. Re-trigger logic respectful. Completed tours do not re-show; dismissed tours respected.
  9. Power-user vs new-user differentiation. Help calibrated to user state.
  10. Mobile parity. Help works on the devices the audience uses.
  11. Maintenance discipline. Tours updated alongside product changes; quarterly audit.
  12. Adoption as success metric. Not just tour completion; feature adoption is the metric that matters.

What it can do on your machine

Read from SKILL.md and the folder at commit 482c9bf. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Interactive Product Tour loads about 4.4k tokens when it runs, and up to ~20k if it reads all its reference files. Until then it costs about 180 tokens; SKILL.md has 2,194 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~180
When it runs · the whole SKILL.md, loaded when a task matches
~4.4k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~20k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rampstackco/claude-skills at commit 482c9bf, republished under its MIT licence (© rampstackco). 2,194 words, ~4,429 tokens.

Download SKILL.mdSave it as .claude/skills/interactive-product-tour/SKILL.md (or your agent's skills folder). This skill also uses 10 other files; get the full folder from GitHub.
name
interactive-product-tour
description
Designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction. Trigger logic, tour architecture, contextual placement, completion tracking. Honest about tooltip-spam (visual noise that users develop blindness to), one-and-done (help invisible at the moment of need), and contextual-when-needed (surfaces help at the moment friction occurs) patterns. Triggers on product tour, in-product tooltip, contextual help, walkthrough, feature tour, hint system, in-app guidance, tour platform. Also triggers when feature adoption is low, when users miss key product capabilities, or when an in-product help system is being scoped for the first time.
category
growth-tooling
catalog_summary
Designing in-product tours and contextual help. Distinguishes tooltip-spam (every button has a tour stop) from one-and-done (tour shows once, never seen…
display_order
8

Interactive Product Tour

A senior product marketing director's playbook for designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction. Trigger logic, tour architecture, contextual placement, completion tracking. The discipline of building help systems that surface at moments of need and disappear when not needed.

Most product tours fail in one of two ways. They paint every button, link, and feature with "click for tour" hints until the visual noise is so great that users develop blindness to the dots. Or they show a single first-login tour the user skips or skims, after which the same help never re-surfaces when the user actually hits a moment of friction. Help that is invisible at the moment of need is help that does not exist.

The tours that work do something different. They trigger when the user is at a moment of friction, not all the time. They surface contextual hints when the user enters a section they have not explored, clicks into a feature requiring setup, or returns after a long absence. The system knows what the user knows and surfaces help at the right moment.

The voice is the senior product marketing director who has watched feature adoption double when tours were redesigned and watched it collapse when more tooltips were piled onto every surface. Practical, opinionated about the trigger logic that distinguishes useful help from visual noise, willing to call out when no in-product tour at all is the right answer.

When to use this skill: scoping an in-product help system for the first time, auditing a tour system that produces engagement metrics with no adoption lift, designing the trigger logic that decides when help surfaces, or deciding which features warrant tours vs documentation.

What this skill covers

This skill spans in-product tours, tooltips, and contextual help. The growth-tooling distinctions:

  • onboarding-wizard-design is the sequential first-run experience. This skill is contextual help WITHIN the product, surfacing across the lifecycle.
  • chatbot-flow-design is conversational help. This skill is non-conversational tour and tooltip help.
  • interactive-product-tour (this skill) is trigger logic, tour architecture, contextual placement, completion tracking, and the discipline of being absent until needed.
  • discovery-research-synthesis is research that informs tour content. Input, not part of.
  • pm-spec-writing is the spec for engineers building the tour. This skill is about WHAT to build; pm-spec-writing is about communicating it.

The audience: product marketers, growth marketers, in-house product teams, agencies running activation work for SaaS clients.

Out of scope: first-run wizards (covered by onboarding-wizard-design); conversational help (covered by chatbot-flow-design); the engineering implementation; specific Userpilot/Pendo/Appcues platform configurations (those stay implementation-side).

The tour decision: when tours earn vs when documentation suffices

Before designing the tour system, decide whether tours are the right tool.

Tours earn investment when:

  • The product has features users genuinely miss without prompting. Specific functionality buried in menus, advanced workflows that require sequence, integrations users do not know exist.
  • The audience benefits from in-context guidance more than out-of-context documentation. Tours teach in the place the user will use the feature; docs require context-switching.
  • The team can maintain tours as the product evolves. Tour content decays; without maintenance commitment, tours point to deprecated UI.
  • The success metric is defined. Feature adoption, time-to-value for specific capabilities, reduction in support tickets for tour-covered features.

Tours do NOT earn investment when:

  • The product's feature set is small enough that documentation suffices. A few tooltips on key features may be all that is needed.
  • The audience prefers self-directed discovery. Some audiences resent in-product guidance and prefer to explore.
  • The team cannot maintain tours alongside product changes. Stale tours are worse than no tours.
  • The product changes frequently. Tour maintenance can exceed tour value if the product churns rapidly.

The decision is not "should we have a tour system"; it is "is in-product tour the right tool for this product and audience."

Detail in references/tour-decision-criteria.md.

Tooltip-spam vs one-and-done vs contextual-when-needed

The keystone framing.

Tooltip-spam. Every button, link, and feature has a "click for tour" hint or pulsing dot. Visual noise. Users develop blindness to the dots; the tour system fails as a teaching surface. Cost: the design effort produces help nobody perceives; the visual clutter degrades the product overall.

One-and-done. A single tour shown on first login. Users skip or skim. The same tour never re-surfaces when the user actually hits a moment of friction. Cost: help that is invisible at the moment of need does not help. Feature adoption stays low; support tickets persist for features the tour covered.

Contextual-when-needed. Tours and tooltips trigger when the user is at a moment of friction (entered a section they have not explored, clicked into a feature requiring setup, returned after a long absence, hit a feature flag's first activation). The system knows what the user knows and surfaces help at the right moment. Cost: trigger logic is meaningful work; payoff is help that compounds adoption over time.

The litmus test. Watch a user encounter a feature for the first time. Does the help system surface useful guidance at that moment, or did it surface guidance at first-login that the user has long forgotten? If the former, contextual-when-needed. If the latter, one-and-done. If the help is competing with 14 other tooltip dots scattered across the page, tooltip-spam.

Trigger logic: event-based vs time-based vs state-based

The mechanism that decides when help surfaces.

Event-based triggers. Help appears in response to a user action. Clicked a feature for the first time, entered a new section, completed a flow.

When to use. Default for most contextual help. The user did something; help responds.

Time-based triggers. Help appears after time elapsed. Returned to the product after 30 days of absence; been on this page for 60 seconds without acting.

When to use. Time can signal need (long absence; stuck on a page). Use sparingly; time alone is a noisy signal.

State-based triggers. Help appears based on user state. New user vs power user; account size; feature usage history.

When to use. When the help differs by user segment. State-based triggers personalize help.

Combined triggers. Most production tour systems combine all three. Event-driven, with time and state modulating frequency and content.

The discipline. The trigger answers "when does this help surface and why." Decorative triggers (showing help when it is not needed) become tooltip-spam.

Detail in references/trigger-logic-patterns.md.

Tour architecture: single tour vs branched vs library of micro-tours

How help is organized.

Single tour. One linear tour covering the product. Simple; rigid; rarely fits how users actually explore.

Branched tour. Tour adapts based on user choices or path through the product. More relevant; more complex.

Library of micro-tours. Dozens of small focused tours, each tied to a specific feature or workflow. Triggered contextually. Most flexible; most maintenance.

The choice. Most modern systems use the micro-tour library approach. Single tours feel canned; branched tours are hard to maintain at scale; a library of contextual micro-tours matches how users actually explore.

Detail in references/tour-architecture-patterns.md.

Contextual placement: where help appears, how it dismisses

The visual design of help.

Placement patterns.

  • Tooltip on hover. Help appears next to the element on hover. Lightweight; familiar.
  • Spotlight overlay. Element highlighted, help appears alongside. More prominent; more disruptive.
  • Sidebar. Help appears in a side panel. Can persist while the user works.
  • Inline. Help appears in the page flow. Non-disruptive; harder to dismiss.

Dismissal mechanics.

  • Click X. Standard close. Always available.
  • Click outside. Help dismisses if the user interacts with anything else. Implies non-modal help.
  • Auto-dismiss. Help fades after a few seconds. Risky; users may not have read it.
  • Persistent until acted on. Help stays until the user takes the suggested action. Powerful for guided flows; intrusive otherwise.

Non-intrusion principle. Help should be findable when wanted, ignorable when not. Modal help that blocks the screen is intrusive; help that disappears too easily fails to teach.

Detail in references/contextual-placement-patterns.md and references/dismissal-and-non-intrusion-patterns.md.

Show full SKILL.md (899 more words)Show less

Completion tracking and re-trigger logic

Knowing what each user has seen, deciding when to show again.

Per-user state tracking.

  • Which tours has the user completed?
  • Which tours has the user dismissed?
  • Which tours has the user seen but not completed?
  • Time since last interaction.

Re-trigger logic.

  • Completed tours: usually do not re-show.
  • Dismissed tours: respect the dismissal; possibly re-show after a long delay if the feature becomes relevant again.
  • Skipped tours: re-show at moments of relevance.
  • Long-absent users: re-orient with abbreviated help.

The over-trigger trap. Showing the same tour to users who have completed it. Trust degrades; users disable tours.

The under-trigger trap. Tours never re-surfacing when the user hits the same friction again. Help fails at the moment of need.

Detail in references/completion-tracking-and-re-trigger.md.

Power-user vs new-user differentiation

Different users need different help.

The principle. Power users do not want tours on features they already use. New users need tours on features they are encountering for the first time. The help system should know the difference.

Differentiation signals.

  • Feature usage history (has the user used this feature before?).
  • Tenure (how long has the user been on the product?).
  • Engagement frequency (active daily vs returning monthly).
  • Self-reported skill level (rare; usually inferred).

Differentiation patterns.

  • Power users see help only on new features.
  • New users see help on the features matching their stage of exploration.
  • Returning users see re-orientation help if their last session was long ago.

The over-helping trap. Helping power users with features they mastered. Trust degrades.

The under-helping trap. Treating all users as power users. New users miss critical help.

Detail in references/power-user-vs-new-user-patterns.md.

Common failure modes

Rapid-fire. Diagnoses in references/common-tour-failures.md.

  • "Tours show but feature adoption does not improve." Help may be visually present but not contextually relevant. Audit trigger logic.
  • "Users disable tours globally." The system is annoying users. Audit frequency, dismissal, and over-triggering.
  • "First-login tour completion is 80 percent; feature adoption is unchanged." One-and-done pattern; tour content not retained at moment of need.
  • "Tooltips appear everywhere; nobody clicks them." Tooltip-spam; rebalance to contextual triggers.
  • "Tour content references features we deprecated 6 months ago." Maintenance lapse.
  • "Power users complain about pop-ups for things they already know." No power-user differentiation.
  • "Tours work on desktop, break on mobile." Mobile UX of help system not tested.
  • "Some teams ship tours; others don't bother. Inconsistent." No tour governance; some teams build, others ignore.
  • "Tours triggered correctly but users do not act on the suggestion." Help content unclear or call-to-action absent.

The framework: 12 considerations for product tour design

When designing or auditing an in-product tour system, walk these 12 considerations.

  1. The tour decision. Are tours the right tool, or does documentation suffice?
  2. Contextual-when-needed, not tooltip-spam or one-and-done. Help surfaces at moments of friction.
  3. Trigger logic sound. Event-based primary, with time and state modulation.
  4. Tour architecture matches usage. Library of micro-tours preferred for most products.
  5. Contextual placement non-intrusive. Help findable when wanted, ignorable when not.
  6. Dismissal mechanics honest. Standard close, click-outside dismiss, no auto-dismiss before reading.
  7. Completion tracking instrumented. Per-user state, per-tour status.
  8. Re-trigger logic respectful. Completed tours do not re-show; dismissed tours respected.
  9. Power-user vs new-user differentiation. Help calibrated to user state.
  10. Mobile parity. Help works on the devices the audience uses.
  11. Maintenance discipline. Tours updated alongside product changes; quarterly audit.
  12. Adoption as success metric. Not just tour completion; feature adoption is the metric that matters.

The output of the framework is a tour system that earns the user's attention by being absent until needed, surfaces help at moments of relevance, and produces feature adoption.

Reference files

Closing: tours earn the user's attention by being absent until needed

The tour systems that work as compounding assets are the ones the user does not perceive as a tour system. Help surfaces at the moment of friction; disappears when the friction passes; never piles up as visual noise. The user encounters a feature for the first time, sees a brief contextual hint, takes the suggested action, and moves on. The system did its job; the user did not have to think about the system.

That is the bar. Below the bar are tooltip-spam (visual noise that users develop blindness to) and one-and-done (help invisible at the moment of need). Above the bar are contextual-when-needed systems where trigger logic, tour architecture, contextual placement, and re-trigger respect work together to make help feel ambient rather than imposed.

The discipline is in the design choices. The decision to build a tour system at all, or rely on documentation. The trigger logic that decides when help surfaces. The architecture that organizes micro-tours by feature and workflow. The placement and dismissal that make help non-intrusive. The completion tracking that prevents re-showing what users already know. The power-user differentiation that respects expertise. The maintenance cadence that keeps tours in sync with the product.

© rampstackco, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 10 other files (references) in skills/interactive-product-tour of rampstackco/claude-skills.

  • SKILL.md
  • README.md
  • references/common-tour-failures.md
  • references/completion-tracking-and-re-trigger.md
  • references/contextual-placement-patterns.md
  • references/dismissal-and-non-intrusion-patterns.md
  • references/power-user-vs-new-user-patterns.md
  • references/tour-anti-patterns.md
  • references/tour-architecture-patterns.md
  • references/tour-decision-criteria.md
  • references/trigger-logic-patterns.md

Open the folder on GitHubat commit 482c9bf

Compare with similar skills

Interactive Product Tour next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Interactive Product Tour compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Interactive Product Tour this skillrampstackco/claude-skills940—~4.4kAutomated safety check: PassMIT
Design Systemaffaan-m/ECC275k—~698Automated safety check: PassMIT
Design Guidepaperclipai/paperclip99k1 repos~3.1kAutomated safety check: PassMIT
Design Audit Against Rams' Principlesthedotmack/claude-mem98k—~4.6kAutomated safety check: PassApache-2.0
Figma Design to Codewarpdotdev/warp65k4 repos~2.9kAutomated safety check: PassAGPL-3.0
Design Consultationgarrytan/gstack136k—~15kAutomated safety check: NotesMIT

Similar skills

  • Design System

    affaan-m/ECC

    Generate a design system from an existing codebase or audit one for visual consistency: extract tokens (colors, typography, spacing, shadows) into design-tokens.json and CSS custom properties with…

    275k GitHub stars~698 tokensUpdated 3 days ago
    Frontend & DesignAuto-check passed

  • Design Guide

    paperclipai/paperclip

    Paperclip UI design system guide for building consistent, reusable frontend components.

    99k GitHub starsUsed in 1 repo~3.1k tokens
    Frontend & DesignAuto-check passed

  • Design Audit Against Rams' Principles

    thedotmack/claude-mem

    Audits a design against Dieter Rams' ten principles of good design, scores each with evidence, and hands off a make-plan prompt for a new, refined or redesigned outcome.

    98k GitHub stars~4.6k tokensUpdated yesterday
    Frontend & DesignAuto-check passed

  • Figma Design to Code

    warpdotdev/warp

    Turns a Figma frame or component into production code that matches the design, using the Figma MCP server and the project's own design system.

    65k GitHub starsUsed in 4 repos~2.9k tokens
    Frontend & DesignAuto-check passed

  • Design Consultation

    garrytan/gstack

    Learns about your product, studies the landscape and writes a DESIGN.md with a full design system covering type, color, layout, spacing and motion.

    136k GitHub stars~15k tokensUpdated today
    Frontend & DesignAuto-check: notes

  • Product Design Workflow Bundle

    XiaomiMiMo/MiMo-Code

    Entry point to a bundle of product design workflows covering context, research, audits, ideation, URL or image to code, design QA and sharing a prototype.

    14k GitHub stars~721 tokensUpdated 4 days ago
    Frontend & DesignAuto-check passed

More from rampstackco/claude-skills

All 103 skills in this repo

  • After Action Report

    rampstackco/claude-skills

    Run a structured after-action review (postmortem, retrospective) on a launch, incident, or completed project to capture timeline, root cause analysis, contributing factors, and actionable lessons.

    940 GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed

  • Analytics Strategy

    rampstackco/claude-skills

    Design measurement frameworks including event taxonomy, KPI hierarchy, dashboard architecture, attribution models, and analytics implementation strategy.

    940 GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check passed

  • Brand Style Guide

    rampstackco/claude-skills

    Build or audit a comprehensive brand style guide that documents the full brand system including story, logo system, color, typography, imagery, voice, applications, and dos/don'ts.

    940 GitHub stars~2.1k tokensUpdated yesterday
    Auto-check passed

  • Brand Voice

    rampstackco/claude-skills

    Develop or document a complete brand voice and tone system covering voice attributes, tone shifts by context, vocabulary preferences, grammar rules, and copy examples.

    940 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed

  • Content And Copy

    rampstackco/claude-skills

    Write or edit website copy, blog content, and editorial pieces with attention to voice, structure, and goal.

    940 GitHub stars~2.1k tokensUpdated yesterday
    Auto-check passed

  • Content Strategy

    rampstackco/claude-skills

    Develop a content strategy covering editorial positioning, content pillars, formats, calendar, governance, and topical authority planning.

    940 GitHub stars~2.6k tokensUpdated yesterday
    Auto-check passed

Questions about Interactive Product Tour

What does Interactive Product Tour do?

Designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction. Interactive Product Tour is an agent skill from rampstackco/claude-skills. Designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction.

When should I use Interactive Product Tour?

Interactive Product Tour fits situations like: tour architecture; contextual placement; completion tracking; in-product tooltip.

How do I install Interactive Product Tour in Claude Code?

Run `npx skills add rampstackco/claude-skills --skill interactive-product-tour -a claude-code`. Or copy the skill folder (skills/interactive-product-tour in rampstackco/claude-skills) into .claude/skills/interactive-product-tour in your project. Claude Code loads it when a task matches its description.

How do I install Interactive Product Tour in Codex?

Run `npx skills add rampstackco/claude-skills --skill interactive-product-tour -a codex`. Or copy the skill folder (skills/interactive-product-tour in rampstackco/claude-skills) into .agents/skills/interactive-product-tour in your project. Codex loads it when a task matches its description.

Can I use Interactive Product Tour in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rampstackco/claude-skills --skill interactive-product-tour -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/interactive-product-tour, .gemini/skills/interactive-product-tour, .github/skills/interactive-product-tour and .opencode/skills/interactive-product-tour in your project.

What does Interactive Product Tour need to run?

SKILL.md names no scripts, command-line tools or credentials: Interactive Product Tour is instructions for the agent only.

Does Interactive Product Tour access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Interactive Product Tour safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Interactive Product Tour use?

Interactive Product Tour is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Interactive Product Tour use?

About 4.4k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 16k tokens, read only when the agent opens those files.

What are the alternatives to Interactive Product Tour?

Skills that share tags, products or a category with Interactive Product Tour: Design System (affaan-m/ECC, 275k stars), Design Guide (paperclipai/paperclip, 99k stars), Design Audit Against Rams' Principles (thedotmack/claude-mem, 98k stars) and Figma Design to Code (warpdotdev/warp, 65k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Interactive Product Tour?

rampstackco (a GitHub organization) maintains it in rampstackco/claude-skills, which has 940 GitHub stars. The repository holds 103 skills in this directory. The repository was last updated on October 7, 2026.

Source: rampstackco/claude-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.