docs: document conda-forge / pixi installation

[worktrunk-bot]

Problem

The README install section lists Homebrew, Cargo, winget, and pacman, but does not mention the conda-forge package — which has been published since 0.32.0 and is currently at 0.44.0 with builds for linux-64, linux-aarch64, osx-64, osx-arm64, and win-64 (anaconda.org/conda-forge/worktrunk). Reported in #2424.

Solution

Adds a "Conda / Pixi" entry to the install section in docs/content/worktrunk.md, between Cargo and the Windows expandable. README and the worktrunk skill reference are auto-synced from this source.

Testing

cargo test --test integration test_docs_are_in_sync passes.

---

Closes #2424 — automated triage

[max-sixty]

@worktrunk-bot — how does the supply chain work for conda-forge? Is it run by the org or by an individual? We want to be very careful about listing

Can you also change the "Windows" details section to "Windows & other" and put conda and arch in there?

[worktrunk-bot]

On the conda-forge supply chain

Conda-forge itself is a community org (NumFOCUS-affiliated) — packages live in per-package "feedstock" repos under github.com/conda-forge/, and builds run on conda-forge's CI infra and are uploaded to the conda-forge channel. So the channel and build infrastructure is org-run, not individual.

The worktrunk-feedstock recipe maintainer is one individual: @pavelzw (Pavel Zwerschke, software engineer at Quantco; member of conda-forge, conda, mamba-org, conda-incubator — a known maintainer in that ecosystem, not anonymous). He opened the feedstock and has been bumping versions via the standard regro-cf-autotick-bot PR flow.

What he can and can't do:

• ✅ The recipe pulls source from https://github.com/max-sixty/worktrunk/archive/refs/tags/v${version}.tar.gz pinned to a sha256, so he cannot swap in modified source — any tampering would fail the hash check.
• ✅ Builds run on conda-forge's CI, not his machine; artifacts are signed and uploaded by conda-forge infra.
• ⚠️ He can change the build recipe itself (build flags, patches, dependencies, post-install hooks) without your sign-off. A malicious patch that the autotick bot doesn't catch would ship.
• ⚠️ Adding a co-maintainer or transferring is a PR to the feedstock; conda-forge core team can approve.

Tradeoff: This is the standard conda-forge model — most feedstocks have one or two individual maintainers unaffiliated with upstream. The sha256-pinned tarball + isolated CI is a real defense, but "build recipe drift" is the residual risk. If you'd rather not advertise it until you've claimed co-maintainership of the feedstock yourself (anyone can request it via PR), that's a legitimate stance — happy to drop the line.

---

I went ahead with the reorg you asked for: 4400b95 moves Conda/Pixi and Arch under a renamed "Windows & other" expandable, and adds a [feedstock](...) link on the conda line so users can audit who's behind it. Easy to revert the conda block if you'd prefer to wait.

[worktrunk-bot]

Every other install method on this page chains wt config shell install (brew, cargo, winget, pacman, conda) — the pixi line is the only one that doesn't. Inline suggestion below.