agentsclimarketplace
Sign in

Duckeighty init

Skill mackee/duckeighty/skills/duckeighty-init

Bootstrap a host for duckeighty: clone the duckeighty repository locally if it is missing, trust the mkcert local CA, install the macOS /etc/resolver entry for *.duckeighty.test, and bring up the shared traefik + dnsmasq ingress stack. After one invocation per host, every app repo only needs the duckeighty-integrate skill to generate its docker-compose.local.yaml. TRIGGER: the user is new to duckeighty, has never run ./duckeighty.sh up, asks to "set up duckeighty" / "install the local HTTPS ingress", or the duckeighty-doctor skill reported several failing checks at once. SKIP: the user already has a working duckeighty checkout and a running ingress (run the duckeighty-doctor skill first if unsure).From its SKILL.md

Install
npx -y skills add mackee/duckeighty --skill duckeighty-init

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

4 things to look at

  • reads credentialsReads from 1 credential source: `DUCKEIGHTY_CHECKOUT`.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 6 commands, including `brew install mkcert nss` and 5 more.
  • fetches URLsInstructs the agent to fetch 1 URL, including https://github.com/mackee/duckeighty.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.8 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it

duckeighty: init (one-time per-host ingress bootstrap)

This skill walks the user through the four steps needed to make https://*.duckeighty.test resolvable and TLS-trusted on their machine. The ingress stack is host-wide: one install per developer, shared by every app repo they work in.

Confirm prerequisites before starting

  1. macOS. The current duckeighty resolver step writes to /etc/resolver/, which is macOS-specific.

  2. Docker daemon is running (docker version succeeds).

  3. mkcert is installed. If not:

    brew install mkcert nss

    Install it and confirm before proceeding.

Step 1 — decide where duckeighty lives (always ask the user)

Do not hardcode a path. Developers use different checkout layouts and the skill has no business assuming which one. The only auto-accepted value is an explicit DUCKEIGHTY_CHECKOUT env var the user has set previously.

1a. Honor an explicit override

if [ -n "${DUCKEIGHTY_CHECKOUT:-}" ] && [ -d "$DUCKEIGHTY_CHECKOUT/.git" ]; then
  CHECKOUT="$DUCKEIGHTY_CHECKOUT"
fi

If set and valid, confirm with the user ("Use the clone at $CHECKOUT?"). If yes, skip to step 2.

1b. Otherwise, present the choice

Always present these options to the user and let them pick. Do not guess based on filesystem layout or tool availability.

#PathWhen it fits
1~/.duckeightyNo existing convention. Shortest path, skill-owned.
2~/src/github.com/mackee/duckeightyYou keep repos under ~/src/<host>/<owner>/<repo>.
3A custom path the user typesAny other layout the user prefers.

If the user picks option 3, ask them for the absolute path.

Once the path is chosen:

CHECKOUT="<chosen>"
mkdir -p "$(dirname "$CHECKOUT")"
git clone https://github.com/mackee/duckeighty "$CHECKOUT"

If $CHECKOUT exists but is not a git clone, stop and ask the user. Do not overwrite.

1c. Persist the choice (optional but recommended)

Suggest the user add this to their shell rc so later init / doctor runs skip the prompt:

export DUCKEIGHTY_CHECKOUT="$CHECKOUT"

All subsequent steps run from $CHECKOUT. Surface the final value in the summary to the user.

Step 2 — install local CA and wildcard certificate

./duckeighty.sh setup-ca

This runs mkcert -install (installs the mkcert root CA into the system keychain) and writes infra/certs/duckeighty.test.pem + infra/certs/duckeighty.test-key.pem. Do not re-run on every init; only run when certs are missing or the user explicitly asks to re-issue.

If mkcert -install asks for a password, that is the normal macOS keychain prompt — proceed.

Step 3 — install the macOS resolver entry (sudo)

./duckeighty.sh setup-resolver

This writes /etc/resolver/duckeighty.test pointing at 127.0.0.1:5354. It needs sudo. Tell the user the command and what it writes before running it — do not silently escalate.

Browser restart is usually not required, but if the user opened https://*.duckeighty.test before setup the browser may cache the failure; suggest a tab reload.

Step 4 — bring up the ingress stack

./duckeighty.sh up

This creates the external shared_ingress network (if missing) and runs docker compose -f infra/compose.yaml up -d. The compose file declares name: duckeighty, so docker compose ls lists it as the duckeighty project. After startup, two containers should be running with restart: unless-stopped:

  • duckeighty-traefik-1 — reverse proxy + TLS terminator on 127.0.0.1:80 / 443
  • duckeighty-dnsmasq-1 — DNS for *.duckeighty.test on 127.0.0.1:5354

Both survive reboots as long as Docker restarts.

Step 5 — verify

Suggest running the duckeighty-doctor skill next, or manually:

"$CHECKOUT"/duckeighty.sh check probe.duckeighty.test

Expected output:

127.0.0.1
HTTP 404

The 404 means TLS + DNS + Traefik all work and the hostname simply has no router yet — which is correct before any app is onboarded.

After init

From any application repo with a compose.yaml, use the duckeighty-integrate skill to generate docker-compose.local.yaml. The ingress stack stays running in the background; no per-app changes under infra/ are ever needed.

Do not

  • Do not re-run setup-ca on every init call. Re-issuing the CA forces the user to re-trust it in every browser. Only re-run when the certs are actually missing or expired.
  • Do not run these commands from inside a random application repo — they must run in the duckeighty checkout ($CHECKOUT).
  • Do not copy infra/ into the user's app repo. The ingress is host-wide and shared; duplication breaks the port 80/443 assumption.
  • Do not silently run sudo. Surface the command, explain what it writes, ask before proceeding.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most project setup skills give in ~1.3k tokens

Counted across 1,553 of the 3,091 authors here whose files we hold, read 2026-09-06

  • Write the configuration filein 36 of 1553
  • Create the directory structurein 35 of 1553, across 33 files
  • Verify the setupin 31 of 1553, across 28 files
  • Run the setup scriptin 30 of 1553, across 29 files
  • Pre-determine the required sample sizein 29 of 1553, across 12 files
  • Check if the configuration already existsin 29 of 1553
  • Document every testin 26 of 1553, across 10 files
  • Start with a hypothesisin 26 of 1553, across 11 files
  • Ask one question at a timein 22 of 1553
  • Test a single variable per testin 21 of 1553, across 9 files
  • Read product marketing context before asking questionsin 19 of 1553, across 8 files
  • Do not peek and stop earlyin 18 of 1553, across 7 files

Said here and by no other author read

  • Confirm macOS prerequisites before starting
  • Ask the user where duckeighty lives
  • Clone the duckeighty repository locally
  • Run the setup-ca command
  • Run the setup-resolver command using sudo
  • Run the up command to start ingress

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.