kt

DevOps Community

Repo stars 0
Author repo skills-registry

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Build, test, analyze, or start Docker for a Kotlin project Use when this capability is needed. Resolve project paths from ~/.cla…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Kotlin build / test / analyze / docker”, “Project paths & JDK”, “Actions”, “build”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name kt directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Kotlin build / test / analyze / docker / Project paths & JDK / Actions” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Kotlin build / test / analyze / docker

Arguments: $ARGUMENTS

Project paths & JDK

Resolve project paths from ~/.claude/project-repos.json. A Kotlin project is any registry entry whose root contains build.gradle or build.gradle.kts.

JDK version is per-project and should be declared in the project's projects/{shortname}.md. Set it before invoking Gradle:

export JAVA_HOME=$(/usr/libexec/java_home -v {version})

Actions

`build`

cd {repo-path} && ./gradlew build -x test
# Multi-module projects:
cd {repo-path} && ./gradlew :{module}:build -x test

On failure, suggest ./gradlew --refresh-dependencies for dependency errors. For compilation errors, quote the file/line and the offending type.

`test`

# All tests:
cd {repo-path} && ./gradlew test

# A specific module:
cd {repo-path} && ./gradlew :{module}:test

# A filter (uses JUnit's `--tests`):
cd {repo-path} && ./gradlew test --tests "{filter}"

# Module + filter:
cd {repo-path} && ./gradlew :{module}:test --tests "{filter}"

If the project uses TestContainers, ensure Docker is running first.

Report: total / passed / failed / skipped. For failures, show class, method, assertion error, and the first few lines of stack trace.

`analyze`

Detekt (common):

cd {repo-path} && ./gradlew detekt
cd {repo-path} && ./gradlew :{module}:detekt
cd {repo-path} && ./gradlew detekt --auto-correct

ktlint (alternative):

cd {repo-path} && ./gradlew ktlintCheck
cd {repo-path} && ./gradlew ktlintFormat

Report issues with: rule name, file:line, message, severity.

`docker`

Starts the project's docker-compose.yml services (Postgres, Redis, any stub/mock servers):

# All services:
cd {repo-path} && docker compose up -d

# Specific service:
cd {repo-path} && docker compose up -d {service}

After start, wait ~5s and check health:

docker compose -f {repo-path}/docker-compose.yml ps

If any container is unhealthy:

docker compose logs --tail=20 {service}

Common fixes:

Port conflict: docker ps to find the claimant
Stale volumes: docker compose down -v && docker compose up -d

Process

Parse arguments: action, shortname, optional module/filter/flags
Set JDK (skip for docker)
cd to the resolved project path
Run the command
Report result

Source: ajvelo/claude-toolkit — distributed by TomeVault.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: DevOps
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @tomevault-io · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Manual integration
External API key: No requirement detected
Detected OS requirements: Docker
Runtime requirements: Docker
Detected file/system behavior: Read-only
Shell exec
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview kt.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

## Kotlin build / test / analyze / docker

**Arguments:** $ARGUMENTS

## Project paths & JDK

Resolve project paths from `~/.claude/project-repos.json`. A Kotlin project
is any registry entry whose root contains `build.gradle` or `build.gradle.kts`.

JDK version is per-project and should be declared in the project's
`projects/{shortname}.md`. Set it before invoking Gradle:

```bash
export JAVA_HOME=$(/usr/libexec/java_home -v {version})
```

## Actions

### `build`

```bash
cd {repo-path} && ./gradlew build -x test
# Multi-module projects:
cd {repo-path} && ./gradlew :{module}:build -x test
```

On failure, suggest `./gradlew --refresh-dependencies` for dependency
errors. For compilation errors, quote the file/line and the offending type.

### `test`

```bash
# All tests:
cd {repo-path} && ./gradlew test

# A specific module:
cd {repo-path} && ./gradlew :{module}:test

# A filter (uses JUnit's `--tests`):
cd {repo-path} && ./gradlew test --tests "{filter}"

# Module + filter:
cd {repo-path} && ./gradlew :{module}:test --tests "{filter}"
```

If the project uses TestContainers, ensure Docker is running first.

Report: total / passed / failed / skipped. For failures, show class,
method, assertion error, and the first few lines of stack trace.

### `analyze`

Detekt (common):
```bash
cd {repo-path} && ./gradlew detekt
cd {repo-path} && ./gradlew :{module}:detekt
cd {repo-path} && ./gradlew detekt --auto-correct
```

ktlint (alternative):
```bash
cd {repo-path} && ./gradlew ktlintCheck
cd {repo-path} && ./gradlew ktlintFormat
```

Report issues with: rule name, file:line, message, severity.

### `docker`

Starts the project's `docker-compose.yml` services (Postgres, Redis, any
stub/mock servers):

```bash
# All services:
cd {repo-path} && docker compose up -d

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Kotlin build / test / analyze / docker → Project paths & JDK → Actions → build → test → analyze
terms    -> Arguments · Resolve project paths from ~/.claude/project-repos.json. · JDK version is per-project and should be declared in the project's projects/{shortname}.md. · On failure, suggest ./gradlew --refresh-dependencies for dependency errors. · If the project uses TestContainers, ensure Docker is running first. · Report: total / passed / failed / skipped. · Report issues with: rule name, file:line, message, severity. · 1. Parse arguments: action, shortname, optional module/filter/flags 2.
files/cmd -> ~/.claude/project-repos.json · build.gradle · build.gradle.kts · projects/{shortname}.md · build · ./gradlew --refresh-dependencies · test · --tests
body sha256 -> 1bc801ccc39b