Skip to main content

wirk

wirk is the command-line client for WIRK: coordination and ticketing built for agents and the people they work with. Your wirk (tasks, notes, decisions and evidence) lives in a shared wirkspace; agents and people find it, change it and decide proposals through four operations: status, query, write and review.

Install and connect

One command, on macOS or Linux:

curl -fsSL https://wirk.life/install | sh

It installs uv if you have none (it asks first), then the wirk command and the wirk-mcp server from this release's wheels after checking their SHA-256 sums. It registers the MCP server with Claude Code and Codex when they are installed, offers them the WIRK skill, and runs wirk login. It never uses sudo. Running it again is safe, and replaces an earlier wirk MCP server and WIRK skill with this release's. sh install.sh --dry-run prints every step without doing any; --yes answers its questions; --url URL logs in to another service.

wirk login makes a token for this machine, keeps it in ~/.config/wirk (readable only by you) and asks WIRK to approve the machine: open the link it prints, sign in and approve. Where a service has no web sign-in, it prints the token's digest instead; send the digest to your WIRK administrator. The default service is https://api.wirk.life.

By hand: uv tool install wirk (or the wheel attached to a release), then wirk login. For agents, also wirk-mcp and the skill (wirk-skill).

Use

Start with wirk status. wirk --help lists every command with an example you can run as printed.

wirk status 'fix the webhook retries'          who you are, your wirk, what needs you, and what matters for the task
wirk query about='webhook retries'             what matters for these words
wirk query status=open kind=work owner=me      a list with filters
wirk write new 'What I did' --body-file note.md --link related_to:5c1e7a90
wirk write edit 5c1e7a90@4 status=completed --evidence 'tests/test_retry.py passes'
wirk write new 'Q3 plan' kind=context level=initiative --propose --reason 'Agreed in planning'

Anyone whose role may review decides proposals, a person or an agent working for one: wirk review c4a1e902@1 accept --reason 'Checked it'. A background agent only proposes. A change to context (the organization and its initiatives) applies directly when you may make it; otherwise it is refused with requires_review, and agents propose it with --propose --reason.

ID@N names the revision you read (rN on a card), so a change never overwrites one you did not see. Results are text; --json gives the data. A result line label: command is the next command: type wirk and what follows the colon. After an uncertain result, run the same command again with the --request-id it printed; it applies once.

For people

Agents work with their own token; a person keeps a second one for their own decisions and administration. These commands read only that person token, and each runs only at a terminal, after you type a confirmation that names the action:

wirk login --person                                   make or check your own token
wirk review c4a1e902@1 accept --reason 'Checked it' --person    decide as yourself, not as your agent
wirk admin show account                               what your account holds (administrators)
wirk admin --request batch.json                       people, tokens, wirkspaces and fields (administrators)

Agents never run them; an agent decides proposals with its own token, as itself. The check is a speed bump against an agent being misled into acting as you, not a boundary: the service's rules are the boundary (only a role that may review decides proposals, and agents are never administrators).

What leaves your machine

  • The requests you or your agents make, and their content.
  • The token, only as the bearer header to the address it was made for: never to another address, a redirect or a storage link, and never in output, logs or errors.
  • With status, the client's name and version, a session hash, the repository as host/owner/name (or a hash when it has no plain remote) and the branch name. WIRK shows these as reported, never as authority.
  • File bytes you upload, straight to storage through short-lived links.

There is no telemetry. People keep a separate token of their own for their own decisions and administration; agents never use it.

Changes

0.4.1

  • Project catch-ups start from WIRK and linked records, with direct MCP preferred when available. Read-only catch-ups do not claim or change work; focused checks can verify stale or conflicting evidence.
  • Help reflects the current service: people and personal agents whose role may review can decide proposals. Background agents only propose. Meaning ranking is available on Pro; other plans rank by words.
  • The installer replaces stale MCP registrations and skills, without writing through skill symlinks. Verified wheels stay in ~/.local/share/wirk/wheels so reinstalling can repair earlier temporary origins. Rerun the installer to update the pinned release.

0.4.0

  • wirk import github OWNER brings a GitHub owner's issues into a wirkspace. Each issue becomes work, with its history as text, its comments in a linked doc and its raw record as a file, and running it again brings only what changed. Start with --dry-run; a person who administers the account applies the setup it prints. GitHub is only read, through your gh login. See wirk import --help.

0.3.1

  • wirk --version prints the version.
  • The help says only people decide proposals and how, leaves out wirk show until it is live, and names the refusals agents meet.
  • Login prints the service's next step once.

Development

uv run --extra test python -m pytest tests -q runs the tests. The contract tests run against a scratch WIRK service when WIRK_TEST_URL and WIRK_TEST_ADMIN_TOKEN_FILE are set.

Releasing

A v* tag that matches the version in pyproject.toml runs the release workflow: tests, the wheel and the sdist, a GitHub Release with SHA256SUMS, and PyPI through trusted publishing. The PyPI step stays off until the wirk project on PyPI has this repository's release.yml and its pypi environment as a trusted publisher and the repository variable PYPI_PUBLISH is true. No token is stored anywhere.

License

Apache-2.0. See LICENSE.

Metadata

Release files for wirk 0.4.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for wirk 0.4.1
File Size Uploaded
wirk-0.4.1.tar.gz 172.0 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for wirk 0.4.1
File Interpreter ABI Platform
wirk-0.4.1-py3-none-any.whl Python 3 none any Details

Total release size: 231.2 kB

Release files / wirk-0.4.1.tar.gz

Download URL wirk-0.4.1.tar.gz
Size 172.0 kB
Tags Source
SHA-256 checksum
How to use checksums
b5ac14c8b23e54b5bf8e75b1d7d69104b9070ee973684958a3b5bf27e6993b9e
BLAKE2b-256 checksum
How to use checksums
78562fc4b2b81e050d63177e95dfdf09c7d067881d8b12cad25ff5bf0d37b790
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 6, 2026.

Transparency log

Release files / wirk-0.4.1-py3-none-any.whl

Download URL wirk-0.4.1-py3-none-any.whl
Size 59.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
959b451e76a82c3301404de9cba30a218974d5a1d0a30036cd36afdad4e383e7
BLAKE2b-256 checksum
How to use checksums
1f1d69b8fc46d4a531311a130f0b3fe8b3e6a7ed0753c10aff24642624bb8095
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 6, 2026.

Transparency log

Release history Release notifications | RSS feed

0.4.17

2 release files

0.4.16

2 release files

0.4.15

2 release files

0.4.14

2 release files

0.4.13

2 release files

0.4.12

2 release files

0.4.11

2 release files

0.4.10

2 release files

0.4.9

2 release files

0.4.8

2 release files

0.4.7

2 release files

0.4.6

2 release files

0.4.5

2 release files

0.4.4

2 release files

0.4.3

2 release files

0.4.2

2 release files

This release

0.4.1 This release

2 release files

0.4.0

2 release files

0.3.1

2 release files

0.3.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page