Using Tech Diagnosis

Last updated: August 20, 2026

Overview

The Tech Diagnosis skill (/tech-diagnosis) investigates technical problems on your store using your Noibu data. It covers two kinds of problem: JavaScript errors and failed requests that block shoppers, and page performance problems measured by Core Web Vitals.

Where the fix is in code your store owns and your theme is in a connected GitHub repository, the skill can write the change and open a pull request for your team to review and merge.

This skill is included with Noibu's AI plugin.

tech-diagnosis.jpg

This skill covers two working modes:

  • Targeted investigation. Point it at a specific issue and it returns a self-contained investigation — what the problem is, the evidence behind it, the likely cause, and a recommended fix.

  • Broad scan. Run the skill without a target and it scans for your highest-impact errors and performance problems and ranks them.


When to use it

  • When a priority error is hurting checkout or conversion and you need the root cause

  • After a code deploy, to confirm a fix actually landed in the data

  • When a page loads slowly, or a layout-shift problem appeared after an app or theme change

  • When you need to scope a technical issue clearly enough to hand it to a developer or an agency

  • When an error belongs to a third-party app and you need a summary to send its vendor

  • When your error backlog needs cleaning up and you want to dismiss issues you will not act on

Verifying a regression works in both directions: run the skill before and after a deploy and compare.

How to trigger it

Ask “what’s the root cause of issue #299?”, “is this checkout error still active after my deploy?”, “which pages are slowest, and on which devices?”, “did my CLS regression clear up?”, or type /tech-diagnosis.

If you name a specific error or symptom, the skill investigates that.

If you do not, it runs a proactive scan.

Connecting your tools first

Tech Diagnosis checks for three connectors at the start of a run and offers to connect any that are missing.

  • GitHub — lets the skill search your source code to confirm the cause and identify the exact file and line. It is also the only route by which a fix can be written and opened as a pull request.

  • A browser extension for your AI tool, such as the Claude extension for Chrome — lets the skill load the affected page live, including with device emulation, to reproduce what shoppers experience.

  • Your ecommerce platform — lets the skill check live store data during diagnosis, such as confirming whether a variant is genuinely out of stock.

Important: The ecommerce platform connector is read-only, and informs the diagnosis rather than making changes.

A code fix reaches your store only through GitHub. If your Shopify theme is not in a connected GitHub repository, Tech Diagnosis can still diagnose the problem fully, it just cannot open a pull request for it.

What a proactive scan returns

An in-chat dashboard with three sections. Each finding carries a trend badge — Active, Re-emerging, or Improving — and its own action buttons.

  • Issues you can fix. Errors in code your store owns, so the fix is yours to make. The skill looks at the last seven days, keeps only errors still occurring within the last 48 hours that have occurred more than ten times in the week, pulls the stack traces, and keeps only those with at least one frame in your own code. Near-duplicates are merged so one fix can close several issues.

  • Performance. Pages outside the “Good” band on Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift, with the worst metric and its value.

  • Vendor issues. Errors caused by a third-party app that has its own support channel. Platform infrastructure and telemetry errors are filtered out, because there is nothing actionable in them.

Findings are ranked by how often they occur, weighted by where in the funnel they occur — a checkout error outranks a homepage error at the same volume.

Real merchant use-case

After an app or theme change, many merchants use the skill to scan for errors first seen in the last 24 hours to catch anything the change introduced.

Investigating a single issue

Whether you name an issue or click through from a scan, the investigation follows the same path: read Noibu’s own analysis of what happened and why, load the live page to reproduce it, search your connected repository for the affected code, and query platform data to confirm or rule out the hypothesis.

The result is a diagnosis in plain language: what the issue is, the sessions and error detail behind it, the most likely cause, and a recommended fix.

Acting on a diagnosis

Four actions are offered at the end of an investigation.

Apply the fix automatically

Available when GitHub is connected and the investigation identified a specific file and line. Clicking it creates a branch, writes the code change, and opens a pull request carrying a low, medium, or high risk label.

Your team reviews the pull request and merges it.

If your AI workspace has the GitHub connector active, you can instruct the merge from the conversation without opening GitHub.

Real merchant use-case

A homewares brand with limited development resources cut bug diagnosis from days to under an hour, and confirmed in the data that a fix had landed before the next sale period opened.

Open a ticket

Creates a ticket in a connected tool like Linear, Jira, GitHub Issues, or Notion, for issues you want a person to pick up. Available for fixable errors and performance findings.

Share with vendor

Generates a vendor-facing summary you can copy, or send directly by email or Slack if those connectors are active. Use this for third-party app errors that are not yours to fix.

Ignore

Marks the issue as closed or ignored in Noibu for backlog cleanup.

Scheduling a recurring scan

At the end of a scan, the skill offers to run it on a schedule. This allows you to build an always-on monitoring and resolution workflow.

A recurring scan can optionally open a draft pull request for each fixable error and each performance finding it identifies. A human reviewer is still required to merge the code for changes to go live.