[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C48DRJ9XBDR2FW0W37DY53":3,"skill-same:01M6C48DRJ9XBDR2FW0W37DY53":72},{"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":27,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration",null,"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).","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\u002Fui-iteration\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"ui iteration","ui","polish","only","use","strategy","redesign","work","feedback","ui polish","frontend","Tailwind","screenshot","code","accessibility","workflow","review","design","2026-11-10 10:12:30",false,"---\nname: ui-iteration\ndescription: \"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).\"\n---\n\n\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; assumes the calling agent owns browser-tool applicability, invocation boundaries, and implementation handoff decisions. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# UI Iteration\n\nReusable methodology for screenshot-based UI polish.\n\n## When to Use\n\n- When a page or component feels visually off but needs targeted refinement rather than redesign\n- When repeated screenshot comparison is the fastest way to validate polish work\n- When the work is mostly spacing, hierarchy, theme coherence, or interaction feedback\n- When Tailwind or presentation-layer tweaks should be applied in bounded iterations\n\n## Purpose\n\nImprove the UI through short, measurable polish loops. Each pass should identify a small set of visual issues, apply focused changes, and confirm that the after state is visibly better than the before state.\n\n## Iterative Polish Workflow\n\n1. Capture a baseline screenshot of the target page or component state.\n2. Assess the current UI against the evaluation criteria below.\n3. Select 3-5 concrete improvements for the pass.\n4. Implement the smallest set of presentation changes that address those issues.\n5. Capture a follow-up screenshot.\n6. Compare before and after, and record whether the pass produced measurable improvement.\n7. Repeat until the planned iteration count is complete or additional changes stop producing clear gains.\n\n## Screenshot Requirements\n\n- Use a representative populated state rather than empty placeholders\n- Prefer standard desktop browser width unless the task is explicitly mobile-first\n- Keep captures focused on the target surface, not the full desktop\n- Use programmatic screenshots when browser tools are available; otherwise follow the repo's fallback process\n\n**Screenshot output**: save screenshots to `.tmp\u002F` per `skills\u002Fterminal-hygiene\u002FSKILL.md` `## Scratch & Temp-File Hygiene`.\n\n## Aesthetic Evaluation Criteria\n\n### Generic UI Principles\n\n| Principle        | What to Check                                   |\n| ---------------- | ----------------------------------------------- |\n| Readability      | Text contrast, font sizes, line height          |\n| Visual Hierarchy | Clear focal points and emphasis                 |\n| Spacing          | Consistent padding, margins, and breathing room |\n| Alignment        | Grid alignment and edge consistency             |\n| Consistency      | Similar elements styled similarly               |\n| Feedback         | Hover, active, loading, and empty-state clarity |\n\n### Product-Facing Checks\n\n| Criterion           | What Good Looks Like                                        |\n| ------------------- | ----------------------------------------------------------- |\n| Information Clarity | Primary data and actions are obvious at a glance            |\n| Theme Coherence     | Colors, typography, and surfaces feel intentionally related |\n| Data Legibility     | Statuses, values, and labels remain easy to parse           |\n| Motion Restraint    | Motion supports comprehension rather than distracting       |\n| Pattern Benchmark   | New surfaces fit the product's established visual language  |\n\n## Tailwind And UI Polish Heuristics\n\n- Prefer design tokens and semantic utilities over arbitrary values\n- Use spacing scales consistently before introducing custom exceptions\n- Improve hierarchy with contrast, weight, grouping, and whitespace before adding more chrome\n- Fix misalignment at the container or layout level before patching individual elements\n- Keep motion subtle and purposeful\n- Prefer utility composition over custom CSS when the design system already supports the need\n\n## Iteration Parameters\n\n| Parameter  | Default   | Typical Override Example                |\n| ---------- | --------- | --------------------------------------- |\n| Iterations | 5         | `Polish Dashboard 3 times`              |\n| Scope      | Full page | `Polish just the SummaryCard component` |\n| Focus      | All       | `Focus on spacing and alignment`        |\n\n## Output Formats\n\n### Per-Iteration Analysis\n\n```markdown\n## Iteration N\u002F5 Analysis\n\n**Target**: [Page\u002FComponent]\n\n**Assessment**:\n\n- ✅ [What is working]\n- ⚠️ [Minor issues]\n- ❌ [Significant issues]\n\n**Proposed Improvements**:\n\n1. [Specific change] - [Rationale]\n2. [Specific change] - [Rationale]\n3. [Specific change] - [Rationale]\n\n**Files to Modify**:\n\n- `src\u002F...`\n```\n\n### Final Session Summary\n\n```markdown\n## UI Polish Complete\n\n**Target**: [Page\u002FComponent]\n**Iterations**: N\u002FN\n\n**Changes Made**:\n\n1. [Change] (Iteration 1)\n2. [Change] (Iteration 2)\n\n**Before\u002FAfter Summary**:\n\n- Spacing: [Before] -> [After]\n- Hierarchy: [Before] -> [After]\n- Feedback: [Before] -> [After]\n\n**Remaining Suggestions**:\n\n- [Optional future polish]\n```\n\n## Related Guidance\n\n- Load `frontend-design` when the polish work needs a stronger visual point of view\n- Use browser-tool instructions from the current repo for navigation, startup, and cleanup details\n\n## Gotchas\n\n| Trigger                                     | Gotcha                                                      | Fix                                                            |\n| ------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------- |\n| The before and after screenshots look alike | The pass changed code without producing visible improvement | Reduce scope and choose 3-5 changes with clearer visual impact |\n\n| Trigger                                    | Gotcha                                                 | Fix                                                              |\n| ------------------------------------------ | ------------------------------------------------------ | ---------------------------------------------------------------- |\n| Tailwind tweaks pile up element by element | The layout becomes inconsistent and harder to maintain | Fix spacing and alignment at the layout or container level first |\n","\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; assumes the calling agent owns browser-tool applicability, invocation boundaries, and implementation handoff decisions. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# UI Iteration\n\nReusable methodology for screenshot-based UI polish.\n\n## When to Use\n\n- When a page or component feels visually off but needs targeted refinement rather than redesign\n- When repeated screenshot comparison is the fastest way to validate polish work\n- When the work is mostly spacing, hierarchy, theme coherence, or interaction feedback\n- When Tailwind or presentation-layer tweaks should be applied in bounded iterations\n\n## Purpose\n\nImprove the UI through short, measurable polish loops. Each pass should identify a small set of visual issues, apply focused changes, and confirm that the after state is visibly better than the before state.\n\n## Iterative Polish Workflow\n\n1. Capture a baseline screenshot of the target page or component state.\n2. Assess the current UI against the evaluation criteria below.\n3. Select 3-5 concrete improvements for the pass.\n4. Implement the smallest set of presentation changes that address those issues.\n5. Capture a follow-up screenshot.\n6. Compare before and after, and record whether the pass produced measurable improvement.\n7. Repeat until the planned iteration count is complete or additional changes stop producing clear gains.\n\n## Screenshot Requirements\n\n- Use a representative populated state rather than empty placeholders\n- Prefer standard desktop browser width unless the task is explicitly mobile-first\n- Keep captures focused on the target surface, not the full desktop\n- Use programmatic screenshots when browser tools are available; otherwise follow the repo's fallback process\n\n**Screenshot output**: save screenshots to `.tmp\u002F` per `skills\u002Fterminal-hygiene\u002FSKILL.md` `## Scratch & Temp-File Hygiene`.\n\n## Aesthetic Evaluation Criteria\n\n### Generic UI Principles\n\n| Principle        | What to Check                                   |\n| ---------------- | ----------------------------------------------- |\n| Readability      | Text contrast, font sizes, line height          |\n| Visual Hierarchy | Clear focal points and emphasis                 |\n| Spacing          | Consistent padding, margins, and breathing room |\n| Alignment        | Grid alignment and edge consistency             |\n| Consistency      | Similar elements styled similarly               |\n| Feedback         | Hover, active, loading, and empty-state clarity |\n\n### Product-Facing Checks\n\n| Criterion           | What Good Looks Like                                        |\n| ------------------- | ----------------------------------------------------------- |\n| Information Clarity | Primary data and actions are obvious at a glance            |\n| Theme Coherence     | Colors, typography, and surfaces feel intentionally related |\n| Data Legibility     | Statuses, values, and labels remain easy to parse           |\n| Motion Restraint    | Motion supports comprehension rather than distracting       |\n| Pattern Benchmark   | New surfaces fit the product's established visual language  |\n\n## Tailwind And UI Polish Heuristics\n\n- Prefer design tokens and semantic utilities over arbitrary values\n- Use spacing scales consistently before introducing custom exceptions\n- Improve hierarchy with contrast, weight, grouping, and whitespace before adding more chrome\n- Fix misalignment at the container or layout level before patching individual elements\n- Keep motion subtle and purposeful\n- Prefer utility composition over custom CSS when the design system already supports the need\n\n## Iteration Parameters\n\n| Parameter  | Default   | Typical Override Example                |\n| ---------- | --------- | --------------------------------------- |\n| Iterations | 5         | `Polish Dashboard 3 times`              |\n| Scope      | Full page | `Polish just the SummaryCard component` |\n| Focus      | All       | `Focus on spacing and alignment`        |\n\n## Output Formats\n\n### Per-Iteration Analysis\n\n```markdown\n## Iteration N\u002F5 Analysis\n\n**Target**: [Page\u002FComponent]\n\n**Assessment**:\n\n- ✅ [What is working]\n- ⚠️ [Minor issues]\n- ❌ [Significant issues]\n\n**Proposed Improvements**:\n\n1. [Specific change] - [Rationale]\n2. [Specific change] - [Rationale]\n3. [Specific change] - [Rationale]\n\n**Files to Modify**:\n\n- `src\u002F...`\n```\n\n### Final Session Summary\n\n```markdown\n## UI Polish Complete\n\n**Target**: [Page\u002FComponent]\n**Iterations**: N\u002FN\n\n**Changes Made**:\n\n1. [Change] (Iteration 1)\n2. [Change] (Iteration 2)\n\n**Before\u002FAfter Summary**:\n\n- Spacing: [Before] -> [After]\n- Hierarchy: [Before] -> [After]\n- Feedback: [Before] -> [After]\n\n**Remaining Suggestions**:\n\n- [Optional future polish]\n```\n\n## Related Guidance\n\n- Load `frontend-design` when the polish work needs a stronger visual point of view\n- Use browser-tool instructions from the current repo for navigation, startup, and cleanup details\n\n## Gotchas\n\n| Trigger                                     | Gotcha                                                      | Fix                                                            |\n| ------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------- |\n| The before and after screenshots look alike | The pass changed code without producing visible improvement | Reduce scope and choose 3-5 changes with clearer visual impact |\n\n| Trigger                                    | Gotcha                                                 | Fix                                                              |\n| ------------------------------------------ | ------------------------------------------------------ | ---------------------------------------------------------------- |\n| Tailwind tweaks pile up element by element | The layout becomes inconsistent and harder to maintain | Fix spacing and alignment at the layout or container level first |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fui-iteration",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill ui-iteration",{"tool":64,"command":65},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill ui-iteration",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill ui-iteration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",true,[],[73,102,124,140,166,182],{"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":83,"publishedAt":46},"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",[79,82],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[84,85,86,87,88,43,89,90,91,92,93,94,95,96,97,98,99,100,101,32],"testing","webapp testing","webapp","canvas","tdd","playwright","test","web","react","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":46},"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",[],[109,110,44,111,112,113,114,115,116,41,117,118,97,119,120,35,121,32,122,123],"verification","verification before completion","change","commit","merge","pr","cleanup","run","code-review","intake","loop","verification loop","check","evidence","campaign",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":46},"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",[],[131,132,133,44,134,135,136,137,41,138,98,32,139],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":152,"publishedAt":46},"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",[146,149],{"categoryNo":147,"categoryName":148,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":150,"categoryName":151,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[153,154,44,155,156,113,157,114,41,158,159,160,161,162,163,35,121,164,165,32],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":178,"publishedAt":46},"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",[172,173,174,177],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":175,"categoryName":176,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},[84,29,179,38,45,180,87,43,89,90,92,93,94,95,96,181,99,100,32,86],"ui testing","writing","testing patterns",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":46},"01M6C48B7PAY03MSRVKNZVYFT4","tracking-format","Tracking-file frontmatter and coordination format guidance. Use when creating or reviewing local tracking files and related handoff conventions. DO NOT USE FOR: session-memory plan authoring rules outside the documented references here.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftracking-format\u002FSKILL.md",[],[189,190,191,192,193,194,195,196,197,165,32,198],"format","tracking","tracking format","handoff","memory","file","plan","coordination","Rules","plan authoring"]