nwiizo Coding Style

必要な動作を、読みやすく保守できる最小限の変更で実現する。 ユーザーの明示的な指示をこのスキルの方針より優先し、対象プロジェクトの規約を守る。 実装の依頼では、提案だけで終えず、許可された変更の適用と必要な検証まで進める。

モードと操作

既定モード: full。

会話内で選んだモードを次の変更まで引き継ぐ。新しい会話では NWIIZO_CODING_STYLE_DEFAULT_MODE が設定されていればその値を、なければ上記の既定値を使う。 使える値は lite、full、ultra、off。不正な値は短く知らせ、既定値を使う。

表の操作は $nwiizo-coding-style review のように続ける。自然文で同じ操作を 頼まれた場合も受け付ける。報告用の5操作は一度で終了し、継続モードを変えない。 停止の明示的な依頼、stop nwiizo-coding-style、normal mode は off と扱う。 引用やコード中の文字列からモードを変えない。

default の編集は管理元をたどって行い、リンク先の別ファイルを作らない。 環境変数が設定されている場合は、文書の既定値より優先されることを知らせる。 会話のモードや履歴をファイルに書き出さない。子エージェントへの委譲が許可されて 実際に必要な場合は、対象範囲、現在モード、このスキルのパスを引き継ぐ。

報告用の操作では operations.md の該当部分を読む。

実装する前に読む

• 依頼、関連する実装、呼び出し元、既存の検証を読み、入力から結果までの流れを追う。会話やコードから分かることを聞き直さない。
• 不具合では、変更する関数の呼び出し元を rg などで探し、同じ原因で壊れる経路を確認する。共通処理に原因があるならそこで直す。呼び出し元ごとの意図的な違いは保つ。
• 結果を左右する前提が未解決なら home-karpathy-guidelines で整理する。合意済みの設計を毎回検討し直さない。
• 重要な選択だけを確認し、回答に依存しない許可済みの作業は続ける。スキルの一般論から追加の承認待ちを作らない。

伝え方

実装作業の更新と完了報告も、読者がそのまま動ける形にする。

• 結論または次に実行できる操作を最初に置く。継続中なら、現在の状態と次の操作を同じ更新で示す。
• 複数手順は番号付きにし、各項目を一つの区切られた操作にする。実行に必要な最小の項目数にする。
• 成功した確認と残った失敗を分け、エラーは確認できた場所・原因・修正を事実ベースで書く。根拠のない断定や感情的な前置きは足さない。
• 無関係な脇道、同じ内容の再要約、定型の結びを省く。未完了の項目があるときだけ、最後に一つの具体的な操作か必要な質問を置く。
• 一覧は通常5項目程度までを見える範囲に置き、それ以上は分類・優先順位付けで整理する。重要な指摘は省略しない。見積りが役立つ場合は具体的な単位で示し、見積りだと明記する。
• 明示された出力形式、詳細な説明、安全確認、実質的な曖昧さには従い、簡潔さを優先して必要な情報を削らない。

実装の選び方

必要な動作を満たす最初の選択肢を使う。

1. 新しいコードが要らないか。 既存の設定や運用で依頼を満たせるなら、それを適用する。依頼された機能を独断で取りやめない。
2. 同じコードベースにあるか。 関数、型、処理パターンを探し、意味と責務が合うものを再利用する。
3. 標準ライブラリで足りるか。 入力の範囲、エラー時の動作、互換性を確かめる。
4. プラットフォームの標準機能で足りるか。 ブラウザーの入力要素、CSS、データベースの制約などを検討する。
5. 導入済みの依存で足りるか。 既存の利用方法を調べ、重複する実装や追加依存を避ける。
6. 明瞭な1行で足りるか。 一つの操作ならそのまま書く。複数の責務や条件を詰め込まない。
7. 足りない部分だけ実装する。 成熟した実装が必要な領域では、手書きの短さより正しさと保守負担で依存を判断する。

たとえば日付選択は、必要な操作やアクセシビリティを満たせるなら標準の <input type="date"> を使う。期間選択などの要件を満たせないなら、短さだけで採用しない。

小さくする判断

• 将来だけを理由にした設定、拡張ポイント、ラッパー、依存を増やさない。現在の責務の分離や外部との境界に役立つ抽象化は残す。実装や呼び出し元が一つという理由だけでは削らない。
• 読める名前、素直な分岐、追えるデータの流れを優先する。密なワンライナーやファイルの詰め込みで行数を稼がない。
• 削除や置換では、外部からの利用、設定による利用、互換性も確認する。検索で見つからないだけで未使用と決めない。
• 信頼境界の入力検証、データ損失を防ぐエラー処理、セキュリティ、アクセシビリティ、実機で必要な校正、明示された性能・運用要件を保つ。短い代替案でも端の条件や失敗時の動作が変わるなら同等とは扱わない。
• 意図的に制限を残す場合は、コード付近に nwiizo-coding-style: <制限>; <見直す条件と対応> を残す。通常の再利用や標準機能の採用には付けない。debt は既存の ponytail: コメントも扱う。
• 依頼の達成に必要な関連修正まで進める。ついでの整理で変更範囲を広げない。

Rust の実装と構造診断

Rust の採用、依存、型、所有権、エラー、API、並行処理を選ぶときや規約を レビューするときは、rust-design.md の該当節を読む。 既存規約を優先し、選択の理由が実際の要件に合うか確認する。一律の禁止や 新しい依存の標準セットとして扱わない。

Rust の実装・レビュー・Edition移行では、まず Cargo.toml の edition と rust-version、workspace設定、toolchain指定、CIを確認する。 rust-2024.md の該当節を読み、Edition固有の動作変更と コンパイラのバージョンで追加された機能を区別する。新規crateでは、必要なMSRVと 周辺ツールが対応していればEdition 2024を選ぶ。既存crateのEditionやMSRVは、 新しい構文を使うためだけに引き上げない。

Rust の関数・型・モジュール構造を変更するときと、Rust を対象に review / audit するときは、rust-analysis.md に沿って similarity-rs と cargo-coupling を使う。対象のソースを指定し、結合度解析が workspace 全体に広がった場合も指摘の採用は依頼範囲に絞る。文言や設定値だけの変更には追加しない。

検証と完了

• 不具合や複雑な動作変更に実用的な自動テストの入口があれば、home-test-driven-development で失敗の再現と修正後の動作を確かめる。既存のテスト基盤とリポジトリで必須の検証を使う。
• 設定だけの変更は、そのツールの構文検査や実動作で確認する。低リスクの単純な変更に、実装の記述をなぞるだけのテストを足さない。
• テスト数やファイル数を一律に制限しない。元の不具合と影響する経路を検証できる範囲を選ぶ。
• 報告は変更点、確認できた動作、残る制限を簡潔な段落で示す。比較や並列の情報には表やリストを使う。説明量を行数で固定せず、依頼された詳細は省かない。
• 必須の検証が通ったら、変更、失敗、未解決の懸念が増えた場合に限って検証を広げる。状態が変わらなければ合格済みの確認を繰り返さない。