Remove repository examples

.agents/skills/effect-machine-pr/SKILL.md

@@ -17,27 +17,26 @@ Ship the requested change through a green, merged pull request. Treat invocation
 
 ## Implement the complete change
 
-1. Inspect the relevant public API, internals, tests, documentation, examples, and analogous Effect implementation before editing.
+1. Inspect the relevant public API, internals, tests, documentation, and analogous Effect implementation before editing.
 2. Implement the long-term design, including generic and optimized semantics where applicable. Follow the Cluster ownership boundary in `AGENTS.md`.
-3. Add observable runtime tests, typetests, differential tests, JSDocs, README or guide updates, and example changes required to make the feature complete.
+3. Add observable runtime tests, typetests, differential tests, JSDocs, README, and guide updates required to make the feature complete.
 4. Add a changeset when required. Use minor for a public addition or breaking change and patch for a compatible fix or implementation improvement. Never use major before 1.0.
 5. Keep the changeset user-facing: explain the resulting API and direct migration, not implementation history or external inspiration.
 
 ## Validate locally
 
 1. Run `pnpm check`.
-2. Run `pnpm check` in every affected package directly below `examples/`.
-3. Run `pnpm perf:types` for changes that affect the public TypeScript API or inference.
-4. Always run `pnpm perf:runtime` before publishing this full-lifecycle workflow. Treat the local run as a functional smoke test; the CI base-versus-PR comparison is authoritative.
-5. Fix every failure and repeat all affected checks. Treat correctness, type safety, runtime performance, and memory regressions as blockers.
-6. Audit the final diff, formatting, generated files, public terminology, changeset level, and working-tree scope.
+2. Run `pnpm perf:types` for changes that affect the public TypeScript API or inference.
+3. Always run `pnpm perf:runtime` before publishing this full-lifecycle workflow. Treat the local run as a functional smoke test; the CI base-versus-PR comparison is authoritative.
+4. Fix every failure and repeat all affected checks. Treat correctness, type safety, runtime performance, and memory regressions as blockers.
+5. Audit the final diff, formatting, generated files, public terminology, changeset level, and working-tree scope.
 
 ## Publish and merge
 
 1. Stage only the intended files, commit with a concise outcome-oriented message, and confirm the worktree is clean.
 2. Fetch the remote base again before pushing. If it advanced materially, integrate it safely and repeat affected validation.
 3. Push the branch and open a ready pull request using the repository template. Record the changeset decision and validation without copying noisy local benchmark tables.
-4. Monitor every required check, example job, and type/runtime performance workflow. Inspect the base-versus-PR reports, not only the aggregate green status.
+4. Monitor every required check and type/runtime performance workflow. Inspect the base-versus-PR reports, not only the aggregate green status.
 5. Diagnose failures from their logs, implement in-scope fixes, rerun relevant local checks, push, and continue monitoring. Never weaken semantics, inference, tests, or thresholds to make CI pass.
 6. Merge only when the pull request is current, mergeable, and every required check is green. Use the repository's normal squash-and-branch-cleanup convention unless instructed otherwise.
 7. Verify the pull request's remote state even if the merge command reports a local worktree checkout error. Confirm the merge commit is present on `origin/<base>` and the remote feature branch was removed.

.github/pull_request_template.md

@@ -10,7 +10,6 @@
 ## Validation
 
 - [ ] `pnpm check`
-- [ ] Relevant example checks, when examples changed
 - [ ] Automated type-performance measurement passed or was not required
 - [ ] Automated runtime- and memory-performance measurement passed or was not required
 

.github/workflows/ci.yml

@@ -43,68 +43,3 @@ jobs:
           github.head_ref == 'changeset-release/main' &&
           github.event.pull_request.user.login == 'github-actions[bot]'
         run: echo "Changesets release pull requests consume their changeset files."
