On 29 October 2026 I joined the Claude Code workshop in Munich, hosted by the Claude Community and GlassFlow at the JetBrains office. The main part was to run a small “crew” of Claude Code sessions that takes a feature request and turns it into merged pull requests. I did the local version of Part 1 on my laptop in the afternoon, before the event. These are my notes. I am not an expert on these tools, so please read this as one person’s first try.

The tools

There are four tools in this workshop. Two of them were new to me.

• gh is the GitHub command line tool. You log in once with gh auth login, and then you can create repos, clone them and look at pull requests from the terminal.
• uv is a fast Python package and project manager. It can also download its own Python version, which helped me on an older system.
• tares is the GlassFlow tool that runs the crew. It keeps the plan, the tickets and the review results, and it starts the Claude Code sessions.
• rius is a Claude Code plugin from GlassFlow that records what a session does, for example how the context window grows. It is a bonus part of the workshop. I did not use it in the end.

The crew

The crew has three roles, and each role is a separate Claude Code session:

• The orchestrator turns the plan into tickets and hands them out.
• The builder writes the code and tests for one ticket and opens a pull request.
• The reviewer reads the pull request and checks that the tests pass.

When the reviewer is happy and CI is green, the builder merges the pull request into main. Then the orchestrator starts the next ticket.

As a person, you only step in at two points: at the start, to say what you want, and at the end, to say if it is done. Everything in between happens without you. You can watch it on a web page at http://127.0.0.1:8787/crew.

Setup on Ubuntu 22.04

My laptop runs Ubuntu 22.04. A few things were different from the workshop setup page:

• The system Python is 3.10, but Tares needs 3.11 or later. uv solved this:

  curl -LsSf https://astral.sh/uv/install.sh | sh
  uv tool install --python 3.12 tares
  

• The gh package in the Ubuntu 22.04 archive is very old. I installed it from GitHub’s own apt repo.
• I already had Claude Code installed with npm, so I skipped the Claude install script. Running it would have put a second claude on my PATH.
• The crew starts claude by itself and does not see shell aliases. So the claude binary on the PATH must be the one logged in to the account you want to use.

Running Part 1

The test project is a tiny link shortener written with FastAPI. The task is to add a click counter: count every redirect and show the count at GET /links/{code}/stats.

First, make your own copy of the starter repo and run it:

mkdir -p ~/claude-workshop && cd ~/claude-workshop
gh repo create my-link-shortener --private --template glassflow/factory-workshop-starter
gh repo clone my-link-shortener && cd my-link-shortener && git pull
uv sync
uv run uvicorn app.main:app --reload

Then start Tares and its MCP endpoint, each in its own terminal, and check the setup:

tares up                                   # web page on port 8787
tares mcp --transport streamable-http      # MCP endpoint on port 8788
tares factory doctor

doctor should show ok for everything except two lines: the crew folder is not trusted yet, and there is no crew yet. The next command fixes both:

tares factory crew up

It opens Claude Code once so you can trust the crew folder, and then it asks five questions. I chose: the crew merges after the reviewer approves and tests pass, no release step, no Codex check, one builder, and no extra permissions.

Then you give it the feature:

tares factory spec "$(cat ~/click-counter-spec.txt)"

The workshop gives a ready-made spec file. It says exactly what to build and asks for one milestone with two tickets. Using it saves some questions and some plan usage.

The part I liked: the questions

Even with a full spec, the planning session found one open point and asked me about it. The redirect handler is a plain def function, so FastAPI runs it in a thread pool. Two redirects at the same time could both read the old count and lose one click. It suggested a threading.Lock in the store, and I said yes.

It had also planned a test that runs many redirects from several threads. Before the work started, a review step pointed out that this test would pass even without the lock, because the race almost never happens in a short test. So the plan changed: one test now fails if the lock is not used, and the thread test stays only as a smoke test. I had the same worry, and I was glad the tool found it by itself.

It also flagged a dev dependency called httpx2 in the starter repo, because the name looks like a fake copy of httpx. I checked it, and it is real: it comes from the pydantic/httpx2 project on GitHub, and the Starlette version in the project tries import httpx2 first. Still, it was good that it asked instead of quietly accepting it.

The result

The crew opened two pull requests, one per ticket. CI passed, the reviewer approved, and both were merged into main. I did not touch the code. After git pull:

• the tests went from 5 to 20, and all passed
• a new link opened twice showed "clicks": 2 at the stats endpoint
• an unknown code returned {"detail": "unknown code"}, as the spec said

At the end, the orchestrator asked me to confirm a small change the reviewer asked for, and whether the project was done.

Things to watch

• Plan usage. On my setup, the orchestrator and the reviewer both ran on Opus, the orchestrator at a high effort level. I am on a Pro plan. The workshop’s own run used about 5% of a Max plan’s 5-hour limit, so on Pro it is a much bigger share. Use one builder and the ready-made spec.
• The GitHub token in Tares. Tares wants its own GitHub token, added on its web page, to follow pull request and CI status. Mine was not set, so Tares reported a 401 error. The crew still worked, because the sessions used my gh login. If you add a token, a fine-grained token limited to the one demo repo is safer than the output of gh auth token, which can reach all of your repos.

• Stop the crew when you are done. The sessions keep running and polling until you stop them:

  tares factory crew down
  

  Then stop tares up, tares mcp and the app.

• Plugins are global. The Rius plugin installs into your user-level Claude Code config, so its start-up hook runs in every Claude Code session you start, not only in the workshop folders. If you don’t use it, uninstall it afterwards.

My take

The demo task is small, so it does not prove much about large projects. But a few things stood out to me. The questions were good. The plan was checked before any code was written, and that check found a test that would not have tested anything. And there is a record of every decision afterwards. I want to try it next on a real task of my own and see how it goes.