[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C47YZ9WWNANK8ARS14T62C":3,"skill-same:01M6C47YZ9WWNANK8ARS14T62C":73},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6C47YZ9WWNANK8ARS14T62C","systematic-debugging",null,"4-phase debugging process (Observe, Hypothesize, Test, Fix) for complex issues. Use when debugging fails, investigating flaky tests, tracking root causes, or facing mysterious bugs. DO NOT USE FOR: writing new tests (use test-driven-development), React component test patterns (use ui-testing), or E2E test setup (use webapp-testing).","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"systematic debugging","debugging","component test","webapp","use","process","fix","tracking","e2e","ui","issues","testing","development","setup","component","react","test","writing","2026-11-10 10:12:30",false,"---\nname: systematic-debugging\ndescription: \"4-phase debugging process (Observe, Hypothesize, Test, Fix) for complex issues. Use when debugging fails, investigating flaky tests, tracking root causes, or facing mysterious bugs. DO NOT USE FOR: writing new tests (use test-driven-development), React component test patterns (use ui-testing), or E2E test setup (use webapp-testing).\"\n---\n\n# Systematic Debugging\n\nEvidence-based debugging methodology using a structured 4-phase approach.\n\n## When to Use\n\n- Initial debugging attempts failed\n- Bug is intermittent or hard to reproduce\n- Multiple potential root causes\n- High-stakes fix (production, security)\n- Teaching debugging skills\n\n## The 4-Phase Process\n\n```\n┌─────────────┐    ┌──────────────┐    ┌─────────────┐    ┌─────────────┐\n│  1. OBSERVE │ -> │ 2. HYPOTHESIZE│ -> │   3. TEST   │ -> │   4. FIX    │\n│             │    │              │    │             │    │             │\n│ Gather data │    │ Form theories│    │ Validate    │    │ Implement & │\n│ Don't assume│    │ Rank by      │    │ One at a    │    │ Verify      │\n│             │    │ likelihood   │    │ time        │    │             │\n└─────────────┘    └──────────────┘    └─────────────┘    └─────────────┘\n       ↑                                      │\n       └──────────────────────────────────────┘\n                (if hypothesis fails)\n```\n\n## Phase 1: OBSERVE\n\n**Goal**: Gather facts without assumptions.\n\n### Actions\n\n- [ ] Document exact symptoms (error messages, behavior)\n- [ ] Identify when it started (commit, deployment, date)\n- [ ] Determine reproduction steps (or note if intermittent)\n- [ ] Check logs, metrics, and monitoring\n- [ ] Note what IS working (bounds the problem)\n\n### Questions to Answer\n\n- What exactly is happening vs. expected?\n- When did this start? What changed?\n- Who\u002Fwhat is affected? (all users, some, specific conditions)\n- Can I reproduce it? How reliably?\n- What have I already tried?\n\n### Observation Log Template\n\n```markdown\n## Bug: [Brief description]\n\n### Symptoms\n\n- [Exact error message or behavior]\n\n### Timeline\n\n- First reported: [date\u002Ftime]\n- Last known working: [date\u002Ftime]\n- Related changes: [commits, deploys]\n\n### Reproduction\n\n- Steps: [1, 2, 3...]\n- Reliability: [always\u002Fsometimes\u002Frarely]\n- Environment: [local\u002Fstaging\u002Fprod]\n\n### What Works\n\n- [Related functionality that IS working]\n```\n\n## Phase 2: HYPOTHESIZE\n\n**Goal**: Generate ranked theories based on evidence.\n\n### Generate Hypotheses\n\nBased on observations, list possible causes:\n\n1. **Most likely** (evidence strongly supports)\n2. **Possible** (evidence partially supports)\n3. **Unlikely but testable** (low probability, easy to rule out)\n\n### Ranking Criteria\n\n- **Evidence fit**: Does it explain ALL symptoms?\n- **Recency**: Recent changes more likely than old code\n- **Complexity**: Simpler explanations first (Occam's Razor)\n- **Testability**: Can we prove\u002Fdisprove it quickly?\n\n### Hypothesis Template\n\n```markdown\n### Hypothesis: [Theory]\n\nEvidence for:\n\n- [Supporting observation]\n\nEvidence against:\n\n- [Contradicting observation]\n\nHow to test:\n\n- [Specific test that proves\u002Fdisproves]\n\nLikelihood: [High\u002FMedium\u002FLow]\n```\n\nSee [debugging-phases.md](.\u002Fdebugging-phases.md) for detailed phase guidance.\n\n## Phase 3: TEST\n\n**Goal**: Validate one hypothesis at a time with evidence.\n\n### Testing Rules\n\n1. **One variable at a time**: Change only what tests the hypothesis\n2. **Record everything**: Document what you tried and results\n3. **Preserve ability to undo**: Don't make permanent changes while testing\n4. **Set time limits**: Timebox each hypothesis test\n\n### Test Log Template\n\n```markdown\n### Testing: [Hypothesis]\n\nTest approach:\n\n- [What I'm changing\u002Fchecking]\n\nResult:\n\n- [What happened]\n\nConclusion:\n\n- [ ] Confirmed (proceed to Fix)\n- [ ] Disproved (next hypothesis)\n- [ ] Inconclusive (need different test)\n```\n\n## Phase 4: FIX\n\n**Goal**: Implement verified fix with confidence.\n\n### Fix Checklist\n\n- [ ] Fix addresses confirmed root cause (not just symptoms)\n- [ ] Fix is minimal (no unrelated changes)\n- [ ] Added test that would catch regression\n- [ ] Verified fix in same environment where bug occurred\n- [ ] Documented what the bug was and how it was fixed\n\n### Post-Fix Verification\n\n- [ ] Original reproduction steps no longer fail\n- [ ] Related functionality still works\n- [ ] No new errors in logs\n- [ ] Performance not degraded\n\n## Quick Debugging Toolkit\n\n### Information Gathering\n\n```\n[CUSTOMIZE] Add your project's debugging commands:\n- Log tailing: [command]\n- Database queries: [tool\u002Faccess]\n- Metrics dashboard: [URL]\n- Error tracking: [tool\u002FURL]\n```\n\n### Common Root Causes Checklist\n\n- [ ] Recent deployment? Check release notes\n- [ ] Environment difference? Compare configs\n- [ ] Data issue? Check for bad\u002Fmissing data\n- [ ] Dependency update? Check lock files\n- [ ] Race condition? Check async code\n- [ ] Resource exhaustion? Check memory\u002Fconnections\n- [ ] Permission change? Check access controls\n\n## Gotchas\n\n| Trigger                                                     | Gotcha                                                                       | Fix                                                                                |\n| ----------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |\n| Making multiple simultaneous changes to isolate the bug     | Root cause becomes impossible to identify — can't know which change fixed it | Revert to baseline; apply one targeted change; verify; then proceed                |\n| Closing the bug without adding a regression test            | Bug recurs under similar conditions undetected                               | Add a test that reproduces the original failure; confirm it is GREEN after the fix |\n| Forming a hypothesis before completing Phase 1 observations | Leads investigation down the wrong path; root cause stays unexamined         | Complete Phase 1 (Observe) fully before proposing any hypothesis                   |\n| Applying changes directly in the production environment     | Risk of cascading failure or data corruption                                 | Reproduce locally first; use staging environments or feature flags                 |\n| Ending the session without updating the observation log     | Investigation must restart from scratch next session                         | Log dated observations before ending the session; commit the log                   |\n| Making permanent code changes while testing hypotheses      | Progressive state contamination — hard to reason about current baseline      | Preserve ability to undo each test step; use feature flags or branches             |\n| Fixing the symptom without root cause analysis              | Bug recurs under different conditions                                        | Follow the 4-phase protocol fully; document root cause before applying fix         |\n","# Systematic Debugging\n\nEvidence-based debugging methodology using a structured 4-phase approach.\n\n## When to Use\n\n- Initial debugging attempts failed\n- Bug is intermittent or hard to reproduce\n- Multiple potential root causes\n- High-stakes fix (production, security)\n- Teaching debugging skills\n\n## The 4-Phase Process\n\n```\n┌─────────────┐    ┌──────────────┐    ┌─────────────┐    ┌─────────────┐\n│  1. OBSERVE │ -> │ 2. HYPOTHESIZE│ -> │   3. TEST   │ -> │   4. FIX    │\n│             │    │              │    │             │    │             │\n│ Gather data │    │ Form theories│    │ Validate    │    │ Implement & │\n│ Don't assume│    │ Rank by      │    │ One at a    │    │ Verify      │\n│             │    │ likelihood   │    │ time        │    │             │\n└─────────────┘    └──────────────┘    └─────────────┘    └─────────────┘\n       ↑                                      │\n       └──────────────────────────────────────┘\n                (if hypothesis fails)\n```\n\n## Phase 1: OBSERVE\n\n**Goal**: Gather facts without assumptions.\n\n### Actions\n\n- [ ] Document exact symptoms (error messages, behavior)\n- [ ] Identify when it started (commit, deployment, date)\n- [ ] Determine reproduction steps (or note if intermittent)\n- [ ] Check logs, metrics, and monitoring\n- [ ] Note what IS working (bounds the problem)\n\n### Questions to Answer\n\n- What exactly is happening vs. expected?\n- When did this start? What changed?\n- Who\u002Fwhat is affected? (all users, some, specific conditions)\n- Can I reproduce it? How reliably?\n- What have I already tried?\n\n### Observation Log Template\n\n```markdown\n## Bug: [Brief description]\n\n### Symptoms\n\n- [Exact error message or behavior]\n\n### Timeline\n\n- First reported: [date\u002Ftime]\n- Last known working: [date\u002Ftime]\n- Related changes: [commits, deploys]\n\n### Reproduction\n\n- Steps: [1, 2, 3...]\n- Reliability: [always\u002Fsometimes\u002Frarely]\n- Environment: [local\u002Fstaging\u002Fprod]\n\n### What Works\n\n- [Related functionality that IS working]\n```\n\n## Phase 2: HYPOTHESIZE\n\n**Goal**: Generate ranked theories based on evidence.\n\n### Generate Hypotheses\n\nBased on observations, list possible causes:\n\n1. **Most likely** (evidence strongly supports)\n2. **Possible** (evidence partially supports)\n3. **Unlikely but testable** (low probability, easy to rule out)\n\n### Ranking Criteria\n\n- **Evidence fit**: Does it explain ALL symptoms?\n- **Recency**: Recent changes more likely than old code\n- **Complexity**: Simpler explanations first (Occam's Razor)\n- **Testability**: Can we prove\u002Fdisprove it quickly?\n\n### Hypothesis Template\n\n```markdown\n### Hypothesis: [Theory]\n\nEvidence for:\n\n- [Supporting observation]\n\nEvidence against:\n\n- [Contradicting observation]\n\nHow to test:\n\n- [Specific test that proves\u002Fdisproves]\n\nLikelihood: [High\u002FMedium\u002FLow]\n```\n\nSee [debugging-phases.md](.\u002Fdebugging-phases.md) for detailed phase guidance.\n\n## Phase 3: TEST\n\n**Goal**: Validate one hypothesis at a time with evidence.\n\n### Testing Rules\n\n1. **One variable at a time**: Change only what tests the hypothesis\n2. **Record everything**: Document what you tried and results\n3. **Preserve ability to undo**: Don't make permanent changes while testing\n4. **Set time limits**: Timebox each hypothesis test\n\n### Test Log Template\n\n```markdown\n### Testing: [Hypothesis]\n\nTest approach:\n\n- [What I'm changing\u002Fchecking]\n\nResult:\n\n- [What happened]\n\nConclusion:\n\n- [ ] Confirmed (proceed to Fix)\n- [ ] Disproved (next hypothesis)\n- [ ] Inconclusive (need different test)\n```\n\n## Phase 4: FIX\n\n**Goal**: Implement verified fix with confidence.\n\n### Fix Checklist\n\n- [ ] Fix addresses confirmed root cause (not just symptoms)\n- [ ] Fix is minimal (no unrelated changes)\n- [ ] Added test that would catch regression\n- [ ] Verified fix in same environment where bug occurred\n- [ ] Documented what the bug was and how it was fixed\n\n### Post-Fix Verification\n\n- [ ] Original reproduction steps no longer fail\n- [ ] Related functionality still works\n- [ ] No new errors in logs\n- [ ] Performance not degraded\n\n## Quick Debugging Toolkit\n\n### Information Gathering\n\n```\n[CUSTOMIZE] Add your project's debugging commands:\n- Log tailing: [command]\n- Database queries: [tool\u002Faccess]\n- Metrics dashboard: [URL]\n- Error tracking: [tool\u002FURL]\n```\n\n### Common Root Causes Checklist\n\n- [ ] Recent deployment? Check release notes\n- [ ] Environment difference? Compare configs\n- [ ] Data issue? Check for bad\u002Fmissing data\n- [ ] Dependency update? Check lock files\n- [ ] Race condition? Check async code\n- [ ] Resource exhaustion? Check memory\u002Fconnections\n- [ ] Permission change? Check access controls\n\n## Gotchas\n\n| Trigger                                                     | Gotcha                                                                       | Fix                                                                                |\n| ----------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |\n| Making multiple simultaneous changes to isolate the bug     | Root cause becomes impossible to identify — can't know which change fixed it | Revert to baseline; apply one targeted change; verify; then proceed                |\n| Closing the bug without adding a regression test            | Bug recurs under similar conditions undetected                               | Add a test that reproduces the original failure; confirm it is GREEN after the fix |\n| Forming a hypothesis before completing Phase 1 observations | Leads investigation down the wrong path; root cause stays unexamined         | Complete Phase 1 (Observe) fully before proposing any hypothesis                   |\n| Applying changes directly in the production environment     | Risk of cascading failure or data corruption                                 | Reproduce locally first; use staging environments or feature flags                 |\n| Ending the session without updating the observation log     | Investigation must restart from scratch next session                         | Log dated observations before ending the session; commit the log                   |\n| Making permanent code changes while testing hypotheses      | Progressive state contamination — hard to reason about current baseline      | Preserve ability to undo each test step; use feature flags or branches             |\n| Fixing the symptom without root cause analysis              | Bug recurs under different conditions                                        | Follow the 4-phase protocol fully; document root cause before applying fix         |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fsystematic-debugging",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill systematic-debugging",{"tool":59,"command":60},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill systematic-debugging",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill systematic-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"debugging-phases.md","REFERENCE","参考文档",5551,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Fdebugging-phases.md",[74,96,121,136,164,183],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":84,"publishedAt":41},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[80,81],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":82,"categoryName":83,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[34,85,26,86,87,88,89,39,90,38,37,24,35,91,92,93,31,94,95,27],"webapp testing","canvas","tdd","workflow","playwright","web","browser","ci","execution","game","coverage",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":41},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[103,104,105,106,107,108,109,110,111,112,113,114,92,115,116,117,118,27,119,120],"verification","verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":41},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[128,129,130,105,131,132,36,133,112,134,93,27,135],"validation","methodology","validation methodology","triage","orchestration","adversarial review","flow","dispatch",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":150,"publishedAt":41},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[142,145],{"categoryNo":143,"categoryName":144,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":146,"categoryName":147,"taxonomyType":148,"taxonomyTypeDesc":149},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[151,152,105,153,154,108,155,109,112,156,157,158,159,160,161,117,118,162,163,27],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":178,"publishedAt":41},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[170,171,172,175],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":82,"categoryName":83,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":173,"categoryName":174,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":176,"categoryName":177,"taxonomyType":148,"taxonomyTypeDesc":149},"01JBSEEDCAT000000000000032","设计师",[34,32,179,180,181,40,86,88,89,39,38,37,24,35,91,182,31,94,27,26],"ui testing","frontend","design","testing patterns",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":191,"publishedAt":41},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[189,190],{"categoryNo":82,"categoryName":83,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":176,"categoryName":177,"taxonomyType":148,"taxonomyTypeDesc":149},[32,192,180,181,105,88,193,112,194,195,196,197,198,117,199,200,27,201],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]