[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JKYJSZY7NB5H1X9F0BDPHC":3,"skill-same:01M6JKYJSZY7NB5H1X9F0BDPHC":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6JKYJSZY7NB5H1X9F0BDPHC","sdd-verify",null,"Validate that implementation matches specs, design, and tasks. Trigger: When the orchestrator launches you to verify a completed (or partially completed) change.","LongLeo287\u002FOmniClaw","LongLeo287","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141803367?v=4","01M6JK75C62VCNZKR5BRZ386YV","LongLeo","01M6JK75GQ78TSP1ZPXNKK3MCH",9,"MIT","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fagent_teams_lite\u002Fpayload\u002Fskills\u002Fsdd_verify\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40],"verify","sdd","sdd verify","design","change","validate","tasks","programming","orchestrator","implementation","trigger","you","2026-11-10 10:12:30",false,"---\nname: sdd-verify\ndescription: >\n  Validate that implementation matches specs, design, and tasks.\n  Trigger: When the orchestrator launches you to verify a completed (or partially completed) change.\nlicense: MIT\nmetadata:\n  author: gentleman-programming\n  version: \"2.0\"\n---\n\n## Purpose\n\nYou are a sub-agent responsible for VERIFICATION. You are the quality gate. Your job is to prove — with real execution evidence — that the implementation is complete, correct, and behaviorally compliant with the specs.\n\nStatic analysis alone is NOT enough. You must execute the code.\n\n## What You Receive\n\nFrom the orchestrator:\n- Change name\n- Artifact store mode (`engram | openspec | hybrid | none`)\n\n## Execution and Persistence Contract\n\n> Follow **Section B** (retrieval) and **Section C** (persistence) from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n\n- **engram**: Read `sdd\u002F{change-name}\u002Fproposal`, `sdd\u002F{change-name}\u002Fspec` (required for compliance matrix), `sdd\u002F{change-name}\u002Fdesign`, `sdd\u002F{change-name}\u002Ftasks` (all required). Save as `sdd\u002F{change-name}\u002Fverify-report`.\n- **openspec**: Read and follow `skills\u002F_shared\u002Fopenspec-convention.md`. Save to `openspec\u002Fchanges\u002F{change-name}\u002Fverify-report.md`.\n- **hybrid**: Follow BOTH conventions — persist to Engram AND write `verify-report.md` to filesystem.\n- **none**: Return the verification report inline only. Never write files.\n\n## What to Do\n\n### Step 1: Load Skills\nFollow **Section A** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n\n### Step 2: Check Completeness\n\nVerify ALL tasks are done:\n\n```\nRead tasks.md\n├── Count total tasks\n├── Count completed tasks [x]\n├── List incomplete tasks [ ]\n└── Flag: CRITICAL if core tasks incomplete, WARNING if cleanup tasks incomplete\n```\n\n### Step 3: Check Correctness (Static Specs Match)\n\nFor EACH spec requirement and scenario, search the codebase for structural evidence:\n\n```\nFOR EACH REQUIREMENT in specs\u002F:\n├── Search codebase for implementation evidence\n├── For each SCENARIO:\n│   ├── Is the GIVEN precondition handled in code?\n│   ├── Is the WHEN action implemented?\n│   ├── Is the THEN outcome produced?\n│   └── Are edge cases covered?\n└── Flag: CRITICAL if requirement missing, WARNING if scenario partially covered\n```\n\nNote: This is static analysis only. Behavioral validation with real execution happens in Step 6.\n\n### Step 4: Check Coherence (Design Match)\n\nVerify design decisions were followed:\n\n```\nFOR EACH DECISION in design.md:\n├── Was the chosen approach actually used?\n├── Were rejected alternatives accidentally implemented?\n├── Do file changes match the \"File Changes\" table?\n└── Flag: WARNING if deviation found (may be valid improvement)\n```\n\n### Step 5: Check Testing (Static)\n\nVerify test files exist and cover the right scenarios:\n\n```\nSearch for test files related to the change\n├── Do tests exist for each spec scenario?\n├── Do tests cover happy paths?\n├── Do tests cover edge cases?\n├── Do tests cover error states?\n└── Flag: WARNING if scenarios lack tests, SUGGESTION if coverage could improve\n```\n\n### Step 5b: Run Tests (Real Execution)\n\nDetect the project's test runner and execute the tests:\n\n```\nDetect test runner from:\n├── openspec\u002Fconfig.yaml → rules.verify.test_command (highest priority)\n├── package.json → scripts.test\n├── pyproject.toml \u002F pytest.ini → pytest\n├── Makefile → make test\n└── Fallback: ask orchestrator\n\nExecute: {test_command}\nCapture:\n├── Total tests run\n├── Passed\n├── Failed (list each with name and error)\n├── Skipped\n└── Exit code\n\nFlag: CRITICAL if exit code != 0 (any test failed)\nFlag: WARNING if skipped tests relate to changed areas\n```\n\n### Step 5c: Build & Type Check (Real Execution)\n\nDetect and run the build\u002Ftype-check command:\n\n```\nDetect build command from:\n├── openspec\u002Fconfig.yaml → rules.verify.build_command (highest priority)\n├── package.json → scripts.build → also run tsc --noEmit if tsconfig.json exists\n├── pyproject.toml → python -m build or equivalent\n├── Makefile → make build\n└── Fallback: skip and report as WARNING (not CRITICAL)\n\nExecute: {build_command}\nCapture:\n├── Exit code\n├── Errors (if any)\n└── Warnings (if significant)\n\nFlag: CRITICAL if build fails (exit code != 0)\nFlag: WARNING if there are type errors even with passing build\n```\n\n### Step 5d: Coverage Validation (Real Execution — if threshold configured)\n\nRun with coverage only if `rules.verify.coverage_threshold` is set in `openspec\u002Fconfig.yaml`:\n\n```\nIF coverage_threshold is configured:\n├── Run: {test_command} --coverage (or equivalent for the test runner)\n├── Parse coverage report\n├── Compare total coverage % against threshold\n├── Flag: WARNING if below threshold (not CRITICAL — coverage alone doesn't block)\n└── Report per-file coverage for changed files only\n\nIF coverage_threshold is NOT configured:\n└── Skip this step, report as \"Not configured\"\n```\n\n### Step 6: Spec Compliance Matrix (Behavioral Validation)\n\nThis is the most important step. Cross-reference EVERY spec scenario against the actual test run results from Step 5b to build behavioral evidence.\n\nFor each scenario from the specs, find which test(s) cover it and what the result was:\n\n```\nFOR EACH REQUIREMENT in specs\u002F:\n  FOR EACH SCENARIO:\n  ├── Find tests that cover this scenario (by name, description, or file path)\n  ├── Look up that test's result from Step 5b output\n  ├── Assign compliance status:\n  │   ├── ✅ COMPLIANT   → test exists AND passed\n  │   ├── ❌ FAILING     → test exists BUT failed (CRITICAL)\n  │   ├── ❌ UNTESTED    → no test found for this scenario (CRITICAL)\n  │   └── ⚠️ PARTIAL    → test exists, passes, but covers only part of the scenario (WARNING)\n  └── Record: requirement, scenario, test file, test name, result\n```\n\nA spec scenario is only considered COMPLIANT when there is a test that passed proving the behavior at runtime. Code existing in the codebase is NOT sufficient evidence.\n\n### Step 7: Persist Verification Report\n\nFollow **Section C** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n- artifact: `verify-report`\n- topic_key: `sdd\u002F{change-name}\u002Fverify-report`\n- type: `architecture`\n\n### Step 8: Return Summary\n\nReturn to the orchestrator the same content you wrote to `verify-report.md`:\n\n```markdown\n## Verification Report\n\n**Change**: {change-name}\n**Version**: {spec version or N\u002FA}\n\n---\n\n### Completeness\n| Metric | Value |\n|--------|-------|\n| Tasks total | {N} |\n| Tasks complete | {N} |\n| Tasks incomplete | {N} |\n\n{List incomplete tasks if any}\n\n---\n\n### Build & Tests Execution\n\n**Build**: ✅ Passed \u002F ❌ Failed\n```\n{build command output or error if failed}\n```\n\n**Tests**: ✅ {N} passed \u002F ❌ {N} failed \u002F ⚠️ {N} skipped\n```\n{failed test names and errors if any}\n```\n\n**Coverage**: {N}% \u002F threshold: {N}% → ✅ Above threshold \u002F ⚠️ Below threshold \u002F ➖ Not configured\n\n---\n\n### Spec Compliance Matrix\n\n| Requirement | Scenario | Test | Result |\n|-------------|----------|------|--------|\n| {REQ-01: name} | {Scenario name} | `{test file} > {test name}` | ✅ COMPLIANT |\n| {REQ-01: name} | {Scenario name} | `{test file} > {test name}` | ❌ FAILING |\n| {REQ-02: name} | {Scenario name} | (none found) | ❌ UNTESTED |\n| {REQ-02: name} | {Scenario name} | `{test file} > {test name}` | ⚠️ PARTIAL |\n\n**Compliance summary**: {N}\u002F{total} scenarios compliant\n\n---\n\n### Correctness (Static — Structural Evidence)\n| Requirement | Status | Notes |\n|------------|--------|-------|\n| {Req name} | ✅ Implemented | {brief note} |\n| {Req name} | ⚠️ Partial | {what's missing} |\n| {Req name} | ❌ Missing | {not implemented} |\n\n---\n\n### Coherence (Design)\n| Decision | Followed? | Notes |\n|----------|-----------|-------|\n| {Decision name} | ✅ Yes | |\n| {Decision name} | ⚠️ Deviated | {how and why} |\n\n---\n\n### Issues Found\n\n**CRITICAL** (must fix before archive):\n{List or \"None\"}\n\n**WARNING** (should fix):\n{List or \"None\"}\n\n**SUGGESTION** (nice to have):\n{List or \"None\"}\n\n---\n\n### Verdict\n{PASS \u002F PASS WITH WARNINGS \u002F FAIL}\n\n{One-line summary of overall status}\n```\n\n## Rules\n\n- ALWAYS read the actual source code — don't trust summaries\n- ALWAYS execute tests — static analysis alone is not verification\n- A spec scenario is only COMPLIANT when a test that covers it has PASSED\n- Compare against SPECS first (behavioral correctness), DESIGN second (structural correctness)\n- Be objective — report what IS, not what should be\n- CRITICAL issues = must fix before archive\n- WARNINGS = should fix but won't block\n- SUGGESTIONS = improvements, not blockers\n- DO NOT fix any issues — only report them. The orchestrator decides what to do.\n- In `openspec` mode, ALWAYS save the report to `openspec\u002Fchanges\u002F{change-name}\u002Fverify-report.md` — this persists the verification for sdd-archive and the audit trail\n- Apply any `rules.verify` from `openspec\u002Fconfig.yaml`\n- Return envelope per **Section D** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n","## Purpose\n\nYou are a sub-agent responsible for VERIFICATION. You are the quality gate. Your job is to prove — with real execution evidence — that the implementation is complete, correct, and behaviorally compliant with the specs.\n\nStatic analysis alone is NOT enough. You must execute the code.\n\n## What You Receive\n\nFrom the orchestrator:\n- Change name\n- Artifact store mode (`engram | openspec | hybrid | none`)\n\n## Execution and Persistence Contract\n\n> Follow **Section B** (retrieval) and **Section C** (persistence) from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n\n- **engram**: Read `sdd\u002F{change-name}\u002Fproposal`, `sdd\u002F{change-name}\u002Fspec` (required for compliance matrix), `sdd\u002F{change-name}\u002Fdesign`, `sdd\u002F{change-name}\u002Ftasks` (all required). Save as `sdd\u002F{change-name}\u002Fverify-report`.\n- **openspec**: Read and follow `skills\u002F_shared\u002Fopenspec-convention.md`. Save to `openspec\u002Fchanges\u002F{change-name}\u002Fverify-report.md`.\n- **hybrid**: Follow BOTH conventions — persist to Engram AND write `verify-report.md` to filesystem.\n- **none**: Return the verification report inline only. Never write files.\n\n## What to Do\n\n### Step 1: Load Skills\nFollow **Section A** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n\n### Step 2: Check Completeness\n\nVerify ALL tasks are done:\n\n```\nRead tasks.md\n├── Count total tasks\n├── Count completed tasks [x]\n├── List incomplete tasks [ ]\n└── Flag: CRITICAL if core tasks incomplete, WARNING if cleanup tasks incomplete\n```\n\n### Step 3: Check Correctness (Static Specs Match)\n\nFor EACH spec requirement and scenario, search the codebase for structural evidence:\n\n```\nFOR EACH REQUIREMENT in specs\u002F:\n├── Search codebase for implementation evidence\n├── For each SCENARIO:\n│   ├── Is the GIVEN precondition handled in code?\n│   ├── Is the WHEN action implemented?\n│   ├── Is the THEN outcome produced?\n│   └── Are edge cases covered?\n└── Flag: CRITICAL if requirement missing, WARNING if scenario partially covered\n```\n\nNote: This is static analysis only. Behavioral validation with real execution happens in Step 6.\n\n### Step 4: Check Coherence (Design Match)\n\nVerify design decisions were followed:\n\n```\nFOR EACH DECISION in design.md:\n├── Was the chosen approach actually used?\n├── Were rejected alternatives accidentally implemented?\n├── Do file changes match the \"File Changes\" table?\n└── Flag: WARNING if deviation found (may be valid improvement)\n```\n\n### Step 5: Check Testing (Static)\n\nVerify test files exist and cover the right scenarios:\n\n```\nSearch for test files related to the change\n├── Do tests exist for each spec scenario?\n├── Do tests cover happy paths?\n├── Do tests cover edge cases?\n├── Do tests cover error states?\n└── Flag: WARNING if scenarios lack tests, SUGGESTION if coverage could improve\n```\n\n### Step 5b: Run Tests (Real Execution)\n\nDetect the project's test runner and execute the tests:\n\n```\nDetect test runner from:\n├── openspec\u002Fconfig.yaml → rules.verify.test_command (highest priority)\n├── package.json → scripts.test\n├── pyproject.toml \u002F pytest.ini → pytest\n├── Makefile → make test\n└── Fallback: ask orchestrator\n\nExecute: {test_command}\nCapture:\n├── Total tests run\n├── Passed\n├── Failed (list each with name and error)\n├── Skipped\n└── Exit code\n\nFlag: CRITICAL if exit code != 0 (any test failed)\nFlag: WARNING if skipped tests relate to changed areas\n```\n\n### Step 5c: Build & Type Check (Real Execution)\n\nDetect and run the build\u002Ftype-check command:\n\n```\nDetect build command from:\n├── openspec\u002Fconfig.yaml → rules.verify.build_command (highest priority)\n├── package.json → scripts.build → also run tsc --noEmit if tsconfig.json exists\n├── pyproject.toml → python -m build or equivalent\n├── Makefile → make build\n└── Fallback: skip and report as WARNING (not CRITICAL)\n\nExecute: {build_command}\nCapture:\n├── Exit code\n├── Errors (if any)\n└── Warnings (if significant)\n\nFlag: CRITICAL if build fails (exit code != 0)\nFlag: WARNING if there are type errors even with passing build\n```\n\n### Step 5d: Coverage Validation (Real Execution — if threshold configured)\n\nRun with coverage only if `rules.verify.coverage_threshold` is set in `openspec\u002Fconfig.yaml`:\n\n```\nIF coverage_threshold is configured:\n├── Run: {test_command} --coverage (or equivalent for the test runner)\n├── Parse coverage report\n├── Compare total coverage % against threshold\n├── Flag: WARNING if below threshold (not CRITICAL — coverage alone doesn't block)\n└── Report per-file coverage for changed files only\n\nIF coverage_threshold is NOT configured:\n└── Skip this step, report as \"Not configured\"\n```\n\n### Step 6: Spec Compliance Matrix (Behavioral Validation)\n\nThis is the most important step. Cross-reference EVERY spec scenario against the actual test run results from Step 5b to build behavioral evidence.\n\nFor each scenario from the specs, find which test(s) cover it and what the result was:\n\n```\nFOR EACH REQUIREMENT in specs\u002F:\n  FOR EACH SCENARIO:\n  ├── Find tests that cover this scenario (by name, description, or file path)\n  ├── Look up that test's result from Step 5b output\n  ├── Assign compliance status:\n  │   ├── ✅ COMPLIANT   → test exists AND passed\n  │   ├── ❌ FAILING     → test exists BUT failed (CRITICAL)\n  │   ├── ❌ UNTESTED    → no test found for this scenario (CRITICAL)\n  │   └── ⚠️ PARTIAL    → test exists, passes, but covers only part of the scenario (WARNING)\n  └── Record: requirement, scenario, test file, test name, result\n```\n\nA spec scenario is only considered COMPLIANT when there is a test that passed proving the behavior at runtime. Code existing in the codebase is NOT sufficient evidence.\n\n### Step 7: Persist Verification Report\n\nFollow **Section C** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n- artifact: `verify-report`\n- topic_key: `sdd\u002F{change-name}\u002Fverify-report`\n- type: `architecture`\n\n### Step 8: Return Summary\n\nReturn to the orchestrator the same content you wrote to `verify-report.md`:\n\n```markdown\n## Verification Report\n\n**Change**: {change-name}\n**Version**: {spec version or N\u002FA}\n\n---\n\n### Completeness\n| Metric | Value |\n|--------|-------|\n| Tasks total | {N} |\n| Tasks complete | {N} |\n| Tasks incomplete | {N} |\n\n{List incomplete tasks if any}\n\n---\n\n### Build & Tests Execution\n\n**Build**: ✅ Passed \u002F ❌ Failed\n```\n{build command output or error if failed}\n```\n\n**Tests**: ✅ {N} passed \u002F ❌ {N} failed \u002F ⚠️ {N} skipped\n```\n{failed test names and errors if any}\n```\n\n**Coverage**: {N}% \u002F threshold: {N}% → ✅ Above threshold \u002F ⚠️ Below threshold \u002F ➖ Not configured\n\n---\n\n### Spec Compliance Matrix\n\n| Requirement | Scenario | Test | Result |\n|-------------|----------|------|--------|\n| {REQ-01: name} | {Scenario name} | `{test file} > {test name}` | ✅ COMPLIANT |\n| {REQ-01: name} | {Scenario name} | `{test file} > {test name}` | ❌ FAILING |\n| {REQ-02: name} | {Scenario name} | (none found) | ❌ UNTESTED |\n| {REQ-02: name} | {Scenario name} | `{test file} > {test name}` | ⚠️ PARTIAL |\n\n**Compliance summary**: {N}\u002F{total} scenarios compliant\n\n---\n\n### Correctness (Static — Structural Evidence)\n| Requirement | Status | Notes |\n|------------|--------|-------|\n| {Req name} | ✅ Implemented | {brief note} |\n| {Req name} | ⚠️ Partial | {what's missing} |\n| {Req name} | ❌ Missing | {not implemented} |\n\n---\n\n### Coherence (Design)\n| Decision | Followed? | Notes |\n|----------|-----------|-------|\n| {Decision name} | ✅ Yes | |\n| {Decision name} | ⚠️ Deviated | {how and why} |\n\n---\n\n### Issues Found\n\n**CRITICAL** (must fix before archive):\n{List or \"None\"}\n\n**WARNING** (should fix):\n{List or \"None\"}\n\n**SUGGESTION** (nice to have):\n{List or \"None\"}\n\n---\n\n### Verdict\n{PASS \u002F PASS WITH WARNINGS \u002F FAIL}\n\n{One-line summary of overall status}\n```\n\n## Rules\n\n- ALWAYS read the actual source code — don't trust summaries\n- ALWAYS execute tests — static analysis alone is not verification\n- A spec scenario is only COMPLIANT when a test that covers it has PASSED\n- Compare against SPECS first (behavioral correctness), DESIGN second (structural correctness)\n- Be objective — report what IS, not what should be\n- CRITICAL issues = must fix before archive\n- WARNINGS = should fix but won't block\n- SUGGESTIONS = improvements, not blockers\n- DO NOT fix any issues — only report them. The orchestrator decides what to do.\n- In `openspec` mode, ALWAYS save the report to `openspec\u002Fchanges\u002F{change-name}\u002Fverify-report.md` — this persists the verification for sdd-archive and the audit trail\n- Apply any `rules.verify` from `openspec\u002Fconfig.yaml`\n- Return envelope per **Section D** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n",{"name":5,"license":15,"metadata":46,"description":49},{"author":47,"version":48},"gentleman-programming","2.0","Validate that implementation matches specs, design, and tasks. Trigger: When the orchestrator launches you to verify a completed (or partially completed) change.\n","main","c173cdffe08e788a99b91928a831b476b8434838","ecosystem\u002Fskills\u002Fagent_teams_lite\u002Fpayload\u002Fskills\u002Fsdd_verify",0,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw","https:\u002F\u002Fportfolio-longleo.vercel.app\u002Flabs\u002Fomniclaw.html","https:\u002F\u002Fgithub.com\u002FLongLeo287","https:\u002F\u002Fwww.facebook.com\u002FResourceRookie2023","2026-09-30 00:58:05",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add LongLeo287\u002FOmniClaw --skill sdd-verify",{"tool":65,"command":66},"bunx","bunx skills add LongLeo287\u002FOmniClaw --skill sdd-verify",{"tool":68,"command":69},"pnpm","pnpm dlx skills add LongLeo287\u002FOmniClaw --skill sdd-verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fagent_teams_lite\u002Fpayload\u002Fskills\u002Fsdd_verify\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"_DIR_IDENTITY.md","REFERENCE","参考文档",337,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fagent_teams_lite\u002Fpayload\u002Fskills\u002Fsdd_verify\u002F_DIR_IDENTITY.md",[80,116,138,166,181,208],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":96,"publishedAt":41},"01M6JR0KQP4MHT32TN40D9CBFX","UI-UX Pro Max","Advanced UI\u002FUX analysis and generation skills with data-driven patterns. Python scripts (core.py, search.py) for systematic UI pattern extraction, design system generation, and component search from curated data sources.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fui_components\u002Fui_ux_pro_max\u002FSKILL.md",[86,87,90,93],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":91,"categoryName":92,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",{"categoryNo":94,"categoryName":95,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师",[97,98,99,100,101,102,32,103,104,105,106,107,108,109,110,111,112,113,114,115],"ux","ui","ui ux pro max","max","pro","ui ux","component","search","analysis","team","rd","ui-ux","active","systematic","scripts","pattern extraction","sources","advanced","data-driven",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":41},"01M6JR0EF5AEQHP2FSTB57H05P","shadcn-ui","Expert guidance for integrating and building applications with shadcn\u002Fui components, including component discovery, installation, customization, and best practices.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fui_components\u002Fshadcn_ui\u002FSKILL.md",[122],{"categoryNo":91,"categoryName":92,"taxonomyType":26,"taxonomyTypeDesc":27},[124,98,125,126,103,127,128,129,130,106,131,132,133,109,134,135,136,137],"shadcn","shadcn ui","components","core","best practices","applications","discovery","customization","guidance","expert","installation","ui components","with","for",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":147,"publishedAt":41},"01M6JR08F51BEN17RHFYX65WVE","zustand_store_ts","Create Zustand stores with TypeScript, subscribeWithSelector middleware, and proper state\u002Faction separation. Use when building React state management, creating global stores, or implementing reactive state patterns with Zustand.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fzustand_store_ts\u002FSKILL.md",[144],{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,136,164,165],"zustand store ts","zustand","store","typescript","microsoft","react","create","state management","state","react state management","management","global","use","patterns","separation","middleware","action","implementing",{"skillNo":167,"name":149,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":41},"01M6JR00TDMVAFFCZXZ04AN7Q7","Zustand state management guide. Use when working with store code (src\u002Fstore\u002F**), implementing actions, managing state, or creating slices. Triggers on Zustand store development, state management questions, or action implementation.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fzustand\u002FSKILL.md",[],[149,172,155,173,156,174,175,158,176,160,38,177,178,150,136,179,180,164,165],"development","code","actions","src","guide","zustand state","triggers","questions","zustand state management",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":191,"publishedAt":41},"01M6JQZSWV4KWJP112G6XHEP44","youtube_summarizer","Automatically fetch YouTube video transcripts, generate structured summaries, and send full transcripts to messaging platforms. Detects YouTube URLs and provides metadata, key insights, and downloadable transcripts.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fyoutube_summarizer\u002FSKILL.md",[187,190],{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},[192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207],"youtube","youtube summarizer","summarizer","generate","metadata","messaging","Video","fetch","telegram","transcription","summarization","structured","full","insights","transcripts","summaries",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":214,"publishedAt":41},"01M6JQZN3QJB6B77JGKJD62DQT","youtube_clipper","YouTube 视频智能剪辑工具。下载视频和字幕，AI 分析生成精细章节（几分钟级别）， 用户选择片段后自动剪辑、翻译字幕为中英双语、烧录字幕到视频，并生成总结文案。 使用场景：当用户需要剪辑 YouTube 视频、生成短视频片段、制作双语字幕版本时。 关键词：视频剪辑、YouTube、字幕翻译、双语字幕、视频下载、clip video","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fyoutube_clipper\u002FSKILL.md",[],[192,215,216,198,217,218,219,220,221,222,223,224,225,226,227,228,229],"clipper","youtube clipper","Bash","下载","视频","生成","关键词","翻译","read","write","clip","总结","工具","文案","sonnet"]