[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C48GPVE120TGPMD1CS365H":3,"skill-same:01M6C48GPVE120TGPMD1CS365H":86},{"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":33,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6C48GPVE120TGPMD1CS365H","ui-testing",null,"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).","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-testing\u002FSKILL.md",[17,22,25,28],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"ui testing","ui","testing","debugging","webapp","use","game","e2e","testing patterns","browser","development","component","react","test","playwright","workflow","canvas","writing","design","frontend","2026-11-10 10:12:30",false,"---\nname: ui-testing\ndescription: \"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).\"\n---\n\n# UI Testing Skill\n\nGuide for creating resilient, maintainable UI component tests.\n\n## When to Use\n\n- Writing tests for React components\n- Debugging flaky or brittle tests\n- Reviewing test code\n- Establishing testing patterns for a project\n- Refactoring tests after UI changes\n\n## Core Philosophy\n\n> \"Test behavior, not implementation.\"\n\nUsers don't care about internal state or DOM structure—they care about what they can see and do.\n\n## Testing Priorities (Confidence vs. Cost)\n\n```\nHigh Confidence, Low Cost → Prioritize\n├── User interactions (clicks, typing)\n├── Visible content changes\n├── Accessibility requirements\n└── Error states\n\nMedium Confidence, Medium Cost → Include\n├── Integration with data fetching\n├── Complex state transitions\n└── Edge cases\n\nLow Confidence, High Cost → Minimize\n├── Implementation details\n├── Internal state values\n└── CSS\u002Fstyling\n```\n\n## Selector Strategy (Priority Order)\n\n### 1. Accessible Queries (Preferred)\n\n```javascript\n\u002F\u002F Best: How users and assistive tech find elements\ngetByRole(\"button\", { name: \"Submit\" });\ngetByLabelText(\"Email address\");\ngetByPlaceholderText(\"Search...\");\ngetByText(\"Welcome back\");\ngetByAltText(\"User avatar\");\n```\n\n### 2. Semantic Queries (Acceptable)\n\n```javascript\n\u002F\u002F Good: Semantic HTML attributes\ngetByTitle(\"Close dialog\");\ngetByDisplayValue(\"current input value\");\n```\n\n### 3. Test IDs (Last Resort)\n\n```javascript\n\u002F\u002F Fallback: When no accessible option exists\ngetByTestId(\"complex-data-grid\");\n```\n\n### Never Use\n\n```javascript\n\u002F\u002F Fragile: Breaks on any refactor\ncontainer.querySelector(\".btn-primary\");\nwrapper.find(\"div > span:first-child\");\ngetByClassName(\"header-title\");\n```\n\n## Test Structure Pattern\n\n```javascript\ndescribe(\"ComponentName\", () => {\n  \u002F\u002F Group by user goal, not by method\n  describe(\"when user [does action]\", () => {\n    it(\"should [expected outcome visible to user]\", () => {\n      \u002F\u002F Arrange: Set up component state\n      render(\u003CComponent {...props} \u002F>);\n\n      \u002F\u002F Act: Simulate user behavior\n      await userEvent.click(getByRole(\"button\", { name: \"Submit\" }));\n\n      \u002F\u002F Assert: Check visible outcomes\n      expect(getByText(\"Success!\")).toBeInTheDocument();\n    });\n  });\n});\n```\n\n## Common Patterns\n\n### Testing User Input\n\n```javascript\nit(\"should update display when user types\", async () => {\n  render(\u003CSearchBox \u002F>);\n\n  const input = getByRole(\"searchbox\");\n  await userEvent.type(input, \"query\");\n\n  expect(input).toHaveValue(\"query\");\n});\n```\n\n### Testing Async Operations\n\n```javascript\nit(\"should show results after search\", async () => {\n  render(\u003CSearchResults \u002F>);\n\n  await userEvent.click(getByRole(\"button\", { name: \"Search\" }));\n\n  \u002F\u002F Wait for visible change, not implementation detail\n  expect(await findByText(\"3 results found\")).toBeInTheDocument();\n});\n```\n\n### Testing Accessibility\n\n```javascript\nit(\"should be accessible\", async () => {\n  const { container } = render(\u003CComponent \u002F>);\n\n  const results = await axe(container);\n  expect(results).toHaveNoViolations();\n});\n```\n\nSee [testing-patterns.md](.\u002Ftesting-patterns.md) for more detailed patterns.\n\n## Project Configuration\n\n[CUSTOMIZE] Add your project's testing setup:\n\n```javascript\n\u002F\u002F Test utilities location: [path]\n\u002F\u002F Custom render with providers: [path]\n\u002F\u002F Mock patterns: [path]\n\u002F\u002F Test data factories: [path]\n```\n\n## Debugging Flaky Tests\n\n1. **Identify the flake**: Run test in isolation 10+ times\n2. **Check async handling**: Are we waiting for the right thing?\n3. **Check test isolation**: Does order matter? Shared state?\n4. **Check timing**: Race conditions in component or test?\n5. **Add debugging**: `screen.debug()`, `logRoles(container)`\n\n## Gotchas\n\n| Trigger                                                                                                    | Gotcha                                                                                                      | Fix                                                                                            |\n| ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |\n| Asserting on `component.state` or internal refs directly                                                   | Breaks on internal refactoring even when user-visible behavior is unchanged                                 | Assert on rendered text, visible elements, or dispatched events — not internal component state |\n| Adding `expect(tree).toMatchSnapshot()` to every component test                                            | One-character internal change triggers cascading snapshot failures; reviewers approve noise without reading | Replace with targeted assertions on specific text, attributes, or DOM structure                |\n| Setting `waitFor` timeout > 1000ms to make a flaky test pass                                               | Masks real performance or async timing issues; adds hard delay to the entire suite                          | Diagnose why the element isn't ready sooner; fix the underlying async handling                 |\n| Writing assertions that validate a third-party library's own behavior (e.g., checking React Query fetched) | Tests validate the library, not your code; break on library version changes                                 | Trust the library; test your code's response to its outputs — not the library's own logic      |\n| Suppressing or ignoring `act()` warnings in the console                                                    | Async state update issues are hidden; test results become unreliable                                        | Fix the timing: wrap state updates in `act()` or switch from `fireEvent` to `userEvent`        |\n| Using `data-testid` when `getByRole` would work                                                            | Tests diverge from user accessibility model; role-based queries are more resilient                          | Follow locator priority: `getByRole` > `getByLabel` > `getByTestId` > CSS (last resort)        |\n| Asserting on internal library DOM nodes (e.g., react-select internals)                                     | Tests break on library upgrade, not on your code breaking                                                   | Trust the dependency; test what the user sees and can interact with                            |\n","# UI Testing Skill\n\nGuide for creating resilient, maintainable UI component tests.\n\n## When to Use\n\n- Writing tests for React components\n- Debugging flaky or brittle tests\n- Reviewing test code\n- Establishing testing patterns for a project\n- Refactoring tests after UI changes\n\n## Core Philosophy\n\n> \"Test behavior, not implementation.\"\n\nUsers don't care about internal state or DOM structure—they care about what they can see and do.\n\n## Testing Priorities (Confidence vs. Cost)\n\n```\nHigh Confidence, Low Cost → Prioritize\n├── User interactions (clicks, typing)\n├── Visible content changes\n├── Accessibility requirements\n└── Error states\n\nMedium Confidence, Medium Cost → Include\n├── Integration with data fetching\n├── Complex state transitions\n└── Edge cases\n\nLow Confidence, High Cost → Minimize\n├── Implementation details\n├── Internal state values\n└── CSS\u002Fstyling\n```\n\n## Selector Strategy (Priority Order)\n\n### 1. Accessible Queries (Preferred)\n\n```javascript\n\u002F\u002F Best: How users and assistive tech find elements\ngetByRole(\"button\", { name: \"Submit\" });\ngetByLabelText(\"Email address\");\ngetByPlaceholderText(\"Search...\");\ngetByText(\"Welcome back\");\ngetByAltText(\"User avatar\");\n```\n\n### 2. Semantic Queries (Acceptable)\n\n```javascript\n\u002F\u002F Good: Semantic HTML attributes\ngetByTitle(\"Close dialog\");\ngetByDisplayValue(\"current input value\");\n```\n\n### 3. Test IDs (Last Resort)\n\n```javascript\n\u002F\u002F Fallback: When no accessible option exists\ngetByTestId(\"complex-data-grid\");\n```\n\n### Never Use\n\n```javascript\n\u002F\u002F Fragile: Breaks on any refactor\ncontainer.querySelector(\".btn-primary\");\nwrapper.find(\"div > span:first-child\");\ngetByClassName(\"header-title\");\n```\n\n## Test Structure Pattern\n\n```javascript\ndescribe(\"ComponentName\", () => {\n  \u002F\u002F Group by user goal, not by method\n  describe(\"when user [does action]\", () => {\n    it(\"should [expected outcome visible to user]\", () => {\n      \u002F\u002F Arrange: Set up component state\n      render(\u003CComponent {...props} \u002F>);\n\n      \u002F\u002F Act: Simulate user behavior\n      await userEvent.click(getByRole(\"button\", { name: \"Submit\" }));\n\n      \u002F\u002F Assert: Check visible outcomes\n      expect(getByText(\"Success!\")).toBeInTheDocument();\n    });\n  });\n});\n```\n\n## Common Patterns\n\n### Testing User Input\n\n```javascript\nit(\"should update display when user types\", async () => {\n  render(\u003CSearchBox \u002F>);\n\n  const input = getByRole(\"searchbox\");\n  await userEvent.type(input, \"query\");\n\n  expect(input).toHaveValue(\"query\");\n});\n```\n\n### Testing Async Operations\n\n```javascript\nit(\"should show results after search\", async () => {\n  render(\u003CSearchResults \u002F>);\n\n  await userEvent.click(getByRole(\"button\", { name: \"Search\" }));\n\n  \u002F\u002F Wait for visible change, not implementation detail\n  expect(await findByText(\"3 results found\")).toBeInTheDocument();\n});\n```\n\n### Testing Accessibility\n\n```javascript\nit(\"should be accessible\", async () => {\n  const { container } = render(\u003CComponent \u002F>);\n\n  const results = await axe(container);\n  expect(results).toHaveNoViolations();\n});\n```\n\nSee [testing-patterns.md](.\u002Ftesting-patterns.md) for more detailed patterns.\n\n## Project Configuration\n\n[CUSTOMIZE] Add your project's testing setup:\n\n```javascript\n\u002F\u002F Test utilities location: [path]\n\u002F\u002F Custom render with providers: [path]\n\u002F\u002F Mock patterns: [path]\n\u002F\u002F Test data factories: [path]\n```\n\n## Debugging Flaky Tests\n\n1. **Identify the flake**: Run test in isolation 10+ times\n2. **Check async handling**: Are we waiting for the right thing?\n3. **Check test isolation**: Does order matter? Shared state?\n4. **Check timing**: Race conditions in component or test?\n5. **Add debugging**: `screen.debug()`, `logRoles(container)`\n\n## Gotchas\n\n| Trigger                                                                                                    | Gotcha                                                                                                      | Fix                                                                                            |\n| ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |\n| Asserting on `component.state` or internal refs directly                                                   | Breaks on internal refactoring even when user-visible behavior is unchanged                                 | Assert on rendered text, visible elements, or dispatched events — not internal component state |\n| Adding `expect(tree).toMatchSnapshot()` to every component test                                            | One-character internal change triggers cascading snapshot failures; reviewers approve noise without reading | Replace with targeted assertions on specific text, attributes, or DOM structure                |\n| Setting `waitFor` timeout > 1000ms to make a flaky test pass                                               | Masks real performance or async timing issues; adds hard delay to the entire suite                          | Diagnose why the element isn't ready sooner; fix the underlying async handling                 |\n| Writing assertions that validate a third-party library's own behavior (e.g., checking React Query fetched) | Tests validate the library, not your code; break on library version changes                                 | Trust the library; test your code's response to its outputs — not the library's own logic      |\n| Suppressing or ignoring `act()` warnings in the console                                                    | Async state update issues are hidden; test results become unreliable                                        | Fix the timing: wrap state updates in `act()` or switch from `fireEvent` to `userEvent`        |\n| Using `data-testid` when `getByRole` would work                                                            | Tests diverge from user accessibility model; role-based queries are more resilient                          | Follow locator priority: `getByRole` > `getByLabel` > `getByTestId` > CSS (last resort)        |\n| Asserting on internal library DOM nodes (e.g., react-select internals)                                     | Tests break on library upgrade, not on your code breaking                                                   | Trust the dependency; test what the user sees and can interact with                            |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fui-testing",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill ui-testing",{"tool":72,"command":73},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill ui-testing",{"tool":75,"command":76},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill ui-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",true,[80],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"testing-patterns.md","REFERENCE","参考文档",6950,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002Ftesting-patterns.md",[87,102,127,143,169,188],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":95,"publishedAt":54},"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",[93,94],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[36,96,38,50,97,49,48,47,98,46,45,37,44,43,99,100,41,40,101,39],"webapp testing","tdd","web","ci","execution","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":54},"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,111,112,113,114,115,116,117,118,119,120,99,121,122,123,124,39,125,126],"verification","verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":54},"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",[],[134,135,136,111,137,138,139,140,118,141,100,39,142],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":155,"publishedAt":54},"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",[149,152],{"categoryNo":150,"categoryName":151,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":153,"categoryName":154,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000038","人力资源",[156,157,111,158,159,114,160,115,118,161,162,163,164,165,166,123,124,167,168,39],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":177,"publishedAt":54},"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",[175,176],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},[35,178,53,52,111,49,179,118,180,181,182,183,184,123,185,186,39,187],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":54},"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",[],[195,196,197,198,199,200,201,202,203,168,39,204],"format","tracking","tracking format","handoff","memory","file","plan","coordination","Rules","plan authoring"]