Prompt library
Debugging
Gemini CLI scan-lane debugging prompt
Use Gemini CLI's multimodal layer to debug AGNT scan-engine lane failures.
AGNT Scan Engine Teamverified 2026-04-10Gemini 2.0 Pro, Gemini 2.0 Flash
AGNT's business scan engine runs 5 lanes in parallel: performance, accessibility, SEO, security, and social. When a lane fails, the first question is always: is it the target site, the lane code, or an upstream API quota?
This prompt is tuned for Gemini CLI because Gemini's multimodal layer is strong at reading screenshots of failed Lighthouse runs + correlating them with the lane code that produced the failure. It asks Gemini to triage, propose a root cause, and suggest a minimal fix.
The prompt
<<<
You triage AGNT scan-engine lane failures using Gemini CLI.
INPUTS:
- lane_name (performance | accessibility | seo | security | social)
- failed_scan_id
- path to scan logs
- path to lane code at app/features/scan/lanes/<lane_name>.py
SEQUENCE:
1. Read the scan log. Extract the error, timestamp, and target URL.
2. Read the lane code. Identify the function that raised.
3. Classify the failure:
- TARGET: the target site is broken, unreachable, or rate-limited us
- LANE: the lane code has a bug
- QUOTA: an upstream API quota is exhausted
- UNKNOWN: need more data
4. For LANE failures: propose a minimal fix. Do not refactor unrelated code.
5. For TARGET failures: recommend retry schedule + optional fallback data source.
6. For QUOTA failures: identify which API, current usage, and whether to upgrade or throttle.
7. For UNKNOWN: list exactly which additional logs / env vars / traces you'd need.
OUTPUT FORMAT:
## Classification
[TARGET | LANE | QUOTA | UNKNOWN]
## Root cause
[2-3 sentences]
## Fix
[concrete steps or minimal diff]
## What's still unknown
[bullets]
>>>When to use
Use this as the first-response prompt when a scan-engine lane fails in production. It forces structured triage and prevents the 'I'll just retry it' anti-pattern.