[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C24VRVAVMYHX8HT50MQ6SJ":3,"skill-same:01M6C24VRVAVMYHX8HT50MQ6SJ":54},{"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":17,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":6,"ownerHtmlUrl":38,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":39,"install":40,"resources":53},"01M6C24VRVAVMYHX8HT50MQ6SJ","game-evidence-reviewer",null,"Review game\u002Fdemo video evidence against Ragnarok Online quality standards.","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\u002Fgame-evidence-reviewer\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27],"game","reviewer","game evidence reviewer","evidence","review","demo video","demo","Video","quality","standards","2026-11-10 10:12:30",false,"---\nname: game-evidence-reviewer\ndescription: Review game\u002Fdemo video evidence against Ragnarok Online quality standards.\n---\n\n# Game Evidence Reviewer Skill\n\nReview game\u002Fdemo video evidence against the approved visual direction and the\nclaims the evidence is meant to establish. Ragnarok Online is a quality\nreference; it does not define automatic thresholds or approval.\n\n## References\n\n- [[Ragnarok Quality Game Demo Criteria|sources\u002Fragnarok-quality-game-demo-criteria]]\n- [Visual Verification](..\u002Fvisual-verification\u002FSKILL.md) owns the currently\n  available visual-inspection tools and their limitations. This guide owns the\n  game-media identity and frame-coverage protocol below.\n- [Design Fidelity Diff](~\u002F.claude\u002Fskills\u002Fdesign-fidelity-diff\u002FSKILL.md) owns\n  comparison against an approved design artifact.\n- Scratch allocation follows\n  [Scratch Space](~\u002F.claude\u002Fskills\u002Fscratch-space\u002FSKILL.md).\n\n## Activation\n\n```text\n\u002Fgame-er [evidence_path]\n```\n\nOr invoke when validating game demo evidence.\n\n## Review Procedure\n\n1. Identify the approved visual direction or acceptance criteria and the\n   specific claims this media is expected to support. If none is supplied,\n   describe observations without inventing product requirements and leave\n   product acceptance unproven (**PARTIAL**).\n2. Record the media identity and mechanical properties: source SHA-256,\n   duration, decoded frame count, frame rate, dimensions, codec, and\n   decode\u002Fintegrity result. Keep temporary outputs in Scratch.\n3. Inspect every decoded frame in chronological order, maintain a coverage\n   manifest, and disclose any gaps or limitations. Use Visual Verification to\n   select a currently available inspection tool and report its limitations.\n   Do not use a sample, contact sheet, frame count, or pixel-difference score as\n   a substitute for required visual inspection.\n4. Assess the visible result against the approved direction. Describe what the\n   character and environment actually do and look like. For animation, assess\n   whether observed poses form the intended coherent action (such as a walk\n   cycle), including contact and recovery poses when relevant. Pixel changes or\n   camera movement alone do not establish coherent animation.\n5. Report product acceptance separately from evidence\u002Fruntime facts. A\n   decodable video, motion, dimensions, frame rate, or codec does not establish\n   visual quality or product acceptance. Where an approved mock exists, use\n   Design Fidelity Diff for the artifact-to-artifact comparison.\n\n## Assessment Areas\n\nAssess only claims relevant to the approved direction and captured behavior:\n\n- **Character and sprite:** readability, pose, silhouette, detail, and fit with\n  the approved style.\n- **Animation and motion:** whether the visible sequence communicates the\n  intended coherent action; note pose, contact, timing, and continuity issues\n  that are actually observable. Distinguish character motion from camera or\n  scene movement.\n- **Environment:** composition, tile or edge continuity, palette, and relation\n  to the approved scene direction. A cool, limited, grayscale, or otherwise\n  non-warm palette is not a defect by itself.\n- **Interaction and game feel:** visible response, collision, or control claims\n  only when the recording contains enough evidence to assess them. Do not infer\n  responsive controls or wall blocking from movement alone.\n\nUse observed evidence and the approved criteria to explain each assessment.\nDo not assign a quality verdict from color counts, pixel counts, image\ndifferences, or other numerical proxies. Mechanical media properties may be\nreported as facts, but they do not decide visual quality.\n\n## Verdicts\n\nAssess each required claim as **PASS**, **PARTIAL**, **FAIL**, or\n**NOT OBSERVED**, with a concise reason tied to inspected frames and timestamps.\n\n- **PASS** means the required claim is visibly supported against the approved\n  direction across the inspected coverage.\n- **PARTIAL** means some evidence supports the claim, but a material limitation\n  or incomplete coverage prevents a full conclusion.\n- **FAIL** means inspected evidence contradicts a required claim or shows a\n  concrete defect against the approved direction.\n- **NOT OBSERVED** means the recording does not show enough evidence to assess\n  the claim.\n\nThe overall result is **PASS** only when all required visual claims pass over\nthe required coverage. Use **PARTIAL** when required claims remain unproven,\ncoverage is incomplete, or a material limitation remains. Use **FAIL** when a\nrequired claim fails. If no approved criteria or required claim list was\nsupplied, report observations but leave product acceptance **PARTIAL**; an\nempty claim list is not approval. Never convert missing evidence into\napproval. A passing media-integrity check is not product acceptance.\n\n## Output Format\n\n```markdown\n## Game Evidence Review\n\n**File**: [path]\n**Media SHA-256**: [hash]\n**Duration**: [value] | **Dimensions**: [width x height] | **Frame rate**: [value] | **Codec**: [value]\n**Decoded frames**: [count] | **Integrity**: [result]\n**Visual coverage**: [all-frame coverage manifest\u002Franges and any gaps]\n**Approved direction \u002F criteria**: [reference, or not supplied]\n\n### Required Claims\n| Claim | Verdict | Visual evidence (frame\u002Ftime) | Limitation |\n|---|---|---|---|\n| [claim] | [PASS \u002F PARTIAL \u002F FAIL \u002F NOT OBSERVED] | [observed evidence] | [limitation or none] |\n\n### Visual Findings\n- Character and sprite: [observed result or not applicable]\n- Animation and motion: [observed coherent action, pose\u002Fcontact findings, or not observed]\n- Environment and style: [observed result against approved direction]\n- Interaction and game feel: [observed result or not observed]\n\n## OVERALL: [PASS \u002F PARTIAL \u002F FAIL]\n**Reason**: [claims that passed, failed, or remain unproven, with coverage limits]\n```\n\n## Critical Rules\n\n1. Inspect every required frame and report the coverage manifest and any gaps.\n   Use Visual Verification for available inspection tools and their limits;\n   never waive required coverage because sampling is convenient.\n2. Use an image-capable route to assess visual claims; numerical pixel or color\n   analysis cannot stand in for seeing the frames.\n3. Report mechanical media facts separately from visual findings and product\n   acceptance.\n4. Camera pans, colored noise, or changed pixels do not prove a coherent walk\n   cycle. Assess the actual poses and intended action.\n5. Judge the actual palette and poses against the approved direction; do not\n   fail a clip merely for lacking warm colors or having limited colors.\n6. Disclose incomplete visual coverage and leave affected required claims\n   PARTIAL or NOT OBSERVED; do not imply full coverage or approval.\n","# Game Evidence Reviewer Skill\n\nReview game\u002Fdemo video evidence against the approved visual direction and the\nclaims the evidence is meant to establish. Ragnarok Online is a quality\nreference; it does not define automatic thresholds or approval.\n\n## References\n\n- [[Ragnarok Quality Game Demo Criteria|sources\u002Fragnarok-quality-game-demo-criteria]]\n- [Visual Verification](..\u002Fvisual-verification\u002FSKILL.md) owns the currently\n  available visual-inspection tools and their limitations. This guide owns the\n  game-media identity and frame-coverage protocol below.\n- [Design Fidelity Diff](~\u002F.claude\u002Fskills\u002Fdesign-fidelity-diff\u002FSKILL.md) owns\n  comparison against an approved design artifact.\n- Scratch allocation follows\n  [Scratch Space](~\u002F.claude\u002Fskills\u002Fscratch-space\u002FSKILL.md).\n\n## Activation\n\n```text\n\u002Fgame-er [evidence_path]\n```\n\nOr invoke when validating game demo evidence.\n\n## Review Procedure\n\n1. Identify the approved visual direction or acceptance criteria and the\n   specific claims this media is expected to support. If none is supplied,\n   describe observations without inventing product requirements and leave\n   product acceptance unproven (**PARTIAL**).\n2. Record the media identity and mechanical properties: source SHA-256,\n   duration, decoded frame count, frame rate, dimensions, codec, and\n   decode\u002Fintegrity result. Keep temporary outputs in Scratch.\n3. Inspect every decoded frame in chronological order, maintain a coverage\n   manifest, and disclose any gaps or limitations. Use Visual Verification to\n   select a currently available inspection tool and report its limitations.\n   Do not use a sample, contact sheet, frame count, or pixel-difference score as\n   a substitute for required visual inspection.\n4. Assess the visible result against the approved direction. Describe what the\n   character and environment actually do and look like. For animation, assess\n   whether observed poses form the intended coherent action (such as a walk\n   cycle), including contact and recovery poses when relevant. Pixel changes or\n   camera movement alone do not establish coherent animation.\n5. Report product acceptance separately from evidence\u002Fruntime facts. A\n   decodable video, motion, dimensions, frame rate, or codec does not establish\n   visual quality or product acceptance. Where an approved mock exists, use\n   Design Fidelity Diff for the artifact-to-artifact comparison.\n\n## Assessment Areas\n\nAssess only claims relevant to the approved direction and captured behavior:\n\n- **Character and sprite:** readability, pose, silhouette, detail, and fit with\n  the approved style.\n- **Animation and motion:** whether the visible sequence communicates the\n  intended coherent action; note pose, contact, timing, and continuity issues\n  that are actually observable. Distinguish character motion from camera or\n  scene movement.\n- **Environment:** composition, tile or edge continuity, palette, and relation\n  to the approved scene direction. A cool, limited, grayscale, or otherwise\n  non-warm palette is not a defect by itself.\n- **Interaction and game feel:** visible response, collision, or control claims\n  only when the recording contains enough evidence to assess them. Do not infer\n  responsive controls or wall blocking from movement alone.\n\nUse observed evidence and the approved criteria to explain each assessment.\nDo not assign a quality verdict from color counts, pixel counts, image\ndifferences, or other numerical proxies. Mechanical media properties may be\nreported as facts, but they do not decide visual quality.\n\n## Verdicts\n\nAssess each required claim as **PASS**, **PARTIAL**, **FAIL**, or\n**NOT OBSERVED**, with a concise reason tied to inspected frames and timestamps.\n\n- **PASS** means the required claim is visibly supported against the approved\n  direction across the inspected coverage.\n- **PARTIAL** means some evidence supports the claim, but a material limitation\n  or incomplete coverage prevents a full conclusion.\n- **FAIL** means inspected evidence contradicts a required claim or shows a\n  concrete defect against the approved direction.\n- **NOT OBSERVED** means the recording does not show enough evidence to assess\n  the claim.\n\nThe overall result is **PASS** only when all required visual claims pass over\nthe required coverage. Use **PARTIAL** when required claims remain unproven,\ncoverage is incomplete, or a material limitation remains. Use **FAIL** when a\nrequired claim fails. If no approved criteria or required claim list was\nsupplied, report observations but leave product acceptance **PARTIAL**; an\nempty claim list is not approval. Never convert missing evidence into\napproval. A passing media-integrity check is not product acceptance.\n\n## Output Format\n\n```markdown\n## Game Evidence Review\n\n**File**: [path]\n**Media SHA-256**: [hash]\n**Duration**: [value] | **Dimensions**: [width x height] | **Frame rate**: [value] | **Codec**: [value]\n**Decoded frames**: [count] | **Integrity**: [result]\n**Visual coverage**: [all-frame coverage manifest\u002Franges and any gaps]\n**Approved direction \u002F criteria**: [reference, or not supplied]\n\n### Required Claims\n| Claim | Verdict | Visual evidence (frame\u002Ftime) | Limitation |\n|---|---|---|---|\n| [claim] | [PASS \u002F PARTIAL \u002F FAIL \u002F NOT OBSERVED] | [observed evidence] | [limitation or none] |\n\n### Visual Findings\n- Character and sprite: [observed result or not applicable]\n- Animation and motion: [observed coherent action, pose\u002Fcontact findings, or not observed]\n- Environment and style: [observed result against approved direction]\n- Interaction and game feel: [observed result or not observed]\n\n## OVERALL: [PASS \u002F PARTIAL \u002F FAIL]\n**Reason**: [claims that passed, failed, or remain unproven, with coverage limits]\n```\n\n## Critical Rules\n\n1. Inspect every required frame and report the coverage manifest and any gaps.\n   Use Visual Verification for available inspection tools and their limits;\n   never waive required coverage because sampling is convenient.\n2. Use an image-capable route to assess visual claims; numerical pixel or color\n   analysis cannot stand in for seeing the frames.\n3. Report mechanical media facts separately from visual findings and product\n   acceptance.\n4. Camera pans, colored noise, or changed pixels do not prove a coherent walk\n   cycle. Assess the actual poses and intended action.\n5. Judge the actual palette and poses against the approved direction; do not\n   fail a clip merely for lacking warm colors or having limited colors.\n6. Disclose incomplete visual coverage and leave affected required claims\n   PARTIAL or NOT OBSERVED; do not imply full coverage or approval.\n",{"name":5,"description":7},"main","8144f00ebafc4306264c63239e4b9fa42e48a90e",".claude\u002Fskills\u002Fgame-evidence-reviewer",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-11 22:19:36",{"source":8,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill game-evidence-reviewer",{"tool":46,"command":47},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill game-evidence-reviewer",{"tool":49,"command":50},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill game-evidence-reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgame-evidence-reviewer\u002FSKILL.md",true,[],[55,73,95,109,123,139],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":28},"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",[],[57,62,63,64,65,66,67,68,69,70,71,72],"user","when","replies","check","use","identity","whatsapp","gmail","read","message","ask",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":28},"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",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[75,85,86,87,88,89,90,91,92,93,94],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":28},"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",[101],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[89,85,103,104,62,105,92,106,88,107,108,93,94],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":28},"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",[],[111,116,117,118,88,119,91,120,121,122],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"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":28},"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",[],[130,131,132,66,133,88,134,135,136,137,138],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":143,"licenseFileUrl":144,"sourceHtmlUrl":145,"categories":146,"keywords":158,"publishedAt":28},"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",[147,152,155],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":153,"categoryName":154,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":156,"categoryName":157,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000032","设计师",[159,160,161,66,162,163,164,62,165,166,167,168,169,170,171,172,173,174,26,175,176,177,178,179,180,181,63,182],"frontend","design","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","web","css","create","examples","with","react components","web ui","pages"]