[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71D6FP536JTKHC20DJVZ6F3":3,"skill-same:01M71D6FP536JTKHC20DJVZ6F3":78},{"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":23,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M71D6FP536JTKHC20DJVZ6F3","devel-jb-jpa-spring-data-kotlin-mapper",null,"A bad run proposes mappings that look neat in Kotlin but violate JPA identity, proxy, or loading semantics.","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-jpa-spring-data-kotlin-mapper\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37],"kotlin","spring","devel jb jpa spring data kotlin mapper","data","jpa","mapper","proxy","loading","bad","cybersecurity","run","look","but","identity","2026-11-10 10:12:30",false,"---\nname: devel-jb-jpa-spring-data-kotlin-mapper\ndescription: \"A bad run proposes mappings that look neat in Kotlin but violate JPA identity, proxy, or loading semantics.\"\ndomain: cybersecurity\n---\n\n# JPA Spring Data Kotlin Mapper\n\nSource mapping: Tier 1 critical skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-10`).\n\n## Mission\n\nGenerate and review persistence mappings that are correct for both Hibernate semantics and Kotlin semantics.\nPrevent bugs that compile cleanly but fail under lazy loading, dirty checking, identity comparison, or query load.\n\n## Read First\n\n- Entity classes and mapped superclasses.\n- Repository interfaces and custom queries.\n- Relevant service methods and transaction boundaries.\n- SQL logs, execution plans, or symptoms such as N+1, deadlocks, or stale reads.\n- Build files to verify JPA-related Kotlin compiler plugins.\n\n## Entity Design Rules\n\n- Do not generate JPA entities as `data class`.\n- Keep transport DTOs and persistence entities separate unless the repository clearly uses a shared model on purpose.\n- Model required columns as non-null only when object construction and persistence lifecycle make that safe.\n- Treat lazy associations and optional associations carefully. Nullable is often the honest model.\n- Use `lateinit` only when the project already accepts that tradeoff and the lifecycle is safe.\n\n## Identity And Equality Rules\n\n- Never accept all-field `equals` and `hashCode` generated by a `data class` entity.\n- Follow project conventions when they already define an entity identity strategy.\n- If no convention exists, choose an identity approach that is stable under persistence and proxying, then explain the tradeoff.\n- Be explicit about mutable fields and lazy associations when discussing equality semantics.\n\n## Query And Fetch Rules\n\n- Diagnose N+1 by looking at actual query count or SQL logs, not by guessing from annotations alone.\n- Prefer targeted fetch solutions:\n  - `@EntityGraph`\n  - `JOIN FETCH`\n  - batch fetching\n  - DTO projection\n- Be careful with collection fetch joins plus pagination. Call out the tradeoff instead of hiding it.\n- Use indexes and uniqueness constraints to support real query patterns and idempotency guarantees.\n\n## Advanced ORM Traps\n\n- Maintain both sides of bidirectional associations in domain methods or helper functions. Half-updated object graphs are a common source of subtle bugs.\n- `orphanRemoval` and cascade remove are not interchangeable. Explain the lifecycle semantics before choosing one.\n- `toString`, debug logging, JSON serialization, and IDE inspection can trigger lazy loads. Treat them as potential side effects, not harmless utilities.\n- Bulk update or delete queries bypass the persistence context and lifecycle callbacks. Call out when subsequent reads may be stale until clear or reload.\n- Multiple bag fetches can explode under Hibernate. If a collection-heavy fetch plan looks \"obviously convenient,\" verify whether the ORM can execute it safely.\n- `Set`-based collections plus mutable equality are especially dangerous. Collection membership can break after entity state changes.\n- `@Version` is usually the clearest optimistic concurrency mechanism when concurrent updates matter. Mention it explicitly when the use case can lose updates.\n- If `open-in-view` is disabled, DTO mapping that touches lazy fields must happen inside a deliberate transaction boundary.\n\n## Expert Heuristics\n\n- Choose entity shape for write correctness first and read shape second. If reads need a different shape, use projections or dedicated queries.\n- If a query is hot and read-only, DTO projection is often a better optimization than tuning entity graphs indefinitely.\n- If a relationship exists only to simplify one query, question whether it belongs in the entity model or in a query model.\n- Treat database indexes as part of the persistence design, not as a late production optimization.\n\n## Kotlin-Specific Checks\n\n- Verify `kotlin(\"plugin.jpa\")` or equivalent no-arg support when JPA entities exist.\n- Verify classes and members are compatible with proxying where needed.\n- Verify nullability reflects database truth rather than wishful API design.\n- Verify repository return types and service expectations agree on null handling.\n\n## Output Contract\n\nReturn these sections:\n\n- `Persistence model`: the entity and relationship shape that should exist.\n- `Correctness risks`: identity, lazy loading, transactional access, and nullability traps.\n- `Performance risks`: N+1, fetch plan, query shape, pagination, and index concerns.\n- `Recommended changes`: entity, repository, and query updates in minimal-diff form.\n- `Verification`: tests or SQL-level checks that confirm the mapping works as intended.\n\n## Guardrails\n\n- Do not recommend `FetchType.EAGER` everywhere to silence lazy loading symptoms.\n- Do not expose entities directly through API responses by default.\n- Do not use `data class` entities.\n- Do not claim an N+1 fix without explaining how the fetch plan changes query behavior.\n- Do not place all persistence intelligence in repositories if the service layer controls the real access pattern.\n\n## Quality Bar\n\nA good run of this skill improves correctness and query behavior together.\nA bad run proposes mappings that look neat in Kotlin but violate JPA identity, proxy, or loading semantics.\n","# JPA Spring Data Kotlin Mapper\n\nSource mapping: Tier 1 critical skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-10`).\n\n## Mission\n\nGenerate and review persistence mappings that are correct for both Hibernate semantics and Kotlin semantics.\nPrevent bugs that compile cleanly but fail under lazy loading, dirty checking, identity comparison, or query load.\n\n## Read First\n\n- Entity classes and mapped superclasses.\n- Repository interfaces and custom queries.\n- Relevant service methods and transaction boundaries.\n- SQL logs, execution plans, or symptoms such as N+1, deadlocks, or stale reads.\n- Build files to verify JPA-related Kotlin compiler plugins.\n\n## Entity Design Rules\n\n- Do not generate JPA entities as `data class`.\n- Keep transport DTOs and persistence entities separate unless the repository clearly uses a shared model on purpose.\n- Model required columns as non-null only when object construction and persistence lifecycle make that safe.\n- Treat lazy associations and optional associations carefully. Nullable is often the honest model.\n- Use `lateinit` only when the project already accepts that tradeoff and the lifecycle is safe.\n\n## Identity And Equality Rules\n\n- Never accept all-field `equals` and `hashCode` generated by a `data class` entity.\n- Follow project conventions when they already define an entity identity strategy.\n- If no convention exists, choose an identity approach that is stable under persistence and proxying, then explain the tradeoff.\n- Be explicit about mutable fields and lazy associations when discussing equality semantics.\n\n## Query And Fetch Rules\n\n- Diagnose N+1 by looking at actual query count or SQL logs, not by guessing from annotations alone.\n- Prefer targeted fetch solutions:\n  - `@EntityGraph`\n  - `JOIN FETCH`\n  - batch fetching\n  - DTO projection\n- Be careful with collection fetch joins plus pagination. Call out the tradeoff instead of hiding it.\n- Use indexes and uniqueness constraints to support real query patterns and idempotency guarantees.\n\n## Advanced ORM Traps\n\n- Maintain both sides of bidirectional associations in domain methods or helper functions. Half-updated object graphs are a common source of subtle bugs.\n- `orphanRemoval` and cascade remove are not interchangeable. Explain the lifecycle semantics before choosing one.\n- `toString`, debug logging, JSON serialization, and IDE inspection can trigger lazy loads. Treat them as potential side effects, not harmless utilities.\n- Bulk update or delete queries bypass the persistence context and lifecycle callbacks. Call out when subsequent reads may be stale until clear or reload.\n- Multiple bag fetches can explode under Hibernate. If a collection-heavy fetch plan looks \"obviously convenient,\" verify whether the ORM can execute it safely.\n- `Set`-based collections plus mutable equality are especially dangerous. Collection membership can break after entity state changes.\n- `@Version` is usually the clearest optimistic concurrency mechanism when concurrent updates matter. Mention it explicitly when the use case can lose updates.\n- If `open-in-view` is disabled, DTO mapping that touches lazy fields must happen inside a deliberate transaction boundary.\n\n## Expert Heuristics\n\n- Choose entity shape for write correctness first and read shape second. If reads need a different shape, use projections or dedicated queries.\n- If a query is hot and read-only, DTO projection is often a better optimization than tuning entity graphs indefinitely.\n- If a relationship exists only to simplify one query, question whether it belongs in the entity model or in a query model.\n- Treat database indexes as part of the persistence design, not as a late production optimization.\n\n## Kotlin-Specific Checks\n\n- Verify `kotlin(\"plugin.jpa\")` or equivalent no-arg support when JPA entities exist.\n- Verify classes and members are compatible with proxying where needed.\n- Verify nullability reflects database truth rather than wishful API design.\n- Verify repository return types and service expectations agree on null handling.\n\n## Output Contract\n\nReturn these sections:\n\n- `Persistence model`: the entity and relationship shape that should exist.\n- `Correctness risks`: identity, lazy loading, transactional access, and nullability traps.\n- `Performance risks`: N+1, fetch plan, query shape, pagination, and index concerns.\n- `Recommended changes`: entity, repository, and query updates in minimal-diff form.\n- `Verification`: tests or SQL-level checks that confirm the mapping works as intended.\n\n## Guardrails\n\n- Do not recommend `FetchType.EAGER` everywhere to silence lazy loading symptoms.\n- Do not expose entities directly through API responses by default.\n- Do not use `data class` entities.\n- Do not claim an N+1 fix without explaining how the fetch plan changes query behavior.\n- Do not place all persistence intelligence in repositories if the service layer controls the real access pattern.\n\n## Quality Bar\n\nA good run of this skill improves correctness and query behavior together.\nA bad run proposes mappings that look neat in Kotlin but violate JPA identity, proxy, or loading semantics.\n",{"name":5,"domain":33,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fdevel-jb-jpa-spring-data-kotlin-mapper","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-jpa-spring-data-kotlin-mapper",{"tool":56,"command":57},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-jpa-spring-data-kotlin-mapper",{"tool":59,"command":60},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill devel-jb-jpa-spring-data-kotlin-mapper","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-jpa-spring-data-kotlin-mapper\u002FSKILL.md",true,[64,70,74],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"agents\u002Findex.json","REFERENCE","参考文档",84,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-jpa-spring-data-kotlin-mapper\u002Fagents\u002Findex.json",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml",238,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-jpa-spring-data-kotlin-mapper\u002Fagents\u002Fopenai.yaml",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"index.json",931,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdevel-jb-jpa-spring-data-kotlin-mapper\u002Findex.json",[79,104,127,149,171,187],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":38},"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",[],[86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,33,103],"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":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":38},"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",[],[111,86,112,89,113,114,115,33,116,117,118,119,120,121,91,122,123,124,125,126],"exploit","services wmi exec exploit","exec","remote","traffic","Bash","analysis","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":38},"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",[],[134,135,136,137,138,139,33,116,140,117,141,142,91,124,143,144,145,146,147,148],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":38},"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",[],[87,156,157,158,159,160,161,92,162,33,103,163,164,165,166,167,168,169,170,91],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":38},"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",[],[178,179,87,180,158,160,181,92,182,162,33,103,117,183,184,185,186,170,91,93],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":38},"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",[],[194,87,158,195,181,92,196,197,33,103,198,199,200,201,202,203,91,93,204,205],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]