Skill v1.0.0
currentTrusted Publisher100/100version: "1.0.0" name: capability-router description: > Start here for build and feature requests. Resolve the intended data source, select only the required Universal App capabilities, and hand the implementation to one owning skill per capability.
Capability Router
The base workspace contains dynamic authentication, theming, an error boundary, an authenticated welcome view, and three packages: frontend, data, and shared. It has no live data source, persistence, charting, or trusted server-side logic until a capability pack adds it.
Decide the source first
Preserve what the user asked to use. Do not select a pack from words such as "dashboard" or "workflow" alone.
| User intent or evidence | Decision | |
|---|---|---|
| A named semantic model, dataset, or report matches one verified source | Use that source with analytics | |
| A supplied Fabric or Power BI URL or explicit IDs | Extract the workspace and item IDs, verify them, and use them | |
| Several sources could match | Ask the user to select the intended source | |
| A named source cannot be found | Ask which source they meant; do not substitute sample data or another model | |
| No source is named | Search a relevant catalog when available, then ask a focused source-or-sample question if still unresolved | |
| The user requested sample data or a mock-up | Use visuals and label the sample data visibly | |
| The user supplied a static file for bundling | Review it and emit typed rows; do not imply that the file is a live source |
Never fabricate identifiers, schemas, query output, or business values. Do not ask the user to describe a discoverable schema. Use the installed tools and version-matched docs to inspect it.
A declared semantic-model app needs its intended model. Sample data is a separate, user-confirmed route, not a fallback for a missing model.
Select the capabilities
| Need | Pack command | Seed or implementation anchor | Owning skill | |
|---|---|---|---|---|
| Read an existing Power BI semantic model | npm run pack:add -- connectors, then npm run pack:add -- analytics | packages/frontend/src/lib/connectors.ts, packages/frontend/src/hooks/use-semantic-model-query.ts, packages/frontend/src/queries/ | `analytics` | |
| Chart semantic-model results | npm run pack:add -- visuals after analytics | frontend visuals kit and typed visual specifications | `visuals` | |
| Chart sample data or app-owned records | npm run pack:add -- visuals | frontend visuals kit and typed visual specifications | `visuals` | |
| Create and own records | npm run pack:add -- data-modeling | packages/data/src/Item.ts, packages/data/src/index.ts, packages/shared/src/index.ts | `data-modeling` | |
| Read an existing warehouse, SQL database, or Lakehouse SQL endpoint | npm run pack:add -- connectors | rayfin/rayfin.yml, rayfin/connectors/<alias>/ | `connectors` | |
| Call an external API, webhook, or custom model endpoint | npm run pack:add -- functions | packages/functions/src/function_app.ts | `functions-capability` | |
| Use a secret or trusted operation | npm run pack:add -- functions | packages/functions/src/function_app.ts | `functions-capability` | |
| Call a published Fabric data agent | npm run pack:add -- functions | packages/functions/src/function_app.ts | `functions-capability` | |
| Bundle a supplied CSV or spreadsheet | no pack | a typed module in the owning workspace package | this skill | |
| Use Kusto or KQL | unavailable in this release | none | `connectors` |
Capabilities compose. An app that stores records, reads a semantic model, charts results, and calls a trusted API needs four separate pack invocations. The current scaffolder accepts one pack per invocation. Run pack commands serially because they mutate workspace manifests, root scripts, and service configuration.
Use data-modeling for records the app owns. Use connectors for records that already exist in a supported Fabric source. Use visuals for rendering, regardless of whether rows come from sample data, Rayfin data, or analytics. Use functions only for trusted code, secrets, app identity connections, or server-side calls.
Kusto and KQL are not supported in this release. Say so and stop rather than swapping in another source.
Optional consolidated install
When several packs are selected, you may avoid a separate install after each pack without inventing a multi-pack command:
- Run each selected
npm run pack:add -- <name> --no-installcommand
serially.
- Inspect every result for preserved files and stop if any pack reports one.
- After all packs apply cleanly, run one install from the workspace root:
npm install --ignore-scripts --no-audit --no-fund
This is a manual authoring optimization, not durable pack caching. The consolidated install does not write the per-pack success markers, so a later ordinary pack reapply may install again.
Preserve workspace ownership
Run pack and lifecycle commands from the workspace root. The pack manifest selects the package manifest that owns its dependencies:
- Frontend and connector dependencies belong in
packages/frontend/package.json. - Decorated entities belong in
packages/data, while browser-safe record contracts belong inpackages/shared. - The functions pack creates
packages/functionsand composes it into the root build and typecheck scripts.
Do not create nested lockfiles or install dependencies separately inside workspace packages. Do not import decorated entity classes into frontend code.
Apply and hand off
Apply selected packs before editing files they seed. If a pack preserves an existing file, report it and stop instead of assuming the pack's contract is installed. Use --force-seeds only with explicit user approval.
After routing:
- Read the owning skill for each selected capability.
- Read the relevant seed files and exact installed package documentation in parallel where independent.
- Establish a runnable shell in
packages/frontendwith honest loading states, preserving protected hosting and the dynamic auth gate. - Verify real query or operation output before writing code that consumes its fields.
- Integrate data, interactions, and polish, then follow
AGENTS.mdfor final validation and deployment.
Substantial independent discovery or implementation may be delegated behind a clear interface. Do not fan out a tiny app or tightly coupled flow merely because parallel agents are available.