실제 제품을 적절한 조작 환경에서 실행해 변경 사항을 검증하고, 사용자가 확인할 수 있는 증거를 모아 인수 보고서로 게시합니다. 기존 검증 계획을 확인하거나 점검 항목을 만들고, `lh` CLI로 결과를 게시할 수 있습니다.
- 변경된 제품 동작을 실제로 확인하기
- 스크린샷 등 검증 증거 수집하기
- 검증 계획과 보고서 작성하기
큰 제품 기능을 역량별 React 단위로 나누어 여러 화면이 필요한 부분만 조합하도록 안내합니다. 데이터, 화면 상태, 동작을 해당 단위에 두어 가벼운 화면이 불필요한 의존성을 불러오지 않게 돕습니다.
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를 사용합니다.
분리한 뒤에는 가벼운 사용 환경의 가져오기 트리를 확인해 불필요한 모듈이 로드되지 않는지 점검합니다.
이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.
AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.
점수에는 넣지 않았습니다. 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.아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
실제 제품을 적절한 조작 환경에서 실행해 변경 사항을 검증하고, 사용자가 확인할 수 있는 증거를 모아 인수 보고서로 게시합니다. 기존 검증 계획을 확인하거나 점검 항목을 만들고, `lh` CLI로 결과를 게시할 수 있습니다.
LobeHub에 AI 모델 제공자를 추가하는 과정을 안내합니다. 런타임 연동, 모델 정보와 설정, 브랜드 표시, 문서화 및 인수 확인을 다루며, 기존 제공자에 모델만 추가하는 경우와 새 연동이 필요한 경우를 구분합니다.
서버 환경 변수로 사용자 설정의 기본값을 지정하도록 구현하는 절차를 안내합니다. 변수 검증, 서버 설정 구성, 사용자 저장소 반영부터 예시 환경 파일과 셀프 호스팅 문서 갱신까지 다룹니다.
에이전트 실행 단계, 도구 호출, 사람의 승인, 컨텍스트 압축, 하위 에이전트 호출에 훅을 등록하는 방법을 안내합니다. 이벤트를 관찰하고 로컬 도구 결과를 모의하거나 설정에 따라 웹훅으로 도구 호출을 허용 또는 거부할 수 있습니다.
에이전트의 이벤트 기반 백그라운드 작업을 설계하고 구현하도록 돕습니다. 소스, 시그널, 액션, 정책의 역할을 나누고 비동기 처리, 중복 실행 방지, 완료 기록과 관측 기능을 다룹니다.
실제 데스크톱 채팅 앱에서 봇 채널의 인수 테스트를 진행합니다. Discord, Slack, Telegram, WeChat, Lark, QQ에서 메시지를 보내고 응답을 기다린 뒤 결과 화면을 캡처합니다. iMessage는 BlueBubbles 브리지를 사용합니다.