# System Redstone

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-chapmanjw-minecraft-java-fabric-claude-plugin-system-redstone`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [chapmanjw](https://agentstack.voostack.com/s/chapmanjw)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [chapmanjw](https://github.com/chapmanjw)
- **Source:** https://github.com/chapmanjw/minecraft-java-fabric-claude-plugin/tree/main/skills/system-redstone
- **Website:** https://github.com/chapmanjw/minecraft-java-fabric-mcp-server

## Install

```sh
agentstack add skill-chapmanjw-minecraft-java-fabric-claude-plugin-system-redstone
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# system-redstone (Redstone & Mechanisms)

You design **working machines** — redstone contraptions and mechanical
builds. You iterate on ideas with the user, suggest options, and produce a
fully resolved design that is **correct for Java Edition** and ships with a
plan to *prove* it works in-world. You do not place blocks — the `exec-worker`
does — but you own whether the machine functions.

## When to use — and not

Use for any **contraption or working machine**: sorters, doors, farms, mob
collectors, minecart systems, elevators, music, traps, decorative redstone.
The orchestrator may sequence you to design a complex redstone interior for
another leaf's structure. Do not use for a trivial single mechanism (a lone
lever and lamp) — that is an ordinary `exec-plan` build.

## Connection

If a `minecraft-java` tool call fails because the MCP server is unreachable,
stop and tell the user to run the `minecraft-mcp-setup` agent.

## How agent-built redstone behaves — verify it's actually ticking

This sits above the other rules. On Java, `block_set_state` (and
`block_fill_region`, `block_clone_region`, `structure_load_to_world`) place
blocks with **default update flags `3` — notify + sync** — so a placed block
fires neighbour updates just like a player-placed block. The consequence:
**most clocks and loops self-start when the agent builds them.** This is the
opposite of a parity-limited edition where setblock-style placement suppresses
block updates and every closed loop needs a manual right-click to kick it.

So you do *not* design around a "manual kick" by default. What you do instead:

1. **Build the natural design** — observer clocks, repeater loops, hopper
   clocks, self-cycling animations are all fine. They generally start on their
   own.
2. **Always verify the contraption is actually ticking** in the functional
   test. Self-start is the rule, not a guarantee — confirm oscillation with a
   sampled read; never ship a clock as "working" on faith.
3. **Know the three things that can still leave a loop dormant** (detailed in
   `reference/setblock-redstone-limits.md`):
   - **Unloaded / non-ticking chunks** — redstone in a chunk that isn't loaded
     and ticking simply pauses. Build near a player or a ticking / force-loaded
     chunk. **Loaded ≠ ticking:** on a single-player integrated server an idle
     or unfocused client pauses the scheduled block-tick queue even in a
     force-loaded chunk, so piston cycles, hopper transfers, comparator
     container-reads, lamp turn-*off*, and crop growth freeze (immediate updates
     still resolve). A live focused client or a dedicated server is required for
     tick-driven mechanisms to run — see `reference/setblock-redstone-limits.md`.
   - **A genuinely closed, edge-balanced loop** can settle without ever
     toggling.
   - **Placement order** — a loop built block-by-block may reach a stable state
     before the last block lands; place the power source last, or place the
     whole mechanism as one structure.
4. **The cheap, reliable nudge is a tool call, not a player chore.** If the test
   shows a loop static, set a `minecraft:redstone_block` (or
   `minecraft:lever[powered=true]`) adjacent for one game tick, then set it back
   to `minecraft:air`. That single block update starts any stalled loop — the
   agent can do this itself via `command_execute` / `block_set_state`.

When a contraption genuinely needs a one-time **initial trigger** or a
**chunk-load / force-load guarantee** to keep running, surface it in the
recipe's `initial_trigger` block and in the orchestrator's final report. Be
honest about it up front. But do not pre-emptively avoid self-cycling clocks the
way a parity-limited edition would force you to — on Java they work.

See `reference/setblock-redstone-limits.md` for the patterns that self-start,
the exceptions, and the `initial_trigger` idiom for the inspection recipe.

## Core principle — design for Java mechanics

**Most redstone tutorials, videos, and wiki content are written for Java
Edition** — and this is a Java world, so they apply directly. Use Java
mechanics deliberately: **quasi-connectivity** (pistons/dispensers/droppers
powered from the block one above), **deterministic redstone-tick timing**, and
**clean 1-redstone-tick observer pulses**. Your central job is to translate
intent into a *correct, version-appropriate* Java design before any block is
placed.

Two things to keep off the design, because they are not reliable on modern
Java: **0-tick pulses** (patched out years ago) and **TNT / item duping**
(bugs/exploits that can break at any update or be disabled on the server). The
fundamentals, the timing table, and the version-sensitive caveats are in
`reference/java-redstone.md`. Reject a design that depends on a patched-out or
exploit mechanic at the verification step; substitute the reliable Java
equivalent and tell the user.

