Tickit

Inspiration

A bug gets spotted in a team chat, the conversation blows up with context, reproduction steps, and potential fixes... and then nothing happens. Nobody creates a ticket. It's just a passing conversation. The discussion gets buried, and a week later someone asks "Wait, didn't we talk about this?"

Writing tickets in project management platforms like Jira is tedious and time-consuming. It pulls developers out of their flow, requires context-switching between tools, and can be distracting in the middle of a development of debugging session.

The result is that a huge number of legitimate bugs, features, and/or issues that are discussed but never formally tracked.

To solve this issue, Tickit meets developers in their home. With so many developers using Discord and conversations already happening, they just had to be translated into tickets and published.

How we built it

Tickit is built with discord.js and listens for thread events using Discord's Gateway API. LLM listens in on the thread, giving context to how the conversation started. All a user needs to do is enter the /create command inside a thread, and Tickit will send the conversation to the LLM, generating a modal for the user to confirm the details of the conversation before publishing a ticket on Jira.

On the server side, Tickit runs as a Node.js Express application containerized and deployed on AWS Fargate, with AWS Bedrock powering the LLM calls and DynamoDB storing server configurations and session state.

Challenges we ran into/What we learned

The way Discord handles thread events are complex. Threads can be created in multiple ways, and to keep track of the conversations within the threads depending on how the thread is created is not always the same.

Inevitably, threads and channels will have noise that's not relevant to the conversation. System messages are also noise. It's important to filter out this 'noise' when creating a ticket.

What's next for Tickit

This project serves as a proof-of-concept for how the project management process can be automated. Eventually, Tickit should expand to support not just Discord, but developers' favourite collaboration applications and other project management software.

Slack is a natural next target — the same core pattern applies, and bringing Tickit there would mean listening for thread activity and publishing to Jira without ever leaving the app.

Tickit will also gain image support, allowing attachments shared in a thread — such as mockups, screenshots, or design files — to be included as context when generating a ticket. This is especially useful for design discussions where a visual artifact is central to the issue being raised.

In the future, Tickit will utilize an agentic workflow to determine the hierarchy and breakdown of tasks into parent tasks, sub-tasks, and issue types — automatically organizing work into structured epics, stories, features, and bugs without manual input.

Beyond task creation, Tickit will link dependencies between related tasks so teams can understand how work items connect across a sprint. To enable smarter prioritization, Tickit will also fetch the entire kanban board for current and upcoming sprints, giving the LLM the context it needs to suggest story point estimates and priority distribution based on existing workload. A natural evolution of this is a path toward AWS Bedrock Knowledge Base, where aggregated kanban board data is periodically ingested through an automated pipeline. Rather than fetching live board state on every request, this would allow Tickit to retrieve historical sprint patterns and team behaviour over time — enabling more informed estimates and surfacing trends like recurring bottlenecks, velocity drift, or issue type distributions across sprints.

On the configuration side, server-level settings will be expanded to support finer-grained scoping — such as per-channel configurations — allowing teams to tailor Tickit's behavior to specific workflows within the same server.

For short-lived session state — such as tracking an active /create flow or buffering thread context mid-interaction — Tickit will introduce Valkey Redis as a lightweight caching layer, keeping ephemeral data out of DynamoDB and reducing read/write overhead for transient operations.

Github Link

https://github.com/hackthebreak2026spring/discord-bot.git

How to use

Add Tickit by opening this link and selecting to add it as a bot: https://discord.com/oauth2/authorize?client_id=1482247320585113683&permissions=294205336576&scope=bot%20applications.commands

Once added, run /setup-config to connect your Jira account. This command walks through first-time credential integration, collecting your Jira domain, project key, and API key so Tickit can publish tickets on your behalf.

⚠️ Important: This is a hackathon proof-of-concept and has not been hardened for production use. Server endpoints are not secured with SSL certificates, and Jira API keys provided via /setup-config are stored in plain text in DynamoDB — not in AWS Secrets Manager or any secure vault. Do not use real or sensitive credentials.

To use Tickit, create a thread in your Discord server — it only works within thread conversations, not regular channels. After discussing the issue, run /create to generate a ticket preview from the thread, or /create <space_key> to target a specific Jira project space. Tickit will send the conversation to the LLM and present a modal for you to review and confirm before the ticket is published.