writing-java-kotlin

Name: writing-java-kotlin
Author: alexei-led

35stars5forks

How to install writing-java-kotlin?

alexei-led/cc-thingz/writing-java-kotlin

$npx -y skills add alexei-led/cc-thingz --skill writing-java-kotlin

Installs into the current project.

Summary

Use only for Java/Kotlin JVM code and JVM build files. Follow the project's JDK, Kotlin, Gradle/Maven, framework, test stack, formatter, static-analysis config, and local conventions.

Files · 1

View on GitHub

SKILL.md

1	# Java and Kotlin Development
2
3	Use only for Java/Kotlin JVM code and JVM build files. Follow the project's JDK,
4	Kotlin, Gradle/Maven, framework, test stack, formatter, static-analysis config,
5	and local conventions.
6
7	## Read First
8
9	Read [principles.md](references/principles.md) before writing, changing, or reviewing Java/Kotlin code. Read conditional references only when the change touches that area.
10
11	## Conditional References
12
13	- [patterns.md](references/patterns.md) — package/module layout, Spring/Ktor/service boundaries, nullability, concurrency, persistence, and build seams.
14	- [testing.md](references/testing.md) — adding or reshaping JUnit, Kotest, Mockito/MockK, Spring, or Gradle/Maven tests; keep the local loop fast.
15	- [linting.md](references/linting.md) — Gradle/Maven toolchains, formatters, ktlint, detekt, Spotless, and slow-check policy.
16	- [cli.md](references/cli.md) — writing or changing JVM CLIs.
17
18	## Project Baseline
19
20	- Inspect `gradle/wrapper/gradle-wrapper.properties`, `settings.gradle`, `build.gradle`, `pom.xml`, `.mvn/`, `gradle.properties`, CI, and nearby code before using version-specific Java, Kotlin, or plugin behavior.
21	- Prefer the project wrapper: `./gradlew` before global `gradle`; `./mvnw` before global `mvn`.
22	- Use the configured Java toolchain and Kotlin `jvmToolchain`. Do not assume the shell's newest JDK is the compile target.
23	- Prefer the JDK/Kotlin stdlib and existing dependencies before adding a library.
24	- Keep domain code free of framework, persistence, HTTP, and DI types unless the project already chose that coupling.
25
26	## Version-Gated APIs
27
28	- Java 21+: records, sealed types, pattern matching, switch expressions, and virtual threads are available when the project toolchain allows them.
29	- Java 25+: treat new platform APIs as available only when Gradle/Maven toolchains and CI target 25 or newer.
30	- Preview features require explicit user or project approval and a visible compiler/test flag.
31	- Kotlin: follow the configured Kotlin language/API version. Do not use a Kotlin 2.x feature unless the build already enables it.
32
33	## Comments, Javadoc, and KDoc
34
35	- Use Javadoc or KDoc for visible public APIs when the project expects generated docs.
36	- Keep API docs to a useful summary, contract, edge case, or effect. Do not restate names and signatures.
37	- Omit comments for simple obvious getters, overrides, and data holders when there is nothing useful to add.
38	- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or framework quirks.
39	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
40	- Do not comment obvious code.
41	- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, framework setup, or regression context.
42
43	## Verification
44
45	Run focused module tests and format/lint while editing, then the project-configured build, tests, lint, static analysis, and formatting checks before final output. Prefer Gradle/Maven test filtering over full-suite runs in the hot loop.
46
47	If a check is unavailable, state that and run the closest configured gate. If a
48	check fails, quote the failure, diagnose the cause, fix one issue, and rerun the
49	relevant check.
50
51	## Failure Cases
52
53	- No clear JVM root: locate the nearest `settings.gradle`, `build.gradle`, or `pom.xml` before choosing commands or package names.
54	- Unknown JDK or Kotlin target: inspect toolchains, compiler options, CI, and wrapper versions before using newer APIs or syntax.
55	- New dependency requested: confirm the JDK/Kotlin stdlib or existing dependencies cannot meet the requirement.
56	- Slow checks by default: switch to focused Gradle/Maven filters or file-scoped format/lint; reserve broad checks for final verification.
57	- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.
58
59	## Final Response
60
61	Include:
62
63	- changed files
64	- checks run and results
65	- checks skipped with reasons
66	- remaining risks or follow-ups

People who liked this also viewed

