Menu
Use when preparing, validating, publishing, or undrafting a Spectre release.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Babysit a GitHub pull request after creation by continuously polling CI checks/workflow runs, new review comments, and mergeability state until the PR is ready to merge (or merged/closed). Diagnose failures, retry likely flaky failures up to 3 times, auto-fix and push branch-related issues when appropriate, and stop only when user help is required (e.g. CI infrastructure issues, exhausted flaky retries, or ambiguous/blocking review feedback). Use when the user asks to monitor a PR, watch CI, handle review comments, or keep an eye on failures and feedback on an open PR.
Use when the user is writing, running, or debugging end-to-end UI automation tests for a Compose for Desktop (aka Compose Multiplatform on desktop) app — including setting up Spectre, clicking or typing in a running window, finding UI nodes by tag or text, waiting for the UI to settle, capturing screenshots or video, or troubleshooting a Compose Desktop or IntelliJ-hosted UI under test. Also use when the user asks how to automate a live running Compose Desktop app, even if they don't mention Spectre by name.
Use when writing, debugging, or reviewing tests that drive a real, on-screen Compose Desktop window with Spectre — the JVM/Kotlin library for automating live Compose Desktop UIs (and IntelliJ/Jewel-hosted Compose) via the semantics tree plus java.awt.Robot, synthetic AWT input, HTTP, or Java-agent attach. Trigger on mentions of `ComposeAutomator`, `RobotDriver`, `AutomatorNode`, `AgentAttach`, `AttachedAutomator`, `AttachOptions`, `findByTestTag`, `waitForNode`, `waitForIdle`, "automate a Compose window", "live/real-window Compose Desktop UI test", cross-JVM Compose automation, attaching to a running Compose JVM, screenshotting or recording a Compose Desktop window, or any task involving `dev.sebastiano.spectre.*` imports. Also use when the user is writing JUnit 4/5 tests against Compose Desktop **and** the test opens a real top-level window — but NOT when the user wants the off-screen `runComposeUiTest` / `createComposeRule` / `onNodeWithTag` framework, which is a different tool.
Use when working on IntelliJ/Jewel popup hosting, ComposePanel embedding, SwingBridgeTheme, popup rendering modes, or AWT/Compose coordinate conversion.
Use when Detekt reports a violation and you need to fix the underlying problem without papering over it with suppressions or configuration changes.
Use when starting nontrivial feature work that should stay isolated from the main checkout. Creates or reuses a safe git worktree with sensible defaults.
| name | spectre-release |
| description | Use when preparing, validating, publishing, or undrafting a Spectre release. |
| metadata | {"internal":true} |
Use this skill for Spectre release work after the tag-driven release workflow has run.
Use the release checker before publishing a validated Central Portal deployment:
scripts/central_portal_check.py status \
--deployment-id <deployment-id>
scripts/central_portal_check.py validate \
--deployment-id <deployment-id> \
--version <version>
The script reads credentials from the 1Password item Spectre Maven Central Portal via op.
It can also use MAVEN_CENTRAL_USERNAME / MAVEN_CENTRAL_PASSWORD or the matching
ORG_GRADLE_PROJECT_mavenCentralUsername / ORG_GRADLE_PROJECT_mavenCentralPassword
environment variables when running in CI-like shells.
The read-only validation checks:
.asc signatures for all published modulesspectre-agent does not contain AttachSpikespectre-agent-runtime has the Java agent manifest and no forbidden bundled classesPublishing is intentionally not automatic.
Prefer the Central Portal UI for the first few releases. If the API path is used, run the
script's publish command only after validate is green:
scripts/central_portal_check.py publish \
--deployment-id <deployment-id> \
--version <version>
The command requires typing this exact confirmation:
publish <deployment-id> <version>
Do not pass --yes unless the user explicitly asks for non-interactive publishing in the
current task.
After Central reports PUBLISHED, undraft the GitHub release:
gh release edit v<version> --draft=false
GitHub releases should point readers to Maven Central for artifacts instead of attaching a partial jar set. Then verify the public Maven Central coordinates resolve from a clean consumer project.