opencode-ship 0.2.1 → 0.4.0

package/CHANGELOG.md

@@ -2,6 +2,74 @@
 
 All notable changes to `opencode-ship` are recorded here.
 
+## 0.4.0 — Profile-aware installer foundation
+
+`opencode-ship@0.4.0` adds the profile-aware installer foundation that issue #18 requires. The package still ships no third-party workflow skill bytes; the `engineering` profile is the future attribution surface for vendored upstream material and currently contains the same five managed files as the `core` profile. The catalog and lock layers now know about profiles, and every command resolves the active profile through one documented precedence chain.
+
+### Verification
+
+- `npm run verify` exits `0` with 226 tests across 34 suites on the v0.4 HEAD.
+
+### Added
+
+- **Profile model.** `src/profile.js` declares `PROFILES = ["core", "engineering"]` and exports `resolveProfile({ cli, config, lock })` for the documented precedence (CLI > ship.config > lock > default). Unknown profiles throw a descriptive `Error` so the CLI can surface them as `exit 2`.
+- **`--profile` CLI flag.** Every subcommand (`init`, `diff`, `update`, `doctor`, `uninstall`) accepts `--profile <name>`; parse errors emit to `stderr` and return `exit 2`.
+- **Lock schema v2.** `CURRENT_LOCK_SCHEMA` is bumped to 2. Newly written locks always carry `manager.profile`; v1 locks (no profile field) still validate as legacy core so v0.3 consumers can upgrade without manual migration. The `ship-lock.schema.json` `enum` allows `[1, 2]` for both `contractVersion` and `manager.schemaVersion`.
+- **`ship.config.json .profile`.** The user config schema accepts an optional `profile` enum (`core | engineering`). The profile is loaded by the same precedence chain as the lock.
+- **Profile-aware catalog.** Every `CATALOG` entry declares a `profiles` array. `filterCatalogByProfile(catalog, profile)` returns the subset that ships under the active profile; `validateCatalog` rejects entries that reference unknown profiles.
+- **Profile-aware doctor.** The new `profile footprint` check scopes asset presence to the active profile; `package integrity` continues to check the full catalog so the maintainer can still see drift in the other profile.
+- **Error to `stderr`.** CLI argument-parsing errors are now written to `stderr` (was `stdout`) so consumers can detect parse failures by exit code alone.
+
+## 0.3.0 — Installer hardening and release pipeline
+
+`opencode-ship@0.3.0` hardens the installer for the public registry. This is the v0.3 installer foundation with the `core` profile only; it carries no third-party workflow skill bytes. The package is now fully consumable from npm with provenance. The catalog installs the five managed files plus the two generated artifacts (`ship.config.json`, `ship.lock.json`), and adds tighter guards around every existing one. The plugin target is `.opencode/plugins/opencode-ship.js` so OpenCode auto-loads it from the plural directory; root-config pointer ownership is recorded for every installer-owned entry so the future v0.4 opt-in `engineering` profile can restore previous values on uninstall. v0.3 is the approved slice shipped by parent spec `Viktorxyz/opencode-ship#16` and plan revision `f85bae931d9eed7763e2f6f4dc68e5fad71bdd38c8a667fc9ffe78b5290200be`.
+
+### Verification
+
+- `npm run verify` exits `0` with 190 tests across 34 suites on the v0.3 HEAD.
+- `npm pack` and the extracted-tarball smoke both succeed; the bundled plugin registers the canonical nine `delivery_*` tools.
+
+### Changed
+
+- **Single-source version.** `src/version.js` is the canonical home for `PACKAGE_VERSION` and `TEMPLATE_SET`. It reads `package.json` directly when running from source and falls back to the esbuild-inlined `process.env.OPENCODE_SHIP_VERSION` for the bundled CLI.
+- **Robust package root resolution.** `src/installer/package-root.js` walks upward from `import.meta.url` until it finds a `package.json` whose `name` is `opencode-ship`, so the catalog resolves the correct source path whether the installer is loaded from `src/installer/` or from the bundled `dist/cli.js` / `dist/plugin.js`.
+- **Catalog-driven installer.** `src/installer/catalog.js` declares a stable `id` for every managed asset (`plugin:opencode-ship`, `agent:delivery-reviewer`, `agent:delivery-verifier`, `skill:delivery-workflow`, `skill:planning-research-checkpoint`), each with a `.opencode/`-rooted target path and a `mode: 0o644` policy. `validateCatalog()` checks unique IDs, unique paths, source existence, non-empty file size, allowed kind set, source containment within the package root, and uniform mode; the planner and doctor consume the same array, so adding a managed file is a one-line catalog change.
+- **Fail-closed on missing source.** `init`, `diff`, and `update` invoke `validateCatalog()` and translate any failure to `exit 4`. The installer no longer produces a zero-byte placeholder when an asset source is missing.
+- **Lock validator.** `src/installer/lock.js` exposes `validateLock()` and `readValidatedLock()`. The lock schema version is enforced (`CURRENT_LOCK_SCHEMA = 1`); an unsupported `manager.schemaVersion` or `contractVersion` returns `kind: "schema"` for the installer to map to `exit 5`; an integrity mismatch maps to `kind: "integrity"`; a malformed shape maps to `kind: "shape"`. `init`, `diff`, `update`, and `uninstall` now route through `readValidatedLock()` so an invalid or unsupported lock can never be silently treated as a fresh install.
+- **Read-only `diff`.** The migration detector in `src/installer/migration.js` returns a `proposedConfigSeed` instead of writing to disk; `planConfigSynthesis()` consumes the seed only when `init`/`update` actually commit.
+- **Delete operations reach the transaction layer.** `stageFiles()` in `src/installer/executor.js` forwards `delete` plans to `executePlan()`. The transaction layer journals and rolls back deletes so a downgrade or asset removal produces an honest, recoverable change.
+- **Real transaction recovery.** `src/installer/transaction.js` writes a sibling backup of every target before promoting a staged file, journals the backup path only, and rolls back in reverse on failure. Recovery on startup replays the same journal so a crash mid-transaction is recovered automatically.
+- **Root-config pointer ownership.** Every installer-owned JSON pointer is recorded in the lock under `manager.rootDocuments[].pointers[]`, including equal-existing leaves. v0.3 records ownership; v0.4 restores the previous values on uninstall.
+- **Doctor is catalog-driven.** `src/installer/commands/doctor.js` walks `CATALOG` instead of hard-coded paths and adds a `package integrity` check that re-runs `validateCatalog()`. Drift and missing assets are reported once per asset. Exit codes now distinguish `3` for lock integrity/shape, `4` for package integrity, `5` for an unsupported lock schema.
+- **Version fallbacks centralised.** `src/version.js` resolves from `package.json` for source-tree callers and from the esbuild-inlined `process.env.OPENCODE_SHIP_VERSION` for the bundled CLI.
+- **Build hygiene.** `scripts/build.mjs` writes the temporary `tsconfig.dts.json` under `.tmp/`, removes it in `finally`, and runs `rm -rf .tmp/` at the end. The previously tracked `tsconfig.dts.json` is removed from the working tree and appended to `.gitignore`.
+- **Lint and format-check roots.** `scripts/lint.mjs` and `scripts/format-check.mjs` scan `assets/` instead of the legacy root `agents/` and `skills/` directories. The `assets/` tree is the only place bundled agents and skills live.
+- **Release workflow.** `.github/workflows/release.yml` validates that the tag matches `package.json#version`, validates `package-lock.json` and `package.json` carry the same version, refuses to republish an existing npm version, renames the tarball to `opencode-ship-<tag>.tgz`, and gates publication on `npm run verify`. The trusted-publisher identity is `Viktorxyz/opencode-ship`; `id-token: write` is granted to the job.
+- **Repository identity.** Schema `$id` URLs, the package homepage, repository URL, and bugs URL all point at `https://github.com/Viktorxyz/opencode-ship/…`. The previously published `0.2.0` and `0.2.1` were produced from the `Viktorxyz/opencode-delivery` GitHub repo; v0.3.0 is the first release from `Viktorxyz/opencode-ship`.
+- **Publishing policy.** `publishConfig.access = "public"` and `publishConfig.provenance = true` are set in `package.json`.
+- **Removal of unused CLI flag.** The unset `--config` flag is removed from `cli-args.js`; the planned v0.4 profile flag will be added to a released version with the documented behavior.
+
+### Added
+
+- `src/version.js` centralises `PACKAGE_VERSION` and `TEMPLATE_SET`.
+- `src/installer/package-root.js` resolves the package root independently of the source/bundle dichotomy.
+- `src/installer/catalog.js#validateCatalog()` is the new fail-closed validation surface; the thrown error carries structured `issues` and a `catalogValidation` flag.
+- `src/installer/lock.js#validateLock()` and `readValidatedLock()` distinguish "fresh install", "supported lock", "unsupported schema", "tampered lock", and "malformed lock".
+- `src/installer/migration.js` returns a `proposedConfigSeed`; `planConfigSynthesis()` consumes it instead of branching on legacy state.
+- `tests/installer/catalog.test.mjs`, `tests/installer/lock-validation.test.mjs`, `tests/installer/root-config.test.mjs`, `tests/installer/migration-pure.test.mjs`, and `tests/release/release-metadata.test.mjs` exercise the new contracts.
+- `tests/package/packed-artifact.test.mjs` extracts the npm tarball into a clean directory and runs its bundled CLI to `init` a fresh Git repository, asserting the plugin path, the five managed files, the lock, and the pointer records.
+- `THIRD_PARTY_NOTICES.md` records that v0.3 contains no third-party skill bytes and reserves the attribution surface for the v0.4 `engineering` profile that introduces them.
+- `scripts/prepack.mjs` runs `validateCatalog()` and verifies every required packaged artifact before publishing.
+
+### Fixed
+
+- `packed-artifact` smoke test now runs `init --force-root-config` end-to-end from the extracted tarball.
+- `diff` against a v0.2.1 consumer briefly wrote `ship.config.json` to disk; `diff` is now strictly read-only even when the migration detector would have seeded one.
+- The legacy migration seed now emits a config that matches the canonical consumer shape (`Viktorxyz/leo`, `pnpm`, `pnpm verify:workspace`, the v0.3 cleanup shape) instead of `"origin"` / `"npm"` / legacy `cleanup.requires`.
+- Lock entries with `sha256: null` no longer reach `writeLock`; the planner/executor no longer produce a lock whose integrity digest silently mismatches its declared hashes.
+- Stale `tsconfig.dts.json` no longer gets tracked; the build artifact is now confined to `.tmp/`, which is gitignored.
+- The plugin target is pluralized to `.opencode/plugins/opencode-ship.js` so OpenCode auto-loads it from the default project plugin directory; the previously-tracked singular directory is removed.
+
 ## 0.2.0 — npm-distributed installer release
 
 `opencode-ship@0.2.0` replaces the v0.1.x copy-the-shim workflow. The package is now an npm-distributed CLI plus a self-contained OpenCode plugin. Run `pnpm dlx opencode-ship@latest init` from any consumer repo to materialise everything needed for the delivery workflow.