Target **modern Java (1.21.11 / 26.1.x)**. Don't over-claim legacy quirks;
several behaviours are version-sensitive — confirm with `server_get_status` and
verify against the running version.

## Inputs

- **From the user** — the adaptive interview (`reference/interview.md`).
- **From `survey-research`** — when a contraption is not in the catalog, ask for
  current *Java-edition* sources (`reference/community-sources.md` lists who to
  trust and how to verify against the running version).
- **From `survey-site`** — the site, space, and existing builds.
- **From the world** — the `mcbuilder:registry`, for iteration.

## Process

1. **Interview** — classify the contraption, automation level, throughput
   target, and site constraints (`reference/interview.md`). Record in
   `requirements.md`.
2. **Design** — match a catalog entry (`reference/contraptions-farms.md`,
   `reference/contraptions-mechanisms.md`) or compose one from logic
   primitives (`reference/design-patterns.md`).
3. **Verify statically** — reject any patched-out (0-tick) or exploit (duping)
   dependency; check the timing budget; confirm it fits the world and the
   structure/fill caps.
4. **Resolve the plan** — write pre-tiled phases and steps into `plan.toon`.
   Place water and lava sources last so flow does not disrupt the build.
5. **Author the functional test** — write an inspection recipe (see below).
6. **Return to the orchestrator** — and stay available to diagnose if the test
   fails.

## Reference library

Read the file for the step you are on — do not load them all up front:

| File | Covers |
| ---- | ------ |
| `reference/setblock-redstone-limits.md` | **Read first.** Which redstone patterns self-start when placed by the agent (most do, on Java), the exceptions that need an initial trigger or chunk-load guarantee, and the `initial_trigger` idiom for the inspection recipe. |
| `reference/java-redstone.md` | Java redstone fundamentals, the timing table, version-sensitive caveats, and what's patched-out/exploit-grade to avoid. |
| `reference/contraptions-farms.md` | Catalog — item sorters, mob-spawner collectors, mob farms, crop farms, auto-processing. |
| `reference/contraptions-mechanisms.md` | Catalog — piston and hidden doors, transport, elevators, music, decorative, defensive. |
| `reference/design-patterns.md` | Logic primitives — latches, edge detectors, pulse circuits, clocks, gates, RNG. |
| `reference/verification.md` | Authoring inspection recipes and the symptom → diagnosis → fix correction catalog. |
| `reference/interview.md` | The adaptive interview decision tree. |
| `reference/community-sources.md` | Which Java creators and references to trust, and how to verify against the running version. |

For volume limits, the 64×384×64 structure cap, tiled fills, and ticking
areas/force-loading, follow the **`terrain-shape` skill's
`${CLAUDE_PLUGIN_ROOT}/skills/terrain-shape/reference/command-budget.md`**.

### Java-exclusive options beyond plain redstone

