[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C2GP0DEG958ZAPXDPFZ6Q4":3,"skill-same:01M6C2GP0DEG958ZAPXDPFZ6Q4":70},{"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":22,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6C2GP0DEG958ZAPXDPFZ6Q4","visual-verification",null,"Verify images, sprites, screenshots, and videos with tools that can inspect visual content reliably; video and animation claims require all-frame analysis (decode and account for every frame).","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\u002Fvisual-verification\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"visual verification","verification","visual","decode","claims","analysis","frame","for","Animation","Video","with tools","videos","with","can","sprites","inspect","images","screenshots","content","Tools","verify","2026-11-10 10:12:30",false,"---\nname: visual-verification\ndescription: Verify images, sprites, screenshots, and videos with tools that can inspect visual content reliably; video and animation claims require all-frame analysis (decode and account for every frame).\n---\n\n# Visual Verification Skill\n\n## Purpose\n\nHandle visual verification with a currently available image-capable tool. Check\nthe active runtime's tool catalog and the current image's accessible path before\nchoosing a route; platform and tool availability can change.\n\nBefore capture or reviewer dispatch, apply [Reuse and scoped follow-up](#reuse-and-scoped-follow-up).\n\n## The Problem\n\nSome runtime Read tools may not render PNG\u002FJPG files on some Linux versions.\nTreat that as a limitation of the specific route: probe the available image\nviewers or approved analysis tools before concluding that visual inspection is\nunavailable. Do not generalize a past tool failure to every Linux host or runtime.\n\n## Working Tools\n\n### For Image Analysis\nUse an image-capable tool available in the active runtime, such as its native\nimage viewer or an approved image-analysis MCP when present. Do not assume a\nspecific provider\u002Ftool is installed; verify availability before invoking it.\n\n### For Browser Screenshots\nUse the repository's supported browser automation route and save captures to a\ndirectory allocated through the canonical [Scratch Space skill](..\u002Fscratch-space\u002FSKILL.md).\n\n### For Video Frames — all-frame analysis\n\nNo current model perceives video continuously; every model, including Gemini and\nthe realtime APIs, samples frames. Motion review is therefore **all-frame\nanalysis**: decode every frame and account for each one yourself.\n\n1. **Provenance.** Record the media SHA-256 (and the transcoded file's hash, if\n   different), selected video stream index, codec and dimensions, duration,\n   nominal frame rates\u002Ftime base, actual decoded frame count and each frame's\n   presentation timestamp (PTS). Obtain these with\n   `ffprobe -v error -select_streams v:0 -count_frames -show_frames -show_entries stream=index,codec_name,width,height,r_frame_rate,avg_frame_rate,time_base,nb_frames,nb_read_frames:format=duration:frame=best_effort_timestamp,best_effort_timestamp_time -of json clip.mp4`.\n   `nb_frames` is container metadata and may be absent or inaccurate; use\n   `nb_read_frames` and the returned `frames[]` records for the decoded count.\n   Preserve actual PTS, including variable spacing. If a reliable count or PTS\n   is unavailable, state what is missing and leave complete coverage unproven.\n   Work in a directory from the [Scratch Space skill](..\u002Fscratch-space\u002FSKILL.md).\n2. **Decode everything.** `ffmpeg -i clip.mp4 -map 0:v:0 -fps_mode passthrough frames\u002Ff%04d.png` to extract the same stream measured above.\n   Confirm the extracted image count equals `nb_read_frames` and the number of\n   returned frame records; report any mismatch and leave uncovered frames unverified.\n3. **Partition mechanically.** Compare consecutive decoded frames for exact\n   pixel equality, including dimensions. Group frames into a *still run* only\n   when every frame is pixel-identical to its predecessor; every non-identical\n   frame is a change frame to inspect. A nonzero difference threshold may help\n   triage or prioritize frames, but never grants coverage or an inspection\n   exemption. Use each frame's PTS; do not assume uniform spacing. Compare the\n   PTS sequence and decoded frames to identify cadence anomalies or duplicates.\n4. **View every change frame, in order, at readable detail.**\n   - Overview: labelled sheets of at most 6 consecutive frames, each at least\n     640 px wide, stamped with frame index and timestamp.\n   - Moving subjects: full-resolution crops that follow the subject (track it by\n     frame difference), about 12 frames per sheet.\n   - Gait: 2× zooms on the feet and shadow for every travel direction. Check\n     foot contact versus floating, sliding of a planted foot, passing poses held\n     while the body translates, facing versus direction of travel, depth order,\n     and overlap with props and characters.\n   - Inspect suspicious frames at full resolution before deciding.\n5. **Cover still runs.** Boundary viewing may cover a run only after exact\n   decoded-pixel equality proves every frame in it identical. View its first\n   frame and the full-resolution frames on both sides of every change point\n   (for example, dialogue advances and UI changes). Read text and UI state at\n   those boundaries.\n6. **Separate layers.** Tell game UI apart from evidence overlays such as\n   caption bars, provenance boxes and the OS cursor. Label any claim that comes\n   from reading code rather than from pixels.\n7. **Coverage manifest.** Keep running notes per frame range. Every decoded\n   frame index must be either a viewed change frame or inside an exact-pixel-\n   identical still run with its boundaries viewed. Reconcile the manifest with\n   `nb_read_frames` and the returned frame records, with no gaps. If the actual\n   total cannot be established, report the unknown count and leave full-clip\n   coverage unproven.\n8. **Long clips.** Split the clip into disjoint contiguous ranges for cheap\n   parallel lanes, with boundary frames shared by adjacent lanes. The parent\n   integrates the findings and reconciles the manifest.\n9. **Report.** State the actual inspection method and covered frame\u002Ftime\n   ranges. Give each finding with its frame indices and actual PTS and a severity;\n   do not infer timestamps from a nominal frame rate. Consider whether capture\n   cadence explains an apparent defect before blaming the product. Label the\n   method \"all-frame analysis\"; do not claim subjective \"feel\". A sampled\n   video-model pass (for example Gemini at its fps cap) is supplementary only;\n   record the sampling it actually used. Where repository policy requires\n   playback, record the actual playback outcome and action-to-result time range;\n   frame analysis is supplementary. If anything could not be decoded or viewed,\n   state the exact covered ranges.\n10. In `\u002Fes` or `\u002Fer`, bind visual claims to the media SHA, frame rate, frame\n    count, coverage manifest and the inspected images.\n\n## Reuse and scoped follow-up\n\nBefore dispatch, apply [pr-lifecycle's SHA-binding rule](..\u002Fpr-lifecycle\u002FSKILL.md#sha-binding-rule-critical--applies-to-every-gate-in-this-chain)\nto existing independent visual verdicts and artifact receipts. Keep original\nreviewer, verdict, reviewed SHA, artifact hashes, observed ranges and limitations;\nrecord applicability in the existing review record, not a new ledger.\n\n- **Unchanged clip and claims:** when the complete delta and provenance show the\n  prior coverage still applies, reuse it with zero reviewer redispatch. A new\n  phase, receipt location or candidate hash alone does not require another viewing.\n- **Ending-only change:** after verifying the earlier footage and its claims are\n  unchanged, retain their valid coverage and request independent inspection only\n  of the changed ending and enough preceding context to judge the transition and\n  resulting state. Record exact source\u002Foutput ranges and the retained receipt.\n  If the change affects earlier meaning, timing, continuity or provenance, expand\n  review to every affected range; uncertain applicability is not unchanged proof.\n- **New or rejected footage:** new captures, changed cast\u002Fcharacters, changed\n  behavior or unresolved rejection findings need affected independent review.\n  Inspect new footage in full for its declared claims; an ending sample cannot\n  approve a new capture. Preserve [continuous-source integrity](..\u002Fevidence-standards\u002FSKILL.md#continuous-video-only--slideshows-are-forbidden)\n  and any stricter domain or repository proof.\n\nBefore each necessary visual dispatch, assign the artifact, claim, exact time\u002Fframe\nranges (all new frames and boundary overlap), required before\u002Fafter context and output\nfields: observed content, claim verdict, limitations and artifact\u002Frange references.\nRanges scope visual follow-up, not source approval: never combine partial source\nreaders into a full-scope vote. Existing lifecycle seat eligibility, independence,\nquorum and authority remain unchanged.\n\nThe coordinator computes and fills mechanical receipt fields from retained primary\nartifacts: hashes, frame indices and presentation timestamps (PTS), source\u002Foutput\nmapping and links. Attribute these as coordinator measurements, not reviewer\nobservations. Repair missing bookkeeping without redispatch when existing evidence\nestablishes the facts; retain the original verdict and clocks. Missing visual\njudgment, ambiguous provenance or an unmet eligibility\u002Fdeadline requirement is not\nbookkeeping and cannot be repaired into approval by the coordinator. Request only\nthe missing or affected independent judgment through the governing review route.\n\n## Verification Rule — FAIL LOUDLY\n\nIf visual verification remains unavailable after probing supported routes, state\nthe exact route(s) attempted and the limitation. Continue other authorized work;\ndo not infer that one unavailable tool means all visual inspection is impossible.\n\nBad behavior (DO NOT DO):\n- \"The sprite looks good based on pixel values\" (you can't see it)\n- Analyzing RGB numbers and claiming to assess visual quality\n- Saying \"I can see it\" when Read returns null\n- Using subagent pixel analysis as a substitute for actually seeing\n\nCorrect behavior:\n- Use an available visual-capable tool and identify the method used.\n- If it fails, try another supported route available in the active runtime.\n- If all supported routes fail, report the exact limitation and leave the visual claim unproven.\n\n## When Assessing Sprites\u002FGame Graphics\n\n1. Capture screenshot or locate sprite file\n2. Use a visual-capable tool that is currently available.\n3. Report observed content and any tool-derived analysis separately.\n4. If no supported route can inspect the image, report that limitation without making a visual claim.\n\n## Sprite Quality Claims\n\nFor sprite quality evaluations, use `\u002Fsprite-eval` when its current definition is available. Do not make sprite quality claims without actual visual inspection through a working tool.\n","# Visual Verification Skill\n\n## Purpose\n\nHandle visual verification with a currently available image-capable tool. Check\nthe active runtime's tool catalog and the current image's accessible path before\nchoosing a route; platform and tool availability can change.\n\nBefore capture or reviewer dispatch, apply [Reuse and scoped follow-up](#reuse-and-scoped-follow-up).\n\n## The Problem\n\nSome runtime Read tools may not render PNG\u002FJPG files on some Linux versions.\nTreat that as a limitation of the specific route: probe the available image\nviewers or approved analysis tools before concluding that visual inspection is\nunavailable. Do not generalize a past tool failure to every Linux host or runtime.\n\n## Working Tools\n\n### For Image Analysis\nUse an image-capable tool available in the active runtime, such as its native\nimage viewer or an approved image-analysis MCP when present. Do not assume a\nspecific provider\u002Ftool is installed; verify availability before invoking it.\n\n### For Browser Screenshots\nUse the repository's supported browser automation route and save captures to a\ndirectory allocated through the canonical [Scratch Space skill](..\u002Fscratch-space\u002FSKILL.md).\n\n### For Video Frames — all-frame analysis\n\nNo current model perceives video continuously; every model, including Gemini and\nthe realtime APIs, samples frames. Motion review is therefore **all-frame\nanalysis**: decode every frame and account for each one yourself.\n\n1. **Provenance.** Record the media SHA-256 (and the transcoded file's hash, if\n   different), selected video stream index, codec and dimensions, duration,\n   nominal frame rates\u002Ftime base, actual decoded frame count and each frame's\n   presentation timestamp (PTS). Obtain these with\n   `ffprobe -v error -select_streams v:0 -count_frames -show_frames -show_entries stream=index,codec_name,width,height,r_frame_rate,avg_frame_rate,time_base,nb_frames,nb_read_frames:format=duration:frame=best_effort_timestamp,best_effort_timestamp_time -of json clip.mp4`.\n   `nb_frames` is container metadata and may be absent or inaccurate; use\n   `nb_read_frames` and the returned `frames[]` records for the decoded count.\n   Preserve actual PTS, including variable spacing. If a reliable count or PTS\n   is unavailable, state what is missing and leave complete coverage unproven.\n   Work in a directory from the [Scratch Space skill](..\u002Fscratch-space\u002FSKILL.md).\n2. **Decode everything.** `ffmpeg -i clip.mp4 -map 0:v:0 -fps_mode passthrough frames\u002Ff%04d.png` to extract the same stream measured above.\n   Confirm the extracted image count equals `nb_read_frames` and the number of\n   returned frame records; report any mismatch and leave uncovered frames unverified.\n3. **Partition mechanically.** Compare consecutive decoded frames for exact\n   pixel equality, including dimensions. Group frames into a *still run* only\n   when every frame is pixel-identical to its predecessor; every non-identical\n   frame is a change frame to inspect. A nonzero difference threshold may help\n   triage or prioritize frames, but never grants coverage or an inspection\n   exemption. Use each frame's PTS; do not assume uniform spacing. Compare the\n   PTS sequence and decoded frames to identify cadence anomalies or duplicates.\n4. **View every change frame, in order, at readable detail.**\n   - Overview: labelled sheets of at most 6 consecutive frames, each at least\n     640 px wide, stamped with frame index and timestamp.\n   - Moving subjects: full-resolution crops that follow the subject (track it by\n     frame difference), about 12 frames per sheet.\n   - Gait: 2× zooms on the feet and shadow for every travel direction. Check\n     foot contact versus floating, sliding of a planted foot, passing poses held\n     while the body translates, facing versus direction of travel, depth order,\n     and overlap with props and characters.\n   - Inspect suspicious frames at full resolution before deciding.\n5. **Cover still runs.** Boundary viewing may cover a run only after exact\n   decoded-pixel equality proves every frame in it identical. View its first\n   frame and the full-resolution frames on both sides of every change point\n   (for example, dialogue advances and UI changes). Read text and UI state at\n   those boundaries.\n6. **Separate layers.** Tell game UI apart from evidence overlays such as\n   caption bars, provenance boxes and the OS cursor. Label any claim that comes\n   from reading code rather than from pixels.\n7. **Coverage manifest.** Keep running notes per frame range. Every decoded\n   frame index must be either a viewed change frame or inside an exact-pixel-\n   identical still run with its boundaries viewed. Reconcile the manifest with\n   `nb_read_frames` and the returned frame records, with no gaps. If the actual\n   total cannot be established, report the unknown count and leave full-clip\n   coverage unproven.\n8. **Long clips.** Split the clip into disjoint contiguous ranges for cheap\n   parallel lanes, with boundary frames shared by adjacent lanes. The parent\n   integrates the findings and reconciles the manifest.\n9. **Report.** State the actual inspection method and covered frame\u002Ftime\n   ranges. Give each finding with its frame indices and actual PTS and a severity;\n   do not infer timestamps from a nominal frame rate. Consider whether capture\n   cadence explains an apparent defect before blaming the product. Label the\n   method \"all-frame analysis\"; do not claim subjective \"feel\". A sampled\n   video-model pass (for example Gemini at its fps cap) is supplementary only;\n   record the sampling it actually used. Where repository policy requires\n   playback, record the actual playback outcome and action-to-result time range;\n   frame analysis is supplementary. If anything could not be decoded or viewed,\n   state the exact covered ranges.\n10. In `\u002Fes` or `\u002Fer`, bind visual claims to the media SHA, frame rate, frame\n    count, coverage manifest and the inspected images.\n\n## Reuse and scoped follow-up\n\nBefore dispatch, apply [pr-lifecycle's SHA-binding rule](..\u002Fpr-lifecycle\u002FSKILL.md#sha-binding-rule-critical--applies-to-every-gate-in-this-chain)\nto existing independent visual verdicts and artifact receipts. Keep original\nreviewer, verdict, reviewed SHA, artifact hashes, observed ranges and limitations;\nrecord applicability in the existing review record, not a new ledger.\n\n- **Unchanged clip and claims:** when the complete delta and provenance show the\n  prior coverage still applies, reuse it with zero reviewer redispatch. A new\n  phase, receipt location or candidate hash alone does not require another viewing.\n- **Ending-only change:** after verifying the earlier footage and its claims are\n  unchanged, retain their valid coverage and request independent inspection only\n  of the changed ending and enough preceding context to judge the transition and\n  resulting state. Record exact source\u002Foutput ranges and the retained receipt.\n  If the change affects earlier meaning, timing, continuity or provenance, expand\n  review to every affected range; uncertain applicability is not unchanged proof.\n- **New or rejected footage:** new captures, changed cast\u002Fcharacters, changed\n  behavior or unresolved rejection findings need affected independent review.\n  Inspect new footage in full for its declared claims; an ending sample cannot\n  approve a new capture. Preserve [continuous-source integrity](..\u002Fevidence-standards\u002FSKILL.md#continuous-video-only--slideshows-are-forbidden)\n  and any stricter domain or repository proof.\n\nBefore each necessary visual dispatch, assign the artifact, claim, exact time\u002Fframe\nranges (all new frames and boundary overlap), required before\u002Fafter context and output\nfields: observed content, claim verdict, limitations and artifact\u002Frange references.\nRanges scope visual follow-up, not source approval: never combine partial source\nreaders into a full-scope vote. Existing lifecycle seat eligibility, independence,\nquorum and authority remain unchanged.\n\nThe coordinator computes and fills mechanical receipt fields from retained primary\nartifacts: hashes, frame indices and presentation timestamps (PTS), source\u002Foutput\nmapping and links. Attribute these as coordinator measurements, not reviewer\nobservations. Repair missing bookkeeping without redispatch when existing evidence\nestablishes the facts; retain the original verdict and clocks. Missing visual\njudgment, ambiguous provenance or an unmet eligibility\u002Fdeadline requirement is not\nbookkeeping and cannot be repaired into approval by the coordinator. Request only\nthe missing or affected independent judgment through the governing review route.\n\n## Verification Rule — FAIL LOUDLY\n\nIf visual verification remains unavailable after probing supported routes, state\nthe exact route(s) attempted and the limitation. Continue other authorized work;\ndo not infer that one unavailable tool means all visual inspection is impossible.\n\nBad behavior (DO NOT DO):\n- \"The sprite looks good based on pixel values\" (you can't see it)\n- Analyzing RGB numbers and claiming to assess visual quality\n- Saying \"I can see it\" when Read returns null\n- Using subagent pixel analysis as a substitute for actually seeing\n\nCorrect behavior:\n- Use an available visual-capable tool and identify the method used.\n- If it fails, try another supported route available in the active runtime.\n- If all supported routes fail, report the exact limitation and leave the visual claim unproven.\n\n## When Assessing Sprites\u002FGame Graphics\n\n1. Capture screenshot or locate sprite file\n2. Use a visual-capable tool that is currently available.\n3. Report observed content and any tool-derived analysis separately.\n4. If no supported route can inspect the image, report that limitation without making a visual claim.\n\n## Sprite Quality Claims\n\nFor sprite quality evaluations, use `\u002Fsprite-eval` when its current definition is available. Do not make sprite quality claims without actual visual inspection through a working tool.\n",{"name":5,"description":7},"main","2d92c349286cf4e1cfed8cdec1773e71f6c601d2",".claude\u002Fskills\u002Fvisual-verification",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-12 14:45:07",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill visual-verification",{"tool":62,"command":63},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill visual-verification",{"tool":65,"command":66},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill visual-verification","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fvisual-verification\u002FSKILL.md",true,[],[71,89,110,123,137,153],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":44},"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",[],[73,78,79,80,81,82,83,84,85,86,87,88],"user","when","replies","check","use","identity","whatsapp","gmail","read","message","ask",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":100,"publishedAt":44},"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",[95],{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[91,101,102,103,30,104,105,106,107,108,109],"resume","compatibility","provenance","history","produce","alias","briefing","state","fresh",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":44},"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",[116],{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},[104,101,118,119,78,28,107,120,30,121,122,108,109],"history resume","branch","repository","worktree","sources",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":44},"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",[],[125,130,131,132,30,133,106,134,135,136],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":44},"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",[],[144,145,146,82,147,30,148,149,150,151,152],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":157,"licenseFileUrl":158,"sourceHtmlUrl":159,"categories":160,"keywords":170,"publishedAt":44},"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",[161,164,167],{"categoryNo":162,"categoryName":163,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":165,"categoryName":166,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":168,"categoryName":169,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000032","设计师",[171,172,173,82,174,175,176,78,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,35,192,193,79,194],"frontend","design","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","react components","web ui","pages"]