[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71D64W0BCZV3Y3TDZNF536K":3,"skill-same:01M71D64W0BCZV3Y3TDZNF536K":71},{"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":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":14,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M71D64W0BCZV3Y3TDZNF536K","devel-jb-integration-resilience-engineer",null,"A bad run adds retries and circuit breakers everywhere while increasing duplication, latency, and operational confusion.","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-integration-resilience-engineer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"engineer","devel jb integration resilience engineer","resilience","integration","latency","bad","retries","cybersecurity","operational","run","duplication","circuit","2026-11-10 10:12:30",false,"---\nname: devel-jb-integration-resilience-engineer\ndescription: \"A bad run adds retries and circuit breakers everywhere while increasing duplication, latency, and operational confusion.\"\ndomain: cybersecurity\n---\n\n# Integration Resilience Engineer\n\nSource mapping: Tier 2 high-value skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-12`).\n\n## Mission\n\nMake integrations behave predictably under partial failure, timeouts, retries, and duplicate delivery.\nTreat every remote boundary as unreliable and every retry as a potential multiplier of load.\n\n## Read First\n\n- External API or messaging contract, including status codes or message schema.\n- SLA, timeout budget, rate-limit rules, and idempotency guarantees.\n- Current client configuration, retry logic, circuit breaker settings, and scheduling configuration.\n- Business criticality of the operation and acceptable degradation behavior.\n- Existing observability around request outcome, retry count, queue depth, and DLQ.\n\n## Design Sequence\n\n1. Classify the operation:\n   - read-only or state-changing\n   - idempotent or non-idempotent\n   - synchronous user path or asynchronous background path\n2. Set timeout budgets from the caller's SLO backward.\n3. Decide which failures are retryable and which are terminal.\n4. Decide where deduplication or idempotency must be enforced.\n5. Add circuit breaking, bulkheading, or rate limiting where failure amplification is plausible.\n6. Add metrics, tracing, and structured outcome logging.\n\n## HTTP Client Rules\n\n- Set connect and response timeouts explicitly.\n- Retry only when the operation is safe to replay or explicitly idempotent.\n- Use exponential backoff with jitter, not fixed-interval retries.\n- Respect `429`, `Retry-After`, and dependency-specific throttling semantics.\n- Distinguish timeout before request reached the server from timeout after side effects may already have happened.\n- Map downstream errors into local semantics deliberately. Do not leak raw remote failures by accident.\n\n## Messaging And Scheduling Rules\n\n- Treat consumers as at-least-once unless a stronger guarantee is proven end to end.\n- Design deduplication with stable keys and durable storage when duplicate delivery matters.\n- Use DLQ or poison-message handling instead of infinite redelivery loops.\n- Be explicit about ordering guarantees and partition-key strategy.\n- For scheduled jobs, prevent overlap with distributed locking when multiple nodes can run the same task.\n- Account for clock skew, long-running jobs, and partial completion when scheduling recurring work.\n\n## Advanced Failure Modes\n\n- Retries at multiple layers multiply explosively. One client retry policy plus platform retry plus queue retry can create storms.\n- Circuit breakers without sensible fallback or operator visibility often only change the failure shape.\n- Fallback data can become a stale correctness problem, not merely a degraded UX.\n- A timeout on a state-changing call may leave the caller uncertain whether the remote side succeeded. This is an idempotency design problem, not just a timeout problem.\n- DLQ without replay discipline creates permanent operational debt.\n- Exactly-once is usually a system property claim, not an individual code property. Be skeptical and precise.\n- If message schema evolution is expected, plan backward-compatible consumers before the first change arrives.\n\n## Boundary-Specific Nuances\n\n- HTTP connection pooling, DNS caching, TLS handshakes, and per-host limits can dominate latency long before business logic does. Client-level transport settings matter.\n- A `202 Accepted` plus asynchronous completion model may be safer than a synchronous state-changing call when dependency latency is unpredictable.\n- Outbox and inbox patterns solve different halves of reliability. Do not talk about one as if it covers both publish and consume idempotency.\n- Kafka rebalance behavior, consumer lag, and partition skew are part of resiliency, not only throughput tuning.\n- Schedulers need both overlap prevention and business-level idempotency. A distributed lock alone does not make the job semantically safe.\n\n## Expert Heuristics\n\n- Put a retry budget around each integration path. If retries exceed the budget, fail fast and surface the degradation clearly.\n- If a dependency is slow but not down, circuit breaking may be less useful than tight timeouts plus bulkheads.\n- If the caller cannot safely determine whether a remote write succeeded, design a reconciliation path, not only a retry policy.\n- If a queue consumer is critical, define operator behavior for DLQ replay before the first poison message appears.\n\n## Output Contract\n\nReturn these sections:\n\n- `Failure model`: what can go wrong at this boundary.\n- `Resilience policy`: timeouts, retries, circuit breaking, bulkheads, fallback, and deduplication.\n- `Idempotency rule`: how duplicate or uncertain delivery is handled.\n- `Operational signals`: which metrics, logs, traces, and alerts are required.\n- `Minimal implementation plan`: client, listener, scheduler, or config changes to make.\n- `Verification`: chaos, integration, or replay tests that prove the design.\n\n## Guardrails\n\n- Do not retry non-idempotent operations by default.\n- Do not add retries without jitter and a retry budget.\n- Do not use fallbacks that silently violate business invariants.\n- Do not leave outcome ambiguity unexplained for timed-out state changes.\n- Do not build resilience policies that operators cannot observe.\n\n## Quality Bar\n\nA good run of this skill produces an integration policy that fails in controlled, explainable ways.\nA bad run adds retries and circuit breakers everywhere while increasing duplication, latency, and operational confusion.\n","# Integration Resilience Engineer\n\nSource mapping: Tier 2 high-value skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-12`).\n\n## Mission\n\nMake integrations behave predictably under partial failure, timeouts, retries, and duplicate delivery.\nTreat every remote boundary as unreliable and every retry as a potential multiplier of load.\n\n## Read First\n\n- External API or messaging contract, including status codes or message schema.\n- SLA, timeout budget, rate-limit rules, and idempotency guarantees.\n- Current client configuration, retry logic, circuit breaker settings, and scheduling configuration.\n- Business criticality of the operation and acceptable degradation behavior.\n- Existing observability around request outcome, retry count, queue depth, and DLQ.\n\n## Design Sequence\n\n1. Classify the operation:\n   - read-only or state-changing\n   - idempotent or non-idempotent\n   - synchronous user path or asynchronous background path\n2. Set timeout budgets from the caller's SLO backward.\n3. Decide which failures are retryable and which are terminal.\n4. Decide where deduplication or idempotency must be enforced.\n5. Add circuit breaking, bulkheading, or rate limiting where failure amplification is plausible.\n6. Add metrics, tracing, and structured outcome logging.\n\n## HTTP Client Rules\n\n- Set connect and response timeouts explicitly.\n- Retry only when the operation is safe to replay or explicitly idempotent.\n- Use exponential backoff with jitter, not fixed-interval retries.\n- Respect `429`, `Retry-After`, and dependency-specific throttling semantics.\n- Distinguish timeout before request reached the server from timeout after side effects may already have happened.\n- Map downstream errors into local semantics deliberately. Do not leak raw remote failures by accident.\n\n## Messaging And Scheduling Rules\n\n- Treat consumers as at-least-once unless a stronger guarantee is proven end to end.\n- Design deduplication with stable keys and durable storage when duplicate delivery matters.\n- Use DLQ or poison-message handling instead of infinite redelivery loops.\n- Be explicit about ordering guarantees and partition-key strategy.\n- For scheduled jobs, prevent overlap with distributed locking when multiple nodes can run the same task.\n- Account for clock skew, long-running jobs, and partial completion when scheduling recurring work.\n\n## Advanced Failure Modes\n\n- Retries at multiple layers multiply explosively. One client retry policy plus platform retry plus queue retry can create storms.\n- Circuit breakers without sensible fallback or operator visibility often only change the failure shape.\n- Fallback data can become a stale correctness problem, not merely a degraded UX.\n- A timeout on a state-changing call may leave the caller uncertain whether the remote side succeeded. This is an idempotency design problem, not just a timeout problem.\n- DLQ without replay discipline creates permanent operational debt.\n- Exactly-once is usually a system property claim, not an individual code property. Be skeptical and precise.\n- If message schema evolution is expected, plan backward-compatible consumers before the first change arrives.\n\n## Boundary-Specific Nuances\n\n- HTTP connection pooling, DNS caching, TLS handshakes, and per-host limits can dominate latency long before business logic does. Client-level transport settings matter.\n- A `202 Accepted` plus asynchronous completion model may be safer than a synchronous state-changing call when dependency latency is unpredictable.\n- Outbox and inbox patterns solve different halves of reliability. Do not talk about one as if it covers both publish and consume idempotency.\n- Kafka rebalance behavior, consumer lag, and partition skew are part of resiliency, not only throughput tuning.\n- Schedulers need both overlap prevention and business-level idempotency. A distributed lock alone does not make the job semantically safe.\n\n## Expert Heuristics\n\n- Put a retry budget around each integration path. If retries exceed the budget, fail fast and surface the degradation clearly.\n- If a dependency is slow but not down, circuit breaking may be less useful than tight timeouts plus bulkheads.\n- If the caller cannot safely determine whether a remote write succeeded, design a reconciliation path, not only a retry policy.\n- If a queue consumer is critical, define operator behavior for DLQ replay before the first poison message appears.\n\n## Output Contract\n\nReturn these sections:\n\n- `Failure model`: what can go wrong at this boundary.\n- `Resilience policy`: timeouts, retries, circuit breaking, bulkheads, fallback, and deduplication.\n- `Idempotency rule`: how duplicate or uncertain delivery is handled.\n- `Operational signals`: which metrics, logs, traces, and alerts are required.\n- `Minimal implementation plan`: client, listener, scheduler, or config changes to make.\n- `Verification`: chaos, integration, or replay tests that prove the design.\n\n## Guardrails\n\n- Do not retry non-idempotent operations by default.\n- Do not add retries without jitter and a retry budget.\n- Do not use fallbacks that silently violate business invariants.\n- Do not leave outcome ambiguity unexplained for timed-out state changes.\n- Do not build resilience policies that operators cannot observe.\n\n## Quality Bar\n\nA good run of this skill produces an integration policy that fails in controlled, explainable ways.\nA bad run adds retries and circuit breakers everywhere while increasing duplication, latency, and operational confusion.\n",{"name":5,"domain":26,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fdevel-jb-integration-resilience-engineer","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-integration-resilience-engineer",{"tool":49,"command":50},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-integration-resilience-engineer",{"tool":52,"command":53},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-integration-resilience-engineer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-integration-resilience-engineer\u002FSKILL.md",true,[57,63,67],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"agents\u002Findex.json","REFERENCE","参考文档",84,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-integration-resilience-engineer\u002Fagents\u002Findex.json",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"agents\u002Fopenai.yaml",267,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-integration-resilience-engineer\u002Fagents\u002Fopenai.yaml",{"path":68,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":69,"sourceHtmlUrl":70},"index.json",952,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-integration-resilience-engineer\u002Findex.json",[72,97,120,142,164,180],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":31},"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",[],[79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,26,96],"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":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":31},"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",[],[104,79,105,82,106,107,108,26,109,110,111,112,113,114,84,115,116,117,118,119],"exploit","services wmi exec exploit","exec","remote","traffic","Bash","analysis","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":31},"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",[],[127,128,129,130,131,132,26,109,133,110,134,135,84,117,136,137,138,139,140,141],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":31},"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",[],[80,149,150,151,152,153,154,85,155,26,96,156,157,158,159,160,161,162,163,84],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":31},"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",[],[171,172,80,173,151,153,174,85,175,155,26,96,110,176,177,178,179,163,84,86],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":31},"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",[],[187,80,151,188,174,85,189,190,26,96,191,192,193,194,195,196,84,86,197,198],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]