agentleFS
kuhlman-labskuhlman-labs/fishhawk/.agents/skills/deploy-local/SKILL.md

deploy-local

Skill9 starsChanged 14 days agoApache-2.0View on GitHub

Start, rebuild or restart the local Fishhawk stack or Docker Desktop Kubernetes deployment. Use for local deployment; use sync-main after a merge.

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. scottmillner/agentic-engineering★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository11 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the intent is ambiguous between process and k8s, use the process mode (up) — it is the daily dev loop.

    line 32
  2. Very specific:

    Run the chosen command with a generous timeout: the first build of five binaries can take a few minutes, and k8s builds an image.

    line 55

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deploy Fishhawk locally

scripts/dev owns the whole bring-up. Do not hand-roll docker compose + go build + fishhawkd serve — scripts/dev adds the port preflight, GitSHA stamping, migrations, the /healthz nonce identity gate, and the MCP-shim banner. Run everything from the repo root (main checkout, not a .claude/worktrees/* checkout unless the user asks).

0. Stop if you are a run agent

reload (especially reload --force) restarts the fishhawkd that a run's own runner talks to, and k8s upgrades and restarts the cluster deployment. Before anything else:

top=$(git rev-parse --show-toplevel) && "$top/scripts/is-run-agent"

Continue only if it prints operator and exits 0. On any other result, stop, do nothing, and report its output to the user. That includes run-agent: …, a git error (you are not in a repository checkout), and a missing script (this checkout predates the guard). The contract lives in scripts/README.md § "is-run-agent".

Pulling main after a merge is the sync-main skill, not this one.

1. Pick the target

User intentCommand
Default — "deploy locally", "start the stack"scripts/dev up --start-deps
Rebuild everything + restart (after a pull / code change)scripts/dev reload --start-deps
Kubernetes (Docker Desktop) — "deploy to k8s", "helm"scripts/dev k8s
Web UI dev server tooadditionally make dev-frontend (:5173, proxies /v0 → :8080), run in background
Tear downUse the teardown-local skill (ordered stop of every layer; make nuke only on explicit request)

If the intent is ambiguous between process and k8s, use the process mode (up) — it is the daily dev loop. Never run make nuke (drops volumes) unless the user explicitly asks to destroy data.

Plain up is a no-op when fishhawkd is already running — it prints fishhawkd already running and does not rebuild. To pick up code changes, use reload.

2. Preflight (run before up/reload/k8s)

docker info >/dev/null 2>&1 && echo docker-ok || echo docker-DOWN
test -f .env && echo env-ok || echo env-MISSING
pgrep -fl '[f]ishhawk-runner .*--run-id' || echo no-live-runner
git status --short | head
uptime
  • Docker down → open -a Docker, then poll until docker info succeeds (a bounded until-loop, not one long sleep).
  • .env missing → cp .env.example .env; FISHHAWKD_DATABASE_URL already matches docker-compose.yml. Tell the user which optional blocks (GitHub App, OAuth) are unset; fishhawkd starts without them but logs warnings. Never print secret values from .env.
  • Live runner → reload restarts fishhawkd and can strand that run's stage in running. reload refuses on its own; STOP and ask the user before passing --force. Same if the user has an in-flight fishhawk_await_* on another run.
  • Want to wait instead of forcing → scripts/dev reload --when-quiet. It waits, bounded, until no runner is live and no reload-relevant restart blocker is reported, then runs the normal guards. reload ignores undispatched_child; only post-merge refuses on it. Knobs and exit codes: scripts/README.md § "reload --when-quiet".
  • Dirty tree → fine for up/reload (binaries get stamped -dirty). Pulling main after a merge is the sync-main skill.
  • Load average far above core count → warn the user; a starved host makes the readiness gate flaky (see operations).

3. Deploy

Run the chosen command with a generous timeout: the first build of five binaries can take a few minutes, and k8s builds an image. If your shell tool caps command duration below ~10 minutes, run it in the background and wait for it to exit.

Success markers in the output:

  • postgres: ready|running and rustfs: ready|running
  • rebuilt N of 5 binaries: …
  • listener identity nonce-verified
  • fishhawkd started (pid N) — logs: logs/fishhawkd.log
  • k8s: /healthz gate + image-identity gate pass

Then verify independently:

curl -fsS "http://${FISHHAWKD_ADDR:-localhost:8080}/healthz" | python3 -m json.tool

(Read FISHHAWKD_ADDR from .env if set — e.g. 127.0.0.1:8080.) Confirm git_sha matches git rev-parse --short HEAD (with -dirty on a dirty tree).

4. Report

One short block: mode, URL, pid, git_sha, which binaries rebuilt, and the MCP banner verbatim if one printed — it is the only thing the user must act on:

  • ACTION REQUIRED / shim-rebuilt banner → the user must reconnect their MCP client (/mcp in Claude Code).
  • auto-swap / schema_major_shim → expectation only; verify with fishhawk_doctor (spec.valid: true) or a version-returning tool reflecting the new GitSHA. If stale: bin/fishhawk-mcp-shim --status, then reconnect the MCP client.
  • fishhawk-runner is spawned fresh from bin/ per stage, and reload rebuilds it (--all). If the change touched runner stages, confirm bin/fishhawk-runner version shows the new GitSHA. Never restart fishhawkd alone: a stale runner silently ignores new stage instructions (#4183).

Troubleshooting

SymptomFix
error: port <p> already has a listener: pid N (…)scripts/dev down; if a foreign process holds it, report it — don't kill non-fishhawkd processes without asking
did not become healthy within 10sRead the printed log tail / tail -50 logs/fishhawkd.log; usually a migration or config error
postgres did not become readydocker logs fishhawk-postgres
Operation not permitted on repo readGrant the app hosting the agent (terminal, Claude Code, Codex) Full Disk Access in System Settings → Privacy & Security, then restart it
Build fails only under a newer local GoCompare with the gate-image Go pin and use matching tools; persistent go env -w changes require authorization (see operations guide)
k8s: STALE fishhawkd image / identity mismatchSee docs/deploy/kubernetes.md § "Image identity"; FISHHAWK_K8S_SKIP_IDENTITY=1 only with the user's OK
k8s: x509: certificate signed by unknown authority in docker buildTLS-inspecting proxy — docs/deploy/kubernetes.md
.git pack Operation timed outCheck whether this checkout is in an iCloud-synced directory; rehydrate a confirmed evicted file

References

  • scripts/dev (_usage for every subcommand), scripts/README.md
  • scripts/README.md § Rebuild matrix and activation; operations for host/container traps
  • scripts/README.md § "scripts/dev lifecycle" (readiness nonce gate, MCP banner, schema-major banner, sweep, ZERR trap), § "Live-run guard for reload / post-merge" (the reload half), § "Restart-blocker guard for reload / post-merge" and § "reload --when-quiet", § "Local k8s ergonomics"
  • docs/deploy/kubernetes.md, docs/local-tls.md (FISHHAWK_DEV_TLS=1), docs/local-webhook-relay.md (FISHHAWK_DEV_WEBHOOK_RELAY=1)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.