@@ -39,19 +107,4 @@ All notable changes to `opencode-ship` are recorded here.
 
 ### Fixed
 
-- **`gh pr view merged blocker.** The GitHub driver no longer requests the unsupported `merged` field on `gh pr view --json`. `merged` is derived from `state` / `mergedAt` instead.
-- **Cleanup-after-merged-PR race.** Cleanup preconditions are validated atomically; the agent-owned worktree and local branch are removed only after the manifest is sealed.
-- **Deterministic cleanup recovery.** A `merged` manifest that has no PR is recovered when the worktree is clean and the recorded head SHA matches the local head.
-- **Stale lockfile / missing adapter schema.** The lockfile is regenerated during `npm install`; the previously missing `schema/project-adapter.schema.json` is published.
-- **Locked JSON parse drift.** Config files generated with extra fields the schema rejected (`inferredFrom`) no longer fail validation; detection now produces schema-compliant output.
-- **Hash-corruption in root-config writes.** The order-preserving JSONC walker now merges new keys with the original source order, so existing pointers are not lost on rewrite.
-
-### Compatibility
-
-- Requires Node `>=22.6.0` (matches `engines` and doctor).
-- Requires `@opencode-ai/plugin >= 1.15.5 < 2` as a peer dependency (it is provided by OpenCode at runtime).
-- The plugin auto-discovers from `.opencode/plugin/opencode-ship.js`; consumers do NOT add a `plugin` entry to `opencode.json` for the bundled plugin (avoid double registration).
-
-### Removed
-
-- The previous source-pinned package layout that required copying `delivery.json`, the project plugin shim, the agents, and the skills by hand.
+- The legacy v0.1.x commit-pinned shim left consumers reading `opencode-delivery` from a vendored `.opencode/plugin/delivery.ts`; v0.2.0 removes that requirement and centralises everything in `dist/plugin.js`.

package/README.md

@@ -2,7 +2,7 @@
 
 > npm-distributed OpenCode installer and delivery plugin: a single command materialises the lifecycle plugin, reviewer/verifier agents, and skills into any consumer repository, with a recoverable lock and never silently overwrites managed files.
 >
-> **Status:** v0.2.0. The installer is now a `pnpm dlx opencode-ship@latest <cmd>` workflow. Five idempotent CLI commands manage a managed-file lock, a transactional promoter, and a compiled ESM plugin that registers the canonical nine `delivery_*` tools. Post-merge cleanup is immediate and recoverable. All 150 tests and the packed-artifact smoke check pass under `npm run verify`.
+> **Status:** v0.4.0 profile-aware installer foundation. The installer is a `pnpm dlx opencode-ship@latest <cmd>` workflow. Five idempotent CLI commands manage a managed-file lock, a transactional promoter, and a compiled ESM plugin that registers the canonical nine `delivery_*` tools. Every command now accepts `--profile <name>` (`core` default, `engineering` opt-in) and resolves the active profile through one documented precedence chain (CLI > ship.config > lock > default). The catalog-driven installer fails closed when a packaged source is missing or a lock carries an unsupported schema. The plugin target is `.opencode/plugins/opencode-ship.js`; OpenCode auto-loads plugins from the plural directory. v0.4 ships the profile foundation required by issue #18 and approved plan `f85bae931d9eed7763e2f6f4dc68e5fad71bdd38c8a667fc9ffe78b5290200be` (`Viktorxyz/opencode-ship#16`); future releases vendor the actual engineering workflow skills via this same profile slot.
 
 ---
 
