tech-diagnosis

Tech Diagnosis

• Proactive — no specific issue. Scans for highest-value errors and CWV problems, surfaces a prioritized list.
• Reactive — a specific signal is named. Produces a self-contained finding (Summary → Cause → Fix).

---

Setup (always runs first)

1. Noibu MCP — confirm connected. If not, stop.
2. Domain — UUID → use it. Name only → resolve. Nothing → list and ask. Capture platform (Shopify, Magento, etc.).
3. Mode + window — detect mode (see below). Default window: 30 days.
4. TodoList — create with mode-appropriate tasks.

There is no config file. Connector status is detected at runtime by checking tool availability. Preferences are asked per session.

Mode detection

• Proactive — no specific issue given. Domain name alone is proactive. Examples: "run tech diagnosis", "what's broken", "scan for issues".
• Share with vendor — message starts with "Share with vendor:". Skip setup and diagnosis → go to Step P4 Share with vendor.
• Ignore issue — message starts with "Ignore issue #". Skip setup and diagnosis → go to Ignore issue flow.
• Reactive — specific issue named alongside domain: error name, metric + page, Noibu issue ID, page URL, or structured handoff. Also reactive for connector reconfiguration requests.
• Ambiguous — ask: "Are you looking for a scan of what's broken across the store, or do you have a specific issue in mind?"

---

Rules

• No client-side data joins. Each Noibu source on its own terms.
• Don't overstate impact. "Present in X sessions", not "blocking X users". No revenue projections or revLost figures.
• Plain language. Translate Noibu labels; keep identifiers in code style.
• Suppress citation sections.
• First visible output is the result, never narration. No preambles, filler, or "let me pull X".
• Never narrate internals. No tool names, query parameters, API state values, filter logic, or fallback decisions. Retries happen silently.
• Pause only at designated points. Reactive: the connector check before diagnosis (Stage 1, plus Stage 2 only when GitHub was declined), then once after the closing offer widget. Proactive: after findings widget. Open-ended questions only; never AskUserQuestion modals.
• After every show_widget call, output one line only. Proactive: "Select an option on a card above to get started." Reactive (closing offer): "Select an option above, or choose another issue to fix." No summary, no recap, nothing else.
• Page criticality is internal only. Checkout > Cart > PDP > Collection > Home > Other. Never a labeled field.
• Name third-party services specifically. Stack trace says Klaviyo, GTM, Shop Pay → use that name.
• Never render a widget from memory. If resuming from a compacted conversation, re-read this SKILL.md before any output.