implementation-chainlisted

# Implementation Chain 実装に着手する前にタスク種別を判定し、対応する chain を **plan に front-load** する。 実装中は判定をやり直さず、定義済みの chain をそのまま実行する。 commit / push / 公開の権限は task request と substrate が持つ。この skill は追加の人間 gate を作らない。 ## タスク種別判定（最初の plan ステップ） | 種別 | 判定基準 | 例 | |------|---------|-----| | `feat` | 新規機能・新規モジュール追加 | API 追加, 新ページ | | `fix` | バグ修正（再現可能な不具合） | crash, 誤動作 | | `refactor` | 振る舞いを変えない構造変更 | 抽出, 改名, 整理 | | `chore` | 設定 / 依存更新 / コード付随の docs 追従 | settings, CI | | `prototype` | 学習・スパイク・本番外コード | 検証スクリプト | | `writing` | 文書自体が一次成果物 | README 改稿, 記事, 論文, llms.txt | `prototype` を選ぶ場合は **「prototype として扱う理由」を plan に必須記載**（fix/feat の悪用防止）。 **harness 自体の変更**: 対象が `~/.claude` の rules / skills / hooks / agents / settings なら、種別に関わらず Plan で skill: `harness-boundary` を 1 回通す（どの層に置くか・モデルに任せられないか・runtime 交換後も残すか。1 行の判断で足りる）。 **README の種別判定**: README 自体の改善・書き直しが目的なら `writing`（Writing Chain → readme-writer）。コード変更に付随する README 追従更新はコードチェーンの Doc Sync で、readme-writer の Incremental モードを使う。 **大きい feat の Plan の補助**: 探索が互いに独立した複数の領域にまたがるときは Explore agent を並列で使い、 各 agent に「主ループが読むべきファイル 5〜10」を返させて読む。設計代替は主ループが並べて比較し、推奨を 添えてユーザーに選ばせる（収束の所在は Matrix の Plan 行）。 **実行者の決定**（Plan の最後、必須）: plan が固まったら 「このセッションが実装するか」を 1 行で決める。判断が要るのは judge-tier の���ッション（Fable）で 走っているとき — そのまま実装に入ると、Review 群まで judge-tier を消費する（built-in `/code-review` と `/simplify` はセッションのモデルを継いで走り、モデル引数は無い。pin できるのは自作 agent と plugin agent の `model:` だけ）。**judge-tier の既定は dispatch**: 実装は build-tier の新規セッション へ渡し、本セッションは packet を書いて検証側に残る。dispatch 先の既定は **Cl