6 picks

Type

writing-java-kotlin

35stars5forks

View on GitHub

How to install writing-java-kotlin?

alexei-led/cc-thingz/writing-java-kotlin

$npx -y skills add alexei-led/cc-thingz --skill writing-java-kotlin

Installs into the current project.

Summary

Use only for Java/Kotlin JVM code and JVM build files. Follow the project's JDK, Kotlin, Gradle/Maven, framework, test stack, formatter, static-analysis config, and local conventions.

Files · 1

View on GitHub

SKILL.md

1	# Java and Kotlin Development
2
3	Use only for Java/Kotlin JVM code and JVM build files. Follow the project's JDK,
4	Kotlin, Gradle/Maven, framework, test stack, formatter, static-analysis config,
5	and local conventions.
6
7	## Read First
8
9	Read [principles.md](references/principles.md) before writing, changing, or reviewing Java/Kotlin code. Read conditional references only when the change touches that area.
10
11	## Conditional References
12
13	- [patterns.md](references/patterns.md) — package/module layout, Spring/Ktor/service boundaries, nullability, concurrency, persistence, and build seams.
14	- [testing.md](references/testing.md) — adding or reshaping JUnit, Kotest, Mockito/MockK, Spring, or Gradle/Maven tests; keep the local loop fast.
15	- [linting.md](references/linting.md) — Gradle/Maven toolchains, formatters, ktlint, detekt, Spotless, and slow-check policy.
16	- [cli.md](references/cli.md) — writing or changing JVM CLIs.
17
18	## Project Baseline
19
20	- Inspect `gradle/wrapper/gradle-wrapper.properties`, `settings.gradle`, `build.gradle`, `pom.xml`, `.mvn/`, `gradle.properties`, CI, and nearby code before using version-specific Java, Kotlin, or plugin behavior.
21	- Prefer the project wrapper: `./gradlew` before global `gradle`; `./mvnw` before global `mvn`.
22	- Use the configured Java toolchain and Kotlin `jvmToolchain`. Do not assume the shell's newest JDK is the compile target.
23	- Prefer the JDK/Kotlin stdlib and existing dependencies before adding a library.
24	- Keep domain code free of framework, persistence, HTTP, and DI types unless the project already chose that coupling.
25
26	## Version-Gated APIs
27
28	- Java 21+: records, sealed types, pattern matching, switch expressions, and virtual threads are available when the project toolchain allows them.
29	- Java 25+: treat new platform APIs as available only when Gradle/Maven toolchains and CI target 25 or newer.
30	- Preview features require explicit user or project approval and a visible compiler/test flag.
31	- Kotlin: follow the configured Kotlin language/API version. Do not use a Kotlin 2.x feature unless the build already enables it.
32
33	## Comments, Javadoc, and KDoc
34
35	- Use Javadoc or KDoc for visible public APIs when the project expects generated docs.
36	- Keep API docs to a useful summary, contract, edge case, or effect. Do not restate names and signatures.
37	- Omit comments for simple obvious getters, overrides, and data holders when there is nothing useful to add.
38	- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or framework quirks.
39	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
40	- Do not comment obvious code.
41	- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, framework setup, or regression context.
42
43	## Verification
44
45	Run focused module tests and format/lint while editing, then the project-configured build, tests, lint, static analysis, and formatting checks before final output. Prefer Gradle/Maven test filtering over full-suite runs in the hot loop.
46
47	If a check is unavailable, state that and run the closest configured gate. If a
48	check fails, quote the failure, diagnose the cause, fix one issue, and rerun the
49	relevant check.
50
51	## Failure Cases
52
53	- No clear JVM root: locate the nearest `settings.gradle`, `build.gradle`, or `pom.xml` before choosing commands or package names.
54	- Unknown JDK or Kotlin target: inspect toolchains, compiler options, CI, and wrapper versions before using newer APIs or syntax.
55	- New dependency requested: confirm the JDK/Kotlin stdlib or existing dependencies cannot meet the requirement.
56	- Slow checks by default: switch to focused Gradle/Maven filters or file-scoped format/lint; reserve broad checks for final verification.
57	- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.
58
59	## Final Response
60
61	Include:
62
63	- changed files
64	- checks run and results
65	- checks skipped with reasons
66	- remaining risks or follow-ups

People who liked this also viewed

6 picks

Type