I’ve been working on Aihki, an MIT-licensed CLI client for Taiga, and thought I’d share it here.
It covers most of what I use day to day — projects, stories, tasks, issues, sprints, wiki, attachments, webhooks. Human-readable terminal output, plus stable JSON output for scripts. Tested against Taiga 6.10.2, and it works with self-hosted instances by discovering the API URL from the web app config.
I also wanted to ask about naming.
The project was originally taiga-cli, but I renamed it to Aihki in v0.2.0. I wasn’t sure whether using “Taiga” as the actual product name might imply it was official — MPL-2.0 doesn’t grant trademark rights, and the FAQ here mentions trademark control as a reason for the move to MPL.
At the same time there’s python-taiga and several other taiga-cli repos around, so I’m not sure what the preferred convention actually is.
Is there written trademark or brand guidance for third-party tools that I’ve missed?
More specifically, would you say:
“Aihki — an independent CLI client for Taiga” is fine, but
“Taiga CLI” as the project’s own name is something third-party tools should avoid?
I’ve already renamed it, so I’m mostly asking to be sure I’m following the convention the team would prefer.
Thanks — my lab runs on Taiga, which is why I ended up building this.
Thank you so much for sharing, it looks great! And thanks a lot as well for taking the name into consideration.
For small side projects we usually do not have much issue, but if it gets big and people start thinking it’s official, it ends up being a problem.
We’d rather you do not mention TaigaNext, since, as such, it does not exist anymore (it is now managed by a completely different company, called Tenzu, and the stack and API is completely different).
To clarify, the issue is with the name. If you make it compatible with Tenzu as well, definitely feel free to mention them, they are a great team making a great product. But the “TaigaNext” name has been a bit of a pain.
A quick update since my original post — the project has moved quite a bit over the past week.
I ended up publishing it as Taiga CLI, while keeping the “independent / not affiliated with the Taiga project” wording explicit in the README and project description.
More importantly, I now have a reproducible end-to-end workflow running against a real Docker-backed Taiga 6.10.2 instance rather than mocked API responses.
A typical issue workflow now looks like this:
$ taiga issue create \
--subject "Checkout confirmation is missing" \
--type Bug
Created issue product-launch#1: Checkout confirmation is missing (version 1)
$ taiga issue edit 1 \
--subject "Show confirmation after checkout" \
--dry-run
Dry run: would edit product-launch#1
$ taiga issue edit 1 --subject "Show confirmation after checkout"
Updated issue product-launch#1: Show confirmation after checkout (version 2)
$ taiga issue assign 1 --to promo_demo
Assigned issue product-launch#1: Show confirmation after checkout (version 3)
$ taiga issue close 1 --status Closed
Closed issue product-launch#1: Show confirmation after checkout (version 5)
One design goal I’ve been focusing on is making the same CLI useful for both people and automation without making either interface implicit.
Normal commands produce human-readable tables, while --json has to be requested explicitly:
$ taiga issue list --json --fields ref,subject,status,assignee,version
{"items":[{"assignee":"promo_demo","ref":1,"status":"Closed","subject":"Show confirmation after checkout","version":5}],"page":{"number":1,"size":30,"total":1},"meta":{"contract":1}}
The JSON format is versioned, each command can expose JSON Schema describing its inputs/outputs plus safety and idempotency metadata, and writes use Taiga’s versioning to avoid silently overwriting conflicting changes.
I’ve also been spending quite a bit of effort on the less-visible failure cases: dry-run guarantees that no write is sent, non-idempotent writes are not blindly retried, and if a connection disappears after a write has already been sent, the CLI reports an ambiguous_commit instead of pretending that it knows whether the operation failed.
The CLI now covers projects, epics, stories, tasks, issues, sprints, wiki pages, webhooks, custom fields and quite a few of the surrounding workflows, and builds are available for macOS, Linux and Windows.
Repository and installation instructions:
I’d especially appreciate feedback from people actually running Taiga — particularly self-hosted instances.
If you try it, I’m less interested in “does the demo work?” than in which part of your real daily Taiga workflow still feels awkward or is missing. Those are the cases I’d like to test next.
