known-issue-research
Known Issue Research
Internal shared skill for the technical-analysis stage of code-fixing workflows. Decides when a confirmed problem needs external web research before (or instead of) deeper code-level analysis, and how to act on the results.
Prerequisite check: this skill declares
effective-web-researchin frontmatterdependencies. On load, verify it is available; if missing, abort and print the install command (npx skills add FuDesign2008/open-skills -g). No silent fallback.
Step-number parameterization
This skill is shared by workflows with different step numbering. All jump targets below are written as placeholders — {impact-assessment step}, {root-cause step}, {upstream-eval step} — and the referencing workflow states its own numbering inline at the reference line (e.g. "jump to step 4"). Never hardcode a workflow's step numbers here.
1. Research routing triage
Run immediately after the problem's existence is confirmed. Decide which class the root cause most likely falls into — this adjusts the priority of later steps, never replaces them:
| Route | Signals | Emphasis |
|---|---|---|
| 🟢 Internal-first | About "our code/logic/conventions"; root cause suspected in this repo | Code location first; quick search (§2) as optional fallback; root-cause analysis is the core |
| 🔵 External-first | Named third-party lib/framework/API + version; or "how to use / why / any known issue"; or any §2 trigger hits (platform silent failure / nested host / no code-level suspects) | Quick search (§2) becomes the primary action — search known cases first |
| 🟣 Hybrid (external-then-internal) | External concept + internal object ("does the X lib we use have vulnerability Y", "apply pattern X to our code") | §2 first to understand the concept externally, then internal root-cause analysis to apply it |