[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699WHXMZ4X2FWD80XTXWWNE":3,"skill-same:01M699WHXMZ4X2FWD80XTXWWNE":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M699WHXMZ4X2FWD80XTXWWNE","react-clean-architecture",null,"Architectural principles for scalable, maintainable React applications. Use when designing component hierarchies, organizing directories, choosing state management patterns, decomposing large components, applying composition patterns (slots, compound components), enforcing colocation, creating custom hooks, setting up Feature-Sliced Design layers, reviewing component structure, or refactoring React code for cleanliness. Covers SRP, the 200-line rule, prop drilling avoidance, server state with TanStack Query, naming conventions (handle\u002Fon), and strict TypeScript governance.","microsoft\u002Frayfin","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699VK9NEV8GH0Y5JKT1G8XG",655,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freact-clean-architecture\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38],"react","architecture","react clean architecture","design","typescript","components","component","2026-11-10 10:12:30",false,"---\nname: react-clean-architecture\ndescription: 'Architectural principles for scalable, maintainable React applications. Use when designing component hierarchies, organizing directories, choosing state management patterns, decomposing large components, applying composition patterns (slots, compound components), enforcing colocation, creating custom hooks, setting up Feature-Sliced Design layers, reviewing component structure, or refactoring React code for cleanliness. Covers SRP, the 200-line rule, prop drilling avoidance, server state with TanStack Query, naming conventions (handle\u002Fon), and strict TypeScript governance.'\n---\n\n# React Clean Architecture\n\nPrinciples and rules for building scalable, maintainable React codebases in enterprise systems.\n\n**Full reference**: See [references\u002Farchitecture-guidelines.md](.\u002Freferences\u002Farchitecture-guidelines.md)\n\n## When to Use\n\n- Designing or reviewing component hierarchies\n- Organizing directories for a new feature or page\n- Decomposing a large component (the 200-line rule)\n- Choosing between local, global, and server state\n- Applying composition patterns (slots, compound components, children)\n- Creating custom hooks to extract logic from components\n- Enforcing colocation and Feature-Sliced Design boundaries\n- Reviewing naming conventions and import strategies\n- Setting up testing strategy for React features\n\n## Constitutional Rules\n\nThese 15 rules are non-negotiable in large-scale React projects.\n\n### 1. Domain-Driven Colocation\n\nKeep all code specific to a page or feature (components, hooks, tests, styles) in that page's folder.\nOnly promote code to global\u002Fshared folders when it is used by **three or more** distinct domains.\n\n### 2. Strict Layered Dependencies\n\nFollow the FSD hierarchy: `App > Pages > Widgets > Features > Entities > Shared`.\nA module may only import from a **lower** layer. Never allow upward or circular imports.\n\n### 3. Public API Encapsulation\n\nEach folder must expose a public API via an `index.ts` file.\nExternal modules must only import from this file, never from the folder's internal files.\n\n### 4. Single Responsibility Hooks\n\nExtract all stateful logic and side effects from components into custom hooks.\nA component's primary job is to map data to JSX; the hook's job is to manage the data.\n\n### 5. The 200-Line Threshold\n\nComponents exceeding 200 lines are architectural failures.\nDecompose them into smaller sub-components or extract logic to hooks immediately.\n\n### 6. Composition Over Prop Drilling\n\nUse the `children` prop and named slots for layouts.\nIf you find yourself passing a prop through more than two levels, use composition or a dedicated context.\n\n### 7. Absolute Import Aliases\n\nBan deep relative paths. Use `@\u002F` aliases (e.g., `@\u002Ffeatures\u002Fauth`) to ensure imports are location-independent and easy to refactor.\n\n### 8. Strict Type Governance\n\nUse TypeScript in strict mode. Ban `any`. Use `unknown` for external data and validate it at the boundary using Zod or equivalent runtime checkers.\n\n### 9. Unified Server State\n\nUse TanStack Query for all remote data. Implement a **Query Key Factory** to prevent hardcoded strings and ensure consistent cache invalidation.\n\n### 10. Handler vs Prop Naming\n\nPrefix internal event functions with `handle` (e.g., `handleReset`).\nPrefix external event props with `on` (e.g., `onReset`).\n\n### 11. Reference Stability\n\nMemoize callbacks and values (`useCallback`, `useMemo`) only when they are dependencies for other hooks or props for memoized components to prevent render cascades.\n\n### 12. Kebab-Case File Standards\n\nUse kebab-case for all files and directories (e.g., `user-profile.tsx`).\nThis ensures cross-platform compatibility and avoids case-sensitivity bugs.\n\n### 13. Semantic HTML and A11y\n\nPrioritize semantic tags (`button`, `nav`, `section`) over generic `div` tags.\nUse automated accessibility linters to enforce ARIA standards in every PR.\n\n### 14. Behavior-Driven Testing\n\nWrite integration tests that mimic user interactions using React Testing Library.\nDo not test internal component state or private methods.\n\n### 15. Proactive State Colocation\n\nKeep state as low as possible. Do not \"lift state up\" to a global provider if only a small sub-tree needs it.\nUse \"Push State Down\" to minimize re-render impacts.\n\n## Quick Decision Tables\n\n### Component Health Check\n\n| Attribute | Clean | Anti-Pattern |\n|-----------|-------|--------------|\n| Length | \u003C 200 lines | 500+ lines (\"God Component\") |\n| Logic | Extracted into custom hooks | Inline `useEffect`\u002F`useState` storms |\n| Props | Specific, typed, minimal | Large untyped objects, prop drilling |\n| Rendering | Declarative, focused | Nested ternaries, inline mapping chains |\n| Styling | Colocated CSS modules or utility classes | Massive global stylesheets or inline styles |\n\n### State Type Selection\n\n| State Type | Tool | Purpose |\n|------------|------|---------|\n| Local | `useState`, `useReducer` | UI toggles, input values |\n| Server | TanStack Query, SWR | Caching and fetching remote data |\n| Global UI | Zustand, Redux Toolkit | App-wide flags (sidebars, themes, modals) |\n| Persistent | LocalStorage + custom hook | User preferences, auth tokens |\n\n### Testing Pyramid\n\n| Level | Frequency | Tool | Target |\n|-------|-----------|------|--------|\n| Unit | High | Vitest\u002FJest | Utilities, hooks, reducers |\n| Integration | Medium | React Testing Library | Feature modules, pages |\n| E2E | Low | Cypress\u002FPlaywright | Critical user journeys |\n\n## Procedures\n\n### Decomposing a Large Component\n\n1. Identify concerns: data fetching, event handling, rendering sections\n2. Extract stateful logic into a `useFeatureName` custom hook\n3. Split rendering into sub-components (each \u003C 200 lines)\n4. Connect via props or composition (children\u002Fslots)\n5. Create `index.ts` barrel exporting only the public API\n\n### Organizing a New Feature Directory\n\n```\nfeature-name\u002F\n├── index.ts              # Public API (barrel)\n├── feature-name.tsx      # Main component\n├── feature-name.test.tsx # Integration test\n├── components\u002F           # Sub-components\n├── hooks\u002F                # Custom hooks\n├── types\u002F                # TypeScript types\n├── utils\u002F                # Pure helper functions\n└── constants.ts          # Feature-specific constants\n```\n\n### Promoting Shared Code\n\n1. Code starts **local** to its feature\u002Fpage\n2. When a second consumer appears, consider if duplication is acceptable\n3. When **three or more** consumers exist, promote to `shared\u002F` or `entities\u002F`\n4. Update the barrel `index.ts` in the target directory\n5. Update all imports to use the new shared path\n\n### Applying Composition Patterns\n\n**Slots pattern** — when a layout needs pluggable sections:\n\n```tsx\nfunction Layout({ header, sidebar, content }: LayoutProps) {\n  return (\n    \u003Cdiv>\n      \u003Cheader>{header}\u003C\u002Fheader>\n      \u003Caside>{sidebar}\u003C\u002Faside>\n      \u003Cmain>{content}\u003C\u002Fmain>\n    \u003C\u002Fdiv>\n  );\n}\n```\n\n**Compound components** — when sub-components share implicit state:\n\n```tsx\n\u003CTabs>\n  \u003CTabs.List>\n    \u003CTabs.Trigger value=\"a\">Tab A\u003C\u002FTabs.Trigger>\n  \u003C\u002FTabs.List>\n  \u003CTabs.Content value=\"a\">Content A\u003C\u002FTabs.Content>\n\u003C\u002FTabs>\n```\n","# React Clean Architecture\n\nPrinciples and rules for building scalable, maintainable React codebases in enterprise systems.\n\n**Full reference**: See [references\u002Farchitecture-guidelines.md](.\u002Freferences\u002Farchitecture-guidelines.md)\n\n## When to Use\n\n- Designing or reviewing component hierarchies\n- Organizing directories for a new feature or page\n- Decomposing a large component (the 200-line rule)\n- Choosing between local, global, and server state\n- Applying composition patterns (slots, compound components, children)\n- Creating custom hooks to extract logic from components\n- Enforcing colocation and Feature-Sliced Design boundaries\n- Reviewing naming conventions and import strategies\n- Setting up testing strategy for React features\n\n## Constitutional Rules\n\nThese 15 rules are non-negotiable in large-scale React projects.\n\n### 1. Domain-Driven Colocation\n\nKeep all code specific to a page or feature (components, hooks, tests, styles) in that page's folder.\nOnly promote code to global\u002Fshared folders when it is used by **three or more** distinct domains.\n\n### 2. Strict Layered Dependencies\n\nFollow the FSD hierarchy: `App > Pages > Widgets > Features > Entities > Shared`.\nA module may only import from a **lower** layer. Never allow upward or circular imports.\n\n### 3. Public API Encapsulation\n\nEach folder must expose a public API via an `index.ts` file.\nExternal modules must only import from this file, never from the folder's internal files.\n\n### 4. Single Responsibility Hooks\n\nExtract all stateful logic and side effects from components into custom hooks.\nA component's primary job is to map data to JSX; the hook's job is to manage the data.\n\n### 5. The 200-Line Threshold\n\nComponents exceeding 200 lines are architectural failures.\nDecompose them into smaller sub-components or extract logic to hooks immediately.\n\n### 6. Composition Over Prop Drilling\n\nUse the `children` prop and named slots for layouts.\nIf you find yourself passing a prop through more than two levels, use composition or a dedicated context.\n\n### 7. Absolute Import Aliases\n\nBan deep relative paths. Use `@\u002F` aliases (e.g., `@\u002Ffeatures\u002Fauth`) to ensure imports are location-independent and easy to refactor.\n\n### 8. Strict Type Governance\n\nUse TypeScript in strict mode. Ban `any`. Use `unknown` for external data and validate it at the boundary using Zod or equivalent runtime checkers.\n\n### 9. Unified Server State\n\nUse TanStack Query for all remote data. Implement a **Query Key Factory** to prevent hardcoded strings and ensure consistent cache invalidation.\n\n### 10. Handler vs Prop Naming\n\nPrefix internal event functions with `handle` (e.g., `handleReset`).\nPrefix external event props with `on` (e.g., `onReset`).\n\n### 11. Reference Stability\n\nMemoize callbacks and values (`useCallback`, `useMemo`) only when they are dependencies for other hooks or props for memoized components to prevent render cascades.\n\n### 12. Kebab-Case File Standards\n\nUse kebab-case for all files and directories (e.g., `user-profile.tsx`).\nThis ensures cross-platform compatibility and avoids case-sensitivity bugs.\n\n### 13. Semantic HTML and A11y\n\nPrioritize semantic tags (`button`, `nav`, `section`) over generic `div` tags.\nUse automated accessibility linters to enforce ARIA standards in every PR.\n\n### 14. Behavior-Driven Testing\n\nWrite integration tests that mimic user interactions using React Testing Library.\nDo not test internal component state or private methods.\n\n### 15. Proactive State Colocation\n\nKeep state as low as possible. Do not \"lift state up\" to a global provider if only a small sub-tree needs it.\nUse \"Push State Down\" to minimize re-render impacts.\n\n## Quick Decision Tables\n\n### Component Health Check\n\n| Attribute | Clean | Anti-Pattern |\n|-----------|-------|--------------|\n| Length | \u003C 200 lines | 500+ lines (\"God Component\") |\n| Logic | Extracted into custom hooks | Inline `useEffect`\u002F`useState` storms |\n| Props | Specific, typed, minimal | Large untyped objects, prop drilling |\n| Rendering | Declarative, focused | Nested ternaries, inline mapping chains |\n| Styling | Colocated CSS modules or utility classes | Massive global stylesheets or inline styles |\n\n### State Type Selection\n\n| State Type | Tool | Purpose |\n|------------|------|---------|\n| Local | `useState`, `useReducer` | UI toggles, input values |\n| Server | TanStack Query, SWR | Caching and fetching remote data |\n| Global UI | Zustand, Redux Toolkit | App-wide flags (sidebars, themes, modals) |\n| Persistent | LocalStorage + custom hook | User preferences, auth tokens |\n\n### Testing Pyramid\n\n| Level | Frequency | Tool | Target |\n|-------|-----------|------|--------|\n| Unit | High | Vitest\u002FJest | Utilities, hooks, reducers |\n| Integration | Medium | React Testing Library | Feature modules, pages |\n| E2E | Low | Cypress\u002FPlaywright | Critical user journeys |\n\n## Procedures\n\n### Decomposing a Large Component\n\n1. Identify concerns: data fetching, event handling, rendering sections\n2. Extract stateful logic into a `useFeatureName` custom hook\n3. Split rendering into sub-components (each \u003C 200 lines)\n4. Connect via props or composition (children\u002Fslots)\n5. Create `index.ts` barrel exporting only the public API\n\n### Organizing a New Feature Directory\n\n```\nfeature-name\u002F\n├── index.ts              # Public API (barrel)\n├── feature-name.tsx      # Main component\n├── feature-name.test.tsx # Integration test\n├── components\u002F           # Sub-components\n├── hooks\u002F                # Custom hooks\n├── types\u002F                # TypeScript types\n├── utils\u002F                # Pure helper functions\n└── constants.ts          # Feature-specific constants\n```\n\n### Promoting Shared Code\n\n1. Code starts **local** to its feature\u002Fpage\n2. When a second consumer appears, consider if duplication is acceptable\n3. When **three or more** consumers exist, promote to `shared\u002F` or `entities\u002F`\n4. Update the barrel `index.ts` in the target directory\n5. Update all imports to use the new shared path\n\n### Applying Composition Patterns\n\n**Slots pattern** — when a layout needs pluggable sections:\n\n```tsx\nfunction Layout({ header, sidebar, content }: LayoutProps) {\n  return (\n    \u003Cdiv>\n      \u003Cheader>{header}\u003C\u002Fheader>\n      \u003Caside>{sidebar}\u003C\u002Faside>\n      \u003Cmain>{content}\u003C\u002Fmain>\n    \u003C\u002Fdiv>\n  );\n}\n```\n\n**Compound components** — when sub-components share implicit state:\n\n```tsx\n\u003CTabs>\n  \u003CTabs.List>\n    \u003CTabs.Trigger value=\"a\">Tab A\u003C\u002FTabs.Trigger>\n  \u003C\u002FTabs.List>\n  \u003CTabs.Content value=\"a\">Content A\u003C\u002FTabs.Content>\n\u003C\u002FTabs>\n```\n",{"name":5,"description":7},"main","0979439a7a0806abd0ee48c2619b37f297ae1324",".github\u002Fskills\u002Freact-clean-architecture",73,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-30 15:20:57",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add microsoft\u002Frayfin --skill react-clean-architecture",{"tool":59,"command":60},"bunx","bunx skills add microsoft\u002Frayfin --skill react-clean-architecture",{"tool":62,"command":63},"pnpm","pnpm dlx skills add microsoft\u002Frayfin --skill react-clean-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freact-clean-architecture\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Farchitecture-guidelines.md","REFERENCE","参考文档",11644,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freact-clean-architecture\u002Freferences\u002Farchitecture-guidelines.md",[74,87,102,111,128,136],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":39},"01M699YEY2QDVPKTZS3HR9AX84","rayfin-getting-started","Use when starting or creating a NEW Rayfin app, or when a Rayfin task comes up and you are not yet inside a Rayfin project. Gets you into a project with the Rayfin CLI, then hands off to the authoritative, version-locked in-project rayfin skill\u002Fdocs that own all in-project work. Triggers: build a Rayfin app, start a Rayfin project, create a new Rayfin app, create-rayfin, npm create @microsoft\u002Frayfin, rayfin init, scaffold rayfin, rayfin CLI, rayfin template, universal app, awesome-rayfin gallery, get started with Rayfin","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002Fskills\u002Frayfin-getting-started\u002FSKILL.md",[],[81,82,83,84,9,85,86],"rayfin getting started","rayfin","scaffold","init","docs","cli",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":99,"publishedAt":39},"01M699YCN4ZDW2AMDP4NVJ2QGC","visuals","Use when user wants to incorporate charts, graphs, data grid,  or other visual representations of data into their project. Use VegaVisual and DataGrid components to create these visuals,  utilizing the shared DataTable input, formatting, theme, and interactivity. Covers the onInteraction selection\u002Fclick events host apps consume, named multi-table data input for layered overlays and reference lines, and Vega-Lite native selections. Triggers: chart, graph, plot, dashboard, KPI, metric, trend, scorecard, data grid, visualize.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002Fsamples\u002Funiversal-app\u002Ftemplate\u002F.agents\u002Fskills\u002Fvisuals\u002FSKILL.md",[93,96],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":97,"categoryName":98,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师",[89,37,100,101],"dashboard","visualize",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":39},"01M699YBEP146MJZJNN8YEBZ2G","schema-discovery","Explore Power BI semantic model schemas using DAX INFO functions. Progressive metadata discovery strategy, scope estimation, and narrowing techniques for tables, columns, measures, and relationships.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002Fsamples\u002Funiversal-app\u002Ftemplate\u002F.agents\u002Fskills\u002Fschema-discovery\u002FSKILL.md",[],[109,110],"schema discovery","dax",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":126,"publishedAt":39},"01M699Y9E80WYFKD1S4MT4B1CS","query-design","Separates DAX data-fetching from TypeScript presentation. Guides when to use  DAX vs. TypeScript vs. Vega-Lite for aggregation, total rows, FORMAT(), SELECTCOLUMNS,  BLANK handling, filtering, multi-grain queries, cross-filtering and cross-highlight subset\u002Foverlay queries, and format strings.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002Fsamples\u002Funiversal-app\u002Ftemplate\u002F.agents\u002Fskills\u002Fquery-design\u002FSKILL.md",[117,120,123],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":124,"categoryName":125,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",[127,35,110,36],"query design",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":39},"01M699Y7CKZ55QSYFE827RRVJE","functions-capability","Apply and build the Universal App functions capability. Use for trusted server-side logic, secrets, external APIs, custom model endpoints, published Fabric data agents, webhooks, or privileged operations.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002Fsamples\u002Funiversal-app\u002Ftemplate\u002F.agents\u002Fskills\u002Ffunctions-capability\u002FSKILL.md",[],[135],"functions capability",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":39},"01M699Y5R87YE620T78Z30KQSA","fabric-sdk","How to query Fabric data from a running app through the Rayfin connectors client. Use getRayfinClient().connectors.\u003Cname>.executeQuery to run DAX against a semantic model, and toQueryResult to normalize the response.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frayfin\u002Fblob\u002Fmain\u002Fsamples\u002Funiversal-app\u002Ftemplate\u002F.agents\u002Fskills\u002Ffabric-sdk\u002FSKILL.md",[],[143,144,110,145,82,146],"sdk","fabric sdk","rayfin connectors","connectors"]