lov-integrate-lovinsp

Integrate Lovinsp

Idempotently integrate lovinsp (click DOM to jump to source code) into the current frontend project. Supports automatic migration from code-inspector.

Triggers

Activate when

• The user asks to use this Skill for its documented outcome.

• The user says "install lovinsp", "integrate lovinsp", "add click-to-jump-to-source", "click to code", "migrate from code-inspector".

• The user is creating or upgrading a browser-rendered frontend application and needs the development-time click-to-locate-source capability.

• Another Skill (such as lov-app-generator) lists Lovinsp integration as a mandatory default invariant.

Do not activate when

• The target is not a browser-rendered frontend project (pure backend service, CLI, library, Skill package with no UI).
• The user only wants to know what lovinsp is and does not require changes to the current project.

This Skill is idempotent: when already integrated, it only performs a version check and will not write configuration repeatedly, so it can be invoked automatically by the model, without requiring step-by-step manual confirmation.

Execution steps

1. Detect project type

Detect the build tool used by the current project:

glob: vite.config.{ts,js,mjs}
glob: webpack.config.{ts,js,mjs}
glob: next.config.{ts,js,mjs}
glob: nuxt.config.{ts,js}
glob: package.json

Determine the bundler type based on the detection result:vite | webpack | esbuild | turbopack | mako

2. Check whether already integrated (idempotency check)

Search in configuration files for:

• lovinsp keyword
• lovinspPlugin keyword
• @lovinsp/ prefix

If it already exists:

1. Check for version updates:pnpm view lovinsp version compare with the current version
2. If there is an update: prompt "current x.x.x → latest y.y.y" and execute pnpm update lovinsp
3. If already up to date: output "✓ lovinsp already integrated (latest v), no action needed"

3. Detect and migrate code-inspector (if present)

Check whether package.json contains code-inspector -related dependencies:

• code-inspector-plugin
• @aspect/code-inspector-plugin

If present, perform the migration:

3.1 Uninstall old dependencies:

pnpm remove code-inspector-plugin
# 或
npm uninstall code-inspector-plugin

3.2 Update references in configuration files:

Replace import statements:

- import { codeInspectorPlugin } from 'code-inspector-plugin';
+ import { lovinspPlugin } from 'lovinsp';

Replace plugin calls:

- codeInspectorPlugin({ bundler: 'vite' }),
+ lovinspPlugin({ bundler: 'vite' }),

3.3 Output migration information:

✓ 已从 code-inspector 迁移到 lovinsp
  - 卸载: code-inspector-plugin
  - 安装: lovinsp
  - 更新: 配置文件

4. Install dependencies (idempotent)

Check whether package.json's devDependencies already contains lovinsp：

• Already exists: skip installation
• Does not exist: execute pnpm add -D lovinsp or npm install -D lovinsp

5. Modify build configuration

Based on the bundler type, add the plugin in the configuration file:

Vite (vite.config.ts):

import { lovinspPlugin } from 'lovinsp';

export default defineConfig({
  plugins: [
    // lovinsp 必须放在框架插件之前
    lovinspPlugin({ bundler: 'vite' }),
    // ... 其他插件
  ]
});

Webpack (webpack.config.js):

const { lovinspPlugin } = require('lovinsp');

module.exports = {
  plugins: [
    lovinspPlugin({ bundler: 'webpack' }),
  ]
};

Next.js with Turbopack (next.config.ts):

import { lovinspPlugin } from 'lovinsp';

export default {
  turbopack: {
    rules: lovinspPlugin({ bundler: 'turbopack' }),
  },
};

Next.js with Webpack (next.config.js):

const { lovinspPlugin } = require('lovinsp');

module.exports = {
  webpack: (config) => {
    config.plugins.push(lovinspPlugin({ bundler: 'webpack' }));
    return config;
  }
};

6. Verify the integration takes effect (must be done when unattended)

Confirming only that "the dependency is installed" is not enough to show the integration succeeded—wrong plugin order or configuration written to a file that is not read will silently fail. So read back once after the configuration is changed.

Static check (done for any bundler):

• The configuration file indeed imports lovinsp and calls lovinspPlugin；
• In a Vite project, lovinspPlugin({ bundler: 'vite' }) is placed before the framework plugin;
• Neither package.json nor the configuration file still has any remaining code-inspector references.

Runtime read-back (for Vite projects, done when the dev server is already running; skip if the user has not started the dev server, do not start or kill the service yourself just to verify):

curl -s http://127.0.0.1:<port>/src/main.tsx | rg "lovinsp-component|lovinsp v"

A hit proves the transform has taken effect. If there is no hit or it is unverified, state truthfully in the result how far the verification went.

build --watch architecture (not vite dev serve）：

• lovinsp's IDE bridge HTTP service starts during the build transform phase and lives as long as the build process; when the project uses vite build --watch(artifacts are statically served by an independent host, rather than vite dev), it must be run with LOVINSP=1 in persistent watch mode; a one-off build will cause the bridge service to die when the process exits, and clicks will not navigate (2026-08-20, 12c007237d)
• When a monorepo is split into two layers, "shell vite build" and "plugin tsdown watch", only the shell layer containing vite.config.ts triggers lovinsp injection; do not substitute the plugin layer's watch for it (2026-08-20, 12c007237d)

7. Output results

After successful integration, output:

✓ lovinsp 集成完成

使用方法：
- Mac: Option + Shift 激活检查器
- Windows: Alt + Shift 激活检查器
- 点击任意 DOM 元素跳转到源码

文档: https://inspector.fe-dev.cn/en

Idempotency guarantee

• Dependency check: skip if already installed
• Configuration check: skip if already configured
• Repeated execution: consistent results, no side effects

Supported frameworks

• Vite: React, Vue2, Vue3, Svelte, Solid, Preact, Qwik, Astro
• Webpack: React, Vue
• Next.js (Turbopack/Webpack)
• Nuxt
• Rspack, Farm, Mako

Execution boundary

A natural language request is enough to trigger it; no legacy slash path, parameter interpolation, or specified assistant is needed. Clearly parse the project, target files, options, and output location in the current request; use the file, search, CLI, and browser capabilities actually provided by the current host. Project dependency versions and external APIs are verified at execution time; do not assume the examples are the current configuration. Bundled scripts are resolved from the Skill root, and business files are resolved from the target project root. Read the current state first, and protect existing uncommitted content and the staging area of other tasks. Analysis and preview requests remain read-only; modifications, commits, pushes, deployments, and releases are each executed according to the explicit scope of the current request. Do not bypass protections, automatically send messages, forcibly terminate user processes, or seize the foreground. On failure, retain the diagnosable original error.

Composition

Before execution, read capability combinations, and hand off to adjacent capabilities according to explicit artifacts.

Runtime context (shared)

Before running, read this package's skill.yaml and Profile contract. The priority order is the current request, project context, this Skill's records, shared preferences, brand/user Profile, and secure defaults. Read only declared fields; hosts without a dedicated runtime may use scripts/profile_store.py to read the shared Profile. For missing configuration, ask only one question that affects the result. Values the user explicitly requests to be saved long-term are written atomically via that script, and the actual path is reported; do not save inferences, credentials, or materials from other tasks.

General feedback loop

When the user provides modification feedback during a Skill-driven task, before continuing with the current artifact you must execute:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Modify only the current task, do not change the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules applicable to all Skills, first update the shared specification.
4. After completing the rule update, versioning, lint, and distribution verification, then apply the modification to the current task.
5. reusable The modification invalidates previous "confirm", "continue", and "send it" instructions; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, and do not automatically proceed to publishing, committing, or other external writes.