compose-atoms

Decompose monolithic React feature viewers into independently mountable capability atoms.

74|11|Updated Jul 4, 2024
One-click install
npx skills add https://github.com/OpenSourceAGI/qwksearch-research-agent --skill compose-atoms-opensourceagi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: compose-atoms
Source: https://github.com/OpenSourceAGI/qwksearch-research-agent/tree/main/apps/qwk-in-lobe/.agents/skills/compose-atoms
Command: npx skills add https://github.com/OpenSourceAGI/qwksearch-research-agent --skill compose-atoms-opensourceagi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large React feature folders often grow into god components where one Viewer or Page owns data fetching, filters, mutations, modals, and host integrations together, making it impossible for portals, share pages, mobile shells, or micro-apps to reuse only a subset of the domain without shipping the entire module graph. ## Core Features & Use Cases - Atom Grain Definition: Defines each atom as the smallest unit a host is allowed not to mount, splitting read atoms, write atoms, workflow atoms, domain slots, and host seams. - State Sinking Rules: Moves fetches, derived view models, transient UI state, and mutation handlers out of the assembler page and into the atom that owns them, relying on SWR key deduping instead of lifted state. - Host-as-Import-List Assembly: Rewrites every host (page, portal, share, micro-app) as a layout plus a deep-import list, eliminating readOnly/mode/variant flags and barrel imports. - Use Case: A public workbench detail page needs only identity, goal, and inventory from a heavy Acceptance viewer; this Skill guides extracting those read atoms so the light host never statically imports decision workflows, chat stores, or write modals. ## Quick Start Ask the AI to apply the compose-atoms skill to split the fat Viewer in src/features/Acceptance into mountable read and write atoms with a light assembler for the public host.

Frequently Asked Questions about compose-atoms

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large React component into reusable pieces?

Split by capability, not visuals: each atom is the smallest unit a host may skip. Extract read atoms that own their own fetch and UI state, write atoms that own one mutation and its modals, and let the page become only a layout plus an import list.

How do I share a feature between a full app and a lightweight public page?

Give each host its own assembler that deep-imports only the atoms it mounts. Light hosts must import hooks from isolated per-resource files, never from feature barrels that also export workflows, stores, or write components.

Should I lift state up so sibling components share fetched data?

No. Multiple atoms calling the same SWR hook share the cache by key, so lifting state to the page is unnecessary and keeps the whole module graph on every host. Only lift state that is genuinely the assembler's job, like which workflow is on screen.

When should I not decompose a component into atoms?

Stop when the file has one capability and one host, even if it is large. Atom splitting only pays off when a second host exists or is imminent, or when new features keep arriving as readOnly, mode, or variant flags on a fat tree.

Why does my light host still bundle the full feature after splitting?

A static import remains somewhere on the light graph, usually a barrel export, a leftover mode flag, or domain hooks still called on the page. Trace the light entry's import tree or grep for a module it must not ship to find the leak.