[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C48B7PAY03MSRVKNZVYFT4":3,"skill-same:01M6C48B7PAY03MSRVKNZVYFT4":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},"01M6C48B7PAY03MSRVKNZVYFT4","tracking-format",null,"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.","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\u002Ftracking-format\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29],"format","tracking","tracking format","handoff","memory","file","plan","coordination","Rules","session","use","plan authoring","2026-11-10 10:12:30",false,"---\nname: tracking-format\ndescription: \"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.\"\n---\n\n# Tracking Format Instructions\n\n## Purpose\n\nThis document defines the standard YAML frontmatter format for tracking files stored in `.copilot-tracking\u002F`. These files help agents maintain context and state across work sessions.\n\n## Directory Structure\n\n```text\n.copilot-tracking\u002F\n├── research\u002F\n│   └── {date}-{topic}.md\n├── archived\u002F\n│   └── issue-001-feature-name.md\n└── calibration\u002F\n    └── review-data.json\n```\n\n- `calibration\u002F` — persistent per-finding calibration cache (populated by `write-calibration-entry.ps1` or `backfill-calibration.ps1`)\n  - `review-data.json` — JSON calibration data (schema: `{ calibration_version: 1, entries: [{ pr_number, created_at, findings[], summary }] }`)\n\n> **Note**: `.copilot-tracking\u002F` stores research notes, archived tracking files, and persistent calibration data. Plans are now stored in session memory at `\u002Fmemories\u002Fsession\u002Fplan-issue-{ID}.md`, not as local files.\n> **Survival**: `.copilot-tracking\u002F` artifacts are `within-worktree` state under `SMC-13`; they survive in the current checkout and machine, but are not durable cross-agent handoffs unless copied to GitHub issues or committed docs.\n\n## YAML Frontmatter Format\n\n> **Scope**: The following format applies to `.copilot-tracking\u002F` research and tracking files only — not to session memory plan files. For session memory plan YAML fields, see Issue-Planner Section 6 in `agents\u002FIssue-Planner.agent.md`.\n\nAll tracking files **MUST** include YAML frontmatter at the top of the file:\n\n```yaml\n---\nstatus: in-progress\npriority: p1\nissue_id: \"001\"\ntags: [feature, api, backend]\ncreated: 2025-12-09\nupdated: 2025-12-09\n---\n```\n\n## Field Definitions\n\n### Required Fields\n\n| Field      | Type   | Description                                     |\n| ---------- | ------ | ----------------------------------------------- |\n| `status`   | string | Current work status (see Status Values below)   |\n| `priority` | string | Work priority level (see Priority Levels below) |\n| `issue_id` | string | Reference to issue number or tracking ID        |\n| `created`  | date   | Creation date in YYYY-MM-DD format              |\n\n### Optional Fields\n\n| Field            | Type   | Description                                           |\n| ---------------- | ------ | ----------------------------------------------------- |\n| `tags`           | array  | Categorization tags (e.g., feature, bugfix, refactor) |\n| `updated`        | date   | Last update date in YYYY-MM-DD format                 |\n| `assigned_agent` | string | Current agent working on this item                    |\n| `blocked_by`     | string | Dependency or blocker reference                       |\n| `related_issues` | array  | Related issue IDs                                     |\n\n### Status Values\n\nUse one of these standardized status values:\n\n- **`pending`** - Work not yet started, awaiting resources or dependencies\n- **`in-progress`** - Actively being worked on\n- **`complete`** - Work finished and verified\n- **`blocked`** - Cannot proceed due to external dependency\n- **`on-hold`** - Paused by decision, may resume later\n\n### Priority Levels\n\nUse one of these standardized priority levels:\n\n- **`p1`** - Critical\u002FUrgent - Immediate attention required\n- **`p2`** - High - Important but not blocking\n- **`p3`** - Normal - Standard priority work\n- **`p4`** - Low - Nice-to-have, can be deferred\n\n#### GitHub Label Mapping\n\nWhen deriving priority from a GitHub issue label, use this mapping:\n\n| GitHub label       | Frontmatter value |\n| ------------------ | ----------------- |\n| `priority: high`   | `p1`              |\n| `priority: medium` | `p2`              |\n| `priority: low`    | `p3`              |\n| (unlabeled)        | `p2` (default)    |\n\n## File Naming Convention\n\nFormat: `issue-{ID}-{short-description}.md`\n\nExamples:\n\n- `issue-001-authentication-system.md`\n- `issue-042-fix-memory-leak.md`\n- `issue-123-refactor-database-layer.md`\n\n## Content Structure\n\nAfter the YAML frontmatter, include:\n\n1. **Summary** - Brief description of the work\n2. **Context** - Background information and decisions\n3. **Progress** - Current state and completed items\n4. **Next Steps** - What needs to happen next\n5. **Notes** - Any relevant observations or blockers\n\n## Example Tracking File\n\n```markdown\n---\nstatus: in-progress\npriority: p2\nissue_id: \"042\"\ntags: [bugfix, performance]\ncreated: 2025-12-09\nupdated: 2025-12-09\nassigned_agent: \"Code-Smith\"\n---\n\n# Issue #42: Optimize Query Performance\n\n## Summary\n\nDatabase queries in the reporting module are taking too long. Need to add indexes and optimize query structure.\n\n## Context\n\n- User reported 30+ second load times\n- Profiling identified N+1 query problem\n- Decision: Add composite index on frequently queried columns\n\n## Progress\n\n- [x] Profiled slow queries\n- [x] Identified missing indexes\n- [ ] Apply index migrations\n- [ ] Validate performance improvement\n\n## Next Steps\n\n1. Create migration for new indexes\n2. Test in staging environment\n3. Measure performance improvement\n4. Update documentation\n\n## Notes\n\n- Be careful with index size - monitor disk usage\n- Consider query caching as future enhancement\n```\n\n## Archiving Completed Work\n\nFor any tracking files (research notes, prompt output) in `.copilot-tracking\u002F` that reach `complete` status:\n\n1. Move the file to `.copilot-tracking\u002Farchived\u002F`\n2. Update `status` to `complete`\n3. Add `completed` date field\n4. Keep file for historical reference\n\nPlans saved to session memory (`\u002Fmemories\u002Fsession\u002Fplan-issue-{ID}.md`) do not need archiving — session memory is scoped to the conversation.\n\n## Cloud Agent Handoff Protocol\n\nThis section is retired as a plan\u002Fdesign\u002Fsession-memory handoff source of truth and delegated to the canonical contract at `skills\u002Fsession-memory-contract\u002FSKILL.md` (`SMC-01`, `SMC-03`, `SMC-08`, `SMC-13`); that delegation retires the old cloud handoff table here. Tracking-format only governs `.copilot-tracking\u002F` file frontmatter and local tracking-file structure.\n\nCode-Conductor\u002FD9 owns durable handoff persistence. Continue implementation stays same-session and session-memory-only, with no redundant GitHub issue comments. Stop, Pause, or resume later paths persist or append durable GitHub issue comments for `\u003C!-- plan-issue-{ID} -->` and `\u003C!-- design-issue-{ID} -->` when those artifacts are needed. When the session-memory plan carries `slice_comment_id` (authored under the split plan\u002Fframe-slices shape), a durable re-emit must preserve that sibling structure — do not inline frame-slice blocks back into the plan comment.\n\n`.copilot-tracking\u002F` files are local scaffolding for research notes, prompt output, archived tracking, and calibration artifacts in the same worktree. They are not suitable for durable cross-agent or cloud-agent handoffs where a new branch or fresh checkout is created. Use the session-memory contract for plan\u002Fdesign\u002Fsession-memory handoff rules, and use GitHub issues, GitHub comments, or committed docs when a handoff must be durable.\n\n## Customization\n\nThis format is a template. Projects may add custom fields as needed:\n\n- `test_coverage` - Percentage or status\n- `review_status` - Code review state\n- `deployment_target` - Environment information\n- `customer_impact` - Business impact notes\n\nMaintain consistency within your project's tracking files.\n\n## Gotchas\n\n| Trigger                     | Gotcha                                                                    | Fix                                                                                 |\n| --------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |\n| Writing a new tracking file | Session-memory plan rules get mixed into local `.copilot-tracking\u002F` files | Use this format only for local tracking files and keep plan state in session memory |\n","# Tracking Format Instructions\n\n## Purpose\n\nThis document defines the standard YAML frontmatter format for tracking files stored in `.copilot-tracking\u002F`. These files help agents maintain context and state across work sessions.\n\n## Directory Structure\n\n```text\n.copilot-tracking\u002F\n├── research\u002F\n│   └── {date}-{topic}.md\n├── archived\u002F\n│   └── issue-001-feature-name.md\n└── calibration\u002F\n    └── review-data.json\n```\n\n- `calibration\u002F` — persistent per-finding calibration cache (populated by `write-calibration-entry.ps1` or `backfill-calibration.ps1`)\n  - `review-data.json` — JSON calibration data (schema: `{ calibration_version: 1, entries: [{ pr_number, created_at, findings[], summary }] }`)\n\n> **Note**: `.copilot-tracking\u002F` stores research notes, archived tracking files, and persistent calibration data. Plans are now stored in session memory at `\u002Fmemories\u002Fsession\u002Fplan-issue-{ID}.md`, not as local files.\n> **Survival**: `.copilot-tracking\u002F` artifacts are `within-worktree` state under `SMC-13`; they survive in the current checkout and machine, but are not durable cross-agent handoffs unless copied to GitHub issues or committed docs.\n\n## YAML Frontmatter Format\n\n> **Scope**: The following format applies to `.copilot-tracking\u002F` research and tracking files only — not to session memory plan files. For session memory plan YAML fields, see Issue-Planner Section 6 in `agents\u002FIssue-Planner.agent.md`.\n\nAll tracking files **MUST** include YAML frontmatter at the top of the file:\n\n```yaml\n---\nstatus: in-progress\npriority: p1\nissue_id: \"001\"\ntags: [feature, api, backend]\ncreated: 2025-12-09\nupdated: 2025-12-09\n---\n```\n\n## Field Definitions\n\n### Required Fields\n\n| Field      | Type   | Description                                     |\n| ---------- | ------ | ----------------------------------------------- |\n| `status`   | string | Current work status (see Status Values below)   |\n| `priority` | string | Work priority level (see Priority Levels below) |\n| `issue_id` | string | Reference to issue number or tracking ID        |\n| `created`  | date   | Creation date in YYYY-MM-DD format              |\n\n### Optional Fields\n\n| Field            | Type   | Description                                           |\n| ---------------- | ------ | ----------------------------------------------------- |\n| `tags`           | array  | Categorization tags (e.g., feature, bugfix, refactor) |\n| `updated`        | date   | Last update date in YYYY-MM-DD format                 |\n| `assigned_agent` | string | Current agent working on this item                    |\n| `blocked_by`     | string | Dependency or blocker reference                       |\n| `related_issues` | array  | Related issue IDs                                     |\n\n### Status Values\n\nUse one of these standardized status values:\n\n- **`pending`** - Work not yet started, awaiting resources or dependencies\n- **`in-progress`** - Actively being worked on\n- **`complete`** - Work finished and verified\n- **`blocked`** - Cannot proceed due to external dependency\n- **`on-hold`** - Paused by decision, may resume later\n\n### Priority Levels\n\nUse one of these standardized priority levels:\n\n- **`p1`** - Critical\u002FUrgent - Immediate attention required\n- **`p2`** - High - Important but not blocking\n- **`p3`** - Normal - Standard priority work\n- **`p4`** - Low - Nice-to-have, can be deferred\n\n#### GitHub Label Mapping\n\nWhen deriving priority from a GitHub issue label, use this mapping:\n\n| GitHub label       | Frontmatter value |\n| ------------------ | ----------------- |\n| `priority: high`   | `p1`              |\n| `priority: medium` | `p2`              |\n| `priority: low`    | `p3`              |\n| (unlabeled)        | `p2` (default)    |\n\n## File Naming Convention\n\nFormat: `issue-{ID}-{short-description}.md`\n\nExamples:\n\n- `issue-001-authentication-system.md`\n- `issue-042-fix-memory-leak.md`\n- `issue-123-refactor-database-layer.md`\n\n## Content Structure\n\nAfter the YAML frontmatter, include:\n\n1. **Summary** - Brief description of the work\n2. **Context** - Background information and decisions\n3. **Progress** - Current state and completed items\n4. **Next Steps** - What needs to happen next\n5. **Notes** - Any relevant observations or blockers\n\n## Example Tracking File\n\n```markdown\n---\nstatus: in-progress\npriority: p2\nissue_id: \"042\"\ntags: [bugfix, performance]\ncreated: 2025-12-09\nupdated: 2025-12-09\nassigned_agent: \"Code-Smith\"\n---\n\n# Issue #42: Optimize Query Performance\n\n## Summary\n\nDatabase queries in the reporting module are taking too long. Need to add indexes and optimize query structure.\n\n## Context\n\n- User reported 30+ second load times\n- Profiling identified N+1 query problem\n- Decision: Add composite index on frequently queried columns\n\n## Progress\n\n- [x] Profiled slow queries\n- [x] Identified missing indexes\n- [ ] Apply index migrations\n- [ ] Validate performance improvement\n\n## Next Steps\n\n1. Create migration for new indexes\n2. Test in staging environment\n3. Measure performance improvement\n4. Update documentation\n\n## Notes\n\n- Be careful with index size - monitor disk usage\n- Consider query caching as future enhancement\n```\n\n## Archiving Completed Work\n\nFor any tracking files (research notes, prompt output) in `.copilot-tracking\u002F` that reach `complete` status:\n\n1. Move the file to `.copilot-tracking\u002Farchived\u002F`\n2. Update `status` to `complete`\n3. Add `completed` date field\n4. Keep file for historical reference\n\nPlans saved to session memory (`\u002Fmemories\u002Fsession\u002Fplan-issue-{ID}.md`) do not need archiving — session memory is scoped to the conversation.\n\n## Cloud Agent Handoff Protocol\n\nThis section is retired as a plan\u002Fdesign\u002Fsession-memory handoff source of truth and delegated to the canonical contract at `skills\u002Fsession-memory-contract\u002FSKILL.md` (`SMC-01`, `SMC-03`, `SMC-08`, `SMC-13`); that delegation retires the old cloud handoff table here. Tracking-format only governs `.copilot-tracking\u002F` file frontmatter and local tracking-file structure.\n\nCode-Conductor\u002FD9 owns durable handoff persistence. Continue implementation stays same-session and session-memory-only, with no redundant GitHub issue comments. Stop, Pause, or resume later paths persist or append durable GitHub issue comments for `\u003C!-- plan-issue-{ID} -->` and `\u003C!-- design-issue-{ID} -->` when those artifacts are needed. When the session-memory plan carries `slice_comment_id` (authored under the split plan\u002Fframe-slices shape), a durable re-emit must preserve that sibling structure — do not inline frame-slice blocks back into the plan comment.\n\n`.copilot-tracking\u002F` files are local scaffolding for research notes, prompt output, archived tracking, and calibration artifacts in the same worktree. They are not suitable for durable cross-agent or cloud-agent handoffs where a new branch or fresh checkout is created. Use the session-memory contract for plan\u002Fdesign\u002Fsession-memory handoff rules, and use GitHub issues, GitHub comments, or committed docs when a handoff must be durable.\n\n## Customization\n\nThis format is a template. Projects may add custom fields as needed:\n\n- `test_coverage` - Percentage or status\n- `review_status` - Code review state\n- `deployment_target` - Environment information\n- `customer_impact` - Business impact notes\n\nMaintain consistency within your project's tracking files.\n\n## Gotchas\n\n| Trigger                     | Gotcha                                                                    | Fix                                                                                 |\n| --------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |\n| Writing a new tracking file | Session-memory plan rules get mixed into local `.copilot-tracking\u002F` files | Use this format only for local tracking files and keep plan state in session memory |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Ftracking-format",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 tracking-format",{"tool":48,"command":49},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill tracking-format",{"tool":51,"command":52},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill tracking-format","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftracking-format\u002FSKILL.md",true,[],[57,91,116,132,159,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,27,28],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":173,"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",[165,166,167,170],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":69,"categoryName":70,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":168,"categoryName":169,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":171,"categoryName":172,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000032","设计师",[72,174,175,176,177,178,75,77,78,79,81,82,83,84,85,179,88,89,28,74],"ui","ui testing","frontend","design","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":171,"categoryName":172,"taxonomyType":144,"taxonomyTypeDesc":145},[174,189,176,177,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"]