@@ -10,7 +10,7 @@
 
 `opencode-ship` is the npm-distributed successor to `opencode-delivery`. It bundles:
 
-- a **nine-tool OpenCode plugin** that auto-loads from `.opencode/plugin/opencode-ship.js`;
+- a **nine-tool OpenCode plugin** that auto-loads from `.opencode/plugins/opencode-ship.js`;
 - a **lifecycle state machine** for one issue → one worktree → one PR → one merge → one cleanup;
 - a **Git worktree driver** (no rebase-after-push, no force-push, no `--force-with-lease`);
 - a **GitHub CLI driver** that talks only to typed `gh pr/issue` verbs (never `gh api`);
@@ -18,7 +18,7 @@
 - **reviewer** and **verifier** subagents, both with strictly bounded `delivery_*` permissions;
 - a **delivery-workflow** skill that drives the canonical lifecycle;
 - a **planning-research-checkpoint** skill that offers a single, optional Deep Research gate per non-trivial plan;
-- a **delivery doctor** that validates the adapter, package pin, and OpenCode compatibility;
+- a **delivery doctor** that walks every catalog entry to verify install state and lock consistency;
 - an **install/doctor/diff/update/uninstall** CLI with stable exit codes and `--json` envelopes;
 - a **.opencode/ship.lock.json** lock that records managed paths, hashes, and the installer-owned JSON pointers;
 - **recovery** for interrupted cleanup, half-written state files, and stale worktrees.
