Why I Built It

Most web highlighters I tried required an account before they let me save anything. That means your reading history — which articles you annotated, what you underlined, what notes you left — lives on someone else's server, tied to a login. I wanted a tool that works the first time you click it, keeps your data in your own browser, and does not phone home.

So I built one.

What It Does

Highlighter is a free browser extension that lets you mark up any web page and leave inline notes, the same way you would with a physical book. You get multiple highlight colors to organize by theme or priority, and a side panel where you can search across everything you have saved.

A few practical extras:

• Quote anchoring — highlights are stored as text excerpts with positional context, so they snap back to the right place when you revisit the page, even if the layout has shifted slightly.
• Weava CSV import — if you are moving from Weava, your existing highlights come with you.
• Flexible export — take your data out as JSON, CSV, or Markdown whenever you want.

How the Local-First Part Works

There is no account, no server, and no analytics. Everything is stored in browser local storage — your highlights never leave your device unless you export them yourself. The extension has no network permissions beyond loading the pages you are already visiting.

This also means no subscription, no "free tier" limits, and no service that could shut down and take your notes with it.

Try It and Tell Me What's Broken

You can install it from the Microsoft Edge Add-ons store.

I am still actively working on it. If a highlight lands in the wrong spot, a page causes a crash, or you want a feature that is obviously missing — leave a comment here or open an issue. Early feedback shapes what gets fixed first.

The problem is not memory. The instructions live in your clipboard instead of in a file the agent loads every time. A skill is that file.

What a skill is

A skill is a folder containing one file: SKILL.md. It has two parts.

The YAML frontmatter carries two fields — a name and a description. The description is the trigger: the agent scans the descriptions of its skills to decide which ones apply to your request. So the description does two jobs — say what the skill does, and name the situations where it fires. Write it as "does X. Use when the user asks for Y."

The body is plain markdown: the workflow, the rules, an example. No code, no config beyond the frontmatter.

Teardown: a commit-message skill

The smallest skill in my pack generates commit messages, and it shows every part doing a job. Its frontmatter, verbatim:

---
name: git-commit-message
description: "Generates conventional-commit messages from staged changes: type prefix + English imperative subject (≤50 chars) + optional body explaining why. Use when the user asks to write, generate, or polish a git commit message."
---

The workflow is five numbered steps, in execution order:

1. Look at the changes (git status --short, git diff --cached --stat). If nothing is staged, stop and ask — never invent a message out of nothing.

2. Pick exactly one type prefix: feat, fix, docs, refactor, test, chore. A change that mixes types gets split into two commits, not averaged into one.

3. Write the subject: type + imperative phrase, ≤50 characters. Empty subjects like "update code" are banned.

4. Write an optional body: 1–3 lines explaining why, not a play-by-play of how.

5. Output a ready-to-run git commit command, not bare text the user has to assemble.

Then come the rules that encode judgment — the things you would otherwise keep correcting in review:

• The subject is for skimmers; the body is for future-you in three months. Keep the two jobs separate.

• No meta-commentary in the message ("generated by AI", etc.) — the message is about the change, nothing else.

And one worked example, with the expected output:

git commit -m "feat: add CAPTCHA verification to login endpoint" -m "Blocks automated credential stuffing; CAPTCHA valid 5 minutes, account locks 10 minutes after 3 failures."

Finally, the anti-patterns — the failure modes, named explicitly:

• Writing a message for an empty staging area: no diff, no commit message.

• Catch-all chore: labeling every feat and fix as chore until the type system means nothing.

• Novel-length subjects that praise the change instead of naming it.

• Body as implementation log ("first changed line 20 of a.py, then b.py…") — the diff already shows that; the body explains why.

Each part earns its place. The description decides triggering. The numbered steps fix the order of operations and include a stop condition. The rules hold the judgment calls. The example anchors the output format better than a paragraph of prose. The anti-patterns tell the agent what to refuse.

Writing your own

1. Pick a workflow you have explained at least three times. Repetition is the selection criterion.

2. Write the description first. If you cannot write a clean trigger, the skill's scope is too wide.

3. Write the workflow as numbered steps in execution order, with stop conditions for the cases where it should not proceed.

4. Add the rules you always end up correcting — naming, format, what to do when the input is ambiguous.

5. Add one worked example — real input, expected output, no placeholders.

6. Add the anti-patterns. The ways this workflow goes wrong are as instructive as the steps.

7. Keep it short. Two minutes to read. If a rule never fires, delete it; a short, accurate skill beats a long, stale one.

Using it

