[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C44DV7Z2K8XYGFDDPTGG8E":3,"skill-same:01M6C44DV7Z2K8XYGFDDPTGG8E":81},{"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":25,"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},"01M6C44DV7Z2K8XYGFDDPTGG8E","documentation-finalization",null,"Documentation finalization workflow for accuracy, cleanup, and design-doc maintenance. Use when updating implementation-facing docs, synchronizing design documents with shipped behavior, or removing obsolete documentation. DO NOT USE FOR: formal specification drafting (use specification-authoring) or source-code implementation decisions (use implementation-discipline)","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\u002Fdocumentation-finalization\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"documentation","documentation finalization","design","docs","workflow","documents","cleanup","code","doc maintenance","code implementation","doc","decisions","behavior","use","discipline","2026-11-10 10:12:30",false,"---\n\nname: documentation-finalization\ndescription: \"Documentation finalization workflow for accuracy, cleanup, and design-doc maintenance. Use when updating implementation-facing docs, synchronizing design documents with shipped behavior, or removing obsolete documentation. DO NOT USE FOR: formal specification drafting (use specification-authoring) or source-code implementation decisions (use implementation-discipline)\"\n---\n\n\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; applies to repository documentation and agent markdown updates. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Documentation Finalization\n\nReusable documentation-finalization process for implementation and design updates.\n\n## When to Use\n\n- When implementation changed names, behavior, file paths, or architecture references in docs\n- When a design document in `Documents\u002FDesign\u002F` must be created or updated for the current domain\n- When obsolete placeholders, duplicate guidance, or stale references must be removed before completion\n- When documentation work needs a consistent finalization checklist rather than ad hoc edits\n\n## Purpose\n\nMake documentation reflect the shipped state of the repository. Treat deletion of stale content as first-class work, and verify every technical statement against implementation before leaving the documentation phase.\n\n## Documentation Areas\n\n### Development Docs\n\n- Update current-state, setup, architecture, and workflow documents to match the implementation\n- Replace outdated file paths, names, timelines, and phase markers\n- Remove \"not yet implemented\" language once behavior exists\n\n### Design Docs\n\n- Keep terminology aligned with actual classes, methods, scripts, headings, and behaviors\n- Refresh examples, formulas, schemas, and interaction descriptions to match current behavior\n- Remove placeholders such as `TBD`, `coming soon`, or obsolete alternative designs\n\n### Decision Docs\n\n- Update existing ADRs when a shipped decision changed\n- Create or refine decision records only when implementation introduced or documented an actual decision\n- Remove obsolete decision records only when a newer source of truth fully supersedes them\n\n### Domain Design Docs\n\n- Prefer updating an existing domain file when the feature extends an established design area\n- Create a new `Documents\u002FDesign\u002F{domain-slug}.md` file only when no current domain doc covers the feature area\n- Keep domain docs focused on the current design state, not as per-issue changelogs\n\n## Documentation Maintenance Responsibilities\n\nThe documentation specialist is responsible for maintaining:\n\n- **CHANGELOG.md**: Update BEFORE merge - add entry during PR documentation finalization.\n- **NEXT-STEPS.md**: Update BEFORE merge - update priorities during PR finalization.\n- **QUICK-START.md**: Update when tooling or setup instructions change.\n- **Documents\u002FDecisions\u002F**: Create new decision records from issue body design content during the implementation phase - keep existing ADRs accurate.\n- **ROADMAP.md**: Update when present - reflect milestone and priority changes from implemented features.\n\nSee also: [Experience-Owner](..\u002F..\u002Fagents\u002FExperience-Owner.agent.md) for customer framing documentation.\n\n## Finalization Workflow\n\n1. Review the relevant implementation and determine what actually changed.\n2. Update the affected development and design documents to match shipped behavior.\n3. Apply any required decision-record updates tied to real implementation decisions.\n4. Remove obsolete content, duplicate guidance, and placeholder text.\n5. Verify terminology, file paths, cross-references, and examples against the codebase.\n6. Run markdown formatting and repo validation before handing off completion.\n\n## Quality Checks\n\n- Match code names, signatures, entity names, and workflow labels exactly\n- Verify file paths, section cross-references, and command examples still exist\n- Remove stale future-tense statements once the work shipped\n- Prefer consolidation over duplication when multiple docs describe the same rule\n- For domain design docs, describe the stable domain behavior rather than issue-by-issue history\n\n## Conciseness Guidelines\n\n- Target roughly 150-250 lines per permanent document when practical\n- Split a document when it serves multiple unrelated purposes or becomes hard to navigate\n- Prefer linking to the authoritative doc instead of restating the same guidance in multiple places\n- Value deletion as much as addition when reducing confusion\n\n## Validation\n\n- Run `markdownlint-cli2 --fix \"**\u002F*.md\"`\n- Run `pwsh -NoProfile -NonInteractive -File .github\u002Fscripts\u002Fquick-validate.ps1`\n- When agent markdown is edited, confirm the `tools:` frontmatter still matches the capabilities described in the body\n\n## Gotchas\n\n| Trigger                                   | Gotcha                                                             | Fix                                                                  |\n| ----------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------- |\n| Updating docs from intent instead of code | Documentation drifts toward the plan rather than the shipped state | Verify names, paths, and behavior against the current implementation |\n\n| Trigger                                      | Gotcha                                                           | Fix                                                             |\n| -------------------------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------- |\n| Turning a domain design doc into issue notes | The file becomes a changelog and stops reflecting the current UX | Rewrite the doc around current domain behavior and delete drift |\n\n## Frame Ports Filled By This Skill\n\n| Port | Work adapter | Auto-N\u002FA adapter | Explicit-skip adapter |\n| --- | --- | --- | --- |\n| `implement-docs` | [agents\u002FDoc-Keeper.agent.md](..\u002F..\u002Fagents\u002FDoc-Keeper.agent.md); [adapters\u002Fimplement-docs-adapter.md](adapters\u002Fimplement-docs-adapter.md) | [adapters\u002Fimplement-docs-auto-na-adapter.md](adapters\u002Fimplement-docs-auto-na-adapter.md) | [adapters\u002Fimplement-docs-explicit-skip-adapter.md](adapters\u002Fimplement-docs-explicit-skip-adapter.md) |\n\nIn `\u002Fspine-run`, the `implement-docs` port resolves through [adapters\u002Fimplement-docs-adapter.md](adapters\u002Fimplement-docs-adapter.md) as the work adapter executed by Senior Engineer. Hub-flow dispatch uses `agents\u002FDoc-Keeper.agent.md` directly. This split-declaration state is documented in [Documents\u002FDesign\u002Fframe-architecture.md](..\u002F..\u002FDocuments\u002FDesign\u002Fframe-architecture.md); see footnote § (split-declaration #612).\n","\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; applies to repository documentation and agent markdown updates. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Documentation Finalization\n\nReusable documentation-finalization process for implementation and design updates.\n\n## When to Use\n\n- When implementation changed names, behavior, file paths, or architecture references in docs\n- When a design document in `Documents\u002FDesign\u002F` must be created or updated for the current domain\n- When obsolete placeholders, duplicate guidance, or stale references must be removed before completion\n- When documentation work needs a consistent finalization checklist rather than ad hoc edits\n\n## Purpose\n\nMake documentation reflect the shipped state of the repository. Treat deletion of stale content as first-class work, and verify every technical statement against implementation before leaving the documentation phase.\n\n## Documentation Areas\n\n### Development Docs\n\n- Update current-state, setup, architecture, and workflow documents to match the implementation\n- Replace outdated file paths, names, timelines, and phase markers\n- Remove \"not yet implemented\" language once behavior exists\n\n### Design Docs\n\n- Keep terminology aligned with actual classes, methods, scripts, headings, and behaviors\n- Refresh examples, formulas, schemas, and interaction descriptions to match current behavior\n- Remove placeholders such as `TBD`, `coming soon`, or obsolete alternative designs\n\n### Decision Docs\n\n- Update existing ADRs when a shipped decision changed\n- Create or refine decision records only when implementation introduced or documented an actual decision\n- Remove obsolete decision records only when a newer source of truth fully supersedes them\n\n### Domain Design Docs\n\n- Prefer updating an existing domain file when the feature extends an established design area\n- Create a new `Documents\u002FDesign\u002F{domain-slug}.md` file only when no current domain doc covers the feature area\n- Keep domain docs focused on the current design state, not as per-issue changelogs\n\n## Documentation Maintenance Responsibilities\n\nThe documentation specialist is responsible for maintaining:\n\n- **CHANGELOG.md**: Update BEFORE merge - add entry during PR documentation finalization.\n- **NEXT-STEPS.md**: Update BEFORE merge - update priorities during PR finalization.\n- **QUICK-START.md**: Update when tooling or setup instructions change.\n- **Documents\u002FDecisions\u002F**: Create new decision records from issue body design content during the implementation phase - keep existing ADRs accurate.\n- **ROADMAP.md**: Update when present - reflect milestone and priority changes from implemented features.\n\nSee also: [Experience-Owner](..\u002F..\u002Fagents\u002FExperience-Owner.agent.md) for customer framing documentation.\n\n## Finalization Workflow\n\n1. Review the relevant implementation and determine what actually changed.\n2. Update the affected development and design documents to match shipped behavior.\n3. Apply any required decision-record updates tied to real implementation decisions.\n4. Remove obsolete content, duplicate guidance, and placeholder text.\n5. Verify terminology, file paths, cross-references, and examples against the codebase.\n6. Run markdown formatting and repo validation before handing off completion.\n\n## Quality Checks\n\n- Match code names, signatures, entity names, and workflow labels exactly\n- Verify file paths, section cross-references, and command examples still exist\n- Remove stale future-tense statements once the work shipped\n- Prefer consolidation over duplication when multiple docs describe the same rule\n- For domain design docs, describe the stable domain behavior rather than issue-by-issue history\n\n## Conciseness Guidelines\n\n- Target roughly 150-250 lines per permanent document when practical\n- Split a document when it serves multiple unrelated purposes or becomes hard to navigate\n- Prefer linking to the authoritative doc instead of restating the same guidance in multiple places\n- Value deletion as much as addition when reducing confusion\n\n## Validation\n\n- Run `markdownlint-cli2 --fix \"**\u002F*.md\"`\n- Run `pwsh -NoProfile -NonInteractive -File .github\u002Fscripts\u002Fquick-validate.ps1`\n- When agent markdown is edited, confirm the `tools:` frontmatter still matches the capabilities described in the body\n\n## Gotchas\n\n| Trigger                                   | Gotcha                                                             | Fix                                                                  |\n| ----------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------- |\n| Updating docs from intent instead of code | Documentation drifts toward the plan rather than the shipped state | Verify names, paths, and behavior against the current implementation |\n\n| Trigger                                      | Gotcha                                                           | Fix                                                             |\n| -------------------------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------- |\n| Turning a domain design doc into issue notes | The file becomes a changelog and stops reflecting the current UX | Rewrite the doc around current domain behavior and delete drift |\n\n## Frame Ports Filled By This Skill\n\n| Port | Work adapter | Auto-N\u002FA adapter | Explicit-skip adapter |\n| --- | --- | --- | --- |\n| `implement-docs` | [agents\u002FDoc-Keeper.agent.md](..\u002F..\u002Fagents\u002FDoc-Keeper.agent.md); [adapters\u002Fimplement-docs-adapter.md](adapters\u002Fimplement-docs-adapter.md) | [adapters\u002Fimplement-docs-auto-na-adapter.md](adapters\u002Fimplement-docs-auto-na-adapter.md) | [adapters\u002Fimplement-docs-explicit-skip-adapter.md](adapters\u002Fimplement-docs-explicit-skip-adapter.md) |\n\nIn `\u002Fspine-run`, the `implement-docs` port resolves through [adapters\u002Fimplement-docs-adapter.md](adapters\u002Fimplement-docs-adapter.md) as the work adapter executed by Senior Engineer. Hub-flow dispatch uses `agents\u002FDoc-Keeper.agent.md` directly. This split-declaration state is documented in [Documents\u002FDesign\u002Fframe-architecture.md](..\u002F..\u002FDocuments\u002FDesign\u002Fframe-architecture.md); see footnote § (split-declaration #612).\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fdocumentation-finalization",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 documentation-finalization",{"tool":59,"command":60},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill documentation-finalization",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill documentation-finalization","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fdocumentation-finalization\u002FSKILL.md",true,[67,73,77],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"adapters\u002Fimplement-docs-adapter.md","REFERENCE","参考文档",3480,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fdocumentation-finalization\u002Fadapters\u002Fimplement-docs-adapter.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"adapters\u002Fimplement-docs-auto-na-adapter.md",306,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fdocumentation-finalization\u002Fadapters\u002Fimplement-docs-auto-na-adapter.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"adapters\u002Fimplement-docs-explicit-skip-adapter.md",331,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fdocumentation-finalization\u002Fadapters\u002Fimplement-docs-explicit-skip-adapter.md",[82,113,136,152,178,196],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":94,"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",[88,91],{"categoryNo":89,"categoryName":90,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":92,"categoryName":93,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[95,96,97,98,99,30,100,101,102,103,104,105,106,107,108,109,110,111,112,39],"testing","webapp testing","webapp","canvas","tdd","playwright","test","web","react","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"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",[],[120,121,122,123,124,125,126,32,127,33,128,129,108,130,131,132,133,39,134,135],"verification","verification before completion","review","change","commit","merge","pr","run","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"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":142,"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",[],[143,144,145,122,146,147,148,149,33,150,109,39,151],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":164,"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",[158,159],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[165,166,122,167,168,125,169,126,33,170,171,172,173,174,175,132,133,176,177,39],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":190,"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",[184,185,186,187],{"categoryNo":89,"categoryName":90,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":92,"categoryName":93,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":188,"categoryName":189,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000032","设计师",[95,191,192,193,28,194,98,30,100,101,103,104,105,106,107,195,110,111,39,97],"ui","ui testing","frontend","writing","testing patterns",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":204,"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",[202,203],{"categoryNo":92,"categoryName":93,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":188,"categoryName":189,"taxonomyType":162,"taxonomyTypeDesc":163},[191,205,193,28,122,30,206,33,207,208,209,210,211,132,212,213,39,214],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]