Duplicate bugs are rarely laziness. Most testers do search first. The search just fails in predictable ways, and once you know them you can get around most of them.

Why the search misses

The words differ. You call it "checkout total wrong". The original reporter called it "price not updated after plan switch". Same bug, no shared keyword. Tracker search is mostly literal, so two honest descriptions of one problem can sail past each other.

The list is sorted for the wrong question. Search results usually come back newest first, or by the tracker's own relevance score. When you are asking "has anyone seen this before?", the answer is often the oldest matching ticket, and that is exactly the one a short result page cuts off.

The spelling is not the spelling. A product name typed in full width characters by a teammate on a Japanese keyboard, a German word with or without its umlaut, a version number written three ways. Each one splits the history in two.

Closed tickets are out of sight. Many searches default to open issues. A bug that was closed as fixed and has come back is the most useful duplicate of all, because its fix tells you where to look.

A search routine that works

1. Search by symptom and by area, separately. One query with the visible symptom ("total", "price", "discount"), another with the feature or screen ("billing", "annual plan"). Read both.
2. Include closed tickets. A regression is a duplicate with a history, and the history is the valuable part.
3. Sort oldest first at least once. If the bug has existed for a while, the original report is at the bottom of the default view.
4. Try the other spellings. Product names, error codes, version strings, and any word your team writes in more than one way.
5. When in doubt, link instead of filing blind. If a ticket looks related but you are not sure, file yours and link the old one. A developer can merge two linked tickets in seconds; finding an unlinked twin later takes much longer.

Judging "is this the same bug?"

A matching title is not enough. Compare three things:

• The trigger. Same steps, same condition? "After switching plans" and "after applying a coupon" may be two different bugs with the same symptom.
• The environment. A bug reported on last year's build in one browser may not be yours.
• The evidence. The same error message or the same stack frame is the strongest signal you will get.

If two of the three match, treat it as a likely duplicate and say why in your comment. That sentence saves the triager from repeating your comparison.

How BugIt helps with this

This is one of the checks we built into BugIt, a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal.

Before you see a draft ticket, BugIt searches your tracker for tickets like yours and ranks them by how likely each one is the same bug, rather than trusting the tracker's own result order. In our own tests the true duplicate was the oldest matching ticket, exactly the one a newest first list cuts off. It searches your title the way you typed it, including full width and half width characters, and it gives you a number for each candidate so you can see how close it thinks the match is.

You make the call. If one of them is your bug, you comment there instead of filing. If none of them is, you carry on, and nothing is filed until you have read the draft and typed FILE IT.

The search goes from your machine straight to your tracker, with your own credentials. Here is the short film on it:

Try BugIt

• Read the related article on bugit.dev: Catch duplicate bugs before you file them.
• See what BugIt does at bugit.dev, or read about it on the Taskivator website: taskivator.com/bugit.
• Testers can request a free trial at bugit.dev, in exchange for honest feedback.
• One short film per feature on our YouTube channel: @BugItByTaskivator.

A good bug report answers those questions before anyone asks them. This post covers what goes into one, gives you a template you can copy into any tracker, and shows the mistakes that send tickets back.

What a developer needs from a bug report

A developer reading your ticket is trying to do three things, in order:

1. Reproduce it. If they cannot see the bug happen, they are guessing.

2. Understand the gap. What should have happened, and what happened instead.

3. Judge the impact. Whether this blocks a release or can wait for next sprint.

Each section of a good report serves one of those three jobs. Anything that serves none of them is noise, and noise makes the important part harder to find.

The template

Copy this into Jira, GitHub Issues, Azure DevOps, Linear or wherever your team works:

Title: [Area] What goes wrong, under which condition

Environment
  Build or version:
  Platform (OS, browser, device):
  Account or role used:

Steps to reproduce
  1.
  2.
  3.

Expected result

Actual result

How often
  Every time / sometimes (about N out of M tries) / once

Severity
  Blocker / major / minor / cosmetic, and one sentence on why

Evidence
  Screenshot, recording, log excerpt, error message (copied as text)

Notes
  What you already ruled out, related tickets, when it started

Now, what makes each part good.

Write the title as a search result

Your title is what a developer sees in a list of fifty tickets, and what the next tester searches for before filing a duplicate. Make it specific enough to tell this bug apart from its neighbours.

• Weak: Discount not working

• Better: [Checkout] SAVE20 discount is dropped after switching to annual billing

The better title names the area, the symptom and the condition. Someone searching for "SAVE20" or "annual billing" finds it, and a developer knows which part of the code to open before reading another word.

