CASE STUDY — Worky
Worky
A small control panel that turns Jira tickets into a visible backlog and one-click AI workflows. The whole team can see what's happening, not just the operator.
Overview
Worky is a small control panel for AI-assisted software work. It turns Jira tickets into a visible backlog and gives a team one place to launch analysis, implementation and review workflows.
The important distinction is that Worky is a launcher, not a replacement for Jira, Git or the IDE. The application contains no AI decision making. That intelligence lives in Codex Skills, while Worky handles the surrounding coordination.
The problem
An AI development workflow scatters fast. Jira holds the request. A terminal holds the commands. An IDE holds the code. The agent’s output ends up somewhere else: a log file, a chat transcript, someone’s memory.
That can work for the person operating it. It is hard for anyone else. A teammate or lead who wants to know whether a ticket has been analyzed, whether work has started, or what state the branch is in has to ask. There is no shared surface where the workflow becomes visible.
The team needed a small internal tool that could make the backlog visible, show whether work had been analyzed or started, and trigger AI workflows non-interactively, without becoming another project-management system.
How Worky helps
Worky gives the workflow a home. Open the panel and you see the backlog, with each ticket’s state clear at a glance: analyzed, started, or not yet touched. From the same view you can launch the next step: analyze a ticket, start implementation on a feature branch, or review what is already there.
The orchestration layer stays thin. Worky knows when to launch a workflow; the skill knows how to reason about a ticket. That separation means new skills can add new workflows without moving AI logic into the web server.
It also runs against a real local project. The panel runs in Docker with the project mounted in, so a workflow can inspect and change real files while the control panel itself stays a small server-rendered application.
Outcomes
The result is a useful internal surface with a small operational story: configure the environment, run docker compose up, and open the panel against the mounted project.
The generic parts stay generic. Backlog synchronization, ticket state and Git state are separate from the skills that provide the intelligence. The panel can grow by adding workflows while preserving the same simple mental model: see the ticket, understand its state, and launch the next step.
If your team has a workflow that currently lives across too many terminals, tools and handoffs, we can give it a home too.
Under the hood
- Stack: Go (standard library only), Docker Compose, Codex CLI + OpenCode behind one runner,
jira-clifor sync, server-renderedhtml/template. - Backlog: a sync script refreshes a single backlog file from Jira. The panel only reads it, so the view never needs Jira API logic.
- Ticket state: derived from the filesystem and Git. A matching branch or analysis file is enough to mark a ticket started or analyzed.
- Artifacts: workflow output lives in a
.project-ai/directory that Worky keeps in.gitignore, so AI-generated files never become accidental commits.