レッドストーン回路の自動テストが失敗した際の切り分け・局所修正手順。CLI版の mc-cli get-blocks, interact-block, place-blocks を使ったデバッグ方法を定義する。
redstone_concept_adder
半加算器・全加算器・Nビット加算器のレシピ。モジュール分割、キャリー伝播、タイミング、フェーズ構成、サーバー環境固有の注意点を含む。加算器を設計する前に必ず読む。
含まれるファイル(1)
- SKILL.md8.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
加算器 (Adder) の設計レシピ
このスキルは、レッドストーンによる加算器(半加算器 / 全加算器 / Nビットリップルキャリー加算器)を設計・実装するための典型レシピです。加算器は全加算器の繰り返しで構成できる典型問題であり、モジュール分割と契約ベースの設計に最も適した題材です。
設計前に以下も必ず読むこと:
.agents/skills/tool_pitfalls/SKILL.md(トラップ集).agents/skills/redstone_concept_logic_gates/SKILL.md(XOR/AND/OR).agents/skills/minecraft_block_summary/SKILL.md- 使用する個別ブロックのスキル(repeater / comparator / observer 等)
1. 加算器の論理構成
1.1 半加算器 (Half Adder, HA)
2つの1ビット入力 A, B を加算し、和 S と桁上げ C を出力する。
| A | B | S | C |
|---|---|---|---|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 1 | 0 |
| 1 | 0 | 1 | 0 |
| 1 | 1 | 0 | 1 |
- S = A XOR B
- C = A AND B
1.2 全加算器 (Full Adder, FA)
2つの1ビット入力 A, B と下位からの桁上げ Cin を加算し、和 S と上位への桁上げ Cout を出力する。
| A | B | Cin | S | Cout |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 |
| 0 | 1 | 0 | 1 | 0 |
| 1 | 0 | 0 | 1 | 0 |
| 1 | 1 | 0 | 0 | 1 |
| 0 | 0 | 1 | 1 | 0 |
| 0 | 1 | 1 | 0 | 1 |
| 1 | 0 | 1 | 0 | 1 |
| 1 | 1 | 1 | 1 | 1 |
- S = A XOR B XOR Cin
- Cout = (A AND B) OR ((A XOR B) AND Cin)
1.3 全加算器のモジュール分割(推奨構成)
全加算器は以下の3モジュールに分割して設計するのが最もデバッグしやすい。親がこの分割を「モジュール仕様契約」として定義し、各モジュールを別サブエージェントに作らせることで、Flash級の推論でも確実に構築できる。
HA1(A, B) --> S1, C1
HA2(S1, Cin)--> S, C2
OR(C1, C2) --> Cout
- モジュールHA1: 入力 A, B → 出力 S1 (=A XOR B), C1 (=A AND B)
- モジュールHA2: 入力 S1, Cin → 出力 S (=S1 XOR Cin), C2 (=S1 AND Cin)
- モジュールOR: 入力 C1, C2 → 出力 Cout (=C1 OR C2)
ポイント: HA1の出力 S1 を HA2 の入力に接続する際、信号到達タイミングを合わせるためにリピーターで遅延を明示的に確保すること。
1.4 Nビット リップルキャリー加算器
全加算器を N 個直列に接続し、下位の Cout を上位の Cin に繋ぐ。
FA0(A0,B0,Cin=0) --> S0, C0
FA1(A1,B1,Cin=C0) --> S1, C1
FA2(A2,B2,Cin=C1) --> S2, C2
...
FAn(An,Bn,Cin=Cn-1)--> Sn, Cout
- キャリー伝播のタイミング: 各FAのCoutが次のFAのCinに届くまでに、上位ビットのA,B入力を待機させる必要がある。各FA間にリピーター遅延を挿入し、キャリー到達後に上位ビット評価を行う。
- モジュール分割: 各FAを1モジュールとし、キャリー伝播経路を契約の「接続ポート」として明示する。
2. XOR ゲートの実装方針
XOR は加算器の核心であり、実装方式によって回路サイズとタイミングが大きく変わる。
2.1 コンパレーター減算式(アナログ入力推奨)
- 信号強度の減算
(A-B)+(B-A)で XNOR を作り、NOT で XOR にする。 - アナログ0-15入力の加算器(16進加算器等)では最もコンパクト。
- 注意: コンパレーター入力までのアナログ配線は 5〜8ブロック以内 に収めること。それ以上離すと減衰で論理判定が壊れる。アナログ経路にリピーターを置くと強度15に二値化されるため、アナログ回路内では絶対に置かない。
2.2 トーチ/ダスト式(二値入力)
- NOT + AND + OR の組み合わせで構成。
- 二値入力の加算器ではこちらが素直。
- トーチの反転段数分の遅延(1RSチック/段)がかかるため、タイミング設計に注意。
3. サーバー環境固有の注意点(必読)
本サーバー環境では以下の仕様が確認されている。これらを守らないと配線が繋がらない。
3.1 facing は「入力方向」を指す
repeater / comparator / observer の facing は 主入力が侵入する方向(入力面) を指す。バニラの感覚(出力方向)とは逆になる点に注意。
- これらは AGENTS.md の絶対制約に従い
connectsのsrc/dstで配置し、facingを自動計算させること。 connectsではsrc(入力元)→dst(出力先)の順で指定。信号は src → dst に流れる。
3.2 アナログ信号は 5〜8 ブロック以内
アナログ(0-15)信号を扱う場合、入力からロジック端子(コンパレーター等)までの配線距離は 最大5〜8ブロック以内 に収めること。
- アナログ経路にリピーターを置くと強度15に二値化され、アナログ情報が失われる。
- 超近接マージ配線で減衰を最小化する。
3.3 フェーズ分離で BUD-lock 回避
レッドストーンソースブロック(レバー、RSブロック等)をデバイスと同Tickで配置すると、ブロック更新がスキップされリピーターがOFFのままロックされる(BUD-lock)。
- 配置順序を 「フェーズ1: デバイス → フェーズ2: ソース」 に分離する。
- フェーズ配列
[PlaceRequest, PlaceRequest]を使用し、フェーズ間は自動的に1tick待機が入る。
3.4 動的状態(powered/lit/power)は place_blocks で書き換えない
powered、lit、power 等の動的状態を place_blocks で直接書き換えてはいけない。正規のプレイでは不可能な操作であり、ブロック更新ループが壊れて異常動作を引き起こす。
- レバー/ボタンの操作は必ず
interact_blockを使用する。 interact_blockの同期ズレを回避するため、操作後はwait_ticks(2)以上の待機を入れてから観測する。
4. 典型フェーズ構成(全加算器)
全加算器を配置する際の典型フェーズ構成。PlaceRequest のフェーズ配列 [PlaceRequest] を使用する。
- フェーズ1(土台・不透過ブロック):
minecraft:stone等で土台を敷き、モジュール間の混線防止用の不透過ブロックも配置。 - フェーズ2(論理デバイス): リピーター、コンパレーター、トーチ、ダスト等の論理素子。
connectsを使用してfacingを自動計算。 - フェーズ3(ソース・入力機器): レバー、ボタン、RSブロック等。BUD-lock 回避のためデバイスより後のフェーズに分離。
- フェーズ4(プローブ/観測点): 必要に応じて観測用ランプやダスト。テスト時には
self.probe(name, pos)で時系列取得を推奨。
土台クリアは
CircuitTest.clear_area = [x1,y1,z1,x2,y2,z2]を使うと、各テスト前に自動でminecraft:airクリアされる(setup内にair fillsを書く手間とミスを防ぐ)。
5. モジュール仕様契約の典型フォーマット
親が契約を定義し、各モジュールを別サブエージェントに作成させる際の典型フォーマット。以下を各モジュールごとに定義する。
### モジュール: HA1
- 入力ポート:
- A: [x, y, z](二値 0/15 または アナログ 0-15)
- B: [x, y, z]
- 出力ポート:
- S1: [x, y, z](= A XOR B、期待信号強度)
- C1: [x, y, z](= A AND B)
- 電源/接地: (必要に応じて)
- フェーズ構成: フェーズ1(土台)→ フェーズ2(デバイス)→ フェーズ3(ソース)
- タイミング: 入力確定から出力確定までの期待遅延(RSチック数)
- 単体テスト:
- 入力 A=0, B=0 → S1=0, C1=0
- 入力 A=1, B=0 → S1=1, C1=0
- 入力 A=0, B=1 → S1=1, C1=0
- 入力 A=1, B=1 → S1=0, C1=1
各モジュールはこの契約(入力ポートに所定信号 → 出力ポートに所定信号)だけを保証すればよい。統合時に契約違反モジュールが機械的に特定できる。
6. ソース (References)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
レッドストーン回路の自動テストが失敗した際の切り分け・局所修正手順。get_blocks, interact_block, place_blocks を使ったデバッグ方法を定義する。
agent 向けテキスト指示(skill / slash command / task プロンプト / CLAUDE.md 節 / コード生成プロンプト)を、バイアスを排した実行者に動かしてもらい、両面(実行者の自己申告 + 指示側メトリクス)で評価して反復改善する手法。改善が頭打ちになるまで回す。プロンプトや skill を新規作成・大幅改訂した直後、またはエージェントの挙動が期待通りにならない原因を指示側の曖昧さに求めたいときに使う。
Minecraft のレッドストーン回路や構造物を設計するための、JSON データモデルの仕様と設計ガイドラインです。
CLI版 mc-cli drop-items コマンドの使い方。ホッパーやコンテナに投入するアイテムを世界にドロップする時に読む。
CLI版 mc-cli fill コマンドの使い方。土台作成や範囲消去(air)を行う前に読む。