実際の製品を操作して、利用者が確認できる動作証拠を集め、検証計画に沿った受け入れレポートとして公開するスキルです。
- 変更後の製品動作を実地で検証したいとき
- 画面キャプチャなどの証拠を集めたいとき
- 検証計画とレポートを作成したいとき
大きな機能を、画面や共有ページごとに必要な能力だけ読み込む部品へ分け、状態や処理の置き場所も整理する設計指針です。
Use for splitting heavy domains into capabilities (原子组件) across page, portal, share or micro-app hosts, sinking state (状态下沉) and replacing mode/readOnly flags. Simple component splits: react.
実行スコア 未検証
インストール方法を見る大きな機能を、ページ、ポータル、共有画面、マイクロアプリなどの利用先が必要なものだけ組み合わせられる「能力単位」に分ける設計ガイドです。見た目だけを小さく分割するのではなく、ある利用先が読み込まずに済ませたいまとまりを部品として切り出します。データ取得、表示用データ、画面内の一時状態、更新処理はそれを使う部品側に置き、組み立て側はレイアウトと読み込む部品の選択を担います。これにより、使わない機能の依存モジュールまで軽量な画面に取り込む構造を避けやすくなります。
同じ機能を通常画面と公開ページなど複数の場所で使い、利用先ごとに編集や操作機能の有無を変えたいときに向いています。機能追加のたびにmodeやreadOnlyの条件分岐が増えている場合や、画面から状態を切り離したい場合にも使えます。単一画面の単純なコンポーネント分割にはreactを使います。
分割後は、軽量な利用先のimportツリーを確認し、不要なモジュールが読み込まれないことを確かめます。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。
点数には入れていません。 2026年10月26日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
A heavy domain is a kit, not a viewer with modes. Each host is an import list. An atom owns the data, actions, and dependencies of one capability. The assembler only chooses what to mount.
This is a module-graph split. Hiding UI does not drop a module. A host that never imports a file is the only host that does not ship it.
Do not use this skill to slice one component into smaller files. That is react.
The folder is a product surface (Conversation, Acceptance, Document, Verify, Task, …) and at least one of these is true:
mode / variant on the fat tree.If the file is large but has one capability and one host, stop. Use react.
An atom is the smallest unit a host is allowed not to mount.
Ask, for every chunk: would any host ship the rest and skip this? If yes, it is an atom. If no, it stays inside its parent.
That grain is coarser than a visual section and finer than the whole page.
| Too coarse | Right grain | Too fine |
|---|---|---|
One Viewer with readOnly | Identity, goal, list, decision, … | Every badge, row, and icon as a public export |
Chat as a single import | List, composer, intervention, … | Every message sub-row the page then rewires |
Document as editor + every panel | Canvas, header, comments as omitted | Internal toolbar buttons |
A workflow (focus review, thread, publish) is one atom to hosts that skip the whole mode. Inside it, keep splitting only if a host would mount a piece of that workflow alone.
The split is worthless if the assembler still holds the domain state. Imports follow the hook. A useStore / useX / handleAccept left on the page keeps that module (and everything it imports) on every host that mounts the page.
Sink everything the atom needs into the atom:
| Sinks into the atom | Stays on the assembler |
|---|---|
| Resource fetch | The record id / scope identity |
| Derived view model (counts, labels, scope) | Which atoms are mounted (the import list) |
| Transient UI (filter, collapse, pending) | Host layout state (focused vs overview, rail) |
| Mutation handlers and their stores/modals | Host seams (provider value the runtime owns) |
// wrong — visual split, state still on the page
const Page = () => {
const { data, mutate } = useX(id);
const [filter, setFilter] = useState('all');
const accept = () => void mutate(...);
return (
<>
<Identity data={data} />
<List data={data} filter={filter} onFilter={setFilter} />
<DecisionBar onAccept={accept} />
</>
);
};
// right — each atom reads and acts; page only assembles
const Page = () => (
<Scope id={id}>
<Identity />
<List />
<Decision />
</Scope>
);
Do not lift "to fetch once" or "so siblings share data". Two atoms calling the same SWR hook share the cache by key. Sibling writes go through that cache (or a store slice the write atom imports), not through page useState.
Lift only when the state is the assembler's job: which workflow is on screen, whether a rail is open. If a value is used to render or mutate one capability, it belongs in that capability.
| Piece | Owns | Must not own |
|---|---|---|
| Domain primitive | Types, predicates, formatters | React, stores, services |
| Data access | One resource, one file | Sibling list / infinite / document hooks |
| Read atom | Present + local UI state + its own fetch | Mutations, trays, owner services, host stores |
| Write atom | One mutation and its UI | Page layout, unrelated writes |
| Workflow atom | A mode assembled from other atoms | Becoming the only entry other hosts can import |
| Domain slot | ReactNode hole for another same-domain atom | A callback whose implementation lives in this file |
| Host seam | Optional host-provided UI, null by default | A fallback that imports the host graph |
| Assembler | Layout + the import list | Domain actions; domain fetch except local chrome |
A visual block that both reads and writes is a read atom + a write atom, joined by a domain slot.
Two seam types — do not mix them:
editSlot, toolbar). The host imports the write atom and passes it in.null. The micro-app / share page never imports the provider value. See split-micro-app for the runtime cut.State and imports live in the atom that needs them.
null when the record is not writable.id, embedded). It does not carry actions, stores, or modal openers.Several atoms calling the same SWR hook is expected. SWR dedupes on key. Do not lift data to the assembler "to fetch once".
The shared read hook is its own file. A light host imports that file, never a hooks.ts / store barrel that also exports list, document, or send-message.
// any host:
import { useX } from '@/features/Domain/useX';
// never from a light host:
import { useX } from '@/features/Domain/hooks';
import { DomainViewer } from '@/features/Domain';
A flag that only changes behavior of code already in the atom is fine. A flag whose purpose is to skip importing another module is not — that module is a slot or a sibling the assembler omits.
dynamic(() => import(...)) only helps when no static import of that module remains on the light graph.
A host is its import list.
// light host — deep imports only
<Scope id={id}>
<ReadA />
<ReadB />
</Scope>
// full host — same reads, write atoms in slots, workflows as siblings
<ReadA extra={<WriteA />} />
<ReadB toolbar={<WriteB />} />
<Workflow />
<WriteC />
Route / portal files compose host skeleton (providers, host seams). Do not add a wrapper page whose only job is to sit between the route and the assembler.
The feature barrel may export the full assembler for in-app use. Light hosts must not import that barrel.
ReactNode slots, not callbacks that close over write modules.readOnly / isPublic / mode / variant on the fat tree.# example: light host must not import a write atom
WORKBENCH_TRACE_MODULE=features/Acceptance/Viewer/Review/AcceptanceDecision bun run build:rr
If the light assembler appears on the importer chain, a static import still exists — usually a barrel, a leftover flag, or actions left on the page.
src/features/Acceptance/Viewer/ is one application of this kit, not the template to copy file-for-file.
| Host | Mounts |
|---|---|
In-app Acceptance/index.tsx | Identity, goal, inventory, decision, focus workflow, ledger + write slots |
| Workbench public detail | Identity, goal, inventory, discussion with sign-in guidance |
| Portal | Full assembler + OriginConversationProvider |
Read AcceptanceGoal (read + editSlot) and AcceptanceGoalEdit (write) for the slot cut. Read originConversation.tsx for a host seam. Read workbench AcceptanceDetail.tsx for a light assembler.
react: single-surface boundaries, styling, memoization.split-micro-app: worker / SSR / gateway / stubs. This skill is how the shared UI is cut afterwards.spa-routes: route files stay thin assemblers.data-fetching-architecture: how the isolated hook fetches, not where a host may import it from.zustand: narrow selectors inside an atom; do not put the whole store on scope context.まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
実際の製品を操作して、利用者が確認できる動作証拠を集め、検証計画に沿った受け入れレポートとして公開するスキルです。
LobeHubにAIモデルプロバイダーを追加し、実行時連携からモデル表示、設定、ブランド表記、文書化、動作確認まで進めるスキルです。
ユーザー設定の初期値をサーバー側の環境変数で切り替えるため、型定義や設定の組み立て、ユーザーストアへの反映、環境変数の例と説明書きを追加する手順です。
エージェント実行中の各段階をフックで監視し、ツール呼び出しの模擬・制御や人の承認、圧縮、サブエージェント処理に介入する仕組みを扱います。
イベントを起点にエージェントのバックグラウンド処理を組み立て、ソース・シグナル・アクション・ポリシーの役割分担や非同期連携を実装するためのスキルです。
DiscordやSlackなどの実際のチャットアプリでボットにメッセージを送り、応答を画面で確認する受け入れテストを行うスキルです。