[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C21Z6WHGGVT4VG0BN0BF77":3,"skill-same:01M6C21Z6WHGGVT4VG0BN0BF77":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6C21Z6WHGGVT4VG0BN0BF77","design-fidelity-diff",null,"Use when implementing or reviewing UI against an approved design mock. Compare rendered artifacts, measure their geometry and visible properties, and itemize concrete deltas instead of judging against a remembered summary.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdesign-fidelity-diff\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41],"design","diff","design fidelity diff","artifacts","ui","use","deltas","properties","summary","geometry","mock","compare","implementing","when","2026-11-10 10:12:30",false,"---\nname: design-fidelity-diff\ndescription: Use when implementing or reviewing UI against an approved design mock. Compare rendered artifacts, measure their geometry and visible properties, and itemize concrete deltas instead of judging against a remembered summary.\n---\n\n# Design fidelity diff\n\n## The rule\n\n**Never compare an implementation against your *summary* of a mock. Compare it\nagainst the *rendered mock*.**\n\nA summary is lossy by construction. You extract \"Option C = one bordered\nsurface, no Custom Action button, pencil marker\" — and every property you did\nnot extract is now invisible to you forever. You cannot self-detect the loss,\nbecause the check (\"does it look like my summary?\") is evaluated against the\nsame lossy artifact that caused it. This is why \"it matches\" feels true right up\nuntil someone opens the screenshot.\n\nThe runtime-evidence harness does **not** cover this. `\u002Fes`, before\u002Fafter\ncaptures, and captioned video all prove the change is **real and works**. None\nof them proves it is **right**. A UI change can pass every existing gate while\ndiverging from the approved design on every visual property.\n\n## When this is mandatory\n\nAny time an approved design artifact exists and you are implementing or\nreviewing against it. Specifically:\n\n- Implementing from a Claude Design project, Figma frame, or HTML mockup\n- The operator says \"follow the mock\" \u002F \"match the design\" \u002F \"like option C\"\n- Reviewing a PR whose description cites a design mock\n- Any time you are about to claim \"matches the mock\" \u002F \"faithful to the design\"\n\nIf the operator selected an option **plus a refinement** (\"I like C but make the\ncustom action clearer\"), the target is **C + the refinement**, not C. Diff\nagainst the refinement artifact — it is the operative spec.\n\n## Procedure\n\n### 1. Render the mock — do not read it\n\nGet pixels, not source. Reading the mock's HTML\u002FCSS and summarizing it is the\nfailure mode this skill exists to prevent.\n\nUse the design tool's supported export or preview mechanism. Keep token-scoped\npreview URLs out of user-facing text and logs. Store temporary captures in a\nunique task-scoped directory under `\u002Ftmp`.\n\n```python\nfrom pathlib import Path\nfrom tempfile import mkdtemp\nfrom playwright.sync_api import sync_playwright\nscratch = Path(mkdtemp(prefix=\"design-fidelity-\", dir=\"\u002Ftmp\"))\nwith sync_playwright() as p:\n    b = p.chromium.launch(headless=True)\n    pg = b.new_page(viewport={\"width\":1440,\"height\":900}, device_scale_factor=2)\n    pg.goto(Path(\"path\u002Fto\u002Fmock.html\").resolve().as_uri(), wait_until=\"load\")\n    pg.query_selector(\"section.opt\").screenshot(\n        path=str(scratch \u002F \"mock_section.png\")\n    )\n```\n\nIsolate the relevant option. If the mock file holds several candidates, hide the\nothers (`el.style.display='none'`) and screenshot — cropping by computed\ncoordinates is fragile and silently produces the *wrong option*, which then gets\n\"verified\" against.\n\n### 2. Render the implementation the same way\n\nSame viewport, same flow, real server. Reuse the repo's existing capture script\nif one exists so mock and impl differ only in what you are testing.\n\n### 3. MEASURE — do not eyeball, and do not ask a model to eyeball\n\nThis is the step that actually finds things. For every geometric or structural\nclaim, query the live DOM:\n\n```python\npg.evaluate(\"\"\"() => {\n  const dock = document.getElementById('composer-stack');\n  const send = document.querySelector('.composer-send');\n  const btn  = document.querySelector('.choice-button');\n  const d = dock.getBoundingClientRect(), s = send.getBoundingClientRect();\n  const cs = getComputedStyle(btn), before = getComputedStyle(btn, '::before');\n  return {\n    send_pct_of_dock: +(s.height \u002F d.height * 100).toFixed(1),\n    send_is_outside_dock: !dock.contains(send),\n    badge_left: btn.getBoundingClientRect().left + parseFloat(cs.paddingLeft),\n    badge_width: parseFloat(before.width),\n  };\n}\"\"\")\n```\n\n`getBoundingClientRect` + `getComputedStyle` (including `::before`\u002F`::after`)\nanswer containment, alignment, size, and ratio questions **exactly**. Use them\nfor anything you would otherwise squint at.\n\n**Pixel-color heuristics are a trap.** Scanning for \"purple-ish pixels\" to find a\nborder or button will happily match an unrelated element elsewhere on the page\nand hand you a confident wrong number. If a measurement result is implausible\n(a 721px-tall dock in a 275px region), it is measuring the wrong thing — throw it\nout and query the DOM instead.\n\n**A multi-model panel is not a substitute either.** Asking a vision model\n\"does this match?\" produces confident, specific, wrong answers on low-contrast\ngeometry — e.g. a seat returning `MAJOR_DEVIATION: the textarea and Send sit\noutside the bordered surface` when a DOM probe proved `send_is_outside_dock`\nwas the *intended* state and the border demonstrably wrapped the textarea. Use\nmodels for judgment (\"is this affordance confusing?\"), never for measurement.\n\n**Measuring is not looking.** A measurement covers only the properties you\nchose to measure; an all-pass scorer still misses a label drawn over content,\na toast clipping \"Cancel\" to \"Canc\", or a header scrolled off-screen. Before any\nfidelity pass, open every final-state frame and the matching mock render as\nimages yourself and list what you see that the measured list did not cover\n(overlap, occlusion, clipping, off-screen chrome). A measured pass with unopened\nframes is not a fidelity pass.\n\n### 3b. A matching attribute is not a matching pixel\n\nComparing a **value** proves the value; it does not prove the user can see it.\nA row like `placeholder | \"Custom Action: type whatever you want…\" | (same) |\nMATCH` is satisfied by a string comparison while the text renders at **1.05:1\ncontrast** and is invisible on screen — which is exactly how an unreadable\nplaceholder survived a 12-row all-MATCH fidelity table on this repo.\n\nFor any property whose whole purpose is to be *read or seen*, add a second row\nasserting it is actually perceivable:\n\n- **Text**: compute the contrast ratio of the *composited* colours (resolve\n  `rgba` over its real backdrop — an alpha colour compared against a token is\n  meaningless). [WCAG AA text contrast](https:\u002F\u002Fwww.w3.org\u002FWAI\u002FWCAG22\u002FUnderstanding\u002Fcontrast-minimum.html)\n  requires 4.5:1 for normal text, including UI labels and placeholders, and\n  3:1 for large text (at least 18 pt, or 14 pt bold), subject to its stated\n  exceptions. Being UI text does not qualify for the large-text threshold.\n- **Meaningful non-text controls, states and graphics**: apply the separate\n  [3:1 non-text rule](https:\u002F\u002Fwww.w3.org\u002FWAI\u002FWCAG22\u002FUnderstanding\u002Fnon-text-contrast.html)\n  against adjacent colours, including its exceptions for inactive controls,\n  unmodified user-agent appearance and essential graphical presentation.\n  Decorative borders and dividers are not automatically subject to this rule.\n- **Anything positioned**: confirm it is inside the viewport and not clipped by\n  an `overflow: hidden` ancestor.\n\nWatch for framework defaults leaking across themes: Bootstrap's\n`.form-control::placeholder` is a light-theme grey, so any dark surface that\nnever overrides it renders dark-on-dark while every attribute assertion passes.\n\nRule of thumb: **if a screenshot row looks empty, do not assume it is empty by\ndesign — measure it.** An apparently blank row is either genuinely blank (a\nbug) or invisible content (also a bug).\n\n### 4. Itemize the delta as a table\n\nOne row per property. Every row is `MATCH` or a concrete number-vs-number.\n\n| Property | Mock | Impl | Verdict |\n|---|---|---|---|\n| Outer border token | `--border-color` purple | `--accent-color` gold | **DELTA** |\n| Send inside border | no | yes | **DELTA** |\n| Send height % of dock | 75% | 5% | **DELTA** |\n| Choice badge gutter | `1\u002F2\u002F3` at x=12 | absent | **DELTA** |\n| Free-form marker | pencil, same gutter | pencil, inline | **DELTA** |\n| Separate Custom Action row | absent | absent | MATCH |\n\nEnumerate properties **from the mock's own source**, not from memory: every\ntoken it sets, every element's containment, every explicit size. That is what\nmakes the list exhaustive rather than \"the things I happened to notice.\"\n\n### 5. Read the mock's prose as spec, not decoration\n\nMock captions state mechanisms and constraints. They are binding.\n\n- *\"the input keeps the same left gutter as the choice rows, but its marker is a\n  pencil instead of a number — so it reads as the final item in the same list\"* —\n  the shared gutter **is** the mechanism. Shipping the pencil without the gutter\n  ships the label, not the feature.\n- Theme files state conventions: *\"Gold for text\u002Flinks. Purple for borders,\n  glows, button bg.\"* Check the token you are about to use against the stated\n  rule.\n\n### 6. Do not launder a deviation as pre-authorized liberty\n\nA caption like *\"the portrait is treated as movable\u002Fresizable\"* authorizes\n**position and size**. It does **not** authorize **containment** — moving an\nelement from outside a border to inside one is a structural change the mock never\nshowed. When tempted to classify a difference as covered by a liberty clause,\nstate the clause and the difference side by side and check they are the same\nkind of thing. If the difference changes what contains what, it is a delta.\n\n## Implementation notes\n\n**Prefer presentational mechanisms that keep the DOM identical.** Numbering\nchoice rows via a CSS counter + `::before` matches the mock without changing\nrendered text or accessible names — which keeps any \"renderer output is\nbyte-identical\" guard meaningful instead of quietly defeating it. Reach for\nmarkup only when the mock's behavior genuinely requires it.\n\n**Encode the fidelity claim as an assertion**, so the delta cannot silently\nreopen:\n\n```python\n\"insideDock\": dock.contains(pip),        # must stay False\n\"pipWidth\": pip.getBoundingClientRect().width,   # must stay \u003C= 60\n```\n\nGuard the *mechanism*, not just the current value — assert the dead layout rule\ncannot come back, and strip comments before grepping CSS so prose explaining a\nremoval does not trip the guard.\n\n## Failure signature this prevents\n\nFour operator-caught rounds on one PR, each found by the operator opening a\nscreenshot, none by the agent: wrong border token → structurally misplaced\nelement → missing gutter mechanism → wrong button geometry. When the procedure\nabove was finally run, it found every remaining delta in **one pass** with exact\nnumbers, and refuted a wrong external verdict at the same time.\n\nIf you are on round two of \"actually, that doesn't match the mock\" — stop\npatching the reported symptom and run this whole procedure. The next delta is\nalready there; you just have not measured it yet.\n","# Design fidelity diff\n\n## The rule\n\n**Never compare an implementation against your *summary* of a mock. Compare it\nagainst the *rendered mock*.**\n\nA summary is lossy by construction. You extract \"Option C = one bordered\nsurface, no Custom Action button, pencil marker\" — and every property you did\nnot extract is now invisible to you forever. You cannot self-detect the loss,\nbecause the check (\"does it look like my summary?\") is evaluated against the\nsame lossy artifact that caused it. This is why \"it matches\" feels true right up\nuntil someone opens the screenshot.\n\nThe runtime-evidence harness does **not** cover this. `\u002Fes`, before\u002Fafter\ncaptures, and captioned video all prove the change is **real and works**. None\nof them proves it is **right**. A UI change can pass every existing gate while\ndiverging from the approved design on every visual property.\n\n## When this is mandatory\n\nAny time an approved design artifact exists and you are implementing or\nreviewing against it. Specifically:\n\n- Implementing from a Claude Design project, Figma frame, or HTML mockup\n- The operator says \"follow the mock\" \u002F \"match the design\" \u002F \"like option C\"\n- Reviewing a PR whose description cites a design mock\n- Any time you are about to claim \"matches the mock\" \u002F \"faithful to the design\"\n\nIf the operator selected an option **plus a refinement** (\"I like C but make the\ncustom action clearer\"), the target is **C + the refinement**, not C. Diff\nagainst the refinement artifact — it is the operative spec.\n\n## Procedure\n\n### 1. Render the mock — do not read it\n\nGet pixels, not source. Reading the mock's HTML\u002FCSS and summarizing it is the\nfailure mode this skill exists to prevent.\n\nUse the design tool's supported export or preview mechanism. Keep token-scoped\npreview URLs out of user-facing text and logs. Store temporary captures in a\nunique task-scoped directory under `\u002Ftmp`.\n\n```python\nfrom pathlib import Path\nfrom tempfile import mkdtemp\nfrom playwright.sync_api import sync_playwright\nscratch = Path(mkdtemp(prefix=\"design-fidelity-\", dir=\"\u002Ftmp\"))\nwith sync_playwright() as p:\n    b = p.chromium.launch(headless=True)\n    pg = b.new_page(viewport={\"width\":1440,\"height\":900}, device_scale_factor=2)\n    pg.goto(Path(\"path\u002Fto\u002Fmock.html\").resolve().as_uri(), wait_until=\"load\")\n    pg.query_selector(\"section.opt\").screenshot(\n        path=str(scratch \u002F \"mock_section.png\")\n    )\n```\n\nIsolate the relevant option. If the mock file holds several candidates, hide the\nothers (`el.style.display='none'`) and screenshot — cropping by computed\ncoordinates is fragile and silently produces the *wrong option*, which then gets\n\"verified\" against.\n\n### 2. Render the implementation the same way\n\nSame viewport, same flow, real server. Reuse the repo's existing capture script\nif one exists so mock and impl differ only in what you are testing.\n\n### 3. MEASURE — do not eyeball, and do not ask a model to eyeball\n\nThis is the step that actually finds things. For every geometric or structural\nclaim, query the live DOM:\n\n```python\npg.evaluate(\"\"\"() => {\n  const dock = document.getElementById('composer-stack');\n  const send = document.querySelector('.composer-send');\n  const btn  = document.querySelector('.choice-button');\n  const d = dock.getBoundingClientRect(), s = send.getBoundingClientRect();\n  const cs = getComputedStyle(btn), before = getComputedStyle(btn, '::before');\n  return {\n    send_pct_of_dock: +(s.height \u002F d.height * 100).toFixed(1),\n    send_is_outside_dock: !dock.contains(send),\n    badge_left: btn.getBoundingClientRect().left + parseFloat(cs.paddingLeft),\n    badge_width: parseFloat(before.width),\n  };\n}\"\"\")\n```\n\n`getBoundingClientRect` + `getComputedStyle` (including `::before`\u002F`::after`)\nanswer containment, alignment, size, and ratio questions **exactly**. Use them\nfor anything you would otherwise squint at.\n\n**Pixel-color heuristics are a trap.** Scanning for \"purple-ish pixels\" to find a\nborder or button will happily match an unrelated element elsewhere on the page\nand hand you a confident wrong number. If a measurement result is implausible\n(a 721px-tall dock in a 275px region), it is measuring the wrong thing — throw it\nout and query the DOM instead.\n\n**A multi-model panel is not a substitute either.** Asking a vision model\n\"does this match?\" produces confident, specific, wrong answers on low-contrast\ngeometry — e.g. a seat returning `MAJOR_DEVIATION: the textarea and Send sit\noutside the bordered surface` when a DOM probe proved `send_is_outside_dock`\nwas the *intended* state and the border demonstrably wrapped the textarea. Use\nmodels for judgment (\"is this affordance confusing?\"), never for measurement.\n\n**Measuring is not looking.** A measurement covers only the properties you\nchose to measure; an all-pass scorer still misses a label drawn over content,\na toast clipping \"Cancel\" to \"Canc\", or a header scrolled off-screen. Before any\nfidelity pass, open every final-state frame and the matching mock render as\nimages yourself and list what you see that the measured list did not cover\n(overlap, occlusion, clipping, off-screen chrome). A measured pass with unopened\nframes is not a fidelity pass.\n\n### 3b. A matching attribute is not a matching pixel\n\nComparing a **value** proves the value; it does not prove the user can see it.\nA row like `placeholder | \"Custom Action: type whatever you want…\" | (same) |\nMATCH` is satisfied by a string comparison while the text renders at **1.05:1\ncontrast** and is invisible on screen — which is exactly how an unreadable\nplaceholder survived a 12-row all-MATCH fidelity table on this repo.\n\nFor any property whose whole purpose is to be *read or seen*, add a second row\nasserting it is actually perceivable:\n\n- **Text**: compute the contrast ratio of the *composited* colours (resolve\n  `rgba` over its real backdrop — an alpha colour compared against a token is\n  meaningless). [WCAG AA text contrast](https:\u002F\u002Fwww.w3.org\u002FWAI\u002FWCAG22\u002FUnderstanding\u002Fcontrast-minimum.html)\n  requires 4.5:1 for normal text, including UI labels and placeholders, and\n  3:1 for large text (at least 18 pt, or 14 pt bold), subject to its stated\n  exceptions. Being UI text does not qualify for the large-text threshold.\n- **Meaningful non-text controls, states and graphics**: apply the separate\n  [3:1 non-text rule](https:\u002F\u002Fwww.w3.org\u002FWAI\u002FWCAG22\u002FUnderstanding\u002Fnon-text-contrast.html)\n  against adjacent colours, including its exceptions for inactive controls,\n  unmodified user-agent appearance and essential graphical presentation.\n  Decorative borders and dividers are not automatically subject to this rule.\n- **Anything positioned**: confirm it is inside the viewport and not clipped by\n  an `overflow: hidden` ancestor.\n\nWatch for framework defaults leaking across themes: Bootstrap's\n`.form-control::placeholder` is a light-theme grey, so any dark surface that\nnever overrides it renders dark-on-dark while every attribute assertion passes.\n\nRule of thumb: **if a screenshot row looks empty, do not assume it is empty by\ndesign — measure it.** An apparently blank row is either genuinely blank (a\nbug) or invisible content (also a bug).\n\n### 4. Itemize the delta as a table\n\nOne row per property. Every row is `MATCH` or a concrete number-vs-number.\n\n| Property | Mock | Impl | Verdict |\n|---|---|---|---|\n| Outer border token | `--border-color` purple | `--accent-color` gold | **DELTA** |\n| Send inside border | no | yes | **DELTA** |\n| Send height % of dock | 75% | 5% | **DELTA** |\n| Choice badge gutter | `1\u002F2\u002F3` at x=12 | absent | **DELTA** |\n| Free-form marker | pencil, same gutter | pencil, inline | **DELTA** |\n| Separate Custom Action row | absent | absent | MATCH |\n\nEnumerate properties **from the mock's own source**, not from memory: every\ntoken it sets, every element's containment, every explicit size. That is what\nmakes the list exhaustive rather than \"the things I happened to notice.\"\n\n### 5. Read the mock's prose as spec, not decoration\n\nMock captions state mechanisms and constraints. They are binding.\n\n- *\"the input keeps the same left gutter as the choice rows, but its marker is a\n  pencil instead of a number — so it reads as the final item in the same list\"* —\n  the shared gutter **is** the mechanism. Shipping the pencil without the gutter\n  ships the label, not the feature.\n- Theme files state conventions: *\"Gold for text\u002Flinks. Purple for borders,\n  glows, button bg.\"* Check the token you are about to use against the stated\n  rule.\n\n### 6. Do not launder a deviation as pre-authorized liberty\n\nA caption like *\"the portrait is treated as movable\u002Fresizable\"* authorizes\n**position and size**. It does **not** authorize **containment** — moving an\nelement from outside a border to inside one is a structural change the mock never\nshowed. When tempted to classify a difference as covered by a liberty clause,\nstate the clause and the difference side by side and check they are the same\nkind of thing. If the difference changes what contains what, it is a delta.\n\n## Implementation notes\n\n**Prefer presentational mechanisms that keep the DOM identical.** Numbering\nchoice rows via a CSS counter + `::before` matches the mock without changing\nrendered text or accessible names — which keeps any \"renderer output is\nbyte-identical\" guard meaningful instead of quietly defeating it. Reach for\nmarkup only when the mock's behavior genuinely requires it.\n\n**Encode the fidelity claim as an assertion**, so the delta cannot silently\nreopen:\n\n```python\n\"insideDock\": dock.contains(pip),        # must stay False\n\"pipWidth\": pip.getBoundingClientRect().width,   # must stay \u003C= 60\n```\n\nGuard the *mechanism*, not just the current value — assert the dead layout rule\ncannot come back, and strip comments before grepping CSS so prose explaining a\nremoval does not trip the guard.\n\n## Failure signature this prevents\n\nFour operator-caught rounds on one PR, each found by the operator opening a\nscreenshot, none by the agent: wrong border token → structurally misplaced\nelement → missing gutter mechanism → wrong button geometry. When the procedure\nabove was finally run, it found every remaining delta in **one pass** with exact\nnumbers, and refuted a wrong external verdict at the same time.\n\nIf you are on round two of \"actually, that doesn't match the mock\" — stop\npatching the reported symptom and run this whole procedure. The next delta is\nalready there; you just have not measured it yet.\n",{"name":5,"description":7},"main","42ccd02cbf5e8e47839dc3eab6fc754dc6b339cf",".claude\u002Fskills\u002Fdesign-fidelity-diff",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-11 22:19:36",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill design-fidelity-diff",{"tool":60,"command":61},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill design-fidelity-diff",{"tool":63,"command":64},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill design-fidelity-diff","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdesign-fidelity-diff\u002FSKILL.md",true,[],[69,85,105,119,133,148],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":42},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[71,76,41,77,78,33,79,80,81,82,83,84],"user","replies","check","identity","whatsapp","gmail","read","message","ask",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":94,"publishedAt":42},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[91],{"categoryNo":92,"categoryName":93,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[87,95,96,97,98,99,100,101,102,103,104],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":42},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[111],{"categoryNo":92,"categoryName":93,"taxonomyType":25,"taxonomyTypeDesc":26},[99,95,113,114,76,115,102,116,98,117,118,103,104],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":42},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[121,126,127,128,98,129,101,130,131,132],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":42},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[140,141,142,33,143,98,144,145,39,146,147],"codexa bench","work","split","default","duplicate","task","normal","codex",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":152,"licenseFileUrl":153,"sourceHtmlUrl":154,"categories":155,"keywords":161,"publishedAt":42},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[156,159,160],{"categoryNo":157,"categoryName":158,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},[162,28,163,33,164,165,166,76,167,168,169,31,32,170,171,172,173,174,175,176,177,178,179,180,181,182,41,183],"frontend","frontend design","generic","ui design","react","html","components","code","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]