[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C47P68YGKHMNWTFF0KTS1V":3,"skill-same:01M6C47P68YGKHMNWTFF0KTS1V":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":41,"install":42,"resources":55},"01M6C47P68YGKHMNWTFF0KTS1V","specification-authoring",null,"Structured authoring guidance for formal specification documents. Use when drafting machine-readable requirements, filling the repository specification template, or refining interfaces and acceptance criteria into a self-contained spec. DO NOT USE FOR: implementation planning (use plan-authoring) or broad design exploration (use brainstorming)","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\u002Fspecification-authoring\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29],"specification authoring","design","spec","documents","brainstorming","planning","acceptance","repository","plan","template","use","design exploration","2026-11-10 10:12:30",false,"---\n\nname: specification-authoring\ndescription: \"Structured authoring guidance for formal specification documents. Use when drafting machine-readable requirements, filling the repository specification template, or refining interfaces and acceptance criteria into a self-contained spec. DO NOT USE FOR: implementation planning (use plan-authoring) or broad design exploration (use brainstorming)\"\n---\n\n\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; outputs repository-local specification documents. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Specification Authoring\n\nReusable process for drafting precise, self-contained specification documents.\n\n## When to Use\n\n- When a formal specification document must be created or updated\n- When requirements, constraints, interfaces, and acceptance criteria need a machine-readable structure\n- When a specification must be complete enough for downstream implementation or review without hidden context\n- When examples and edge cases need to be captured in a durable spec format\n\n## Purpose\n\nProduce specifications that read as contracts, not notes. Every requirement should be explicit, scoped, and testable, with a structure that downstream humans and models can parse consistently.\n\n## Authoring Principles\n\n- Use precise, unambiguous language\n- Distinguish requirements, constraints, recommendations, and patterns explicitly\n- Prefer structured sections, tables, and numbered requirement IDs over narrative prose\n- Define acronyms, domain terms, and assumptions in the document itself\n- Include examples and edge cases when they materially reduce ambiguity\n- Keep the document self-contained unless an external reference is truly authoritative and unavoidable\n\n## Authoring Workflow\n\n1. Clarify the specification scope, audience, and primary purpose.\n2. Gather the constraints, interfaces, dependencies, and acceptance criteria that belong in the contract.\n3. Fill the full repository specification template in order.\n4. Convert vague statements into explicit requirements, constraints, or guidelines.\n5. Add concrete examples and edge cases where ambiguity would otherwise remain.\n6. Verify the document is internally consistent and does not depend on unstated context.\n\n## Required Template\n\n````md\n---\ntitle: [Concise Title Describing the Specification's Focus]\nversion: [Optional: e.g., 1.0, Date]\ndate_created: [YYYY-MM-DD]\nlast_updated: [Optional: YYYY-MM-DD]\nowner: [Optional: Team\u002FIndividual responsible for this spec]\ntags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]\n---\n\n# Introduction\n\n[A short concise introduction to the specification and the goal it is intended to achieve.]\n\n## 1. Purpose & Scope\n\n[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]\n\n## 2. Definitions\n\n[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]\n\n## 3. Requirements, Constraints & Guidelines\n\n[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]\n\n- **REQ-001**: Requirement 1\n- **SEC-001**: Security Requirement 1\n- **[3 LETTERS]-001**: Other Requirement 1\n- **CON-001**: Constraint 1\n- **GUD-001**: Guideline 1\n- **PAT-001**: Pattern to follow 1\n\n## 4. Interfaces & Data Contracts\n\n[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]\n\n## 5. Acceptance Criteria\n\n[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]\n\n- **AC-001**: Given [context], When [action], Then [expected outcome]\n- **AC-002**: The system shall [specific behavior] when [condition]\n- **AC-003**: [Additional acceptance criteria as needed]\n\n## 6. Test Automation Strategy\n\n[Define the testing approach, frameworks, and automation requirements.]\n\n- **Test Levels**: Unit, Integration, End-to-End\n- **Frameworks**: Project-approved test frameworks (see `.github\u002Fcopilot-instructions.md`)\n- **Test Data Management**: [approach for test data creation and cleanup]\n- **CI\u002FCD Integration**: [automated testing in GitHub Actions pipelines]\n- **Coverage Requirements**: [minimum code coverage thresholds]\n- **Performance Testing**: [approach for load and performance testing]\n\n## 7. Rationale & Context\n\n[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]\n\n## 8. Dependencies & External Integrations\n\n[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]\n\n### External Systems\n\n- **EXT-001**: [External system name] - [Purpose and integration type]\n\n### Third-Party Services\n\n- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]\n\n### Infrastructure Dependencies\n\n- **INF-001**: [Infrastructure component] - [Requirements and constraints]\n\n### Data Dependencies\n\n- **DAT-001**: [External data source] - [Format, frequency, and access requirements]\n\n### Technology Platform Dependencies\n\n- **PLT-001**: [Platform\u002Fruntime requirement] - [Version constraints and rationale]\n\n### Compliance Dependencies\n\n- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]\n\n**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify \"OAuth 2.0 authentication library\" rather than a framework-specific package name and version.\n\n## 9. Examples & Edge Cases\n\n```code\n\u002F\u002F Code snippet or data example demonstrating the correct application of the guidelines, including edge cases\n```\n\n## 10. Validation Criteria\n\n[List the criteria or tests that must be satisfied for compliance with this specification.]\n\n## 11. Related Specifications \u002F Further Reading\n\n[Link to related spec 1]\n[Link to relevant external documentation]\n````\n\n## Quality Checklist\n\n- Requirements use stable IDs and testable wording\n- Constraints and recommendations are not mixed together\n- Interfaces and dependencies describe the contract, not incidental implementation details\n- Acceptance criteria can be validated without guessing at intent\n- Definitions section covers every acronym and domain-specific term that could confuse a reader\n\n## Related Guidance\n\n- Load `software-architecture` when the specification defines architectural constraints or layer boundaries\n- Load project-specific skills when documenting domain rules or framework-specific constraints\n\n## Gotchas\n\n| Trigger                                 | Gotcha                                                        | Fix                                                        |\n| --------------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- |\n| Writing recommendations as requirements | The spec over-commits optional guidance as mandatory behavior | Label requirements, constraints, and guidelines separately |\n\n| Trigger                            | Gotcha                                                         | Fix                                                                  |\n| ---------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------- |\n| Depending on unstated repo context | Readers cannot implement or review the spec without side input | Expand definitions, assumptions, and interfaces until self-contained |\n","\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; outputs repository-local specification documents. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Specification Authoring\n\nReusable process for drafting precise, self-contained specification documents.\n\n## When to Use\n\n- When a formal specification document must be created or updated\n- When requirements, constraints, interfaces, and acceptance criteria need a machine-readable structure\n- When a specification must be complete enough for downstream implementation or review without hidden context\n- When examples and edge cases need to be captured in a durable spec format\n\n## Purpose\n\nProduce specifications that read as contracts, not notes. Every requirement should be explicit, scoped, and testable, with a structure that downstream humans and models can parse consistently.\n\n## Authoring Principles\n\n- Use precise, unambiguous language\n- Distinguish requirements, constraints, recommendations, and patterns explicitly\n- Prefer structured sections, tables, and numbered requirement IDs over narrative prose\n- Define acronyms, domain terms, and assumptions in the document itself\n- Include examples and edge cases when they materially reduce ambiguity\n- Keep the document self-contained unless an external reference is truly authoritative and unavoidable\n\n## Authoring Workflow\n\n1. Clarify the specification scope, audience, and primary purpose.\n2. Gather the constraints, interfaces, dependencies, and acceptance criteria that belong in the contract.\n3. Fill the full repository specification template in order.\n4. Convert vague statements into explicit requirements, constraints, or guidelines.\n5. Add concrete examples and edge cases where ambiguity would otherwise remain.\n6. Verify the document is internally consistent and does not depend on unstated context.\n\n## Required Template\n\n````md\n---\ntitle: [Concise Title Describing the Specification's Focus]\nversion: [Optional: e.g., 1.0, Date]\ndate_created: [YYYY-MM-DD]\nlast_updated: [Optional: YYYY-MM-DD]\nowner: [Optional: Team\u002FIndividual responsible for this spec]\ntags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]\n---\n\n# Introduction\n\n[A short concise introduction to the specification and the goal it is intended to achieve.]\n\n## 1. Purpose & Scope\n\n[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]\n\n## 2. Definitions\n\n[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]\n\n## 3. Requirements, Constraints & Guidelines\n\n[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]\n\n- **REQ-001**: Requirement 1\n- **SEC-001**: Security Requirement 1\n- **[3 LETTERS]-001**: Other Requirement 1\n- **CON-001**: Constraint 1\n- **GUD-001**: Guideline 1\n- **PAT-001**: Pattern to follow 1\n\n## 4. Interfaces & Data Contracts\n\n[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]\n\n## 5. Acceptance Criteria\n\n[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]\n\n- **AC-001**: Given [context], When [action], Then [expected outcome]\n- **AC-002**: The system shall [specific behavior] when [condition]\n- **AC-003**: [Additional acceptance criteria as needed]\n\n## 6. Test Automation Strategy\n\n[Define the testing approach, frameworks, and automation requirements.]\n\n- **Test Levels**: Unit, Integration, End-to-End\n- **Frameworks**: Project-approved test frameworks (see `.github\u002Fcopilot-instructions.md`)\n- **Test Data Management**: [approach for test data creation and cleanup]\n- **CI\u002FCD Integration**: [automated testing in GitHub Actions pipelines]\n- **Coverage Requirements**: [minimum code coverage thresholds]\n- **Performance Testing**: [approach for load and performance testing]\n\n## 7. Rationale & Context\n\n[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]\n\n## 8. Dependencies & External Integrations\n\n[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]\n\n### External Systems\n\n- **EXT-001**: [External system name] - [Purpose and integration type]\n\n### Third-Party Services\n\n- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]\n\n### Infrastructure Dependencies\n\n- **INF-001**: [Infrastructure component] - [Requirements and constraints]\n\n### Data Dependencies\n\n- **DAT-001**: [External data source] - [Format, frequency, and access requirements]\n\n### Technology Platform Dependencies\n\n- **PLT-001**: [Platform\u002Fruntime requirement] - [Version constraints and rationale]\n\n### Compliance Dependencies\n\n- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]\n\n**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify \"OAuth 2.0 authentication library\" rather than a framework-specific package name and version.\n\n## 9. Examples & Edge Cases\n\n```code\n\u002F\u002F Code snippet or data example demonstrating the correct application of the guidelines, including edge cases\n```\n\n## 10. Validation Criteria\n\n[List the criteria or tests that must be satisfied for compliance with this specification.]\n\n## 11. Related Specifications \u002F Further Reading\n\n[Link to related spec 1]\n[Link to relevant external documentation]\n````\n\n## Quality Checklist\n\n- Requirements use stable IDs and testable wording\n- Constraints and recommendations are not mixed together\n- Interfaces and dependencies describe the contract, not incidental implementation details\n- Acceptance criteria can be validated without guessing at intent\n- Definitions section covers every acronym and domain-specific term that could confuse a reader\n\n## Related Guidance\n\n- Load `software-architecture` when the specification defines architectural constraints or layer boundaries\n- Load project-specific skills when documenting domain rules or framework-specific constraints\n\n## Gotchas\n\n| Trigger                                 | Gotcha                                                        | Fix                                                        |\n| --------------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- |\n| Writing recommendations as requirements | The spec over-commits optional guidance as mandatory behavior | Label requirements, constraints, and guidelines separately |\n\n| Trigger                            | Gotcha                                                         | Fix                                                                  |\n| ---------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------- |\n| Depending on unstated repo context | Readers cannot implement or review the spec without side input | Expand definitions, assumptions, and interfaces until self-contained |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fspecification-authoring",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill specification-authoring",{"tool":48,"command":49},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill specification-authoring",{"tool":51,"command":52},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill specification-authoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fspecification-authoring\u002FSKILL.md",true,[],[57,91,116,132,160,180],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":71,"publishedAt":30},"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",[63,68],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":69,"categoryName":70,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000009","前端开发",[72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,28],"testing","webapp testing","webapp","canvas","tdd","workflow","playwright","test","web","react","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":30},"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",[],[98,99,100,101,102,103,104,105,106,107,108,109,86,110,111,112,113,28,114,115],"verification","verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":30},"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",[],[123,124,125,100,126,127,128,129,107,130,87,28,131],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":146,"publishedAt":30},"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",[138,141],{"categoryNo":139,"categoryName":140,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[147,148,100,149,150,103,151,104,107,152,153,154,155,156,157,112,113,158,159,28],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":174,"publishedAt":30},"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",[166,167,168,171],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":69,"categoryName":70,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":169,"categoryName":170,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":172,"categoryName":173,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000032","设计师",[72,175,176,177,19,178,75,77,78,79,81,82,83,84,85,179,88,89,28,74],"ui","ui testing","frontend","writing","testing patterns",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":188,"publishedAt":30},"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",[186,187],{"categoryNo":69,"categoryName":70,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":172,"categoryName":173,"taxonomyType":144,"taxonomyTypeDesc":145},[175,189,177,19,100,77,190,107,191,192,193,194,195,112,196,197,28,198],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]