Drop the folder into your agent's skills directory, and the agent picks it up by matching the description — no further configuration. If you want working examples first, the five skills in the pack this teardown came from are free and MIT-licensed: commit messages, code review, meeting minutes, technical proofreading, and structured deep research.

Repo: https://github.com/alapha888/agent-skills-en

npx skills add alapha888/agent-skills-en

The structure is the stable part; the rules are yours. Take the workflow you explained three times this week, and write it down once.

The failure is structural, not stylistic: the writing started before the question was defined and before the sources were tiered. So I wrote the workflow down as a skill, and the skill's first claim is blunt: the quality floor of research is set by its sources, not its prose.

Step one: define the question before searching anything

The workflow starts with one sentence stating what the report must answer, plus at most three sub-questions. Starting before the question is clear guarantees the research will sprawl — the agent collects whatever it finds first and the report's shape is decided by search order instead of by the question.

Step two: tier the sources before you believe them

Sources are tiered before searching, so you don't believe whatever you find first:

• Primary: official docs, original papers, original filings, protocol/legal texts, measured data.

• Secondary: reputable press, industry reports, expert interviews.

• Tertiary: social-media posts, forum threads, aggregator sites — leads only, never evidence.

That last line is a hard rule in the skill: no tertiary source supports a core conclusion. A forum thread can point a direction, never serve as evidence.

Step three: cross-verify, and count independence honestly

Key conclusions need two or more independent sources. Two sources quoting the same origin don't count as independent — that is the trap that makes a single press release look like a consensus. If no second source exists, the conclusion is downgraded to a "single-source claim" and marked as such, instead of being quietly upgraded by confident wording.

Related rules:

• Every number in the report has a source. A number without a source is deleted, not rewritten.

• Date every key fact ("as of Sep 2026"). Undated information is treated as "possibly stale" by default.

Writing structure: conclusion first, uncertainty last

Only after those three steps does writing start, and the structure is fixed:

• Opening: 3–5 lines stating the core conclusions.

• Body: one section per sub-question, each in "conclusion → evidence → sources" order.

• Closing: an uncertainty statement — what wasn't found, what's speculation, under what conditions the conclusions change.

The skill also insists on ordering inside the author's head: state "what you don't know" before "what you know" — honest uncertainty beats pretty certainty. And mark speculation as speculation: use "may", "likely", "unverified" — never dress speculation up with "clearly" or "it is well known".

The report outline template from the skill:

# Research Report: <Topic> (example outline)

**Core conclusions** (3–5 lines): …

## 1. Sub-question one
- Conclusion: …
- Evidence: … (source: primary/secondary, as of …)
- Evidence: … (second independent source)

## 2. Sub-question two
…

## Uncertainty statement
- Not found: …
- Single-source claims: … (one source only, pending verification)
- Invalidation conditions: if … changes, conclusion X in this report needs reassessment.

The anti-patterns are the point

The skill lists its own failure modes explicitly:

• Single-source verdicts: one social-media post becomes "research shows".

• Speculation as fact: "clearly" and "it is well known" are the most dangerous words in a research report.

• Undated facts: 2023 data presented as the current state; the conclusion quietly expires.

• Evidence pile with no conclusion: 20 sources listed, and the reader still can't tell what the author believes.

• Hiding the unknowns: burying what wasn't found makes the report look omniscient and plants landmines.

That last one is why the uncertainty statement is a required closing section rather than a footnote. A report whose unknowns are explicit can be trusted where it does claim something; a report that hides them cannot be trusted anywhere.

The skill

This is one of five free, MIT-licensed skills in a small pack I maintain — the others cover commit messages, code review, meeting minutes, and technical proofreading. Each one is a single SKILL.md file: copy the folder into your agent's skills directory and it applies the workflow without being re-explained every session.

Repo: https://github.com/alapha888/agent-skills-en — the research skill is under skills/deep-research-framework/, including the full workflow and anti-pattern list.

If your work has house rules of its own — sources you always trust or never cite — fork the file and add them to the tiering step. The structure is the stable part; the source list is yours.

Every developer who has worked with a coding agent for more than a day has run into this: you start a new session, the agent asks you to write a commit message, and you spend two minutes re-explaining your team's commit format — conventional commits, imperative subject, body explains why not how. Or you ask for a code review and get back a list of semicolon complaints. Or you paste meeting notes and the agent invents a name for the action item owner because you forgot to assign one.

These are recurring conventions, not one-off instructions. The right fix is to write each convention down once, in a file the whole team can version-control and share. That is what a skill does: a folder with a SKILL.md that your agent (Claude Code, Codex, Cursor, Gemini CLI, or any tool that reads from a skills directory) loads when the task matches. The file carries the workflow, the rules, the examples, and the anti-patterns. Once committed to the repo, every teammate's agent follows the same rules without any of them having to explain it again.

