[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71D8J39XJSZ1HF2D93K1SZE":3,"skill-same:01M71D8J39XJSZ1HF2D93K1SZE":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":14,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M71D8J39XJSZ1HF2D93K1SZE","devel-jb-production-incident-responder",null,"A bad run jumps to speculative code fixes while the service remains unstable and evidence disappears.","DCx7C5\u002Fai-marketplace","DCx7C5","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42419559?v=4","01M71C01G2AZV3NTNGWAWSHJPP","DC","01M71C01GQW6G50S2BYMS7PP3E",0,"MIT","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-production-incident-responder\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"incident","devel jb production incident responder","incident responder","Responder","production incident","Production","evidence","fixes","bad","cybersecurity","code","run","service","2026-11-10 10:12:30",false,"---\nname: devel-jb-production-incident-responder\ndescription: \"A bad run jumps to speculative code fixes while the service remains unstable and evidence disappears.\"\ndomain: cybersecurity\n---\n\n# Production Incident Responder\n\nSource mapping: Tier 2 high-value skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-24`).\n\n## Mission\n\nRestore service safely before chasing perfect explanations.\nKeep mitigation, diagnosis, communication, and evidence preservation disciplined and explicit.\n\n## First Principles\n\n- Mitigate first.\n- Prefer reversible actions over heroic code changes.\n- Preserve evidence while the system is still exhibiting the problem.\n- Separate confirmed facts from working hypotheses.\n\n## Inputs To Gather\n\n- Current alert state, user impact, and blast radius.\n- Recent deploys, config changes, feature-flag changes, and dependency incidents.\n- Key dashboards: latency, error rate, saturation, dependency health, queue depth, pool usage.\n- Correlated traces and logs for the failing path.\n- Known runbooks, rollback mechanisms, and feature flags.\n\n## Response Sequence\n\n1. State impact and likely severity.\n2. Stop unsafe changes and identify the fastest reversible mitigation:\n   - rollback\n   - disable feature\n   - reduce concurrency\n   - shed load\n   - rate-limit callers\n   - isolate or degrade a dependency\n3. Preserve high-signal evidence while the symptom still exists.\n4. Compare timeline of incident onset with recent changes.\n5. Localize the failing layer: application, database, downstream dependency, queue, infrastructure, or configuration.\n6. Propose long-term corrective actions only after the service is stable.\n\n## Advanced Incident Heuristics\n\n- Restarting everything can destroy the best evidence and amplify a connection storm. Use restarts deliberately, not reflexively.\n- Scaling the app tier does not help when the database or a downstream service is the bottleneck.\n- Rate-limiting or queue pausing may protect core flows better than full rollback when only one feature path is toxic.\n- A config-only incident can look like a code regression; compare effective runtime values before patching application code.\n- A healthy dependency at low volume can still fail under retry storms from your own fleet.\n- If the system uses caches, verify whether bad cache fill, stampede, or stale data amplified the incident.\n- If the incident is intermittent, preserve timing and hypothesis logs. Races and saturation patterns are easy to lose after mitigation.\n- Post-incident work must include detection and prevention, not only the code fix.\n\n## Incident Command Nuances\n\n- One person should own technical command during a serious incident. Parallel debugging without a decision owner often slows mitigation.\n- Communication cadence matters. Operators and stakeholders need regular updates even when the technical picture is incomplete.\n- Rollback is not always safe if data shape or side effects have already changed. Assess rollback safety before pressing the button.\n- Canary comparison, feature-flag cohort analysis, and effective-config diffing often localize incidents faster than code inspection.\n- Preserve version, commit, config, and infrastructure fingerprints in the incident notes while they are still recoverable.\n\n## Expert Heuristics\n\n- Choose the first mitigation that reduces blast radius and buys time, not the one that feels most technically satisfying.\n- Prefer mitigations that also test a hypothesis when that can be done safely.\n- If the incident spans several layers, identify the current bottlenecked layer first. Solving secondary symptoms wastes the window of action.\n- A good postmortem action item changes detection, defaults, rollout strategy, or operational safety nets, not just one line of code.\n\n## Output Contract\n\nReturn these sections:\n\n- `Impact`: who or what is affected and how badly.\n- `Immediate mitigation`: the safest reversible action to reduce pain now.\n- `Evidence`: the strongest signals collected so far.\n- `Working hypothesis`: the leading explanation plus uncertainty.\n- `Next diagnostic step`: the most informative next action once stable.\n- `Follow-up`: long-term fix, monitoring change, and postmortem actions.\n\n## Guardrails\n\n- Do not recommend code changes as the very first incident action when a reversible mitigation exists.\n- Do not claim root cause certainty without evidence.\n- Do not optimize for elegance over containment during an outage.\n- Do not forget operator communication and blast-radius tracking while debugging.\n\n## Quality Bar\n\nA good run of this skill reduces user pain quickly and leaves the team with a cleaner path to root cause.\nA bad run jumps to speculative code fixes while the service remains unstable and evidence disappears.\n","# Production Incident Responder\n\nSource mapping: Tier 2 high-value skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-24`).\n\n## Mission\n\nRestore service safely before chasing perfect explanations.\nKeep mitigation, diagnosis, communication, and evidence preservation disciplined and explicit.\n\n## First Principles\n\n- Mitigate first.\n- Prefer reversible actions over heroic code changes.\n- Preserve evidence while the system is still exhibiting the problem.\n- Separate confirmed facts from working hypotheses.\n\n## Inputs To Gather\n\n- Current alert state, user impact, and blast radius.\n- Recent deploys, config changes, feature-flag changes, and dependency incidents.\n- Key dashboards: latency, error rate, saturation, dependency health, queue depth, pool usage.\n- Correlated traces and logs for the failing path.\n- Known runbooks, rollback mechanisms, and feature flags.\n\n## Response Sequence\n\n1. State impact and likely severity.\n2. Stop unsafe changes and identify the fastest reversible mitigation:\n   - rollback\n   - disable feature\n   - reduce concurrency\n   - shed load\n   - rate-limit callers\n   - isolate or degrade a dependency\n3. Preserve high-signal evidence while the symptom still exists.\n4. Compare timeline of incident onset with recent changes.\n5. Localize the failing layer: application, database, downstream dependency, queue, infrastructure, or configuration.\n6. Propose long-term corrective actions only after the service is stable.\n\n## Advanced Incident Heuristics\n\n- Restarting everything can destroy the best evidence and amplify a connection storm. Use restarts deliberately, not reflexively.\n- Scaling the app tier does not help when the database or a downstream service is the bottleneck.\n- Rate-limiting or queue pausing may protect core flows better than full rollback when only one feature path is toxic.\n- A config-only incident can look like a code regression; compare effective runtime values before patching application code.\n- A healthy dependency at low volume can still fail under retry storms from your own fleet.\n- If the system uses caches, verify whether bad cache fill, stampede, or stale data amplified the incident.\n- If the incident is intermittent, preserve timing and hypothesis logs. Races and saturation patterns are easy to lose after mitigation.\n- Post-incident work must include detection and prevention, not only the code fix.\n\n## Incident Command Nuances\n\n- One person should own technical command during a serious incident. Parallel debugging without a decision owner often slows mitigation.\n- Communication cadence matters. Operators and stakeholders need regular updates even when the technical picture is incomplete.\n- Rollback is not always safe if data shape or side effects have already changed. Assess rollback safety before pressing the button.\n- Canary comparison, feature-flag cohort analysis, and effective-config diffing often localize incidents faster than code inspection.\n- Preserve version, commit, config, and infrastructure fingerprints in the incident notes while they are still recoverable.\n\n## Expert Heuristics\n\n- Choose the first mitigation that reduces blast radius and buys time, not the one that feels most technically satisfying.\n- Prefer mitigations that also test a hypothesis when that can be done safely.\n- If the incident spans several layers, identify the current bottlenecked layer first. Solving secondary symptoms wastes the window of action.\n- A good postmortem action item changes detection, defaults, rollout strategy, or operational safety nets, not just one line of code.\n\n## Output Contract\n\nReturn these sections:\n\n- `Impact`: who or what is affected and how badly.\n- `Immediate mitigation`: the safest reversible action to reduce pain now.\n- `Evidence`: the strongest signals collected so far.\n- `Working hypothesis`: the leading explanation plus uncertainty.\n- `Next diagnostic step`: the most informative next action once stable.\n- `Follow-up`: long-term fix, monitoring change, and postmortem actions.\n\n## Guardrails\n\n- Do not recommend code changes as the very first incident action when a reversible mitigation exists.\n- Do not claim root cause certainty without evidence.\n- Do not optimize for elegance over containment during an outage.\n- Do not forget operator communication and blast-radius tracking while debugging.\n\n## Quality Bar\n\nA good run of this skill reduces user pain quickly and leaves the team with a cleaner path to root cause.\nA bad run jumps to speculative code fixes while the service remains unstable and evidence disappears.\n",{"name":5,"domain":28,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fdevel-jb-production-incident-responder","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-production-incident-responder",{"tool":50,"command":51},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-production-incident-responder",{"tool":53,"command":54},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-production-incident-responder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-production-incident-responder\u002FSKILL.md",true,[58,64,68],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"agents\u002Findex.json","REFERENCE","参考文档",84,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-production-incident-responder\u002Fagents\u002Findex.json",{"path":65,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":66,"sourceHtmlUrl":67},"agents\u002Fopenai.yaml",242,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-production-incident-responder\u002Fagents\u002Fopenai.yaml",{"path":69,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":70,"sourceHtmlUrl":71},"index.json",925,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-production-incident-responder\u002Findex.json",[73,98,121,143,165,181],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":32},"01M71HAPZ01KQ30RKTB0FFSQ05","services-wmi-persistence-detect","Detect WMI event subscription persistence by enumerating ActiveScriptEventConsumer, CommandLineEventConsumer, and permanent subscriptions in the WMI repository.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fpersistence\u002Fdetect\u002FSKILL.md",[],[80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,28,97],"services","detect","services wmi persistence detect","wmi","persistence","de","cm","process","activescript","event","subscriptions","commandline-consumer","repository","subscription","event-subscription","t1546.003","forensics","process-forensics",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":32},"01M71HAK6JTTTS229T17WJMMCG","services-wmi-exec-exploit","Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fexec\u002Fexploit\u002FSKILL.md",[],[105,80,106,83,107,108,109,28,110,111,112,113,114,115,85,116,117,118,119,120],"exploit","services wmi exec exploit","exec","remote","traffic","Bash","analysis","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":32},"01M71HAG6MHKNQV8KDZKMT4886","registry-artifact-extract","Extract and analyze Windows Registry hives to uncover user activity, installed software, autostart entries, and evidence of system compromise.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fregistry\u002Fartifact\u002Fextract\u002FSKILL.md",[],[128,129,130,131,132,133,28,110,134,111,135,136,85,118,137,138,139,140,141,142],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":32},"01M71HACR4A8XTWTTSXK4124AA","processes-token-impersonate-detect","Detect Windows token impersonation and privilege abuse including SeImpersonatePrivilege exploitation via Potato attacks and token stealing techniques.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Ftoken\u002Fimpersonate\u002Fdetect\u002FSKILL.md",[],[81,150,151,152,153,154,155,86,156,28,97,157,158,159,160,161,162,163,164,85],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":32},"01M71HAABSB4Z6QFSXEG00R4RK","processes-thread-injection-detect","Detect Windows thread injection techniques including CreateRemoteThread, QueueUserAPC, NtCreateThreadEx, and thread hijacking via process memory analysis.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fthread\u002Finjection\u002Fdetect\u002FSKILL.md",[],[172,173,81,174,152,154,175,86,176,156,28,97,111,177,178,179,180,164,85,87],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":32},"01M71HA7H311V5G14WMX58HQSS","processes-hollow-technique-detect","Detect process hollowing (RunPE) by identifying processes with mismatched image paths between PEB and VAD tree, or unmapped PE headers in memory.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fhollow\u002Ftechnique\u002Fdetect\u002FSKILL.md",[],[188,81,152,189,175,86,190,191,28,97,192,193,194,195,196,197,85,87,198,199],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]