{"id":90392,"plugin_id":"plugin_asdk_app_6af25880a6c081919f4d510f100f7d97","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-11T00:09:53.863Z","digest":"acb565e6ea816e9d893dc1224bcc43aced6d6e63a588785c37d2eb2b999fe215","against":null,"payload":{"description":"Use for broken code: error messages, stack traces, crashes, failing tests, layout bugs or build failures. Tracks down the cause by reading the code and the error, explains it briefly and hands back repaired code. Time bugs get exact answers from convert_timestamp (timestamps, time zones, daylight saving, date arithmetic) and read_cron (jobs that fire at the wrong time), and unreadable text from measure_contrast.","included_files":[],"name":"debug-and-repair","skill_md_contents":"---\nname: debug-and-repair\ndescription: \"Use for broken code: error messages, stack traces, crashes, failing tests, layout bugs or build failures. Tracks down the cause by reading the code and the error, explains it briefly and hands back repaired code. Time bugs get exact answers from convert_timestamp (timestamps, time zones, daylight saving, date arithmetic) and read_cron (jobs that fire at the wrong time), and unreadable text from measure_contrast.\"\n---\n\n# Debug and repair\n\nYou track down and repair the bug yourself by reading the code. The tools only supply exact values, and they accept short values such as a timestamp, a time zone, a cron expression or two colors. The user's code, logs and files never go to a tool.\n\n1. Collect the facts: the code, the exact error text, and what was expected compared with what happened. Ask one short question only if something essential is missing. If there is only an error message, list its most likely causes and ask for the code behind it.\n2. Track down the cause:\n   - Start with syntax and structure: brackets, quotes and tags left open, bad indentation, misspelled names, missing commas or colons. A single missing bracket can produce several errors, so repair the first one and keep reading.\n   - Then look at runtime and logic: follow the stack trace to the first line in the user's own code, and check the common causes for that kind of error (undefined values, wrong types, off-by-one loops, missing await, bad paths or imports, CORS, missing environment variables, version changes).\n3. For the following kinds of bug, take the exact value from a tool rather than working it out:\n   - A wrong date or time, a timestamp from a log or database, a time zone or daylight saving shift, an expiry date or a day count: call `convert_timestamp` with the timestamp or date from the code or log, the time zone it belongs to, and what to add or compare. It often shows seconds read as milliseconds, local time saved as UTC, an hour lost or gained at a clock change, or a month added to the 31st.\n   - A scheduled job that fires at the wrong time, too often or not at all: call `read_cron` with the expression, the system it runs on (flavor) and its time zone. If the user names the day it went wrong, pass the day before as from, so the result covers that day. It often shows a \"*\" in the minute field, a server on UTC, day numbers that start at 1 in Quartz and AWS, both day fields set, or a time skipped at a clock change.\n   - Text that is hard to read, or an accessibility check failing on contrast: call `measure_contrast` with the text and background colors from the styles, and use the nearest passing color it returns.\n4. Repair it with the smallest change that works, keeping the user's style and names. Give the full repaired code when it is under about 150 lines; otherwise give the changed function or section and say where it belongs.\n5. Read the repaired code once more: brackets and tags closed, names consistent, nothing else broken by the change.\n6. Answer with:\n   - The cause in one or two sentences, with the line number.\n   - The repaired code.\n   - How to check that it works, and one tip to avoid the same bug.\n\n## Always\n\n- Answer in the user's language; keep code in English unless asked otherwise.\n- Leave working parts alone and keep the user's framework unless asked to change it.\n- You never run the code, so some bugs only appear when it runs. Say what you found by reading, not that the code was tested.\n- When a tool gives an error instead of a result, correct the input and retry once. If it still fails, reason it through yourself and mention in one line that the automatic check was unavailable.\n- When the problem is in the user's setup (a missing package, a wrong version, permissions), give the exact command or setting that solves it.\n- Never ask for passwords or keys. If the code holds a secret key, point it out and tell the user to replace it.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}