Worky

The problem

Our Jira tickets, terminal commands, code and agent output all lived in different places. The person running a workflow could follow it, but everyone else had to ask whether a ticket had been analysed or started.

Worky lists the backlog and launches analysis, implementation and review from the same screen.

Requirements

• Keep Jira as the backlog instead of creating another project management system.
• Run against a real local project inside Docker.
• Use server-rendered HTML with no database or frontend framework.
• Keep AI instructions out of the web server so each workflow can change independently.

What we built

We wrote the brief, designed the interface and built the Go service and Docker setup. The panel shows each Jira ticket as not started, analysed or in progress. From the same screen, a developer can launch an analysis, start implementation or request a review.

The runner supports Codex CLI and OpenCode. Workflow files go into .project-ai/, which Worky adds to .gitignore so they are not committed with product code.

Technical choices

• Git and the filesystem hold the status. A matching branch or analysis file marks a ticket as started or analysed. There is no status database to keep in sync.
• Jira sync is a separate script. The script writes one backlog file; the panel only reads it.
• Skills contain the AI instructions. The Go server launches a named workflow but does not contain its prompt or business logic.
• Local access is guarded. Ticket keys are validated before they become paths. Requests have timeouts, and termination signals are passed to child processes.

Result

We use Worky every day. Anyone on the team can check a ticket’s status without asking the developer running it, and a new skill adds a workflow without requiring changes to the panel. The whole application still starts with docker compose up.

This is an internal tool, so we do not claim external performance or productivity figures.