DEV Community: Orhan Eren Kara

From three browser tabs to an AI prompt: keeping research notes tied to their sources

Orhan Eren Kara — Tue, 13 Oct 2026 13:55:37 +0000

When comparing technical approaches, collecting information is only half the job. A quote in a notes document can lose its source, and an AI chat can blur together what a page said and what I thought about it.

I'm building MindContext, a Chrome side panel that keeps research notes and saved quotes connected to source pages and prepares context for an AI chat. This is a small workflow you can try—not a claim that it verifies sources or guarantees accurate AI answers.

A three-source experiment

Choose one real question, such as comparing two libraries for a project. Open three relevant sources and use a consistent note structure:

Source claim: What does this page actually say? Save the useful passage.
My observation: What constraint or question does that raise for my project?
Still unknown: What evidence would I need before deciding?

MindContext lets you keep a note attached to the page URL, save selected text from the right-click menu, and group related pages into a research project. The aim is to keep the relationship between a note and its source visible.

Review the context before sending it

Bring the relevant page context, your notes, and saved quotes together, then review the prepared prompt before sending it to ChatGPT, Claude, or Gemini. Remove material you don't want to share.

A useful request for that chat could be:

Compare these sources against my project constraints. Separate claims from the sources from my own observations. Point out disagreements and missing evidence. Don't invent a conclusion where the supplied material isn't enough.

That instruction isn't a reliability guarantee. Check the answer against the original sources, especially when it changes a technical decision.

What this workflow doesn't solve

Notes and quotes are stored locally in Chrome and are tied to the browser profile; there is no cross-device sync in the version described here. Local note storage does not mean the material stays local after you choose to send it to an external AI service.

MindContext organizes the context. It does not establish whether a source is true or whether an AI comparison is correct.

Try one research question

If you regularly research across browser tabs, I'd appreciate a small trial:

Collect passages and notes from three sources on one topic.
Group them into a research project.
Review the context you would bring into an AI chat.
Tell me which step still feels cumbersome or makes you return to your old workflow.

Would you organize by source page, by question, or both? That is the part I'd particularly like feedback on. Please use non-sensitive material for the trial.

Try MindContext on the Chrome Web Store

I'm the developer. I'm looking for concrete workflow feedback, not claiming a measured productivity improvement.

A recorded bug is not yet a regression test: what I review before running the draft

Orhan Eren Kara — Tue, 13 Oct 2026 13:53:03 +0000

A click sequence explains what happened, but it does not automatically prove that the original bug is covered. I'm building QA Bug → Regression Test, a Chrome extension that exports recorded browser steps as a Markdown bug report and an editable Playwright TypeScript draft. Here's the review I would apply before using that draft.

1. Write down the starting state

Which user role is needed? What test records already exist? Which page should the flow start on? A recording does not recreate backend data, account permissions, or authentication state. Document those prerequisites without copying credentials into a report.

2. Check that the locator means the intended element

A selector that works once may target the wrong element when two buttons have the same name. Review the locator and any warnings or skipped steps against the original action. Don't fix ambiguity by blindly choosing the first match.

3. Assert the result that makes the bug meaningful

After a failed login, seeing a login form isn't enough if the issue is the error message. The assertion should represent the expected behavior. For example, in a test intentionally exercising invalid credentials:

await expect(
  page.getByText(
    'Epic sadface: Username and password do not match any user in this service',
    { exact: true },
  ),
).toBeVisible();

This is an illustrative assertion, not a complete login test. The setup and preceding actions still matter.

4. Replace sensitive placeholders with safe test data

A placeholder such as REPLACE_WITH_TEST_VALUE deliberately isn't the original password. Supply appropriate test data using your project's secure test-data approach. Review the report, code, and any screenshot before sharing; sensitive-data detection is incomplete.

5. Run it in the project where it will live

Check the base URL, fixtures, authentication setup, and expected result. An exported file is a starting point for review, not a passing-test guarantee. Unsupported contexts or missing setup can require manual edits.

I'd like one concrete trial

If you handle browser bug reports or use Playwright, try one non-sensitive scenario on a demo or test site:

Start a session and reproduce the issue.
Add a visibility assertion and the expected/actual result.
Stop the session and export the report or Playwright draft.
Tell me the first thing you needed to add or change before using it.

A missing prerequisite, confusing locator, or skipped action is more useful feedback than a general thumbs-up. Please don't share credentials or private application data.

Install QA Bug → Regression Test · Watch the workflow demo

I'm the developer. I'm looking for feedback on the handoff, and I haven't established that this workflow saves time for other teams.

I built a Chrome extension that turns bug reproductions into Playwright test drafts

Orhan Eren Kara — Sat, 03 Oct 2026 19:25:45 +0000

A bug report often says “this button broke,” but the steps that caused it get lost. I built QA Bug → Regression Test to capture one manual bug reproduction and turn it into two editable starting points: a Markdown bug report and a Playwright TypeScript regression-test draft.

The workflow is straightforward:

Open a web page and start a bug session from the Chrome side panel. The extension requests access to that site when recording begins.
Reproduce the issue. The recorder captures supported clicks, form input, selections, and navigation. You can add visible-text or visible-element assertions, a bug title, expected and actual results, and one optional screenshot.
Stop the session, review what was captured, then generate and download the report and test draft.

The goal is to reduce the work between finding a bug and writing down enough detail for someone else to reproduce it. The generated test is a draft, not a passing test guarantee: check its locators, warnings, skipped steps, and assertions, replace any test-data placeholders, and run it in your own Playwright project. The recorder currently focuses on the initial site's main frame; cross-origin pages and some popup or new-tab flows can need manual work.

Sessions are stored locally in Chrome. There is no account or cloud sync in this version. Recognized sensitive form values and supported URL query/hash values receive rule-based redaction, but detection is not exhaustive. Page text, URL paths, and screenshot pixels can still contain private information, so review every output before sharing it. The optional feedback form sends only the message and optional reply email you choose to submit; it does not attach your recording or screenshot.

The interface and bug reports support English and Turkish. The generated Playwright code uses TypeScript.

Try it: QA Bug → Regression Test on the Chrome Web Store

If you do manual QA or write Playwright tests, I'd be interested to hear which part of the bug-to-test handoff costs you the most time.

I built MindContext to keep research notes connected to their sources

Orhan Eren Kara — Sat, 03 Oct 2026 18:44:11 +0000

When I research a topic, I usually end up with too many tabs, a separate notes document, and a chat window. The frustrating part is not collecting information. It is remembering where a quote came from and which of my notes belonged to that source.

I built MindContext, a Chrome side panel for that workflow. It keeps a note attached to the page URL, lets me save selected text through the right-click menu, and groups related pages into research projects. When I want to discuss the material with ChatGPT, Claude, or Gemini, it prepares the page context, my notes, and saved quotes in one place. I can review the prompt before sending it.

A small example

Suppose I am comparing three articles about a library or technical approach. I can:

Save the useful passages from each article.
Add my own questions and observations next to each source.
Group the pages in one research project.
Bring the collected context into an AI chat for comparison.

The notes and quotes are stored locally in Chrome. There is no account required to use the extension. The optional feedback form sends only the answers the user chooses to submit to the developer through Formspree.

This is an early version. It currently works in Chrome, and notes are local to the browser profile; there is no cross-device sync. I would rather learn whether the core workflow is useful before adding more features.

If you research across many tabs, I would appreciate your take: Where does your current note-taking workflow break down? Would attaching notes to individual pages help, or would you organize them differently?

Try MindContext on the Chrome Web Store