Build one complete feature the Runtime Kit way: a package lists data and an action, Runtime Kit checks that package file, a React screen reads the named data, and a button asks the named action to do work.
What you will build
You are building a small welcome panel for a product launch screen.The panel needs three public pieces:| Product moment | Runtime Kit shape |
|---|---|
| The screen shows welcome copy. | A package record becomes named data for useBitfieldData(...). |
| The user clicks for a launch suggestion. | A package slot named welcome.suggest becomes the action the button calls. |
| The screen handles real UI states. | The React screen renders loading, error, empty, and success. |
welcome.suggest. Runtime Kit keeps those jobs separated.01
Files start as source material owned by the package.
02
things-to-store-and-run.json declares records, bytes, and targets.
03
Runtime Kit checks the package before app code sees handles.
04
The app reads data names and calls action names.
Before you start
You need these public facts before the feature can work:| Requirement | What it means |
|---|---|
| Account and key | Your product has access to Bitfield through the account flow. |
| Active device | This machine or runtime identity triggered Bitfield in the billing window. |
| Package set name | The product has a package set, such as launch-demo. |
| Runtime Kit package | Your app can import @bitfield/runtime-kit and @bitfield/runtime-kit/react. |
~/.bitfield. Runtime Kit and account flows own local activation and package state. If one device behaves differently from another, use Local state and Troubleshooting instead of copying folders by hand.Step 1: Create the package folder
Create one package folder inside the package set you are working on:Step 2: List what the package brings
things-to-store-and-run.json declares what this package brings.record is the data the screen will read. The slot is the named target the button will call.The names that matter later are:| Name | Used by | Meaning |
|---|---|---|
package::welcome-package::welcome-copy | Package file | Stable package-owned record address. |
welcome-copy | React screen | Data name exposed to the screen. |
welcome.suggest | Button action | Action name used by sendRequestToBitfieldTarget(...). |
Step 3: Admit the package
Before admission, this is only a folder with a package file.After admission, Runtime Kit has checked the package and can expose data names and action names.| Before admission | After admission |
|---|---|
things-to-store-and-run.json is source material. | Runtime Kit has checked the package file. |
welcome-copy exists only as package data. | Runtime Kit can make it available to a screen. |
welcome.suggest is only declared. | App code can ask that action for work. |
slots/suggestion-slot.bin is package-owned material. | App code still calls the action name, not the file. |
things-to-store-and-run.json first. See Package file failures.Step 4: Read the named data
Your React screen readswelcome-copy.What should happen
Step 5: Send a request from the button
The button calls the action by name.| Request part | Shape |
|---|---|
| Action name | welcome.suggest |
| Payload | { topic: string } |
| Reply | { suggestion: string } encoded as JSON bytes |
| Error owner | The request caller handles failed request or failed decode. |
What should happen
Step 6: Put the read and request together
This is the full screen. It reads named data and askswelcome.suggest for work without importing package setup.welcome.suggest.Step 7: Verify the feature
Use this checklist before treating the feature as done:| Check | Pass condition |
|---|---|
| Package file exists | welcome-package/things-to-store-and-run.json exists. |
| Record is declared | The package file has a record for welcome-copy. |
| Action is declared | The package file has a slot named welcome.suggest. |
| Read states render | The component renders loading, error, empty, and success. |
| Request has a shape | The button sends { topic: string } and decodes { suggestion: string }. |
| No private imports | App code imports only public Runtime Kit functions. |
| No local state edits | No one fixes the feature by editing ~/.bitfield by hand. |
What not to do
Do not make the React component parsethings-to-store-and-run.json. That moves package admission into the UI.Do not hardcode package folder paths into app code. The folder is package input, not the app API.Do not import the slot implementation into the button. Call welcome.suggest.Do not skip loading, error, or empty states. Runtime Kit features still have real user states.Do not publish package examples that contain private tokens, account secrets, or real customer data.What changes when the feature grows
The public chain can grow without changing its shape.| Growth | What stays stable |
|---|---|
| More copy records. | Components still read data names. |
| A faster slot implementation. | The action name can stay welcome.suggest. |
| A package-owned help file. | The package still lists owned material in things-to-store-and-run.json. |
| A non-React screen later. | The read/request split still applies. |
Another product with a package named welcome-package. | Package sets keep project material separated. |
Debug the chain
When something fails, locate which link failed:| Symptom | Check this link | Fix path |
|---|---|---|
| Package cannot be admitted. | things-to-store-and-run.json and package-owned paths. | Package file failures |
| Component never receives data. | Data name and screen scope. | Named data read failures |
| Button throws before work starts. | Action name and payload shape. | Action request failures |
| Reply cannot be parsed as JSON. | Reply shape and decoder. | Reply decoding failures |
| Works on one device but not another. | Activation and package-set state. | Local state confusion |
things-to-store-and-run.json. Then check the data name or action name. Then check the component.Feature map
Keep this map beside the feature while building it:Quick reference
Where to go next
Read JavaScript Runtime Kit when you want the full mental model.Read Packages when you are shapingthings-to-store-and-run.json.Read things-to-store-and-run.json when you need exact record, stored_bytes, or slot field rules.Read Read data in React when a component needs named data.Read Send a request when a button needs an action.Read Runtime Kit API when you need exact request, reply, selector, and render-state contracts.Read Troubleshooting when the chain breaks.Now build the bigger version
Take the same chain and build a screen that uses two packages.Package one owns the copy:launch.next-step, for the button that helps the user keep moving. The UI now has copy, checklist data, and a callable action while still using the same public read/request shape.When that shape feels clear, learn the larger composition in Placeable surfaces, then copy the full example in Placeable surface product loop.