@@ -29,6 +29,8 @@ The package **does not** own:
 - issue-label catalogues, release scripts, or deploy hooks;
 - framework- or language-specific expertise.
 
+The only source tree that ships in the npm tarball is `assets/`. Anything copied under `dist/`, `schema/`, `docs/`, or the top-level `THIRD_PARTY_NOTICES.md` is part of the installable distribution. The `assets/` directory is the single canonical managed-asset source for the catalog; nothing else provides packaged agents or skills.
+
 ## Distribution
 
 Once `opencode-ship` is published, consumers install with `pnpm dlx` (or `npx`) and never edit the file by hand:
@@ -44,15 +46,15 @@ pnpm dlx opencode-ship@latest uninstall # remove only the files still matching t
 If you want to try a pre-release tarball locally without publishing to npm:
 
 ```bash
-pnpm dlx --package=/absolute/path/opencode-ship-0.2.0.tgz opencode-ship init
+pnpm dlx --package=/absolute/path/opencode-ship-0.3.0.tgz opencode-ship init
 ```
 
-The plugin auto-discovers from `.opencode/plugin/opencode-ship.js`; the consumer does not add a plugin entry to `opencode.json`. The installer merges only Build-agent permissions into the root `opencode.json` (or `.jsonc`); all other root-config fields remain owned by the user. Use `--force-root-config` on `init` to create a minimal `opencode.json` if the consumer has none.
+The plugin auto-discovers from `.opencode/plugins/opencode-ship.js`; the consumer does not add a plugin entry to `opencode.json`. The installer merges only Build-agent permissions into the root `opencode.json` (or `.jsonc`); all other root-config fields remain owned by the user. Use `--force-root-config` on `init` to create a minimal `opencode.json` if the consumer has none.
 
 ### Managed file layout
 
 ```
-.opencode/plugin/opencode-ship.js
+.opencode/plugins/opencode-ship.js
 .opencode/agents/delivery-reviewer.md
 .opencode/agents/delivery-verifier.md
 .opencode/skills/delivery-workflow/SKILL.md
@@ -61,6 +63,8 @@ The plugin auto-discovers from `.opencode/plugin/opencode-ship.js`; the consumer
 .opencode/ship.lock.json       # installer-managed; drives update + uninstall
 ```
 
