Skip to main content Startseite Ersteller equinor fusion-web-components fusion-developer-app
fusion-developer-app Guides feature development in Fusion Framework React apps, including app-scoped framework research needed to choose the right hooks, modules, packages, and integration patterns before implementation. USE FOR: building new features, adding components or pages, creating hooks and services, wiring up API endpoints, extending Fusion module configuration, and answering app implementation questions about which Fusion Framework surface to use. DO NOT USE FOR: issue authoring, skill authoring, CI/CD configuration, backend service changes, or general Fusion documentation that is not tied to app implementation.
Zur Installation springen Skills Marktplatz Entdecken und erkunden Sie KI-Skills, die von der Community erstellt wurden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Prompt kopierenPrompt-Details anzeigen Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
npx skills add https://github.com/equinor/fusion-web-components --skill fusion-developer-appDer Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
ZIP herunterladen Herunterladen... Mehr aus diesem Repository
Use Fusion DevTools CLI (fdev) for API testing, token acquisition, service discovery, and person lookup during development. USE FOR: calling Fusion REST APIs, getting access tokens as JSON, discovering services and environments, resolving persons, PIM role activation. DO NOT USE FOR: modifying backend service code, deploying services, infrastructure changes, CI/CD pipeline configuration, or Service Bus operations.
Verwandte Berufe SOC
Basierend auf der SOC-Berufsklassifikation
name fusion-developer-app description Guides feature development in Fusion Framework React apps, including app-scoped framework research needed to choose the right hooks, modules, packages, and integration patterns before implementation. USE FOR: building new features, adding components or pages, creating hooks and services, wiring up API endpoints, extending Fusion module configuration, and answering app implementation questions about which Fusion Framework surface to use. DO NOT USE FOR: issue authoring, skill authoring, CI/CD configuration, backend service changes, or general Fusion documentation that is not tied to app implementation. license MIT compatibility Requires a Fusion Framework React app bootstrapped with @equinor/fusion-framework-cli. Works best when styled-components, @equinor/eds-core-react, and @equinor/fusion-react-* packages are installed. metadata {"version":"0.3.0","status":"active","owner":"@equinor/fusion-core","skills":["fusion-research","fusion-code-conventions"],"tags":["fusion-framework","react","eds","fusion-react-components","styled-components","app-development","charts","ag-charts","feature-flag"],"mcp":{"suggested":["fusion"]}}
Fusion App Development
When to use
Use this skill when developing features, components, hooks, services, or types for a Fusion Framework React application.
Typical triggers:
"Add a component / hook / service / page for ..."
"Wire up the API"
"Configure a Fusion module"
"Which Fusion Framework hook / package should this app use?"
"Persist this preference as an app setting"
"Add bookmark / analytics / feature flag support"
"Add a chart / people picker / person column to AG Grid"
"How do I write a custom Fusion Framework module?"
"Should this be a Fusion module or a React context?"
Building in src/
References Fusion Framework modules, EDS, @equinor/fusion-react-*, or styled-components
References app settings, bookmarks, analytics, app.config.ts
Adding route, page, or data-fetching layer
References charting: @equinor/fusion-framework-react-ag-charts, chart.js, react-chartjs-2
When not to use Do not use this skill for:
Issue authoring/triage → fusion-issue-authoring
Skill authoring → fusion-skill-authoring
Backend/service changes (separate repo)
CI/CD or deployment config
Architecture docs (use ADR template)
For Fusion Framework package ownership, hook behavior, or example discovery → use fusion-research first.
Required inputs
Mandatory
What to build: feature, component, hook, or service description
Where it fits: layer (component, hook, service, type) and parent/sibling context
For ambiguous requests, consult assets/follow-up-questions.md before implementing.
Conditional
API endpoint details when the feature involves data fetching
Design/layout specifics when building visual components
Fusion module name when extending module configuration
Whether state should persist per-user, be shareable via bookmark, or stay runtime-only
Instructions
Step 1 — Discover project conventions Inspect target repo before writing code:
Read package.json — package manager (bun/pnpm/npm), scripts, dependencies.
Read tsconfig.json — TypeScript settings, path aliases.
Scan src/ — directory layout, layer structure.
Check docs/adr/ or contribute/ for project-specific code standards.
Check formatter/linter config (biome.json, .eslintrc, prettier).
Read app.config.ts and app.manifest.ts — endpoints, environment setup.
Delegate uncertain Fusion Framework behavior, package ownership, or cookbook examples to fusion-research before writing code.
Adapt to discovered conventions. references/ patterns are defaults — defer to project-specific rules when they differ.
Step 2 — Plan the implementation New app from scratch → use assets/new-app-checklist.md.
Break into discrete files/changes.
Map to correct directory. Typical Fusion app:
src/components/ — React components (presentation layer)
src/hooks/ — Custom React hooks (state and side-effect logic)
src/api/ — API clients, data transforms, business logic
src/types/ — TypeScript interfaces, type aliases, enums
src/routes.ts — Route definitions (when using Fusion Router)
src/config.ts — Fusion module configuration
src/App.tsx — Root component, layout shell
Identify shared types early — define before referencing.
Project uses routing → follow references/using-router.md for DSL + page patterns.
Different structure → follow it.
Step 3 — Implement following code conventions Follow project code standards from Step 1. For naming, TSDoc, inline comments, type patterns, code style, error handling → defer to fusion-code-conventions.
For convention questions during implementation, invoke fusion-code-conventions directly.
Step 4 — Style with styled-components, EDS, and Fusion React components Follow references/styled-components.md, references/styling-with-eds.md, references/using-fusion-react-components.md:
Use styled-components for custom styling (Fusion convention).
No CSS Modules, global CSS, Tailwind, or alternative CSS-in-JS unless project uses them.
Use Styled object pattern for co-located styled components.
Prefer EDS (@equinor/eds-core-react) for standard UI.
Use EDS design tokens (@equinor/eds-tokens) for colors, spacing, typography.
Extend EDS with styled() for customization.
Use @equinor/fusion-react-* for domain needs not in EDS (person display/selection, side sheets, progress).
Inline style props: one-off tweaks only.
For page/view structure (shell composition, layout zones, empty/loading states), invoke agents/design.md. For component-level EDS styling, invoke agents/styling.md.
Step 5 — Wire up data fetching (when applicable) Follow references/configure-services.md, references/using-react-query.md, references/configure-mocking.md:
Register HTTP clients via configureHttpClient in config.ts or app.config.ts.
Access clients with useHttpClient(name) from @equinor/fusion-framework-react-app/http.
Prefer @equinor/fusion-framework-react-app/* hooks over direct module access. Reserve framework.modules.* for non-React contexts.
React Query: wrap useQuery in thin custom hooks.
Query keys: derived from API path + parameters.
Keep client UI state in React state/context, not server-state libs.
Step 6 — Configure Fusion modules (when applicable) Identify which module the user needs, then read only the matching reference:
Need Reference HTTP clients / API integration references/configure-services.mdContext module references/using-context.mdRouter and pages references/using-router.mdAG Grid references/using-ag-grid.mdAG Charts (standalone) references/using-ag-charts.mdAG Grid integrated charts references/using-ag-grid-charts.mdEDS + Fusion React components references/using-fusion-react-components.mdPeople service (search, display, pick) references/using-people-service.mdSettings references/using-settings.mdBookmarks references/using-bookmarks.mdAnalytics references/using-analytics.mdRuntime config / environment references/using-assets-and-environment.mdFeature flags references/using-feature-flags.mdGeneral framework modules references/using-framework-modules.mdCustom module authoring references/using-custom-modules.md
Module setup in config.ts via AppModuleInitiator callback.
Access modules via hooks: useAppModule, useHttpClient, useCurrentContext.
Register HTTP endpoints in app.config.ts for new API integrations.
Enable navigation with enableNavigation in config.ts when app uses routing.
Define routes via Fusion Router DSL (layout, index, route, prefix) for auto code splitting.
Unclear framework API → use fusion-research before choosing implementation pattern.
Step 7 — Validate Use assets/review-checklist.md as post-generation checklist.
Run typecheck (bun run typecheck or pnpm typecheck) — zero errors.
Run lint/format check — zero violations.
Every new exported symbol has TSDoc.
Styling follows project conventions.
No new dependencies unless justified/approved.
Expected output
New/modified src/ files following project layer structure.
All files pass typecheck + lint.
Every exported function, component, hook, and type has TSDoc.
Styling follows project conventions.
Brief summary of what changed and why.
Helper agents Optional helpers in agents/. Use for focused review or mid-implementation guidance. Runtimes without skill-local agents apply criteria inline.
Companion skill: fusion-research for source-backed Fusion ecosystem research when implementation is blocked by uncertainty.
agents/framework.md — Fusion Framework integration: modules, HTTP clients, bootstrap, runtime config, settings, bookmarks, analytics. Prefers mcp_fusion_search_framework ; falls back to mcp_fusion_search_docs. Consult when wiring config.ts, app.config.ts, or framework module access.
agents/styling.md — EDS component selection, styled-components, design tokens, accessibility. Prefers mcp_fusion_search_eds . Consult when building/modifying visual components.
agents/design.md — page/view structure: Fusion Portal shell composition, layout zones, side panel usage, empty/loading state patterns. References equinor-design-system for layout ground truth. Delegates component-level checks to agents/styling.md. Consult when scaffolding new pages or layout wrappers.
agents/data-display.md — AG Grid vs AG Charts, module setup, column defs, chart options, integrated charting. Prefers mcp_fusion_search_framework . Consult for grids, charts, dashboards. Use assets/charts-decision-matrix.md for library selection.
agents/person-components.md — @equinor/fusion-react-person: PersonAvatar, PersonCard, PersonListItem, PersonPicker, PeoplePicker, PeopleViewer, PersonCell (AG Grid). DOM event pattern, valueGetter setup, pitfalls. Consult for any person display, search, or selection UI.
agents/code-quality.md — delegates convention checks (naming, TSDoc, TS strictness, intent comments) to fusion-code-conventions, aggregates findings. Run on every new/modified file before finalizing.
Safety & constraints
No new dependencies without explicit approval.
No direct DOM manipulation — use React patterns.
No any types — TypeScript strict mode standard.
No secrets or credentials in source files.
Conventional commits (feat:, fix:, refactor:, etc.).
No infrastructure files (docker-compose, CI config) unless explicitly asked.