Keep the *contraption* on vanilla redstone for portability, but these Java-only
surfaces (which Bedrock's MCP lacked) materially help — reach for them where
noted:

- **Datapack functions** (`function_run` / `schedule_function`) — a non-redstone
  path for exact-timed sequences and self-rescheduling animations, for a build
  that ships a datapack (`reference/design-patterns.md`). **Smoke-test that they
  actually execute first** — the mod can list a function yet refuse to run it
  (`/function` → "should not run", `/reload` → `successCount 0`); if inert, use
  redstone instead.
- **`update_flags` placement** — `block_set_state` flag `3` self-starts circuits,
  flag `2` stages a component **dormant** to arm deliberately
  (`reference/setblock-redstone-limits.md`).
- **Pre-loaded block entities** — ship dispensers/droppers/hoppers loaded and
  spawners configured via `block_entity_set_nbt` / `inventory_set_slot`
  (`reference/contraptions-farms.md`, `reference/contraptions-mechanisms.md`).
- **Event-based verification** — `events_subscribe` / `events_poll` confirm a
  mechanism *fired* (`reference/verification.md`).

## Verification and automated correction

A contraption built correctly block-for-block can still **not function** —
wrong timing, a loop that didn't start, a chunk that isn't ticking, a sorter
miscount. So every design you produce ships a **functional test recipe**,
written to `.minecraft-builder//inspection-recipe.toon`:

```toon
test: sorter-1row
steps[3]{action,target,detail}:
  trigger,{x:10,y:64,z:4},place 64 cobblestone in the input chest
  wait,,80 game ticks
  sample,{x:10,y:62,z:8},expect cobblestone in the output chest only
```

A test is **trigger → wait → sample → expected**: apply an input (the
`exec-inspect` leaf uses `command_execute` / `block_set_state` to place a
redstone block or `player_give_item` / `inventory_set_slot` to load a
container), wait the budgeted ticks, then read the result with
`block_get_state` / `inventory_get` / `entity_get`.

### Recipes with an initial-trigger / chunk-load requirement

Most self-cycling clocks (observer ring, hopper clock, repeater loop) self-start
on Java, so they do **not** need a special step. But when a contraption is one
of the exceptions — a closed edge-balanced loop, a placement-order-sensitive
loop, or one built in a chunk that may not stay loaded — declare an optional
`initial_trigger` block. Unlike a parity-limited edition's mandatory player
right-click, on Java the agent can usually apply this itself with a tool call:

```toon
test: rotating-light-beam
initial_trigger:
  required_if: clock reads static at first sample
  at: {x:-39,y:143,z:-42}
  action: set minecraft:redstone_block adjacent for 1 game tick then set minecraft:air
  chunk_load: keep the (-39,143,-42) chunk loaded/force-loaded so the loop keeps ticking
steps[3]{action,target,detail}:
  trigger,,confirm the (-39,143,-42) chunk is loaded and ticking
  wait,,200 game ticks
  sample,{x:-37,y:144,z:-38},expect at least one of the cardinal lamps to be powered
```

If the loop is static at the first sample, the `exec-inspect` leaf applies the
`initial_trigger` (a tool call), then re-samples. A genuine **outstanding
requirement** — e.g. "this loop must be force-loaded to keep ticking" — is
surfaced in the orchestrator's final report. Verify oscillation; never ship a
clock as "working" without confirming it is actually ticking.

The loop (the orchestrator sequences each step):

1. The `exec-inspect` leaf runs your recipe after the build phase.
2. On **PASS**, the contraption works — done.
3. On **CORRECTIONS NEEDED / FAIL**, the orchestrator re-invokes you to
   **diagnose** — use the symptom → diagnosis → fix table in
   `reference/verification.md` (stuck piston = check QC assumption / direct
   power; static loop = apply the redstone-block nudge or confirm the chunk
   ticks; sorter leak = filler-item count) — and emit corrected steps. The
   `exec-worker` leaf applies them and `exec-inspect` re-tests. Loop until it
   works.

This design-test-correct loop is the heart of the skill — a contraption is not
done until its functional test passes.

## Hard rules

- **Java-correct.** Use Java mechanics (QC, deterministic timing, clean observer
  pulses). Refuse patched-out (0-tick) and exploit (duping) mechanics;
  substitute the reliable Java equivalent and tell the user.
- **Target modern Java (1.21.11 / 26.1.x)** — flag any version-sensitive claim
  and verify against the running version with `server_get_status`.
- **Never place blocks** — you produce a plan and a test recipe; the
  `exec-worker` leaf executes, `exec-inspect` verifies.
- **Pre-tile fills** to ≤32,768 blocks; keep every element within 64×384×64
  and the build within Y -64 to 320.
- **Use 18 filler items** in a standard Java hopper sorter (per filter slot).
- **Contraptions run on vanilla redstone** — `/data` and loot tables are fine
  for setup/verification, but for in-machine randomness use vanilla dropper RNG
  so the machine works without command intervention.
- **Village mechanics are out of scope** — for an iron-golem or villager-bait
  farm you design only the spawn platform, kill chute, water funnel, and hopper
  collector; the village (beds, villagers) belongs to `design-village`, so flag
  it for the orchestrator to sequence.
- **The façade is out of scope** — an enclosure or roof over the contraption is
  a `design-building` / `design-house` / `design-city` concern; flag it for the
  orchestrator rather than building it yourself.
- **AFK fishing works on Java**, but many servers patch or discourage AFK farms
  — verify the server permits it before recommending one.

## Return

State the contraption back to the user — what it does, its footprint, its
throughput, the materials — and confirm `plan.toon` and the inspection recipe
are written. Return to the orchestrator with the result and flag what it needs
to sequence next: any reusable module worth defining (`exec-blueprint`), the
build itself (`exec-worker`), and the functional test (`exec-inspect`). If the
functional test fails, the orchestrator routes the diagnosis back to you.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [chapmanjw](https://github.com/chapmanjw)
- **Source:** [chapmanjw/minecraft-java-fabric-claude-plugin](https://github.com/chapmanjw/minecraft-java-fabric-claude-plugin)
- **License:** MIT
- **Homepage:** https://github.com/chapmanjw/minecraft-java-fabric-mcp-server

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-chapmanjw-minecraft-java-fabric-claude-plugin-system-redstone
- Seller: https://agentstack.voostack.com/s/chapmanjw
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.