[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EVBHZ9X3DCBKCS4ZJ96Z95":3,"skill-same:01M7EVBHZ9X3DCBKCS4ZJ96Z95":52},{"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":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":13,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":37,"install":38,"resources":51},"01M7EVBHZ9X3DCBKCS4ZJ96Z95","ulw-qa",null,"[omh] Hostile scenario testing: adversarial QA and fix loops. Use when the user says: ultraqa, adversarial qa, hostile scenarios, e2e qa, real-world qa, qa scenario, release qa, 敵対的QA.","mhyahya854\u002FAI-Second-Brain_Universal-Rules","mhyahya854","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F194078115?v=4","01M7EGSP2M9T858SDHJMXQ257Y","01M7EGSP3N6HN6879SVDPMD4DZ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Frlaope\u002Foh-my-hermes\u002Fulw-qa\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: \"ulw-qa\"\ndescription: \"[omh] Hostile scenario testing: adversarial QA and fix loops. Use when the user says: ultraqa, adversarial qa, hostile scenarios, e2e qa, real-world qa, qa scenario, release qa, 敵対的QA.\"\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [workflow, oh-my-hermes, verification]\n    category: verification\n    phase: qa\n    role: reviewer\n    quality_tier: scenario-gated\n---\n\n# Ultraqa\n\nThis is an OMH `ultraqa` workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).\n\n## Why This Exists\n\n`ultraqa` exists because behavior that passes its own tests can still fail under inputs and conditions nobody wrote down: it turns the changed behavior and known risks into hostile scenarios, records each one's observed pass or fail apart from any proposed fix, and hands fixes to the selected coding executor.\n\n## Do Not Use When\n\n- Judging whether a rendered page, image, or terminal frame looks right across viewports and states; use `omh-visual-qa`.\n- Confirming that a finished change meets its acceptance criteria with the smallest proving check, when no hostile scenarios are wanted; use `omh-verification-gate`.\n\n## Examples\n\nGood example:\n\n- Prompt: $ultraqa test the setup wizard with hostile install paths, stale config, and missing PATH cases.\n- Expected behavior: Generate adversarial QA scenarios, expected signals, observed results, and fix-or-retry routing.\n- Why: The request asks for verification pressure and hostile scenarios.\n\nBad example:\n\n- Prompt: ultraqa: treat casual chat or unaccepted work as if this workflow already produced verified results.\n- Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing `ultraqa`.\n- Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.\n\n## Completion Checklist\n\n- The scenario, expected behavior, observed result, and pass\u002Ffail basis are named.\n- Proposed fixes are separated from observed QA evidence.\n- Missing or failed verification routes back to plan, fix, or a narrower test.\n\n## Recovery Notes\n\n- If the expected behavior is unclear, route back to plan before running adversarial checks.\n- If verification fails, return to fix or research with the failed signal instead of advancing.\n\n\n\n## When to Use\n\nUse when the task needs adversarial test scenarios, verification, and fix loops.\n\n    Strong routing signals: `ultraqa`, `$ultraqa`, `adversarial qa`, `hostile scenarios`, `e2e qa`, `real-world qa`, `qa scenario`, `release qa`, `敵対的QA`, `リリース前QA`, `障害シナリオ`, `장애 상황`, `쿠버네티스 장애`, `적절히 진단`, `검증 체크리스트`, `릴리즈 전 gate`, `злые сценарии`, `прогони e2e`, `e2e сценарий`, `e2e тест`, `адверсариальное тестирование`, `对抗式测试`, `发布前测试`, `故障场景`, `uji skenario ekstrem`, `lakukan QA adversarial`, `uji skenario kegagalan sebelum rilis`, `bantu cari celah lewat pengujian end to end`, `uji aplikasi dengan kondisi pengguna nyata`, `jalankan siklus pengujian dan perbaikan berulang`, `kiểm thử các tình huống cực đoan`, `tiến hành QA phản biện`, `kiểm thử các tình huống thất bại trước khi phát hành`, `giúp tìm lỗ hổng qua kiểm thử end to end`, `kiểm thử ứng dụng với điều kiện người dùng thực tế`, `chạy các chu kỳ kiểm thử và sửa lỗi lặp lại`\n\n## Catalog Metadata\n\nCategory: `verification`\nPhase: `qa`\nQuality tier: `scenario-gated`\nReasoning demand: `standard`\n\nQuality bar:\n\n- Do not start this engine as an automatic continuation of another skill's output: an accepted plan, a clarified brief, or a routing recommendation is planning evidence, not permission. Unless the user explicitly invoked this engine themselves, restate in one line what will start (engine, scope, selected executor) and wait for the user's explicit go-ahead first.\n- A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when the interjection changes scope, say so and update the declared plan or todo instead of silently abandoning it. A mid-run message is the latest steering for the active task, not automatically a replacement objective: it replaces the objective when the user says so and steers the current one otherwise.\n- A follow-up that needs new authority, materially expands the scope, or changes external state not already authorized is described first and started only on the user's approval; persistence never broadens the authorized scope. A refused escalation gets a safer alternative inside the boundary, or the authorization the boundary asks for — never a workaround or an indirect execution.\n- The closing brief scales to the change: one or two sentences for a simple change. Lead with the result and validation; omit abandoned approaches unless they explain a tradeoff, and internal bookkeeping. Disclose requested-but-not-done work and material prepared\u002Funmerged work; omit unrelated non-action footers. Required accounting stays outside this scaling. Order: result -> relevant evidence\u002Flimits -> observed accounting (when required) -> specific question (if useful). For a real unresolved user decision or a useful briefing discussion, offer one specific, content-linked question. Completed work needs no question; discussion grants no authority. Never estimate usage.\n- Generate hostile scenarios from changed behavior and known risk areas.\n- Report pass\u002Ffail evidence separately from proposed fixes.\n- Delegate code mutations discovered by QA to the selected coding executor.\n- Read actual host\u002Fexecutor evidence before claiming build, verification, review, documentation, or PR-preparation results.\n- On a web app, run hostile scenarios against the target the user named (local or staging unless stated); a scenario that would submit, buy, send, or delete on a live surface waits for the user's approval.\n- Read the browser console after every navigation and interaction, and keep a failing scenario's screenshot and console errors as its observed evidence.\n\nRequired inputs:\n\n- changed behavior\n- acceptance criteria\n- known risk areas\n\nExpected outputs:\n\n- adversarial scenarios\n- pass\u002Ffail evidence\n- fix recommendations\n\nArtifact expectations:\n\n- QA scenario evidence\n- runtime verification summary\n\nSafety rules:\n\n- Do not imply hidden Hermes runtime behavior.\n- Use the smallest verification that can prove the claim.\n\n## Runtime Evidence\n\nUse the current host's own tools and subagent\u002Ftask mechanism when available;\notherwise run the same lanes sequentially or name the unavailable capability.\nA prepared plan, handoff, checklist, or skill installation is not execution,\nreview, CI, merge-readiness, or merge evidence. Record actual tool results, or\n`not_observed` \u002F `not_available`, in the record; never invent dispatch or host\naccounting.\nTreat supplied context as advisory, not proof of hidden memory reads or writes.\nState scope, constraints, verification, and the stop condition before work.\nReply in the user's own words and the host's own voice: the host's persona owns\nreply language, tone, speech level, and sentence endings, progress updates\nincluded (where it sets no language, use the one the user wrote in), and OMH\nshapes structure and content only; OMH's record terms\n(surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in\nrecords and tool calls, never in the sentence the user reads unless they ask\nabout one; and when a real unresolved user decision or a useful briefing discussion\nremains, offer one specific, content-linked question. Completed work needs no question;\nomit unrelated non-action footers and generic offers to continue.\nSupporting paths are relative to this skill directory; sibling skill paths are\nrelative to its parent. Resolve them from the host-provided skill base directory\n(`{baseDir}` on hosts that provide it), never a hardcoded install location.\nA named workflow not installed here is unavailable, not permission to emulate\nits host-specific capabilities. Verify through the real surface before done.\n","# Ultraqa\n\nThis is an OMH `ultraqa` workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).\n\n## Why This Exists\n\n`ultraqa` exists because behavior that passes its own tests can still fail under inputs and conditions nobody wrote down: it turns the changed behavior and known risks into hostile scenarios, records each one's observed pass or fail apart from any proposed fix, and hands fixes to the selected coding executor.\n\n## Do Not Use When\n\n- Judging whether a rendered page, image, or terminal frame looks right across viewports and states; use `omh-visual-qa`.\n- Confirming that a finished change meets its acceptance criteria with the smallest proving check, when no hostile scenarios are wanted; use `omh-verification-gate`.\n\n## Examples\n\nGood example:\n\n- Prompt: $ultraqa test the setup wizard with hostile install paths, stale config, and missing PATH cases.\n- Expected behavior: Generate adversarial QA scenarios, expected signals, observed results, and fix-or-retry routing.\n- Why: The request asks for verification pressure and hostile scenarios.\n\nBad example:\n\n- Prompt: ultraqa: treat casual chat or unaccepted work as if this workflow already produced verified results.\n- Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing `ultraqa`.\n- Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.\n\n## Completion Checklist\n\n- The scenario, expected behavior, observed result, and pass\u002Ffail basis are named.\n- Proposed fixes are separated from observed QA evidence.\n- Missing or failed verification routes back to plan, fix, or a narrower test.\n\n## Recovery Notes\n\n- If the expected behavior is unclear, route back to plan before running adversarial checks.\n- If verification fails, return to fix or research with the failed signal instead of advancing.\n\n\n\n## When to Use\n\nUse when the task needs adversarial test scenarios, verification, and fix loops.\n\n    Strong routing signals: `ultraqa`, `$ultraqa`, `adversarial qa`, `hostile scenarios`, `e2e qa`, `real-world qa`, `qa scenario`, `release qa`, `敵対的QA`, `リリース前QA`, `障害シナリオ`, `장애 상황`, `쿠버네티스 장애`, `적절히 진단`, `검증 체크리스트`, `릴리즈 전 gate`, `злые сценарии`, `прогони e2e`, `e2e сценарий`, `e2e тест`, `адверсариальное тестирование`, `对抗式测试`, `发布前测试`, `故障场景`, `uji skenario ekstrem`, `lakukan QA adversarial`, `uji skenario kegagalan sebelum rilis`, `bantu cari celah lewat pengujian end to end`, `uji aplikasi dengan kondisi pengguna nyata`, `jalankan siklus pengujian dan perbaikan berulang`, `kiểm thử các tình huống cực đoan`, `tiến hành QA phản biện`, `kiểm thử các tình huống thất bại trước khi phát hành`, `giúp tìm lỗ hổng qua kiểm thử end to end`, `kiểm thử ứng dụng với điều kiện người dùng thực tế`, `chạy các chu kỳ kiểm thử và sửa lỗi lặp lại`\n\n## Catalog Metadata\n\nCategory: `verification`\nPhase: `qa`\nQuality tier: `scenario-gated`\nReasoning demand: `standard`\n\nQuality bar:\n\n- Do not start this engine as an automatic continuation of another skill's output: an accepted plan, a clarified brief, or a routing recommendation is planning evidence, not permission. Unless the user explicitly invoked this engine themselves, restate in one line what will start (engine, scope, selected executor) and wait for the user's explicit go-ahead first.\n- A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when the interjection changes scope, say so and update the declared plan or todo instead of silently abandoning it. A mid-run message is the latest steering for the active task, not automatically a replacement objective: it replaces the objective when the user says so and steers the current one otherwise.\n- A follow-up that needs new authority, materially expands the scope, or changes external state not already authorized is described first and started only on the user's approval; persistence never broadens the authorized scope. A refused escalation gets a safer alternative inside the boundary, or the authorization the boundary asks for — never a workaround or an indirect execution.\n- The closing brief scales to the change: one or two sentences for a simple change. Lead with the result and validation; omit abandoned approaches unless they explain a tradeoff, and internal bookkeeping. Disclose requested-but-not-done work and material prepared\u002Funmerged work; omit unrelated non-action footers. Required accounting stays outside this scaling. Order: result -> relevant evidence\u002Flimits -> observed accounting (when required) -> specific question (if useful). For a real unresolved user decision or a useful briefing discussion, offer one specific, content-linked question. Completed work needs no question; discussion grants no authority. Never estimate usage.\n- Generate hostile scenarios from changed behavior and known risk areas.\n- Report pass\u002Ffail evidence separately from proposed fixes.\n- Delegate code mutations discovered by QA to the selected coding executor.\n- Read actual host\u002Fexecutor evidence before claiming build, verification, review, documentation, or PR-preparation results.\n- On a web app, run hostile scenarios against the target the user named (local or staging unless stated); a scenario that would submit, buy, send, or delete on a live surface waits for the user's approval.\n- Read the browser console after every navigation and interaction, and keep a failing scenario's screenshot and console errors as its observed evidence.\n\nRequired inputs:\n\n- changed behavior\n- acceptance criteria\n- known risk areas\n\nExpected outputs:\n\n- adversarial scenarios\n- pass\u002Ffail evidence\n- fix recommendations\n\nArtifact expectations:\n\n- QA scenario evidence\n- runtime verification summary\n\nSafety rules:\n\n- Do not imply hidden Hermes runtime behavior.\n- Use the smallest verification that can prove the claim.\n\n## Runtime Evidence\n\nUse the current host's own tools and subagent\u002Ftask mechanism when available;\notherwise run the same lanes sequentially or name the unavailable capability.\nA prepared plan, handoff, checklist, or skill installation is not execution,\nreview, CI, merge-readiness, or merge evidence. Record actual tool results, or\n`not_observed` \u002F `not_available`, in the record; never invent dispatch or host\naccounting.\nTreat supplied context as advisory, not proof of hidden memory reads or writes.\nState scope, constraints, verification, and the stop condition before work.\nReply in the user's own words and the host's own voice: the host's persona owns\nreply language, tone, speech level, and sentence endings, progress updates\nincluded (where it sets no language, use the one the user wrote in), and OMH\nshapes structure and content only; OMH's record terms\n(surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in\nrecords and tool calls, never in the sentence the user reads unless they ask\nabout one; and when a real unresolved user decision or a useful briefing discussion\nremains, offer one specific, content-linked question. Completed work needs no question;\nomit unrelated non-action footers and generic offers to continue.\nSupporting paths are relative to this skill directory; sibling skill paths are\nrelative to its parent. Resolve them from the host-provided skill base directory\n(`{baseDir}` on hosts that provide it), never a hardcoded install location.\nA named workflow not installed here is unavailable, not permission to emulate\nits host-specific capabilities. Verify through the real surface before done.\n",{"name":5,"license":14,"metadata":23,"description":7},{"hermes":24},{"role":25,"tags":26,"phase":30,"category":29,"quality_tier":31},"reviewer",[27,28,29],"workflow","oh-my-hermes","verification","qa","scenario-gated","main","4c174e06a831864e98c30f630a7aa6c04738b094","skills\u002F_intake\u002Fgithub\u002Frlaope\u002Foh-my-hermes\u002Fulw-qa","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules","https:\u002F\u002Fgithub.com\u002Fmhyahya854","2026-11-06 02:03:37",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add mhyahya854\u002FAI-Second-Brain_Universal-Rules --skill ulw-qa",{"tool":44,"command":45},"bunx","bunx skills add mhyahya854\u002FAI-Second-Brain_Universal-Rules --skill ulw-qa",{"tool":47,"command":48},"pnpm","pnpm dlx skills add mhyahya854\u002FAI-Second-Brain_Universal-Rules --skill ulw-qa","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Frlaope\u002Foh-my-hermes\u002Fulw-qa\u002FSKILL.md",true,[],[53,61,69,77,84,91],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":57,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":18},"01M7EX4T721AAH60R0239P8WBZ","frontend-slides","Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT\u002FPPTX to web, or create slides for a talk\u002Fpitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fzarazhangrui\u002Ffrontend-slides\u002Ffrontend-slides\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fzarazhangrui\u002Ffrontend-slides\u002Ffrontend-slides\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":65,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":18},"01M7EX495RSHTTCEJVX7C83FA3","design-dna","Extract, define, and apply design DNA across three dimensions: design system (tokens), design style (qualitative feel), and visual effects (Canvas, WebGL, 3D, particles, shaders, scroll effects, etc.). Use this skill when: (1) a user wants to see the full 3-dimension design structure\u002Fschema, (2) a user provides images, screenshots, or URLs of reference designs and wants them analyzed into a structured JSON profile covering all three dimensions, (3) a user has a Design DNA JSON and content and wants a design generated from it, or (4) any combination of these phases. Triggers on \"design DNA\", \"extract design style\", \"analyze design\", \"design tokens from reference\", \"generate design from JSON\", \"design system from screenshot\", \"design profile\", \"style guide JSON\", \"visual effects analysis\", \"design with effects\", \"3d design analysis\".","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fzanwei\u002Fdesign-dna\u002Fdesign-dna\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fzanwei\u002Fdesign-dna\u002Fdesign-dna\u002FSKILL.md",[],[],{"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":73,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":18},"01M7EX45RF2XZKRC3KDJDTT1PH","wireframe","Generate JSON wireframe with HTML preview","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fyhassy\u002Fwireframe-skill\u002Fwireframe-skill\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fyhassy\u002Fwireframe-skill\u002Fwireframe-skill\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":18},"01M7EWZEM3MHD48AYSYFR2C9JP","social-publishing","Schedule and publish social media posts across 13 platforms (X, LinkedIn, Instagram, Facebook Pages, TikTok, Discord, Telegram, YouTube, Reddit, WordPress, Pinterest) via the SocialClaw API. Use when the user wants to publish, schedule, or manage social media content programmatically. Requires SOCIALCLAW_API_KEY.","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fwshobson\u002Fagents\u002Fsocial-publishing\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":18},"01M7EWKDEK9840C728VXT78EQ9","hermes-tweet","Install and operate Hermes Tweet, a Hermes Agent plugin for X\u002FTwitter research, timeline reading, tweet analysis, and approval-gated private or state-changing operations. Use this skill when installing Hermes Tweet, researching X\u002FTwitter accounts, monitoring launch signals, investigating mentions, auditing giveaways, or preparing gated X operations. Use proactively when a Hermes Agent workflow needs current X\u002FTwitter context. Requires XQUIK_API_KEY for read and action tools.","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fwshobson\u002Fagents\u002Fhermes-tweet\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":18},"01M7EWASXP3NZWW95CJPT2CRWN","refactoring-ui","Audit and fix visual hierarchy, spacing, color, and depth in web UIs. Use when the user mentions \"my UI looks off\" (or amateur\u002Funprofessional), \"fix the design\", \"Tailwind styling\", \"color palette\", \"visual hierarchy\", \"design system\", \"spacing scale\", or \"component styling\". Also trigger when building consistent design tokens, creating dark mode themes, improving data-visualization clarity, or polishing UI details before launch. Covers grayscale-first workflow, constrained design scales, shadows, and component styling. For typeface selection, see web-typography. For usability audits, see ux-heuristics.","https:\u002F\u002Fgithub.com\u002Fmhyahya854\u002FAI-Second-Brain_Universal-Rules\u002Fblob\u002Fmain\u002Fskills\u002F_intake\u002Fgithub\u002Fwondelai\u002Fskills\u002Frefactoring-ui\u002FSKILL.md",[],[]]