+These seven files (five managed plus two generated) form the default `core` install footprint. The opt-in `engineering` profile installs additional assets through the same catalog; the installer’s catalog and doctor both read from `assets/` so adding new managed files never requires rewriting the doctor or installer entry points. v0.3 ships the `core` profile only.
+
 ### Schema files
 
 These JSON Schemas are published and discoverable through the `exports` map:
@@ -73,6 +77,8 @@ These JSON Schemas are published and discoverable through the `exports` map:
 
 Existing consumers of `opencode-delivery@0.1.x` (commit-pinned shim) can run `pnpm dlx opencode-ship@latest init` from the same checkout. Migration recognises `.opencode/delivery.json`, `.opencode/delivery.lock.json`, the two canonical agents, and the generic plugin `.opencode/plugin/delivery.ts`, and adopts them when their bytes match. Legacy artifacts are preserved on disk so a downgrade remains possible; the installer does NOT modify Leo or any other consumer.
 
+`diff` is now strictly read-only; it reports every change but never writes to disk, even when the migration phase has a candidate seed-config to plant.
+
 ## Lifecycle
 
 1. Begin a Build task: the delivery plugin immediately runs any queued post-merge cleanups. Failed cleanups are recorded in `ship.lock.json#cleanupPending` and retried at the next delivery task or plugin startup.
@@ -100,12 +106,12 @@ Existing consumers of `opencode-delivery@0.1.x` (commit-pinned shim) can run `pn
 | `1` | expected negative result (`diff` saw changes; `doctor` unhealthy) |
 | `2` | invalid input, unsupported project, ambiguous detection |
 | `3` | ownership / hash / structural conflict |
-| `4` | filesystem, staging, rollback, or transaction failure |
+| `4` | filesystem, staging, rollback, or transaction failure; also surfaced when a catalog source is missing |
 | `5` | unsupported lock/config schema |
 
 ## Development
 
-`npm run verify` runs `format:check`, `lint`, `typecheck`, `build`, and the auto-discovered test suite. 150 tests cover lifecycle, drivers, recovery, doctor, agents, the installer CLI, plugin registration, the isolated packed-artifact smoke check, and the order-preserving root-config merge.
+`npm run verify` runs `format:check`, `lint`, `typecheck`, `build`, and the auto-discovered test suite. The tests cover the installer CLI, the lock and root-config planners, the catalog validator, the schema validator, agents, the packed-artifact smoke check, the transaction-recovery contract, the profile-resolution precedence chain, the catalog profile filter, and the order-preserving root-config merge. v0.4 ships with 226 tests across 34 suites on the approved plan hash `f85bae931d9eed7763e2f6f4dc68e5fad71bdd38c8a667fc9ffe78b5290200be`.
 
 ```
 npm ci
