# Build an original SDK folder

Build directly on the SDK foundation and import the finished folder unchanged.

Extract `/block-sdk/sdk-docs.zip` into a development directory, then run:

```sh
node packages/block-cli/cli.js create my-block javascript
node packages/block-cli/cli.js validate my-block
node packages/block-cli/cli.js test my-block
node packages/block-cli/cli.js pack my-block my-block.stillmade-block --original
```

`create` supplies an editable starter. Replace its identity, task behavior, controls
and fixtures with your Block's requirements, retaining applicable SDK license
notices. The directory layout is:

```text
my-block/
  stillmade.block.json
  src/run.js
  src/view.html          optional custom interface
  src/view.css           optional styles
  src/view.js            optional interface behavior
  tests/fixtures.json
```

`src/run.js` is an isolated function body operating on `input`; it returns declared
outputs. The custom interface uses the supplied `StillMade` bridge. A photo editor
can read typed image pixels, apply its edits in `run.js`, show before/after images
through `StillMade.previewImage`, and call `StillMade.run` from its controls.
Author those files directly under the SDK contract; external framework packages,
Node services and a separate standalone website are not this runtime's source.
No build/install command executes during import.

Select **my-block** with Choose folder to import that source unchanged. Development
tools may live beside it; select the Block directory, not an SDK checkout containing
several example builds. Use at least two fixtures (normal and edge cases) for the
canonical archive, and use `--original` only for your own original implementation
without reused repository/dependency code. Direct folder import and archive import
retain the same runtime and interface; packaging adds explicit retained-source
evidence. Security, source-rights confirmation and hosted execution approvals still
use the ordinary review path. They do not adapt the Block.

This is the implemented SDK, not the full future runtime catalog. It supports
data-only recipes, isolated JavaScript, reviewed hosted text and speech generation, and a reviewed ComfyUI core-image adapter,
typed inputs/outputs, schema-driven controls,
optional sandboxed HTML interfaces,
behavior fixtures, package validation, standalone execution, and app import.
Python source, external modules, native dependencies, custom ComfyUI nodes and
per-frame editor renderers are not executable through this SDK version. ComfyUI
requires an explicitly selected account connection and a real remote review;
recipe and JavaScript examples continue to run offline.