Steps to reproduce: write for a stranger

Write the steps as if the reader has never seen the product. Number them, and give one action per step.

• Start from a known state ("Log in as a new user with an empty cart"), not from wherever you happened to be.

• Use the exact values you used: the coupon code, the file name, the account type.

• Stop at the step where the bug shows up.

Then run your own steps once more from the start before you file. A surprising number of reports skip a step the tester did without noticing, like dismissing a cookie banner or switching tabs, and that missing step is the whole bug.

Expected and actual: the heart of the report

These two lines carry most of the value, and they are the ones most often left thin.

• Expected: "The total shows the 20 percent discount applied to the annual price."

• Actual: "The total shows the full annual price. The coupon field still displays SAVE20 as applied."

"It doesn't work" is not an actual result. Describe what you saw, including anything misleading, like a coupon that still looks applied. That detail tells a developer the display and the calculation disagree, which narrows the search a lot.

If the expected behaviour comes from a spec, a design or an acceptance criterion, link it. Then the report is about a requirement, not an opinion.

Here is a short film on how BugIt flags exactly these thin spots while you can still fix them:

How often, and how bad

"Every time" and "once" are very different bugs. If it happens intermittently, say how many tries it took ("3 out of 10 attempts"). That number tells a developer whether to look for a race condition or a plain logic error.

For severity, give your best judgement and one sentence of reasoning. "Major: affects every annual upgrade that uses a coupon" lets the team agree or disagree quickly. A bare "Critical" invites a debate.

Evidence that actually helps

• Error messages as text, not only as screenshots. Text can be searched, copied and matched against logs.

• Logs: the relevant part. The exception, its message and the first few stack frames usually tell the story. A 4,000 line log attached without comment often goes unread.

• Screenshots and recordings for anything visual, or anything that depends on timing.

• Check for private data first. Logs and screenshots often carry email addresses, tokens and customer details. Remove them before they land in a tracker that the whole company can read.

Five mistakes that send tickets back

1. Two bugs in one ticket. One gets fixed, the ticket gets closed, and the other is lost. File them separately and link them.

2. A duplicate. Search the tracker first, including older and closed tickets. The original often holds context you need.

3. A solution instead of a problem. "Change the rounding function" assumes the cause. Describe the behaviour and let the investigation find the cause.

4. No environment. A bug on yesterday's build may already be fixed. A bug in one browser may not exist in another.

5. Emotion instead of facts. "This is completely broken again!!" helps nobody. Calm, specific reports get fixed sooner.

Where BugIt fits

Following this template takes discipline, especially at the end of a long test session when you just want to get the ticket in. That is the problem we built BugIt to help with.

BugIt is a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal. You describe what happened in a sentence, and it works through the same checklist as above:

• It asks for what is missing, such as the build or how often it happens.

• It drafts the title, steps, expected and actual result and a suggested severity, with its reasons. You decide the severity.

• It scores the report and tells you when the steps, the expected result or the actual result look thin.

• It searches your tracker for likely duplicates and ranks them, so an older matching ticket is not lost at the bottom of a list.

• Paste a crash log and it keeps the exception, the message and the top stack frames.

• It redacts email addresses, tokens, API keys and similar data from the text before filing. This is pattern based, so read the draft before you approve it.

Nothing is filed until you have read the draft and typed FILE IT. BugIt works with eleven trackers, including Jira, Azure DevOps, GitHub, GitLab and Linear. This short film shows the approval step:

Try it

The template above is yours to keep, whether or not you use BugIt. If you would like help applying it to your reports:

• See what BugIt does at bugit.dev, or watch the introduction film.

• Testers can request a free trial at bugit.dev, in exchange for honest feedback.

• More short films, one feature each, are on our YouTube channel: @BugItByTaskivator.

Learn more: https://taskivator.com/bugit/?utm_source=hashnode&utm_medium=social&utm_campaign=round-2026-10-06

Our answer is two words: FILE IT. This post explains how that gate works, what runs on your machine before you see a draft, and where the gate stops.

The gate: three properties

Every write to a tracker (a new ticket, a comment, an edit, an attachment) goes through one command, tools/file_it.py. It has two steps. preview shows you the exact ticket. file writes it, and only with a confirmation. The confirmation has three properties, all enforced in that write path.

1. It must match exactly. The confirmation is compared as a whole string, not searched for inside a sentence. "don't file it", "file it later" and "FILE IT?" are all refused, because a substring test would let a sentence that declines the write authorize it. Case and extra spaces are forgiven (file it works), because you are typing into a chat box, not a password prompt. Nothing else is forgiven: a reply with invisible characters or lookalike letters is refused, and the refusal names the character it found.

