walnut-plugin-author

# Walnut Plugin author Use the unified `apiVersion: 1` plugin model. Read `docs/reference/plugin-development.md` and the executable example `examples/plugins/walnut-demo` (the Walnut Plugin Demo) before writing code. Follow the eight steps below in order. Each one has a check you can run, so you never claim a plugin works because the code looks right. ## 1. Choose the capabilities first Decide what the plugin contributes before scaffolding, because the answer picks the template: | The plugin needs | Capability to use | Template | |---|---|---| | The Personal AI to call something | `registry.tool` | `server` | | A recurring or scheduled action | `registry.cronAction` | `server` | | To react to sessions or tasks | `registry.hook` | `server` | | Two-way task sync with an external system | `registry.sync` plus `sourceClaim` and `display` | `server` | | A screen in the console | `ui.app` | `web` | | A screen that reads server state | `ui.app` plus `registry.wsMethod` or `http.route` | `both` | | Instructions an agent should read | a `skills/<name>/SKILL.md` directory | either | | A namespaced slash command | `registry.command` | `server` | | An external page that needs browser isolation | a `webview` manifest entry | either | Write the list down before step 2. A plugin that registers a capability nobody asked for is a review finding, not a feature. ## 2. Scaffold with one command ```bash npx @open-walnut/plugin-cli new <plugin-id> --dev --template both ``` That command sc...