agentleFS
harukikuriharukikuri/spotnote/.claude/skills/examples-repro/SKILL.md

examples-repro

Skill25 starsChanged 25 days agoMITView on GitHub

Reproduce a reported Spotnote bug in the example apps (examples/) and pin it down with a failing E2E test before fixing it. Use when the user reports a bug, pastes an issue, or says something "doesn't work" in their app.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 0 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Start the app closest to theirs: pnpm --filter spotnote-examples-<app> dev (pnpm dev is React 19).

    line 31
  2. Very specific:

    Put it in e2e/spotnote.spec.js (or e2e/agent.spec.js if the agent is part of it), named for the behavior: "a note on a slotted element …

    line 46
  3. Very specific:

    If it's about one framework only, skip the others in the test: test.skip(app.name !== "vue", "Vue only: …").

    line 48
  4. Very specific:

    If you added markup that other frameworks have too, add it to each app, and pick it through a field on APPS in e2e/playwright.config.js …

    line 50
  5. Very specific:

    Run it and check it fails for the reported reason, not a typo: E2E_APPS=<app> pnpm --filter spotnote-e2e exec playwright test -g "<name>".

    line 52
  6. Very specific:

    Commit the test with the fix, as fix: … written for users (it goes in the release notes).

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Reproduce a bug in the examples

Goal: a failing E2E test that shows the bug, in the example app closest to the report. Then fix the code until it passes. Don't fix first: without the test you can't tell the fix worked, or keep it working.

1. Read the report

Note what decides where it can happen:

  • Framework and version, and their Vite version: each major has an app, examples/<framework>/<app>/ (DEVELOPMENT.md, "Examples layout"). Another JSX framework (Preact, …)? Use React's app: the same Babel pass stamps it.
  • The markup: what kind of element (a component's root, a .map() item, a slot, an SVG, a conditional), and in which file type.
  • What they did: clicked, Shift-clicked, edited the file (HMR), changed page, reloaded, with or without the agent connected (MCP).
  • What they expected, and what happened: the prompt's text, a pin's place, the panel, an error in the console.

Missing something that changes where it can happen? Ask for it (one question) before guessing.

2. Reproduce it by hand

  1. Start the app closest to theirs: pnpm --filter spotnote-examples-<app> dev (pnpm dev is React 19). Edit the newest app of the framework, and copy it to the others with node examples/sync.mjs.
  2. Does the example already have markup like theirs? Use it. If not, add the smallest piece that has the shape from the report to an existing page (a new element, a component). Keep the examples' look: placeholder bars (<Bar>), no real content.
  3. Drive it in a browser (Playwright from e2e/, as in .claude/skills/docs-update/screenshot.mjs) and see the bug happen.

Can't reproduce it? Say what you tried, and ask for the piece of their code or the prompt Spotnote copied: don't fix a bug you haven't seen.

3. Write the failing test

  • Put it in e2e/spotnote.spec.js (or e2e/agent.spec.js if the agent is part of it), named for the behavior: "a note on a slotted element names the file it's written in".
  • If it's about one framework only, skip the others in the test: test.skip(app.name !== "vue", "Vue only: …").
  • If you added markup that other frameworks have too, add it to each app, and pick it through a field on APPS in e2e/playwright.config.js (like title, repeated).
  • Run it and check it fails for the reported reason, not a typo: E2E_APPS=<app> pnpm --filter spotnote-e2e exec playwright test -g "<name>".

4. Fix, then run everything

Fix the code under package/ or mcp/. Then the test passes, and so does the rest: pnpm lint && pnpm test && pnpm test:e2e.

Markup you added to the examples can move line numbers that other things rely on: see the examples-sync skill.

Commit the test with the fix, as fix: … written for users (it goes in the release notes).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.