@@ -113,19 +119,19 @@ npm run build
 npm run verify
 ```
 
-The shipped artifact is built by esbuild (`scripts/build.mjs`); self-contained `dist/*.d.ts` are emitted by `tsc` from the in-package `src/plugin.ts`, `src/cli.ts`, and `src/core.ts` entry points. The `prepack` script fails closed if `esbuild` or `tsc` is missing or any required build artifact is absent.
+The shipped artifact is built by esbuild (`scripts/build.mjs`); self-contained `dist/*.d.ts` are emitted by `tsc` from the in-package `src/plugin.ts`, `src/cli.ts`, and `src/core.ts` entry points. The `prepack` script fails closed if `esbuild` or `tsc` is missing or any required build artifact is absent. The temporary config lives at `.tmp/tsconfig.dts.json`, under the gitignored `.tmp/` directory, so a tracked config file is never accidentally committed.
 
 ## Status and licensing
 
 - **License:** MIT. See `LICENSE`.
-- **Versioning:** SemVer. v0.2.0 is the first npm-distributed release. Subsequent releases follow standard `<major>.<minor>.<patch>` rules.
+- **Versioning:** SemVer. v0.2.0 is the first npm-distributed release. v0.3.0 is the installer foundation with core-only defaults. v0.4.0 adds the profile-aware installer foundation (`--profile` flag, lock schema v2, profile precedence) that issue #18 requires.
 - **Compatibility:** the bundled plugin targets `@opencode-ai/plugin >= 1.15.5 < 2` and OpenCode `>= 1.15.5`.
 
 ## FAQ
 
 **Is the package on npm?**
 
-Not yet. The repository is a draft PR. Once the release workflow lands, the first published tag will produce a GitHub Release tarball and (optionally) an npm release. Until then, install from a local tarball with `pnpm dlx --package=…`.
+Yes, `opencode-ship` is published as a public npm package. The release workflow at `.github/workflows/release.yml` validates the tag against `package.json`, packs a single tarball, publishes that tarball to npm (`--access public --provenance`), and uploads the same tarball as the GitHub Release asset. Consumers who cannot reach npm can run from the GitHub tarball URL shown in the release body.
 
 **Where is the `@opencode-ai/plugin` dependency?**
 
@@ -133,4 +139,12 @@ The plugin is bundled (`scripts/build.mjs` does not externalize it). Consumers d
 
 **What does `init` actually write?**
 
-It writes (or refreshes) the seven managed files in `.opencode/`, the user-owned `ship.config.json`, and the integrity-hashed `ship.lock.json`. It also merges eleven JSON-pointer values into the root `opencode.json` (or `.jsonc`) without overwriting unrelated keys. By default it does not create `opencode.json` — pass `--force-root-config` to do so.
+It writes (or refreshes) five managed files in `.opencode/`, plus the user-owned `ship.config.json` and integrity-hashed `ship.lock.json`. It also merges eleven JSON-pointer values into the root `opencode.json` (or `.jsonc`) without overwriting unrelated keys. By default it does not create `opencode.json` — pass `--force-root-config` to do so. The catalog validator runs first and exits `4` if a packaged source is missing, so the installer refuses to materialise a half-built state.
+
+**Where does the lock live and how is it integrity-checked?**
+
+`.opencode/ship.lock.json`. Every recorded file path, sha256, and pointer hash is rolled up into `integrity.lockSha256`. The installer refuses to write or apply updates against a tampered or schema-incompatible lock (`exit 3` for tampering, `exit 5` for an unsupported schema). Downgrading the schema is non-trivial; the lock schema version is part of the contract.
+
+**What is the canonical source tree?**
+
+`assets/` is the only path that ends up in the npm tarball alongside `dist/`, `schema/`, `docs/`, and `THIRD_PARTY_NOTICES.md`. The packaged plugin reads agent and skill bytes from `assets/agents/` and `assets/skills/`; the catalog declares these paths up front, and the doctor walks the catalog to verify install state. Anything copied under root `agents/` or `skills/` during local development is a build convenience, not part of the installable distribution.

package/THIRD_PARTY_NOTICES.md

@@ -0,0 +1,12 @@
+# Third-Party Notices
+
+`opencode-ship@0.4.0` ships the profile-aware installer foundation
+(`core` and `engineering` profiles). The current package version does
+not bundle third-party skill content. The `engineering` profile is
+the attribution surface for vendored upstream material; future
+releases that vendor skills must list the exact files, source
+commit, reuse mode, and license here.
+
+## Bundled skill content
+
+None in v0.4.0.