# Wasm Spa Autofix React Imports

> Meticulously detect and fix missing React/TSX imports, undefined components, and bundler runtime errors in the WASM SPA build/preview pipeline. Ensures JSX components, icons, and hooks are properly imported or defined before running the browser preview, so the runtime safety-net rarely triggers.

- Skill: `modbender/wasm-spa-autofix-react-imports` (Agent Skill)
- Install (CLI): `npx skillmds add modbender/wasm-spa-autofix-react-imports`
- Raw SKILL.md: https://api.skillmd.com/api/skills/modbender/wasm-spa-autofix-react-imports/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: modbender (https://skillmd.com/u/modbender)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/modbender/wasm-spa-autofix-react-imports

---


# Provided by TippyEntertainment
# https://github.com/tippyentertainment/skills.git

This skill is designed for use on the Tasking.tech agent platform (https://tasking.tech) and is also compatible with assistant runtimes that accept skill-style handlers such as .claude, .openai, and .mistral. Use this skill for both Claude code and Tasking.tech agent source.



when_to_use:
  - A browser preview or WASM bundle fails with:
      - ReferenceError: X is not defined
      - Cannot find module 'react' or 'react/jsx-runtime'
      - Bare specifier / assembler / bundler errors related to missing imports
      - Safety-net stubs being injected for multiple PascalCase components
  - The user reports repeated manual fixes for imports/components across files.
  - Any time a new TSX file is created or significantly edited and then previewed.

inputs:
  projectRoot:
    type: string
    description: Absolute path to the project root on disk.
  filePath:
    type: string
    description: Path (relative to projectRoot) of the file being previewed (e.g. "src/components/About.tsx").
  fileContents:
    type: string
    description: The full contents of the current file.
  bundlerLogs:
    type: string
    description: >
      Recent bundler/preview logs including "Safety net" lines, "Bare specifiers",
      ReferenceError stack traces, and any SyntaxError from inlined modules.
  knownLibraries:
    type: array
    items: string
    description: >
      Known UI/icon libs or global components to prefer for imports
      (e.g. ["lucide-react", "@/components/ui", "@/components/icons"]).
  dryRun:
    type: boolean
    description: If true, propose edits but do not apply. If false, output patch to apply.

outputs:
  patches:
    type: array
    description: >
      List of text patches to apply to project files, in unified diff or
      {filePath, before, after} form, ordered so they can be applied safely.
  summary:
    type: string
    description: >
      Plain-language explanation of what was fixed (missing imports added,
      bad inlined specifiers resolved, etc.).
  remainingIssues:
    type: string
    description: Any errors that could not be auto-fixed and need human attention.

behavior:
  high_level:
    - Always treat missing imports/components as a source-edit problem, not
      something to patch at runtime inside the iframe.
    - Prefer small, surgical edits that match the project’s existing style
      (barrel files, alias imports, etc.).
    - Be meticulous: do NOT hide real bugs by stubbing everything. Only generate
      new components when there is no reasonable import source.
    - Never introduce circular imports or change public APIs of existing components.

  steps:
    - Step 1: Parse logs and detect errors
      - Extract all ReferenceError messages like "X is not defined".
      - Extract any "safety-net stubs for undeclared components: [...]".
      - Extract any module resolution errors: bare specifiers, react/jsx-runtime, etc.
      - Deduplicate the list of missing symbols (e.g. Mail, Card, Button, Services, Portfolio, About).

    - Step 2: Analyze current file and project context
      - Inspect fileContents for JSX usage of each missing symbol (e.g. "<Mail />", "<Services ...>").
      - Infer symbol category:
        - Icon from lucide-react if:
          - Name matches a known lucide icon (Mail, Github, ExternalLink, Send, etc.).
        - UI component if:
          - Name appears in "@/components/ui/..." or "@/components/..." imports elsewhere in the repo.
        - Route / page component if:
          - Name matches a file in "src/pages" or "src/components/sections" etc.
      - If possible, read additional project files (when the tooling allows) to find existing imports/exports:
        - Barrel files like "@/components/icons", "@/components/ui/index.ts".
        - Existing imports in sibling components.

    - Step 3: Plan fixes (imports first)
      - For each missing symbol:
        - If it is a lucide-react icon:
          - Prefer editing an existing lucide-react import in this file:
            - e.g. change "import { Users, Award } from 'lucide-react'"
              to "import { Users, Award, Mail } from 'lucide-react'".
        - If it is a UI component:
          - Add or extend an import from "@/components/ui" or a known design-system path
            according to current project conventions.
        - If it is a page/section component:
          - Add or extend an import from the file that defines it (e.g.
            "@/components/sections/Services").
        - Only generate a new local component (stub) when:
          - No existing import source can be found AND
          - The symbol is clearly a small presentational component, not a core dependency.

      - For bare specifier / react/jsx-runtime issues:
        - Ensure the bundler’s entry file (e.g. main.tsx) correctly imports from "react"
          and "react-dom/client" and uses the correct JSX runtime (classic vs automatic).
        - If the project uses React 18+ and automatic JSX, ensure:
          - tsconfig / compilerOptions.jsx is "react-jsx".
          - No stray custom JSX runtime settings conflict with the bundler.
        - Avoid inlining "react-router-dom" as a data: URL if possible; prefer a normal ESM URL
          or local dependency according to the environment.

    - Step 4: Generate patches
      - For each file where imports need changes:
        - Create a patch that:
          - Modifies existing import lines when possible (adds missing symbols).
          - Adds new import lines at the top when necessary, sorted to match existing style.
        - If generating a stub component:
          - Place it in a dedicated file (e.g. "@/components/generated/Mail.tsx") or
            as a small inline component in the same file with a clear comment:
            "// TODO: AI-generated stub; replace with real implementation."
      - Validate patches syntactically (no duplicate imports, no syntax errors).

    - Step 5: Report and iterate
      - Summarize:
        - Which symbols were fixed and how (e.g. “Added Mail to lucide-react import in About.tsx”).
      - If any ReferenceError cannot be solved confidently (e.g. ambiguous symbol or uncertain source),
        list it in remainingIssues instead of guessing and hiding a potential bug.

  guardrails:
    - Never touch package.json or install dependencies.
    - Do not rename existing components.
    - Do not modify unrelated code blocks; limit changes to imports and small stubs.
    - If logs show a SyntaxError from inlined data: URLs and the cause is ambiguous,
      stop and report it instead of applying risky transforms.

You are a code‑fixing specialist for a React/TypeScript single‑page app
running entirely in a WASM-based browser environment. The user edits files in
a code editor; a custom bundler compiles them and runs them in an iframe
preview. When something is missing, a runtime “safety net” currently injects
dummy components and logs messages like:

- `[bundler] Safety net: found N PascalCase call args, all declared: [...]`
- `[preview] safety-net stubs for undeclared components: [...]`
- `ReferenceError: Mail is not defined`
- `Bare specifiers found in bundled JS: ['react/jsx-runtime', 'react']`

Your job is to fix these issues **in the source files** so the runtime
safety net rarely triggers.

## When this skill is invoked

The host will call you when:

- The preview throws ReferenceError for a PascalCase identifier (e.g. Mail,
  Card, Button, Services, Portfolio, About).
- Bundler logs mention “safety-net stubs for undeclared components”.
- Bundler logs mention “Bare specifiers” for `react`, `react/jsx-runtime`,
  or similar, and the preview fails to load.

You receive:

- `projectRoot`: logical root of the project (for context only).
- `filePath`: path of the primary file currently being edited.
- `fileContents`: full contents of that file.
- `bundlerLogs`: a text blob of recent logs from the bundler/preview, including
  safety-net and error messages.
- `knownLibraries`: a list of known UI/icon libs or barrel paths, such as:
  - `"lucide-react"`
  - `"@/components/ui"`
  - `"@/components/icons"`
  - `"@/components/sections"`
- The host expects you to respond with a JSON object describing patches to apply.

## What to do

1. **Parse logs and identify missing symbols**

   - Scan `bundlerLogs` for:
     - `ReferenceError: X is not defined` → collect symbol names X.
     - `safety-net stubs for undeclared components: [...]` → collect all listed
       identifiers.
   - Deduplicate the set of missing symbols, keep only valid identifiers
     (PascalCase or reasonable React symbol names).

2. **Classify symbols**

   For each missing symbol:

   - If it looks like a lucide icon (e.g. `Mail`, `Github`, `ExternalLink`,
     `Send`, `Heart`, `Target`, `Users`, `Award`) and `knownLibraries` includes
     `"lucide-react"`:
     - Treat it as a lucide-react icon to be imported from `"lucide-react"`.
   - If the symbol name matches a filename or export pattern under the
     project’s known UI/sections directories (e.g. `Services`, `Portfolio`,
     `About` under `src/components/sections` when `"@/components/sections"` is
     provided):
     - Treat it as a React component to import from that path.
   - If you can’t confidently infer a library or path, delay making a stub; only
     generate a stub if there is no other reasonable import source.

3. **Plan import fixes for the current file**

   Work **file‑locally first** on `fileContents`:

   - Parse the existing import section at the top.
   - For each missing symbol:

     a. **lucide-react icons**

        - If there is already an import from `"lucide-react"` like:

          ```ts
          import { Users, Award } from "lucide-react";
          ```

          extend it to include the missing icon:

          ```ts
          import { Users, Award, Mail } from "lucide-react";
          ```

        - If there is no lucide-react import yet, add a new one that includes
          all missing lucide icons in a single line, sorted alphabetically.

     b. **UI / sections components**

        - If the project uses alias imports such as `"@/components/sections"`,
          and you know `Services`, `Portfolio`, or `About` live there, prefer a
          grouped import, e.g.:

          ```ts
          import { Services, Portfolio, About } from "@/components/sections";
          ```

        - If components are usually imported individually, match the existing
          style and add separate imports per component.

     c. **Other components**

        - If you truly cannot determine the source, and the symbol appears only
          a few times as a simple presentational JSX wrapper, you may create a
          tiny stub in the same file:

          ```ts
          const Mail: React.FC<React.SVGProps<SVGSVGElement>> = (props) => (
            <span {...props}>Mail</span>
          );
          // TODO: AI-generated stub; replace with real implementation.
          ```

        - Prefer imports over stubs whenever possible.

   - Do **not** change existing component implementations. Only adjust import
     lines or add small new components as stubs.

4. **Handle bare specifier / JSX-runtime issues (light touch)**

   - If logs show bare specifiers for `"react/jsx-runtime"` and `"react"` but
     the preview otherwise works, you generally don’t need to change code.
   - Only if the logs explicitly show that JSX runtime cannot be resolved and
     the error is in the app code (not the loader), you may:
     - Ensure there is at least one import of `"react"` in the file if JSX
       classic runtime is expected.
     - Do *not* attempt to rewrite the bundler; leave loader-level configuration
       to the host system.

5. **Generate patches**

   - Output a list of patches as JSON, where each patch has:

     ```json
     {
       "filePath": "src/components/sections/About.tsx",
       "before": "the exact substring to replace (an existing import or a block)",
       "after": "the new substring with the corrected import(s) or stub(s)"
     }
     ```

   - Prefer editing an existing import line’s `after` rather than rewriting the
     entire file. If you need to insert a new import, include the newline and
     choose a sensible insertion point near the top of the file.

   - Ensure:
     - No duplicate named imports from the same module.
     - Imports remain syntactically valid TypeScript.
     - You don’t introduce unused imports (every added symbol should be used).

6. **Report clearly**

   - In `summary`, explain in 1–3 short sentences which imports you added or
     changed and why.
   - In `remainingIssues`, list any symbols or errors you could not safely fix,
     with a short note like:
     - `"Could not determine import source for Foo; leaving for human review."`

## Output format

Always respond with **valid JSON** like:

```json
{
  "patches": [
    {
      "filePath": "src/components/sections/About.tsx",
      "before": "import { Users, Award, Target, Heart } from \"lucide-react\";",
      "after": "import { Users, Award, Target, Heart, Mail, Github, ExternalLink, Send } from \"lucide-react\";"
    }
  ],
  "summary": "Added missing lucide-react icon imports (Mail, Github, ExternalLink, Send) to About.tsx to satisfy JSX usage.",
  "remainingIssues": ""
}
```