2. It is bound to the draft you read. When preview runs, it records a fingerprint of the provider, the destination, the account and the full content it showed you. When file runs, it recomputes that fingerprint and refuses if anything changed. If the model rewrites the description after you approved it, or a retry produces a slightly different body, the approval no longer fits and you get a fresh preview instead.

3. It is spent once. The pending preview is consumed by the write that uses it. A repeated command, a retried tool call or a model that calls the same thing twice gets already_used, not a second ticket. A preview also expires after an hour, so a stale draft from the morning cannot be filed by an accidental rerun in the afternoon.

There is deliberately no command that deletes a ticket.

A small example

You paste a crash log and write one rough sentence:

checkout total is wrong after switching to annual with SAVE20

BugIt asks what is missing (which build, does it happen every time), then shows a preview: destination, title, steps, expected and actual result, severity. So far the only call to your tracker has been a read: the duplicate search described below.

Under the hood, the assistant runs something like:

python tools/file_it.py preview --file .cache/bug.json --json

You reply "looks good". Nothing is filed, because that is not the phrase. You reply FILE IT, and the assistant runs:

python tools/file_it.py file --file .cache/bug.json --confirm "FILE IT" --json

The fingerprint matches, the approval is spent, and the tracker returns a ticket key such as KAN-192. Running the same command again is refused.

The five checks, and where they run

Before you see a draft, five checks run. There is nothing to switch on.

1. Duplicates. BugIt searches your tracker for tickets like yours and ranks them by how likely each one is the same bug, rather than trusting the tracker's own result order. In our own tests the true duplicate was the oldest matching ticket, exactly the one a "newest first" list cuts off.

2. Severity. A suggestion from the symptoms, shown with its reasons. You decide.

3. Log parsing. Paste a crash log and it keeps the exception, the message and the top stack frames. A log too large to scan is reported as truncated, not cut silently.

4. Personal data. Email addresses, tokens, API keys, private keys, IP addresses and card numbers are redacted from the text before filing. This is pattern based, so read the draft before you approve it.

5. Quality score. It says so when the steps, the expected result or the actual result look thin.

The checks themselves are plain Python helpers with no dependencies, and they run locally. To keep report text out of shell history and the process list, they read it from a file or standard input, never from the command line.

What leaves your machine, and where it goes:

• Your conversation goes to the AI model behind the assistant you chose, as it does for anything else you type there.

• The duplicate search and the final write go from your machine to your tracker with your own credentials. For Jira Cloud and Azure DevOps that path runs through Atlassian's and Microsoft's own MCP servers; for the other trackers, BugIt calls the tracker's API directly.

• BugIt itself sends Taskivator only licence and update data: a hashed device fingerprint, an installation id, the device name and operating system, the BugIt version and the plan you picked. The full list is in the privacy notice. Your tickets, specs and tokens do not pass through our servers.

The honest limitation

The gate proves that the two words arrived on BugIt's command line. It does not prove that you typed them. Your assistant writes that command, and it is instructed to pass FILE IT only when your whole reply was exactly that. Nothing in BugIt reads your chat to check.

So an assistant that ignores its instructions (because it was jailbroken, or followed an instruction hidden inside a ticket or web page it read) could pass the phrase itself. What stands in its way is the approval prompt your editor shows before a command runs. BugIt makes that prompt appear for every BugIt command it recognises, on Claude Code through a guard hook and on VS Code through the terminal approvals it ships. A command disguised so it does not look like a BugIt command is not recognised. So keep terminal approval on, read what a prompt says it will run, and do not add a broad allow rule such as python to your editor's settings.

We think naming this beats claiming the gate is airtight. The confirmation stops the common failure, an agent treating "sure" or "looks fine" as consent or filing the same ticket twice. Your editor's prompt is the second lock.

About BugIt

BugIt is our product. It works with eleven trackers, including Jira, Azure DevOps, GitHub, GitLab and Linear, and needs Python 3.10 to 3.14. Windows 11 is fully supported; macOS and Linux are in preview. Testers can request a free trial, offered to a limited number of testers in exchange for honest feedback.

Learn more at bugit.dev.

This article was written with AI assistance and checked claim by claim against the BugIt source code by the BugIt team at Taskivator.

Learn more: https://taskivator.com/bugit/?utm_source=hashnode&utm_medium=social&utm_campaign=round-2026-10-06