The pack below is free and MIT-licensed. Five skills, one repo: github.com/alapha888/agent-skills-en.

1. git-commit-message

The pain: Agents default to vague commit messages — fix bug, update file, refactor. Getting a useful message requires spelling out your format every time, and even then the agent often conflates the subject line with an explanation.

What the skill does: The agent follows a strict two-part structure. The subject is type: imperative phrase, capped at 50 characters. The body explains why the change was made, not how. Bug fixes must include the trigger condition. If the staging area is empty, the agent stops and asks rather than inventing a message from context.

"The subject is for skimmers; the body is for future-you in three months. Keep the two jobs separate."

A real example the skill ships with:

git commit -m "fix: keep order-list filters across pagination" -m "Trigger: filter first, then turn the page. Cause: page turns dropped the query params."

Install: Clone the repo and copy skills/git-commit-message into ~/.claude/skills/ (global) or .claude/skills/ inside your project.

2. code-review-checklist

The pain: Ask an agent to review a PR and you get a mix of real issues and style opinions — trailing spaces, quote style, indentation. The noise buries the signal, and team members learn to ignore agent reviews.

What the skill does: Reviews follow five axes in strict priority order: correctness, security, readability, performance, test coverage. Every comment is formatted as [axis] file:line problem → suggested fix. The review is capped at 10 comments. Diffs over roughly 400 lines are flagged for splitting before the review proceeds. Correctness and security issues are marked Must fix; the rest are Should fix.

"No style policing: indentation, quotes, semicolons — that's the linter's job, not a human's."

A real example comment the skill ships with:

[Must fix][Correctness] order.py:87 empty order list triggers IndexError → guard for empty before taking [0]

Install: Copy skills/code-review-checklist into ~/.claude/skills/ or .claude/skills/ in your project.

3. meeting-notes

The pain: Raw meeting notes are long and unstructured. Paste them into an agent and you typically get a bullet-point summary that buries the actual decisions, invents deadlines that were never mentioned, and assigns owners to action items that had none.

What the skill does: The output opens with the conclusion, then organizes everything into three buckets. Decisions are phrased as "Decided to do X" — never "Discussed X." Action items each carry an owner and a deadline; missing owners are marked [unassigned], missing deadlines [TBD]. Open questions state what is blocking and who owns the next step. The final minutes are no longer than one third the length of the raw notes.

"Do not fabricate. Names, dates, and numbers not in the notes must not appear; mark missing ones [to confirm]."

Install: Copy skills/meeting-notes into ~/.claude/skills/ or .claude/skills/ in your project.

4. deep-research-framework

The pain: Agents are willing to write confident-sounding research reports full of numbers with no traceable source. You ask for a competitive analysis and get statistics that either come from a single blog post or cannot be verified at all.

What the skill does: Before searching, the agent writes the research question in one sentence. Sources are tiered before searching begins: primary sources are official docs, original papers, filings, and measured data; secondary sources are reputable press, industry reports, and expert interviews; tertiary sources — social posts, forum threads, aggregator sites — are leads only, never evidence. Key conclusions require two or more independent sources (two sources quoting the same origin do not count as independent). Reports open with conclusions and close with an explicit uncertainty statement. Every key fact is dated.

"Every number in the report has a source. A number without a source is deleted, not rewritten."

Install: Copy skills/deep-research-framework into ~/.claude/skills/ or .claude/skills/ in your project.

5. tech-writing-proofread

The pain: Ask an agent to proofread a README or doc and it rewrites the whole thing — changing the structure, rephrasing accurate but imperfect sentences, and occasionally "correcting" technical claims it does not fully understand.

What the skill does: The agent proofreads only, in one pass, across six specific categories: typos and spelling, grammar, punctuation, inline code and proper noun formatting, sentence style, and structure. The output is an itemized list in the format Original → Suggestion → Reason, followed by a short count of issues by category. Suspected factual errors are flagged [verify] and left as-is. The agent does not touch anything outside those six categories.

"Fix language, not facts."

Install: Copy skills/tech-writing-proofread into ~/.claude/skills/ or .claude/skills/ in your project.

Install the Whole Pack

To add all five skills at once:

npx skills add alapha888/agent-skills-en

The pack is free and MIT-licensed — use it, fork it, or adapt it for your team's conventions.

A Pro pack with three additional skills is available for $39: https://alapha888.github.io/agent-skills-pro/