From Tab Chaos to Clarity: Why I Built a Chrome Extension for Jira + GitHub

Archit Bhargava — Sat, 14 Feb 2026 01:36:29 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

A Chrome extension but let me tell you about the problem first.

If you work in a team where:

Jira tickets aren’t pre-assigned
Multiple developers resolve tickets dynamically
Ticket status determines what goes to production
Commits are used to track ownership
Then you probably know this problem.
It’s not about writing code.

It’s about tracking responsibility — without losing your mind.

The Workflow We Had

In our setup:

Developers pick up tickets freely.
Whoever solves it moves the status.
A tracker reports resolved tickets to the project manager.
Production pushes depend on knowing which tickets were completed and by whom.
Since assignees aren’t fixed beforehand, the most reliable source of truth became:

Git commits.

So we started adding Jira ticket IDs inside commit messages.

Example:

feat: add validation for payment form (PROJ-142)

This helped us:

Identify who solved which ticket
Track what goes to dev vs prod
Avoid duplicate work
Maintain accountability

But a new problem started.

The Real Pain: Tab Chaos

Every time I needed to commit a ticket:

Open Jira
Find the ticket
Copy the ID
Switch back to GitHub
Write the commit
Re-check acceptance criteria
Switch again
Open another tab
Lose context

Sometimes I reused the same tab.
Sometimes I opened new ones.

Either way — I kept breaking flow.

When you’re working across multiple tickets?

It’s chaos.

It Got Worse…

While committing, I often needed to check:

Edge cases mentioned in comments
Special instructions
Whether something should not go to production yet
Small requirements hidden in discussion threads

I even started writing personal reminders in Notepad.
And sometimes?
I forgot to review them before pushing.

That’s risky.

The Real Problem Was Context Switching

The issue wasn’t copying ticket IDs.

It was losing context.

Jira lived in one tab.
GitHub lived in another.
My notes lived somewhere else.

My brain became the integration layer.

And that’s not scalable.

Demo

https://chromewebstore.google.com/detail/jira-github-side-panel/ihedlilomeijpkldieojppicjhcjchij

My Experience with GitHub Copilot CLI

So I Built a Chrome Extension

Instead of accepting the chaos, I built a Chrome extension that connects Jira context directly inside GitHub.

View Jira Tickets Inside GitHub

Hover over a ticket ID
Instantly see ticket details in a tooltip
Open Jira in a side panel without leaving GitHub

No more full tab switching.
No more breaking flow just to re-read acceptance criteria.

Personal Notes Per Ticket

I added a feature to:

Save private notes per ticket
Review them before merging or pushing

No more scattered Notepad files.
Everything stays attached to the ticket.

Lightweight Configuration
Simple setup for Jira instance
Quick toggle for tooltip behavior
Minimal friction

It works quietly in the background.

How I Built the UI (With GitHub Copilot in terminal)

For the UI layer, I experimented with AI-assisted development using GitHub Copilot terminal. Since this is a Chrome extension, the UI had to be built using plain JavaScript along with HTML and CSS, with no heavy frameworks and no React setup, just lightweight scripts injected directly into GitHub’s DOM. Instead of manually scaffolding every component, I described the UI structure in comments and let Copilot suggest layout patterns, tooltip logic, and side panel structures. I iterated on those suggestions, refined the styling and interactions step by step, and adjusted state handling to fit the extension environment. Copilot accelerated the repetitive parts such as structuring the popup, creating consistent UI elements, and wiring basic state flows, while I focused on the core logic, workflow decisions, and overall UX design. It did not replace thinking; it acted like a fast UI assistant. The result was a clean, lightweight interface that solves a real problem without overengineering it.

What’s Next?

I’m still improving it.

If you’ve faced similar Jira + GitHub workflow problems, I’d love to hear how you solved them.

Because at the end of the day:

Great engineering isn’t just about code.

It’s about designing better systems — including how we work.

Building My Interactive Portfolio with React Router, Gemini CLI & Cloud Run

Archit Bhargava — Mon, 02 Feb 2026 01:52:24 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I’m Archit, a frontend developer who loves building clean, scalable interfaces and turning complex ideas into intuitive user experiences. Over the past year, I’ve worked deeply with React, component libraries, and real-world product systems, and I wanted my portfolio to reflect more than just what I’ve built. I wanted it to show how I think, how I solve problems, and how I design experiences. This project became my way of treating my portfolio like a real product instead of a static resume, and using it to showcase both my technical skills and design mindset in a way that actually feels useful to the people viewing it.

🛠️ How I Built It

Designing for real users, not just layouts

I built my portfolio using React and React Router, but the real focus wasn’t the stack, it was the experience. Instead of another long scrolling page, I designed the site like a product journey where users can choose how they want to explore my work. Some people want a fast overview, others want deeper context, and some want to understand the technical decisions behind projects. React Router made it easy to structure these different paths cleanly while keeping the architecture scalable, maintainable, and closer to how real-world frontend applications are built.

Using Gemini CLI as a development partner

Throughout development, I used Gemini CLI as a thinking partner rather than a code generator. I leaned on it to refine UX copy, validate component boundaries, reason through routing flows, and debug deployment issues. Having AI available directly in the terminal made iteration faster and more enjoyable, especially when working through Docker setup and Cloud Run configuration problems. Instead of replacing my thinking, Gemini sharpened it, acting like a second brain I could bounce ideas off while building.

Shipping to production with Cloud Run

For deployment, I containerized the application and shipped it to Google Cloud Run. I deliberately avoided traditional static hosting because I wanted this portfolio to run in a real production environment. Cloud Run forced me to think about environment-based port binding, health checks, serving optimized builds, and debugging cold starts. That extra friction turned out to be a gift because it made the project feel like real engineering work rather than just another side project deployment.

What I'm Most Proud Of

A portfolio that feels like a product

What I’m most proud of is how this portfolio feels like a product instead of a personal website. The multiple exploration paths, clean routing structure, and intentional UX decisions make it easy for different users to get what they want quickly, whether that’s a recruiter scanning for experience or a developer diving into technical details. It reflects how I actually build software in real teams, where clarity, intent, and usability matter more than flashy visuals.

Using AI thoughtfully, not as a shortcut

I’m also proud of how intentionally I used AI in this project. Instead of treating Gemini as a shortcut, I used it as a collaborator to improve decisions, speed up iteration, and strengthen the final result. Combined with deploying on Cloud Run, this project helped sharpen both my frontend and production engineering skills. More than just a portfolio refresh, this became a product exercise, a UX experiment, and a real-world deployment challenge rolled into one.

DEV Community: Archit Bhargava