release
- Repo stars 2,493
- Author updated Live
- Author repo hoverfly
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @SpectoLabs · no license declared
- Token usage
- Lean
- Setup complexity
- Manual integration
- External API key
- Not required
- Operating systems
- Docker
- Runtime requirements
- Docker
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: release
description: Automate the full hoverfly release process — version bump, GitHub release, wait for CI, trigger…
category: engineering
runtime: Docker
---
# release output preview
## PART A: Task fit
- Use case: Automate the full hoverfly release process — version bump, GitHub release, wait for CI, trigger Homebrew update. Release version: $ARGUMENTS Execute the following phases in order. Confirm with the user before moving to each phase. Stop immediately if any step fails. runs entirely locally; runs on Docker. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Current state / Instructions / Phase 1 — Version bump & push” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Automate the full hoverfly release process — version bump, GitHub release, wait for CI, trigger Homebrew update. Release version: $ARGUMENTS Execute the following phases in order. Confirm with the user before moving to each phase. Stop immediately if any step fails. runs entirely locally; runs on Docker. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Current state / Instructions / Phase 1 — Version bump & push” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Current state / Instructions / Phase 1 — Version bump & push”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: release
description: Automate the full hoverfly release process — version bump, GitHub release, wait for CI, trigger…
category: engineering
source: SpectoLabs/hoverfly
---
# release
## When to use
- Automate the full hoverfly release process — version bump, GitHub release, wait for CI, trigger Homebrew update. Relea…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Current state / Instructions / Phase 1 — Version bump & push” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "release" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Current state / Instructions / Phase 1 — Version bump & push
rules -> SKILL.md triggers / order / output contract
runtime -> Docker | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Hoverfly Release
Release version: $ARGUMENTS
Current state
- Current version: !
grep 'hoverfly.version' core/hoverfly.go | grep -o 'v[0-9]*\.[0-9]*\.[0-9]*' - Branch: !
git branch --show-current - Working tree clean: !
git status --porcelain | wc -l | xargs
Instructions
Execute the following phases in order. Confirm with the user before moving to each phase. Stop immediately if any step fails.
Phase 1 — Version bump & push
- Validate that
$ARGUMENTSmatches the patternvX.Y.Z(e.g.v1.13.0). If not, stop and ask the user for a valid version. - Verify the working tree is clean (
git status --porcelainis empty) and the current branch ismaster. If not, stop and tell the user. - Run:
make update-version VERSION=$ARGUMENTS - Push:
git push origin master
Tell the user the version commit has been pushed and that a CircleCI build has been triggered (no need to wait for it).
Phase 2 — Create GitHub release
- Create the release with auto-generated notes:
gh release create $ARGUMENTS --generate-notes --target master - Show the user the release URL.
- Tell the user this has triggered the CircleCI
deploy-releasejob, which will build cross-platform binaries and Docker images. This typically takes 20+ minutes.
Phase 3 — Wait for release assets
Poll once per minute until all 7 expected zip bundles appear in the release assets. The expected files are:
hoverfly_bundle_OSX_amd64.ziphoverfly_bundle_OSX_arm64.ziphoverfly_bundle_windows_amd64.ziphoverfly_bundle_windows_386.ziphoverfly_bundle_linux_amd64.ziphoverfly_bundle_linux_386.ziphoverfly_bundle_linux_arm64.zip
To check, run:
gh release view $ARGUMENTS --json assets --jq '.assets[].name'
Each poll iteration:
- Count how many of the 7 expected files are present
- Report progress to the user: "X/7 assets uploaded..."
- Sleep 60 seconds between checks
- After 45 minutes with no completion, warn the user and ask whether to keep waiting
Phase 4 — Trigger Homebrew update
Once all 7 assets are confirmed:
- Trigger the Homebrew formula bump workflow:
gh workflow run homebrew-bump-formula.yml -f version=$ARGUMENTS - Tell the user the workflow has been triggered and they need to manually merge the resulting PR in
SpectoLabs/homebrew-tap.
Done
Summarize what was completed:
- Version bumped to
$ARGUMENTS - GitHub release created with auto-generated notes
- All 7 platform bundles uploaded by CircleCI
- Homebrew formula update triggered
- Remaining manual step: merge the PR in
SpectoLabs/homebrew-tap
Decide Fit First
Design Intent
How To Use It
Boundaries And Review