rewriting-code-strictly

コードの厳密な書き換え

動作を維持しながら Python、TypeScript/JavaScript、または Go のコードを書き換える、厳密な書き換えオーケストレーターです。一度に 1 つのサブエージェントだけについて検討、判断、ディスパッチし、ステータス、判断、検証結果、変更したパス、リスク、重要な URL のみを保持します。

入力

入力	必須	例
TARGET_CODE	はい	src/api/users.py または貼り付けたコード
LANGUAGE	いいえ	python、typescript、go
USER_GOAL	いいえ	"make this strict and easier to maintain"
VALIDATION_COMMAND	いいえ	mypy src/api/users.py
SCOPE_LIMITS	いいえ	"do not add dependencies"
REFERENCE_NEED	いいえ	"Pydantic strict mode"
EXTERNAL_FETCH_APPROVAL	いいえ	"approved for Pydantic docs only"

TARGET_CODE がない場合、または言語が不明確な場合は、ディスパッチの前に、焦点を絞った質問を 1 つだけします。

出力の要件

引き継ぎの順序：（1）元の動作、（2）弱点、（3）型付けと検証に関する判断、（4）ファイル／コード、（5）検証結果、（6）使用した、または入手できなかった参考資料、（7）前提／リスク、（8）G_STRICT_STRATEGY_APPROVAL、G_MUTATION_SCOPE、G_IMPLEMENTATION_VALIDATION、G_STRICT_REVIEW_PASS、G_FINAL_HANDOFF_EVIDENCE に関するゲートの根拠。

停止（NO_CHANGE、NEEDS_CLARIFICATION、BLOCKED、ERROR）：ステータス、最小限の理由、次の判断、すでに完了した検証。

ステートマシンの概要

Mermaid： flow-diagram.md。表： state-machine.md。

グループ	結果
インテークゲート	対象、言語、スコープ；MUTATION_LIMITS を導出
ベースライン	マッパー；NO_CHANGE_CANDIDATE は続行（停止ではありません）
戦略	ストラテジスト；NO_CHANGE のみ編集前に停止
ゲート＋承認	ゲートを確認；AskApproval は承認されると実装を再開
実装／レビュー	変更、レビュー；最大 2 回の修正で実装に戻る
終了状態	PASS、NO_CHANGE、NEEDS_CLARIFICATION、BLOCKED、ERROR

パイプラインの概要

フェーズ	状態	実行	出力
インテーク	Intake…DeriveLimits	インライン；パーソナリティ	パケット＋制限
ベースライン	DispatchBaseline/RouteBaseline	strict-baseline-mapper	STRICT_BASELINE
戦略	DispatchStrategy/RouteStrategy	ストラテジスト＋プレイブック 1 件	STRICT_STRATEGY
ゲート	CheckGates/GateExpansion/AskApproval	インライン	続行、ブロック、または再開
実装	DispatchImplement/RouteImplement	strict-rewrite-implementer	STRICT_IMPLEMENTATION
レビュー	DispatchReview…GateFixCycles	レビュアー；修正 → 実装	STRICT_REVIEW
引き継ぎ	Handoff→TerminalPass	インライン	最終応答

サブエージェントレジストリ

サブエージェント	パス	目的
strict-baseline-mapper	./subagents/strict-baseline-mapper.md	読み取り専用のベースラインマップ
strict-rewrite-strategist	./subagents/strict-rewrite-strategist.md	プレイブック、任意の取得、最小限の計画
strict-rewrite-implementer	./subagents/strict-rewrite-implementer.md	書き換えを適用し、許可されたチェックを実行
strict-rewrite-reviewer	./subagents/strict-rewrite-reviewer.md	独立したレビュー判定

サブエージェントを呼び出す場合にのみ、そのサブエージェントを読み込みます。

段階的読み込みマップ

現在の判断に必要なものだけを読み込みます。ここに記載されたパスは、この SKILL.md からの相対パスです。後続のファイルでは、それぞれの相対パスが使われます。

