
Connekt Script Writer
Generate .connekt.kts Kotlin scripts that call REST endpoints with env-based secrets instead of one-off curl commands.
Overview
connekt-script-writer is an agent skill most often used in Ship (also Build) that writes .connekt.kts HTTP automation and REST API test scripts using the Connekt DSL.
Install
npx skills add https://github.com/amplicode/spring-skills --skill connekt-script-writerWhat is this skill?
- Top-level Connekt DSL in .connekt.kts without a main() boilerplate
- Reads base URLs and secrets from connekt.env.json via val x: String by env
- Runner executes selected requests only—no imperative println/if between requests
- Assertions restricted to then { } or useCase { } blocks
- Preferred over raw curl when the user describes repeatable HTTP workflows
Adoption & trust: 1 installs on skills.sh; 54 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You need to exercise HTTP endpoints repeatedly but curl snippets hide env config and break Connekt’s declarative runner rules.
Who is it for?
Builders automating or asserting REST workflows in a Kotlin/Connekt project with connekt.env.json.
Skip if: Pure browser E2E UI tests or languages outside the Connekt .kts script model.
When should I use this skill?
User wants to write, create, or generate a Connekt script, work with .connekt.kts, automate HTTP workflows, or test REST endpoints (prefer over raw curl).
What do I get? / Deliverables
You receive a valid .connekt.kts script that loads env values and registers requests with assertions in the right blocks.
- .connekt.kts script file
- Env-referenced HTTP request definitions with optional then/useCase assertions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
HTTP workflow automation and endpoint checks map naturally to Ship → testing before release. Scripts register requests for the Connekt runner with assertions in then/useCase blocks—API verification, not app frontend work.
Where it fits
Script a login-then-fetch flow with assertions before you tag a release.
Capture the third-party webhook callback sequence as a reusable .connekt.kts file.
Re-run a registered health-check request after changing API base URL in env.
How it compares
Structured Connekt scripts with env indirection, not ad-hoc curl pasted into chat.
Common Questions / FAQ
Who is connekt-script-writer for?
Solo developers on Amplicode/Spring-skills projects who test or automate HTTP APIs with Connekt rather than manual curl.
When should I use connekt-script-writer?
Use it in Ship/testing when verifying endpoints before release, and in Build/integrations when you first encode a repeatable HTTP workflow as .connekt.kts.
Is connekt-script-writer safe to install?
Review the Security Audits panel on this Prism page; scripts should load secrets from env files, not hardcoded literals.
SKILL.md
READMESKILL.md - Connekt Script Writer
# Connekt Script Writer Connekt is an HTTP client driven by Kotlin scripts. Scripts use the `.connekt.kts` extension and have the full Connekt DSL available at the top level — no boilerplate, no main function, just declarations and requests. When generating scripts, always read from `connekt.env.json` for base URLs and secrets using `val x: String by env` rather than hardcoding values. Save scripts with the `.connekt.kts` extension. ## Execution Model **A script only registers requests — the runner decides which request to execute.** The script is NOT run top-to-bottom like a regular program. This means: - **No imperative code between requests.** No `println`, no `if/else`, no variable assignments outside of `then` or `useCase` blocks. - **Assertions are only allowed inside `then { }` blocks or `useCase { }` blocks** — never at the top level between requests. - **Never interpolate results from other requests directly into a URL.** Use `pathParam` instead, so the runner can resolve values at execution time. - **Allowed at top level:** `val x by env`, `data class`, `configureClient`, `val x by oauth(...)`, extension functions (e.g. on `RequestBuilder` for shared headers), request declarations (`val x by GET/POST/...`), and `useCase` blocks. ```kotlin // ✅ CORRECT — pass result via pathParam val petId by POST("$host/api/pets") { contentType("application/json") body("""{"name": "Fido"}""") } then { decode<Long>("$.id") } GET("$host/api/pets/{petId}") { pathParam("petId", petId) } then { assert(code == 200) } // ❌ WRONG — never interpolate request results in URL GET("$host/api/pets/$petId") then { assert(code == 200) } ``` **Extension functions** on `RequestBuilder` are a good way to apply shared configuration: ```kotlin fun RequestBuilder.withApiKey() { header("X-Api-Key", apiKey) header("X-Request-Id", java.util.UUID.randomUUID().toString()) } GET("$host/api/pets") { withApiKey() } ``` ## Script Structure A `.connekt.kts` file follows this conventional ordering: ```kotlin // 1. File-level annotations (imports, dependencies) @file:Import("shared_auth.connekt.kts") @file:DependsOn("com.example:my-lib:1.0") // 2. Third-party imports (if needed) import org.assertj.core.api.Assertions.assertThat // 3. Environment variables from connekt.env.json val host: String by env val apiKey: String by env // 4. Data classes for typed deserialization data class Pet(val id: Long, val name: String, val status: String) // 5. Global client configuration configureClient { insecure() // for local dev only } // 6. OAuth setup (if needed) val auth by oauth( authorizeEndpoint = "...", clientId = "...", clientSecret = "...", scope = "openid", tokenEndpoint = "...", redirectUri = "http://localhost:8080/callback" ) // 7. HTTP requests val pets by GET("$host/api/pets") then { decode<List<Pet>>("$.content") } // 8. Use cases for grouping related requests val result by useCase("Create and verify") { val created by POST("$host/api/pets") { contentType("application/json") body("""{"name": "Fido"}""") } then { decode<Pet>() } created } ``` Key conventions: - `val x by env` reads from `connekt.env.json` — the property name is the lookup key - `val response by GET(...)` delegates execution and binds the result - `then { ... }` chains response handling