agentleFS
lucasyhzhu-debuglucasyhzhu-debug/claude-skills/skills/proofing-room/SKILL.md

proofing-room

Skill0 starsChanged 3 months agoMITView on GitHub

Use when someone wants to review, proof, comment on, mark up, draw on, or collect feedback on an HTML page, static site, landing page, slide deck, or generated report — and feed that feedback back to an agent. Drops a self-contained wrapper onto any HTML so reviewers pin comments, edit copy in place, and draw boxes/arrows/freehand marks to show what they mean, then export an anchored JSON (plus a replay file an agent screenshots) an agent can action. No backend, no build step. Triggers include "add review/proofing mode", "let me comment on this page", "let me draw on this slide", "show you exactly where this goes", "collect feedback on this HTML", "make this markup-able", or "turn review notes into a JSON for an agent".

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. Nicegarrry/claude-skills★ 026% same

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 4 are distinctive, and 10 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 10

    Very specific

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

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

    Add this once, just before </body>:

    line 72
  2. Very specific:

    Add <script src="/proofing-room.js"></script> to the shared template / layout / <head> include so every page gets it.

    line 83
  3. Very specific:

    Add the tag once in the root layout.

    line 91
  4. Very specific:

    Every export that contains a drawing writes a second file next to the JSON: proofing-markup-<page>-<date>.js (or -rN for a send round), a …

    line 212
  5. Distinctive:

    Only then plan the changes.

    line 232
  6. Very specific:

    When a page uses alwaysOn, also hide the proofing chrome in its print CSS (@media print { …

    line 302
  7. Very specific:

    v7 field notes: Every exported comment gains num, the reviewer's ordinal, which is what the badge shows on the page and in a capture.

    line 394
  8. Very specific:

    All values are percentages of the mark's frame, one decimal place.

    line 407
  9. Very specific:

    When you're given a proofing-*.json:

    line 413
  10. Distinctive:

    Treat these as approved copy changes unless the user says otherwise.

    line 427
  11. Very specific:

    Screenshot every drawing before planning: If markups[] is non-empty, run the capture step in Capturing a drawing for each frames[] entry …

    line 434
  12. Very specific:

    Persist the data-pr-key and data-pr-frame attributes: when you edit the source HTML: keep every existing one on its element, and let …

    line 438
  13. Distinctive:

    If actioning a note requires building or restructuring slide/deck content — adding slides, adding or reworking data exhibits/charts, or …

    line 450
  14. Distinctive:

    Run it after any change to the frame, geometry, export or replay code.

    line 471

≈ “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

Proofing Room

Overview

Proofing Room is a single drop-in script (proofing-room.js) that turns any HTML page into a review surface. A human reviewer can pin comments to elements, edit copy in place, and draw on the page — box, arrow, freehand — to show what they mean when words won't do it; then one button exports an anchored JSON describing every comment, edit and drawing, which an agent reads to action the changes. No backend, no framework, no build step — it's vanilla JS that stores state in localStorage.

Core loop: agent builds HTML → human reviews in proofing mode → exports JSON → agent applies the feedback. This skill handles both ends: wiring the wrapper in, and acting on the JSON that comes back.

A drawing can't be read out of its coordinates, so the export ships a replay companion and the agent side has one extra step: render the marks back over the page and screenshot it (see Drawing and Capturing a drawing).

Works on both scrolling pages (landing pages, reports, long HTML) and slide decks where only one slide renders at a time (display/visibility/ transform/opacity toggling). On a deck, each pin tracks its own slide and is hidden while that slide is off-screen, and Extract JSON maps every slide's prose — not just the one on screen. (Jumping from the tray to a comment on another slide auto-navigates reveal.js decks; for other custom deck frameworks, navigate to the slide yourself, then the pin appears.)

When to use

  • "Add a way for me / a client to comment on this page or site."
  • "Let me draw on the slide / show you exactly where this shape goes."
  • "Let me proof / review / mark up this HTML (landing page, report, deck)."
  • "Collect feedback on this generated page and turn it into something you can act on."
  • You produced an HTML artifact and want a tight review loop with a human.
  • You were handed a proofing-*.json file and need to apply the feedback.

How activation works

The wrapper is dormant by default. It only shows the review UI when the URL carries the proof flag, so ordinary visitors never see it:

mypage.html?proof              → proofing mode ON
mypage.html                    → normal page (wrapper does nothing)
https://site.com/about?proof   → proofing mode ON
mypage.html?markup=file.js     → REPLAY mode: renders an exported drawing,
                                 no review UI (see Capturing a drawing)

#proof at the end of the URL also works as a fallback (handy for file:// URLs where some browsers drop the query string). ?proof=1 still works too — the flag just needs to be present.

This means you add one unconditional <script> tag and the script gates itself. No conditional loader / no framework shim is required.

Wiring it in

Pick the case that matches the target. In all cases, copy proofing-room.js (it sits next to this SKILL.md) to where the page can load it.

A standalone HTML file

  1. Copy proofing-room.js next to the .html file.
  2. Add this once, just before </body>:
    <script src="proofing-room.js"></script>
  3. Tell the user: open the file and add ?proof to the URL (or use #proof if opening via file://).

A static site / multi-page site

  1. Copy proofing-room.js into the served root (e.g. public/, static/, assets/).
  2. Add <script src="/proofing-room.js"></script> to the shared template / layout / <head> include so every page gets it.
  3. Reviewers append ?proof to any route. Comments are stored per-path, so each page keeps its own review set.

A Next.js / React app

  1. Copy proofing-room.js into public/.
  2. Add the tag once in the root layout. Because the script self-gates on ?proof, you do not need a conditional client component — just include it:
    // app/layout.tsx — inside <body>
    <script src="/proofing-room.js" defer />
    (If a Content-Security-Policy blocks external scripts, host it from the same origin as above rather than inlining.)
  3. Reviewers visit any route with ?proof.

Keep the wrapper a separate file, not inlined, so updates are a one-file swap and the page's own source stays clean.

What the reviewer can do (explain this to the user)

  • + Comment (shortcut c) → click any element to pin a numbered comment. The pin lands at the exact point you clicked, not the element's edge.
  • ✎ Edit text (shortcut e) → click prose to rewrite it in place. Editing is plaintext-only (rich paste can't smuggle in markup); Enter commits, Esc cancels (restores the original text, records nothing); the original is kept.
  • Threads → each tray comment has a ✓ Resolve / ↩ Reopen toggle and a ↳ Reply affordance that opens an inline composer (Ctrl/Cmd+Enter submits, Esc cancels). Replies render nested under the comment, stamped with the author. A resolved comment is muted (green-tinted, dimmed pin) but still exports.
  • Reviewer field → stamps each comment/edit/reply with a name.
  • Extract JSON → downloads proofing-<page>-<date>.json (the handoff file).
  • 📤 Send comments to Claude → downloads a round JSON containing only the NEW (unsent) notes, copies a ready-made prompt to the clipboard (paste into Claude — the wording adapts to a slide pack vs an app, see mode: below), and greys those notes with a sent rN tag. Each click sends the next round only — an iterating review loop without re-sending old feedback. Unsent notes ship regardless of status (a self-resolved note still counts as raised).
  • 📋 Recopy round N prompt → copies the last round's prompt again, for when something else lands on the clipboard before it gets pasted. Hidden until a round has been sent. It does not re-export or advance the round — the JSON already in Downloads is still the right file. Clicking Send again would not help, because those notes are already marked sent and Send reports nothing new; this button is the only way back to the prompt. It survives a reload, is cleared by Clear all, and if the browser refuses the clipboard write it shows the prompt in a pre-selected textarea so Ctrl+C still works.
  • ∿ Pen / ↗ Arrow / ▢ Box (shortcut d) → draw on the page. See Drawing below.
  • ⊘ Hide N sent drawings → clears sent ink off the page so the next round can be drawn on a clean slide. The marks stay in the tray, in localStorage and in every export — a sent round is a record, and deleting it would strand 📋 Recopy too. Offered inline in the send toast, and once switched on it stays on, so later rounds' ink clears itself as it's sent. A hidden drawing's row is tagged ink hidden. Hidden until something has been sent; Clear all is still the only real wipe.
  • Keyboard → c/e/d toggle the modes (ignored while typing in a field or with a modifier held); Ctrl/Cmd+Enter submits the comment popover and reply composers, and commits a drawing; Ctrl/Cmd+Z undoes the last mark; Esc clears the active mode / popover / drawing in progress.
  • Collapse (click the header) → shrinks to a floating toolbar that keeps the Comment / Edit / Extract buttons but hides the comment list, so it covers less of the page.
  • Drag the header → move the panel anywhere; position is remembered.
  • A thick plum border + "Proofing mode" badge signal the page is in review. The badge also reads "Pack updated HH:MM" (with the date too, when it wasn't today), so a reviewer with the page open in a tab from before a rebuild can tell at a glance whether it is the current one. Hover for the full timestamp.
  • Everything persists in localStorage per page path, so a reload is safe. On activation every prose leaf is stamped a stable data-pr-key so anchors survive DOM edits between review rounds.

Drawing (v7)

Some feedback isn't copy. "Put a three-up card row here, this tall, and move the CTA to the end of it" is a layout instruction, and pinning it to a paragraph makes the agent guess where here is. So the reviewer can draw:

  • ▢ Box — put something this size, in this spot.
  • ↗ Arrow — move this there / point at that.
  • ∿ Pen — freehand: circle it, cross it out, gesture at it.

A drawing is a group plus one note. Marks accumulate across all three tools into one draft group — the bar at the bottom of the screen counts them, undoes the last (Ctrl+Z), clears, commits (✓ Add note, or Ctrl+Enter) or discards (Esc). Committing asks for one note covering the whole drawing. This is deliberate: three arrows and a box that serve a single instruction, split into four notes, read as four unrelated requests and get actioned separately.

Committed drawings appear in the tray as one row tagged with the mark counts (▢×1 ↗×2 ∿×1), get a numbered square badge at the drawing's top-left, and behave like any other comment — resolve, reply, delete, send in a round.

Once a round is sent, its ink is still lying over the slide with nothing left to say, which makes the next round awkward to draw. ⊘ Hide N sent drawings clears it off the page (see the reviewer list above) — presentation only, so nothing an agent reads is affected.

Frames — what the coordinates are relative to

Marks are stored as percentages of their frame, not of the viewport or the page. A frame is the slide or section the drawing sits on, stamped data-pr-frame="fN" in document order exactly the way prose leaves get data-pr-key. Hidden slides are stamped too, so drawing on slide 5 doesn't depend on which slide was up when proofing mode started.

That indirection is the whole trick: it makes a drawing survive a scroll, a resize, a deck changing slides, and the frame being hoisted somewhere else for capture. It also means a mark on an off-screen slide is not painted — it reappears when its slide does.

The frame is picked as the innermost ancestor that is a real frame — a <section>, <article>, <main>, an element with the exact class slide, or one carrying data-pr-frame-root — and is large enough to be one. The looser [class*="slide"] match only wins when nothing better is found, so a deck built as .slide > .slide-body measures against .slide, not the inner wrapper. Put data-pr-frame-root on the element you want to be the coordinate space if a page disagrees with that guess.

Marks outside the frame are not clamped: an arrow starting off-slide and pointing in is a real instruction, and a negative percentage says so exactly.

Capturing a drawing (the agent side)

You cannot read a drawing out of its coordinates. "A 40×18% box at (12, 60)" tells you almost nothing about whether an arrow curves behind a bar or in front of it. Render it and look at it.

Every export that contains a drawing writes a second file next to the JSON: proofing-markup-<page>-<date>.js (or -rN for a send round), a plain-text assignment of window.__PROOFING_MARKUP. It's .js rather than .json on purpose: fetch() of a local .json is blocked under file://, a same-directory <script src> is not, and headless capture has to work from file://.

  1. Copy the replay file next to the page HTML (same directory — that's what makes the script load work).
  2. For each entry in the export's frames[], screenshot the page with the marks replayed and that one frame isolated, sized to the frame's own w×h:

    msedge --headless=new --disable-gpu --window-size=1280,720 \
      --virtual-time-budget=5000 --screenshot=frame-f2.png \
      "file:///path/to/deck.html?markup=proofing-markup-deck-r1.js&frame=f2"

    (chrome works identically. Write shots to a scratch path, never into the repo.)

  3. Read each image. The numbered badge in the picture is the note's num in the JSON — that's how you match a mark to its instruction.
  4. Only then plan the changes.

Replay mode hides all the proofing chrome (panel, border, badge) and never touches localStorage, so it can't disturb the reviewer's session. &frame=<key> isolates that frame: walking up from it, every sibling is hidden and every ancestor transform cleared, so a display:none deck gets its target slide shown, a flex-track deck advanced with translateX gets the track neutralised, and an ordinary page is reduced to the section in question. That is what makes one clean capture possible on a deck with no navigation API. Scrollbars are suppressed so a window sized to w×h isn't cropped.

Other knobs: omit &frame= to render every mark in place with no isolation (right for a scrolling page you want in one shot); add &isolate=0 to keep the frame filter but leave the page alone. When the replay has painted, the <html> element carries data-pr-replay="ready" (error if the file wouldn't load) — useful if you're driving a real browser rather than a --virtual-time-budget screenshot.

Optional config

Set window.__PROOFING_CONFIG before the script tag to tune behaviour:

<script>window.__PROOFING_CONFIG = {
  sendPrefix: "proofing-myproject-",  // names every download: the Send-round JSON,
                                      // Extract JSON, and the markup replay file.
                                      // Set it on any page opened over file:// —
                                      // without it names are slugged from the full
                                      // pathname, which for a synced OneDrive folder
                                      // means a ~140-character filename.
  mode: "slides",                     // "slides" | "spec" — which prompt to copy. Omit to auto-detect
  packUpdated: "2026-08-07T15:34:00",  // overrides the "Pack updated HH:MM" on the badge.
                                      // Omit over file:// — document.lastModified is the
                                      // file's mtime, which is exactly right. SET IT on a
                                      // served page with no Last-Modified header, where
                                      // lastModified falls back to load time and the badge
                                      // would always claim the pack is fresh.
  alwaysOn: true                      // skip the ?proof gate (local review copies only —
                                      // never ship alwaysOn on a public page)
};</script>
<script src="proofing-room.js"></script>

mode: — the copied prompt matches what is being proofed

A slide pack's notes are usually about framing and message rather than a page of copy, so one prompt cannot serve both. Auto-detected from the page — a deck renders one slide at a time, which is the tell — and overridable when the guess is wrong.

spec is just the name of the not-a-deck mode. Neither prompt mentions a written spec; that instruction and the specPath option were removed in v6.4.

ModeThe prompt asks for
specRead all the comments/edits and the context each sits in before defining the strategy for executing them; expect flow-on impacts across multiple pages and page reordering, planned as one efficient set of shifts rather than note-by-note.
slidesRead all notes first and give a holistic plan across the whole pack before changing anything; expect cross-cutting notes (framing philosophy, house writing voice, action-oriented over descriptive) that apply pack-wide rather than only at their anchor; expect structural calls (reorder, cut, move to an appendix); keep every number, date, source line and citation exactly as-is.

Both wordings exist because a note pinned to one line is often really about the voice or framing of every slide, or about a page other than the one it sits on. Actioning those one anchor at a time yields a pack that contradicts itself, and rework when two notes wanted the same structural shift — so the prompt asks for the plan first.

Set mode: "slides" by hand on a deck that scrolls a track. The detector counts how many slide-shaped containers are rendered, not how many are in the viewport, so it only recognises decks that hide inactive slides (display:none, visibility, opacity:0). A deck laid out as a flex track and advanced with transform: translateX(...) — a common deck-template pattern — keeps every slide rendered and reads as an ordinary page, so it silently gets the spec prompt. The override is the fix; the heuristic can't tell the two apart.

When a page uses alwaysOn, also hide the proofing chrome in its print CSS (@media print { #pr-root,#pr-border,#pr-badge,#pr-pins,#pr-toast,#pr-pop{display:none!important} }) or PDFs grow a phantom trailing page from the body-appended elements.

The JSON contract

Extract JSON downloads an object shaped like this:

{
  "tool": "proofing-room",
  "version": "7",
  "url": "https://site.com/about?proof",
  "path": "/about",
  "title": "About",
  "extractedAt": "2026-07-19T10:30:00.000Z",
  "reviewers": ["Nick", "Lucas"],
  "replayFile": "proofing-markup-about-2026-08-06.js",  // v7: only when a drawing exists
  "comments": [
    {
      "id": "c1",
      "num": 1,                        // v7: the reviewer's ordinal = the badge number
      "author": "Nick",
      "text": "Tighten this to one line — too wordy.",
      "status": "open",               // v6: "open" | "resolved" (resolved still exports)
      "replies": [                     // v6: threaded replies, oldest first
        { "author": "Lucas", "text": "Agreed — cut the clause.", "createdAt": "…" }
      ],
      "createdAt": "…",
      "anchorText": "Body copy",       // visible text of the element, RE-READ at export time
      "anchorResolved": true,          // v7.3: false when the anchor could not be found at all
      "anchorStale": true,             // v7.3: present only when the stored text disagreed with the live element
      "anchorTextStored": "old text",  // v7.3: what it used to say, kept so nothing is lost
      "section": "Things you can review", // nearest heading above it
      "selector": "main > section:nth-of-type(2) > … > h3:nth-of-type(1)",
      "key": "t14",                    // v6: stable data-pr-key of the anchored leaf
      "tag": "h3",
      "xPct": 42.5,                    // v6: click point as % of the element rect (0–100)
      "yPct": 61.0                     // v6: (absent on comments carried over from v5 state)
    }
  ],
  "edits": [
    {
      "id": "e1",
      "author": "Lucas",
      "original": "old copy",
      "text": "new copy",              // the reviewer's rewrite
      "createdAt": "…",
      "section": "…", "selector": "…",
      "key": "t9",                     // v6: stable data-pr-key of the edited leaf
      "tag": "p"
    }
  ],
  // v7: a DRAWING is a comment with kind:"markup", a frame and marks. It appears
  // in comments[] (so a text-only reader still gets the instruction) and its
  // geometry is indexed below — markups[] is not a second work list.
  "markups": [
    {
      "id": "c4", "num": 4,
      "frame": { "key": "f2", "selector": "div#track > section:nth-of-type(2)",
                 "label": "Where the money actually goes", "w": 1280, "h": 720 },
      "marks": [
        { "tool": "box",   "x": 6, "y": 55, "w": 88, "h": 23 },
        { "tool": "arrow", "x1": 30, "y1": 90, "x2": 86, "y2": 86 },
        { "tool": "pen",   "pts": [[6, 16.5], [12.6, 23.5], [19.2, 16.5]] }
      ]
    }
  ],
  // v7: the screenshot worklist — one row per annotated frame
  "frames": [
    { "key": "f2", "selector": "…", "label": "Where the money actually goes",
      "w": 1280, "h": 720, "notes": [4] }
  ],
  "document": [
    // flattened prose map of the page, each block with any comments attached:
    { "tag": "h3", "text": "Body copy", "selector": "…",
      "comments": [ { "author": "Nick", "text": "Tighten this…" } ],
      "edited": false }
  ]
}

v6 field notes. status and replies[] exist on every comment (v5 state is migrated on load: missing status → "open", missing replies → []). key is the anchored leaf's data-pr-key — the durable anchor; xPct/yPct are the click point as a percentage of that leaf's bounding rect. Comments/edits carried over from older (v5) state have no key/xPct/yPct and fall back to selector then anchorText. The Send-round export (📤 Send comments to Claude) is the same shape with a round number, carrying only the unsent comments/edits for that round — plus, in v7, that round's markups, frames and replayFile.

v7 field notes. Every exported comment gains num, the reviewer's ordinal, which is what the badge shows on the page and in a capture. A drawing carries kind: "markup", frame and marks; it still has the usual anchorText, section, selector and key of the element under the drawing's centre, as context — the geometry is what carries the request, so don't treat the anchor as the target the way you would for a pin. Mark shapes:

toolFieldsMeans
boxx, y, w, hput something this size, here
arrowx1, y1, x2, y2move this → there, or point at that
penpts: [[x,y], …]freehand gesture (simplified, corners preserved)

All values are percentages of the mark's frame, one decimal place. Older state loads unchanged: a v5/v6 session has no drawings, and markups/frames come back empty.

Acting on extracted JSON (the agent side)

When you're given a proofing-*.json:

  1. Locate each target by selector first, then key, then anchorText + tag. section orients you. key is only durable if the page's source actually carries the data-pr-key attributes — a hand-built page that never had them gets them stamped fresh in document order on every activation, so adding or deleting a section renumbers the lot and t321 comes to mean a different element. Where key and selector disagree, tag is the tie-breaker: it is captured live, so the one it matches is the real target. anchorStale: true means the wrapper already caught this — anchorText holds what the element says now and anchorTextStored what the note was showing the reviewer. Read both: a note written against the stored text may be about nothing at all, and saying so is more useful than actioning it.
  2. Apply edits literally — replace the element's text original → text. Treat these as approved copy changes unless the user says otherwise.
  3. Action comments as instructions/requests against their anchored element. They're feedback, not literal replacements — interpret and implement, then report what you changed per comment id. A comment's status: "resolved" means the reviewer already closed it out; read its replies[] for thread context before acting. xPct/yPct locate the pin within the element when the anchor is coarse.
  4. Screenshot every drawing before planning. If markups[] is non-empty, run the capture step in Capturing a drawing for each frames[] entry and look at the images. A drawing is a layout instruction; actioning it from the numbers is guessing.
  5. Persist the data-pr-key and data-pr-frame attributes when you edit the source HTML: keep every existing one on its element, and let new prose leaves and frames get stamped on the next activation (do not renumber existing ones). These are the durable anchor grammar that lets later review rounds re-attach to the right elements and slides even after your edits.
  6. Attribute changes to reviewers where relevant, and confirm anything ambiguous or destructive with the user before applying.
  7. The document array is a convenience map of all prose blocks with their comments already attached — use it to review the page holistically.

When feedback means building, not just editing copy

If actioning a note requires building or restructuring slide/deck content — adding slides, adding or reworking data exhibits/charts, or changing layout (not just rewriting copy in place) — that is a design task, not a copy task. Hand it to whatever deck-authoring skill or design system the project uses, rather than improvising layout inline. Literal edits and pure copy comments stay here (steps 2–3). A drawing is almost always this case — that's usually why the reviewer drew instead of typing — so screenshot it first (step 4), then hand the build to the design skill with the image and the note together.

Files in this skill

  • proofing-room.js — the drop-in wrapper (the artifact you copy in).
  • example.html — a demo page that loads the wrapper; open it with ?proof to see the tool, or use it to verify a change. Its opening comment is a manual test script; it includes a two-slide deck for the hidden-slide drawing case.
  • test-drawing.html — automated tests for the drawing layer (17 checks). Open it directly — no flag needed — or run it headlessly and read the title / the report:
    msedge --headless=new --window-size=1280,900 --virtual-time-budget=6000 \
      --dump-dom "file:///…/test-drawing.html" | grep -o "PASS [0-9]*/[0-9]*"
    Run it after any change to the frame, geometry, export or replay code.
  • README.md — human-facing setup 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.