メニュー
Named export conventions and barrel file usage rules for the Trezor Suite codebase. Use when writing imports, exports, or deciding on module structure.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
publishConfig rules for public npm packages in the Trezor Suite monorepo. Use when adding or editing publishConfig, exports, or preparing a package for npm publishing.
How to create and structure packages in the Trezor Suite monorepo, including scopes and sizing guidance. Use when creating new packages or resolving cyclic dependencies.
Use when writing component or hook tests in suite-native and need to choose between renderWithBasicProvider, renderWithStoreProvider, or store helpers like createStoreFromPreloadedState, createLightStore, or mergePreloadedState.
Generated code must be aligned with security headers (e.g. no unsave JS eval). The permissions policy is especially relevant when changing any code related with the `navigator` object.
Trigger on any mention of Trezor wallet interaction, crypto addresses, sending crypto, checking balances, signing messages, or hardware wallet operations via MCP. Also trigger when users mention configuring or troubleshooting the Trezor MCP server connection.
How to create and implement IndexedDB storage migrations in the Trezor Suite web app. Use when writing migrations that transform persisted data between Suite versions.
| name | import-export |
| description | Named export conventions and barrel file usage rules for the Trezor Suite codebase. Use when writing imports, exports, or deciding on module structure. |
Consistency. With named exports you can always be sure that the exported value will not be renamed at one point. It's much easier to refactor with named exports because you can mass-replace and be more confident that it covered everything. Same goes for searching for a value.
Tree-shaking. With named exports, Webpack can recognize which exported values are unused and eliminate them. If you want to import all exports from a file and not use default exports, – use:
import * as colorUtils from './utils.js';
Use them in packages to define public interface.
Do not use them inside a module to export from directory. If you feel it shall be separated, create a new package. They can introduce accidental circular dependencies and may hurt tree-shaking.