-
-  discover-examples:
-    runs-on: ubuntu-latest
-    outputs:
-      matrix: ${{ steps.examples.outputs.examples }}
-      required: ${{ steps.examples.outputs.examples_required }}
-    steps:
-      - uses: actions/checkout@v7
-        with:
-          fetch-depth: 0
-      - id: examples
-        run: >-
-          node scripts/ci-changes.mjs
-          --base ${{ github.event.pull_request.base.sha }}
-          --head ${{ github.event.pull_request.head.sha }}
-          --github-output "$GITHUB_OUTPUT"
-
-  example:
-    needs: discover-examples
-    if: needs.discover-examples.outputs.required == 'true'
-    strategy:
-      fail-fast: false
-      matrix:
-        include: ${{ fromJSON(needs.discover-examples.outputs.matrix) }}
-    name: example (${{ matrix.example }})
-    runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: ${{ matrix.directory }}
-    steps:
-      - uses: actions/checkout@v7
-      - uses: pnpm/action-setup@v6
-        with:
-          package_json_file: ${{ matrix.directory }}/package.json
-      - uses: actions/setup-node@v7
-        with:
-          node-version: 24
-          cache: pnpm
-          cache-dependency-path: |
-            pnpm-lock.yaml
-            ${{ matrix.directory }}/pnpm-lock.yaml
-      - run: pnpm --dir ../.. install --frozen-lockfile
-      - run: pnpm --dir ../.. build
-      - run: pnpm install --frozen-lockfile
-      - run: pnpm check
-
-  examples:
-    if: always()
-    needs: [discover-examples, example]
-    name: examples
-    runs-on: ubuntu-latest
-    steps:
-      - name: Require every example check to pass
-        env:
-          DISCOVERY_RESULT: ${{ needs.discover-examples.result }}
-          EXAMPLES_REQUIRED: ${{ needs.discover-examples.outputs.required }}
-          EXAMPLE_RESULT: ${{ needs.example.result }}
-        run: |
-          test "$DISCOVERY_RESULT" = "success"
-          if test "$EXAMPLES_REQUIRED" = "true"; then
-            test "$EXAMPLE_RESULT" = "success"
-          else
-            test "$EXAMPLE_RESULT" = "skipped"
-            echo "Examples are not affected by this pull request." >> "$GITHUB_STEP_SUMMARY"
-          fi

AGENTS.md

@@ -61,14 +61,6 @@ pnpm perf:runtime
 
 Use the pull request performance workflows to compare against the base branch; do not draw conclusions from a single noisy benchmark run. Record the relevant checks and performance result in the pull request.
 
-When an example changes, run its own check from the example directory:
-
-```sh
-pnpm check
-```
-
-Every package directly below `examples/` must have a `check` script and a committed lockfile.
-
 ## Pull request conventions
 
 - Add or update a changeset for changes under `src/` or changes to `package.json`, following the changelog-writing guide in `.changeset/README.md`.

README.md

@@ -679,20 +679,6 @@ import { MachineTest } from "@typeonce/effect-machine/testing"
 
 Each ESM entrypoint is independent and tree-shakeable.
 
-## Examples
-
-Every package directly under [`examples/`](./examples) has its own lockfile and
-`check` script.
-
-| Example                             | What it demonstrates                                                                                                                                                                                          |
-| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [Playground](./examples/playground) | Five focused React examples: atomic turnstile commands, state-scoped traffic-light timers, hierarchical microwave safety, a resource-owned media player, and a worker-hosted machine synchronized across tabs |
-| [Pokémon](./examples/pokemon)       | Compound workflow states, invoked child machines, typed emissions, Atom reactivity, and a live Effect service                                                                                                 |
-| [Platformer](./examples/platformer) | Nested parallel statecharts, typed deep history, raised events, state-scoped timers, deterministic model tests, and a playable SVG adapter                                                                    |
-
-The playground is the shortest path from one concept to working code. The
-standalone examples show larger composition and ownership boundaries.
-
 ## Reference and development
 
 - [API reference](https://effect-machine.typeonce.dev)