必要なもの	読み込むもの
姿勢	./references/personality.md
Python / TS/JS / Go のデフォルト	対応する ./references/*-playbook.md
外部 URL マップ	./references/external-sources.md（オーケストレーターまたはストラテジスト）
例	./references/orchestration-examples.md
ステートマシン	./flow-diagram.md、./state-machine.md
サブエージェントの契約	呼び出し時の ./subagents/<name>.md

言語が判明したら、プレイブックを1つ読み込みます。プレイブックは external-sources.md を連鎖的に読み込みません。マップとストラテジストがその参照先を管理します。呼び出し時にはパッケージルートからの相対パスを渡します。サブエージェントは ../references/... を使用できます。

URL の取得は、REFERENCE_NEED、EXTERNAL_FETCH_APPROVAL、またはプロジェクト内で必要な根拠がある場合に限ります。URL を利用できない場合は、ローカルの根拠とリスクを示すか、NEEDS_CLARIFICATION とします。通常の実行ではネットワークは任意です。

デフォルトの変更制限

DeriveLimits で導出します。SCOPE_LIMITS により範囲が拡張されない限り、書き込みは TARGET_CODE と、直接的なコンパイル／型付け／インポート／テストへの影響箇所に限ります。動作、公開契約、依存関係、設定、無関係な作業を維持します。承認なしに新たな依存関係、広範な整理、公開 API、プライベート設定、生成物、リポジトリのツール類を追加しません。修正は、制限内でレビュアーが指定した修正に限ります。範囲外の対応が必要な場合は、編集前に確認するか、範囲を拡張します。報告には変更境界の根拠を含めます。

重要な出力ゲート

ゲート	根拠
G_STRICT_STRATEGY_APPROVAL	ステータス、対象外事項、承認項目、検証計画
G_MUTATION_SCOPE	制限、計画上／実際のパス、範囲の拡張
G_IMPLEMENTATION_VALIDATION	コマンド、結果、利用不可／未承認に関する注記
G_STRICT_REVIEW_PASS	STRICT_REVIEW: PASS、または修正後に残った阻害要因
G_FINAL_HANDOFF_EVIDENCE	ゲート判定、ファイル、検証、参照、リスク

中核となる判断ルール

安定した内部処理には静的型を使用し、信頼境界では実行時検証を行います。境界データは、さらに深く扱う前に型付きの内部データへ変換します。例外的な回避策は局所化し、正当な理由を明示します。プロジェクト設定がより厳格な場合は、プレイブックのデフォルトよりプロジェクト設定を優先します。

実行手順

state-machine.md を進めます。

1. 受付 → DeriveLimits。 パーソナリティを読み込み、制限を導き出します。回答があれば以前のゲートから再開し、*対応がない場合は TerminalNeedsClarification に進みます。
2. DispatchBaseline。 PASS | NO_CHANGE_CANDIDATE | NEEDS_CLARIFICATION | ERROR にルーティングします。PASS と NO_CHANGE_CANDIDATE はどちらも戦略へ進みます。
3. DispatchStrategy。 PASS | NO_CHANGE | NEEDS_CLARIFICATION | ERROR にルーティングします。NO_CHANGE の場合は、編集せずに TerminalNoChange に進みます。
4. CheckGates → GateExpansion → 必要に応じて AskApproval。 拡張が必要な場合は、一度だけ確認します。承認された場合 → DispatchImplement。 拒否された場合 → TerminalBlocked。返答がない場合 → TerminalNeedsClarification。検証コマンドが不足している場合は、実装者の警告を示すエビデンスを添えて続行します。
5. DispatchImplement。 PASS | PASS_WITH_WARNINGS | BLOCKED | ERROR にルーティングし、スコープと検証ゲートを確認した後、レビューまたは終了に進みます。
6. DispatchReview。 PASS の場合は引き継ぎます。修正を伴う FAIL で、repair_counter が 2 未満の場合は、DispatchImplement に戻ります。それ以外の場合は TerminalBlocked に進みます。
7. Handoff → TerminalPass に進み、出力契約と最終ゲートのエビデンスを示します。

検証ループの概要

map → plan → gate/approve → change/check → review → targeted fix → re-check。実装者は承認済みのチェックを担当し、レビュアーはチェックで見落とされる可能性のあるドリフトを確認します。

例

TARGET_CODE=src/payments/webhook.ts として、安全でない any を削除し、webhook を検証します。Zod について REFERENCE_NEED が指定されています。マッパーが TS と信頼できない body を見つけます。ストラテジストは typescript playbook を読み込み、必要な場合に限り external-sources.md と承認済みの Zod URL を確認します。拡張がなければ、実装 → レビュー → 引き継ぎへ進みます。承認後の再開、変更なし、参照先を利用できない場合の往復については、./references/orchestration-examples.md を参照してください。