[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71D6CX6ZD0GFRJEXDS6ACXG":3,"skill-same:01M71D6CX6ZD0GFRJEXDS6ACXG":73},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":14,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M71D6CX6ZD0GFRJEXDS6ACXG","devel-jb-java-kotlin-migration-assistant",null,"Source mapping: Tier 3 specialized skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-19`).","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-java-kotlin-migration-assistant\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"java kotlin","kotlin","java","devel jb java kotlin migration assistant","migration","assistant","pipeline","spring","cybersecurity","specialized","source","mapping","sk","developer","2026-11-10 10:12:30",false,"---\nname: devel-jb-java-kotlin-migration-assistant\ndescription: \"Source mapping: Tier 3 specialized skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-19`).\"\ndomain: cybersecurity\n---\n# Java Kotlin Migration Assistant\n\nSource mapping: Tier 3 specialized skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-19`).\n\n## Mission\n\nTranslate Java into Kotlin in a way that improves long-term maintainability without introducing semantic drift.\nPrioritize behavioral equivalence first, idiomatic cleanup second, and broad redesign only when explicitly requested.\n\n## Read First\n\n- The Java class and its callers.\n- Existing tests and any contract documentation.\n- Spring annotations, JPA annotations, Jackson annotations, validation annotations, and logging patterns.\n- Build plugins and Kotlin compiler configuration already present in the repository.\n- Whether the module is internal-only or has external consumers that care about binary compatibility.\n\n## Migration Order\n\nUse this default order unless the repository strongly suggests otherwise:\n\n1. Tests and support utilities.\n2. Stateless helpers and internal-only classes.\n3. Services and controllers.\n4. Domain models and DTOs.\n5. Entities and framework-sensitive classes last.\n\nThe most fragile classes are usually entities, heavily proxied services, reflection-heavy config classes, and public library APIs.\n\n## Translation Rules\n\n- Preserve public behavior before pursuing idiomatic compression.\n- Convert fields plus getters plus setters into properties only when that does not change framework expectations.\n- Replace Lombok consciously:\n  - `@Data` is not a universal reason to create a Kotlin `data class`\n  - `@Builder` may map to named\u002Fdefault parameters or may need an explicit builder for Java callers\n  - `@Slf4j` usually becomes an explicit logger field or companion object\n- Replace checked-exception-heavy flows carefully. Kotlin does not enforce checked exceptions, but Java callers may still depend on them semantically.\n- Keep annotations on the correct target after translation. Kotlin use-site targets matter.\n\n## Nullability And Platform-Type Rules\n\n- Treat every Java type crossing into Kotlin as suspect until nullability is proven.\n- Add explicit Kotlin nullability based on contracts, not on optimistic guesses.\n- If upstream Java code lacks annotations, prefer defensive boundary checks over sprinkling `!!`.\n- Distinguish internal invariants from external compatibility. Sometimes a Kotlin non-null model is correct internally even when the Java boundary remains nullable.\n- Re-check collections, optionals, and maps separately. Java usage patterns often hide null values inside otherwise non-null containers.\n\n## Spring And JPA Nuances\n\n- Verify proxy-sensitive classes still work after translation:\n  - `@Transactional`\n  - `@Cacheable`\n  - `@Async`\n  - method security\n- Do not convert JPA entities into `data class`.\n- Preserve JPA constructor, field access, and equality semantics deliberately.\n- Re-check `@ConfigurationProperties`, Jackson creator behavior, and validation annotations after constructor translation.\n- If the project relies on interface-based proxies, do not accidentally move critical behavior into non-interface methods that callers bypass.\n\n## Advanced Migration Traps\n\n- Default parameters can change Java call sites, overload generation, and reflective constructor expectations.\n- Kotlin properties may alter method signatures, bean-introspection shape, and serialization behavior compared with explicit Java accessors.\n- Inline classes, sealed hierarchies, and scope-function-heavy refactors are not first-pass migration tools. Use them after compatibility is proven.\n- Replacing mutable Java collections with read-only Kotlin interfaces does not magically make the backing data immutable.\n- `equals`, `hashCode`, and `toString` generation can silently change semantics for entities, cache keys, and logging.\n- Library modules may need `@JvmStatic`, `@JvmOverloads`, `@JvmField`, or explicit overload preservation for Java consumers.\n- Mixed Java\u002FKotlin modules can expose incremental compilation and annotation-processing surprises. Keep build verification tight during migration.\n\n## Bytecode And Interop Nuances\n\n- `internal` visibility is a module-level bytecode concept, not a source-level privacy guarantee. Do not use it casually in previously public or Java-consumed APIs.\n- Interface default methods, companion objects, and top-level functions alter Java call ergonomics and sometimes reflective lookup paths.\n- SAM conversion, raw types, and wildcard variance can change overload resolution at Java call sites even when Kotlin looks cleaner.\n- `Optional\u003CT>`, primitive wrappers, arrays, and checked exceptions each deserve explicit migration treatment; do not lump them under generic nullability cleanup.\n- Parameter-name retention, generated constructors, and method overloading affect frameworks that use reflection or bytecode-generated proxies.\n- Annotation processors, generated metamodels, and kapt or KSP transitions can change what \"successful migration\" means for the build beyond source compilation.\n\n## Expert Heuristics\n\n- If a class is consumed by Java, optimize for interop predictability before Kotlin elegance.\n- Migrate behaviorally boring classes first to establish project conventions for logging, nullability, builders, and testing.\n- Delay introduction of coroutines, sealed redesigns, and stronger domain modeling until the mixed Java\u002FKotlin seam is stable.\n- When uncertain, preserve explicit methods over collapsing everything into properties or generated helpers. Debuggability and binary stability matter during migration.\n\n## Output Contract\n\nReturn these sections:\n\n- `Migration scope`: what is being converted now and what stays in Java for the moment.\n- `Behavioral invariants`: what must remain unchanged.\n- `Kotlin translation plan`: the exact language-level changes to make.\n- `Framework constraints`: Spring, Jackson, JPA, validation, and binary-compatibility concerns.\n- `Verification`: tests and runtime checks that prove no semantic drift.\n\n## Guardrails\n\n- Do not change public API shape casually.\n- Do not hide uncertain nullability behind `!!`.\n- Do not mix migration with broad architectural redesign unless explicitly asked.\n- Do not make entity, proxy, or serialization classes \"more idiomatic\" at the cost of framework correctness.\n\n## Quality Bar\n\nA good run of this skill yields Kotlin that is safer and cleaner while still behaving like the original Java where it matters.\nA bad run produces \"Java with Kotlin syntax\" or, worse, a pretty rewrite that silently breaks callers, proxies, or persistence.\n","# Java Kotlin Migration Assistant\n\nSource mapping: Tier 3 specialized skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-19`).\n\n## Mission\n\nTranslate Java into Kotlin in a way that improves long-term maintainability without introducing semantic drift.\nPrioritize behavioral equivalence first, idiomatic cleanup second, and broad redesign only when explicitly requested.\n\n## Read First\n\n- The Java class and its callers.\n- Existing tests and any contract documentation.\n- Spring annotations, JPA annotations, Jackson annotations, validation annotations, and logging patterns.\n- Build plugins and Kotlin compiler configuration already present in the repository.\n- Whether the module is internal-only or has external consumers that care about binary compatibility.\n\n## Migration Order\n\nUse this default order unless the repository strongly suggests otherwise:\n\n1. Tests and support utilities.\n2. Stateless helpers and internal-only classes.\n3. Services and controllers.\n4. Domain models and DTOs.\n5. Entities and framework-sensitive classes last.\n\nThe most fragile classes are usually entities, heavily proxied services, reflection-heavy config classes, and public library APIs.\n\n## Translation Rules\n\n- Preserve public behavior before pursuing idiomatic compression.\n- Convert fields plus getters plus setters into properties only when that does not change framework expectations.\n- Replace Lombok consciously:\n  - `@Data` is not a universal reason to create a Kotlin `data class`\n  - `@Builder` may map to named\u002Fdefault parameters or may need an explicit builder for Java callers\n  - `@Slf4j` usually becomes an explicit logger field or companion object\n- Replace checked-exception-heavy flows carefully. Kotlin does not enforce checked exceptions, but Java callers may still depend on them semantically.\n- Keep annotations on the correct target after translation. Kotlin use-site targets matter.\n\n## Nullability And Platform-Type Rules\n\n- Treat every Java type crossing into Kotlin as suspect until nullability is proven.\n- Add explicit Kotlin nullability based on contracts, not on optimistic guesses.\n- If upstream Java code lacks annotations, prefer defensive boundary checks over sprinkling `!!`.\n- Distinguish internal invariants from external compatibility. Sometimes a Kotlin non-null model is correct internally even when the Java boundary remains nullable.\n- Re-check collections, optionals, and maps separately. Java usage patterns often hide null values inside otherwise non-null containers.\n\n## Spring And JPA Nuances\n\n- Verify proxy-sensitive classes still work after translation:\n  - `@Transactional`\n  - `@Cacheable`\n  - `@Async`\n  - method security\n- Do not convert JPA entities into `data class`.\n- Preserve JPA constructor, field access, and equality semantics deliberately.\n- Re-check `@ConfigurationProperties`, Jackson creator behavior, and validation annotations after constructor translation.\n- If the project relies on interface-based proxies, do not accidentally move critical behavior into non-interface methods that callers bypass.\n\n## Advanced Migration Traps\n\n- Default parameters can change Java call sites, overload generation, and reflective constructor expectations.\n- Kotlin properties may alter method signatures, bean-introspection shape, and serialization behavior compared with explicit Java accessors.\n- Inline classes, sealed hierarchies, and scope-function-heavy refactors are not first-pass migration tools. Use them after compatibility is proven.\n- Replacing mutable Java collections with read-only Kotlin interfaces does not magically make the backing data immutable.\n- `equals`, `hashCode`, and `toString` generation can silently change semantics for entities, cache keys, and logging.\n- Library modules may need `@JvmStatic`, `@JvmOverloads`, `@JvmField`, or explicit overload preservation for Java consumers.\n- Mixed Java\u002FKotlin modules can expose incremental compilation and annotation-processing surprises. Keep build verification tight during migration.\n\n## Bytecode And Interop Nuances\n\n- `internal` visibility is a module-level bytecode concept, not a source-level privacy guarantee. Do not use it casually in previously public or Java-consumed APIs.\n- Interface default methods, companion objects, and top-level functions alter Java call ergonomics and sometimes reflective lookup paths.\n- SAM conversion, raw types, and wildcard variance can change overload resolution at Java call sites even when Kotlin looks cleaner.\n- `Optional\u003CT>`, primitive wrappers, arrays, and checked exceptions each deserve explicit migration treatment; do not lump them under generic nullability cleanup.\n- Parameter-name retention, generated constructors, and method overloading affect frameworks that use reflection or bytecode-generated proxies.\n- Annotation processors, generated metamodels, and kapt or KSP transitions can change what \"successful migration\" means for the build beyond source compilation.\n\n## Expert Heuristics\n\n- If a class is consumed by Java, optimize for interop predictability before Kotlin elegance.\n- Migrate behaviorally boring classes first to establish project conventions for logging, nullability, builders, and testing.\n- Delay introduction of coroutines, sealed redesigns, and stronger domain modeling until the mixed Java\u002FKotlin seam is stable.\n- When uncertain, preserve explicit methods over collapsing everything into properties or generated helpers. Debuggability and binary stability matter during migration.\n\n## Output Contract\n\nReturn these sections:\n\n- `Migration scope`: what is being converted now and what stays in Java for the moment.\n- `Behavioral invariants`: what must remain unchanged.\n- `Kotlin translation plan`: the exact language-level changes to make.\n- `Framework constraints`: Spring, Jackson, JPA, validation, and binary-compatibility concerns.\n- `Verification`: tests and runtime checks that prove no semantic drift.\n\n## Guardrails\n\n- Do not change public API shape casually.\n- Do not hide uncertain nullability behind `!!`.\n- Do not mix migration with broad architectural redesign unless explicitly asked.\n- Do not make entity, proxy, or serialization classes \"more idiomatic\" at the cost of framework correctness.\n\n## Quality Bar\n\nA good run of this skill yields Kotlin that is safer and cleaner while still behaving like the original Java where it matters.\nA bad run produces \"Java with Kotlin syntax\" or, worse, a pretty rewrite that silently breaks callers, proxies, or persistence.\n",{"name":5,"domain":27,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fdevel-jb-java-kotlin-migration-assistant","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-java-kotlin-migration-assistant",{"tool":51,"command":52},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-java-kotlin-migration-assistant",{"tool":54,"command":55},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-java-kotlin-migration-assistant","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-java-kotlin-migration-assistant\u002FSKILL.md",true,[59,65,69],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"agents\u002Findex.json","REFERENCE","参考文档",84,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-java-kotlin-migration-assistant\u002Fagents\u002Findex.json",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"agents\u002Fopenai.yaml",242,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-java-kotlin-migration-assistant\u002Fagents\u002Fopenai.yaml",{"path":70,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":71,"sourceHtmlUrl":72},"index.json",934,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-java-kotlin-migration-assistant\u002Findex.json",[74,99,122,144,166,182],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":33},"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",[],[81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,27,98],"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":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":33},"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",[],[106,81,107,84,108,109,110,27,111,112,113,114,115,116,86,117,118,119,120,121],"exploit","services wmi exec exploit","exec","remote","traffic","Bash","analysis","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":33},"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",[],[129,130,131,132,133,134,27,111,135,112,136,137,86,119,138,139,140,141,142,143],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":33},"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",[],[82,151,152,153,154,155,156,87,157,27,98,158,159,160,161,162,163,164,165,86],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":33},"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",[],[173,174,82,175,153,155,176,87,177,157,27,98,112,178,179,180,181,165,86,88],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":33},"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",[],[189,82,153,190,176,87,191,192,27,98,193,194,195,196,197,198,86,88,199,200],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]