release

Name: release
Author: SpectoLabs

Engineering Community

Repo stars 2,493
Author repo hoverfly

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

Decide Fit First

Core job: Automate the full hoverfly release process — version bump, GitHub release, wait for CI, trigger Homebrew update. Release version…
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 “Current state”, “Instructions”, “Phase 1 — Version bump & push”, “Phase 2 — Create GitHub release”, 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 release 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 “Current state / Instructions / Phase 1 — Version bump & push” 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 / write / 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.

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 $ARGUMENTS matches the pattern vX.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 --porcelain is empty) and the current branch is master. 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-release job, 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.zip
hoverfly_bundle_OSX_arm64.zip
hoverfly_bundle_windows_amd64.zip
hoverfly_bundle_windows_386.zip
hoverfly_bundle_linux_amd64.zip
hoverfly_bundle_linux_386.zip
hoverfly_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

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

Fluxly category: Engineering
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: @SpectoLabs · 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
Write / modify
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 release-spectolabs.preview

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

SKILL.md SKILL.md

# 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

1. **Validate** that `$ARGUMENTS` matches the pattern `vX.Y.Z` (e.g. `v1.13.0`). If not, stop and ask the user for a valid version.
2. **Verify** the working tree is clean (`git status --porcelain` is empty) and the current branch is `master`. If not, stop and tell the user.
3. Run: `make update-version VERSION=$ARGUMENTS`
4. 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

1. Create the release with auto-generated notes:
   ```
   gh release create $ARGUMENTS --generate-notes --target master
   ```
2. Show the user the release URL.
3. Tell the user this has triggered the CircleCI `deploy-release` job, 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.zip`
- `hoverfly_bundle_OSX_arm64.zip`
- `hoverfly_bundle_windows_amd64.zip`
- `hoverfly_bundle_windows_386.zip`
- `hoverfly_bundle_linux_amd64.zip`
- `hoverfly_bundle_linux_386.zip`
- `hoverfly_bundle_linux_arm64.zip`

To check, run:
```
gh release view $ARGUMENTS --json assets --jq '.assets[].name'
```

…

Evidence boundary and execution chain

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

sections -> Current state → Instructions → Phase 1 — Version bump & push → Phase 2 — Create GitHub release → Phase 3 — Wait for release assets → Phase 4 — Trigger Homebrew update
terms    -> $ARGUMENTS · Validate · Verify · all 7
files/cmd -> grep 'hoverfly.version' core/hoverfly.go | grep -o 'v[0-9]\.[0-9]\.[0-9]' · git branch --show-current · git status --porcelain | wc -l | xargs · $ARGUMENTS · vX.Y.Z · v1.13.0 · git status --porcelain · master
body sha256 -> d828881576cf