code-standards

コード標準 — 変更ワークフロー

コードを変更します。このスキルは実行順序を示すもので、特定の技術スタックに依存しません。各コマンドはプロジェクトの実際のツールチェーンに合わせてください。作業を始める前に、プロジェクト独自のドキュメント（README、CONTRIBUTING、AGENTS.md／CLAUDE.md、Makefile、パッケージスクリプト）を一度読み、ビルド、テスト、リント、フォーマットのコマンドを確認してください。

手順

1. 状況を把握します。 プロジェクトの教訓や注意点を記録したファイル（例：tasks/lessons.md）を読み、内容に従います。 変更するサブシステムのドキュメントを1つ見つけて読み、ツリー全体は確認しません。
2. 複雑な変更の場合は計画します（手順が3つ以上、またはアーキテクチャ上の選択が必要な場合）。tasks/todo.md に簡潔な計画を記載します。変更するファイル、追加するテスト、リスクを含めてください。予定から外れた場合は、作業を止めて計画を立て直します。
3. ベースラインを確認します。 何も変更する前に、プロジェクトのビルドとテストのコマンドを成功させます。 既存の失敗があれば、まずそれに対処します。壊れたベースラインの上に作業を積み重ねてはいけません。
4. 実装します。 根本原因に対処する最小限の変更を行います。周辺のコードスタイルに合わせてください。 変更するファイルに一括自動フォーマッターを実行しないでください。 実際の差分がノイズに埋もれてしまいます。
5. テストします。 新しい動作には、変更がなければ失敗するテストを追加します。セキュリティ上の防御には、否定的なアサーションを含むテストを追加します（誤ったトークンなら拒否される、状態が変わらない、データが漏えいしない）。
6. 検証します。 「完了」とする前に、すべてのチェック（ビルド＋リント＋型チェック＋テスト）が成功するまで実行します。
7. セルフレビューします。 自分の差分を他の人のPRであるかのように確認します（またはレビュー用スキルを呼び出します）。指摘事項は提示前に修正します。
8. 締めくくります。 同じ変更でドキュメントを更新します。修正を受けたり、予想外のことがあったりした場合は、教訓を記録したファイルに追記します。Conventional Commits 形式のコミットメッセージを作成します（feat|fix|docs(scope): …）。

注意すべきポイント — 次の作業に取りかかるときは、いったん止まってプロジェクトのガイドラインを再確認します…

• 公開または共有インターフェース（API、ワイヤ形式、スキーマ）を変更する → すべての呼び出し元を確認し、追加による変更を優先します
• 依存関係を追加する → 推移的な依存のサイズとライセンス、標準ライブラリですでに対応できるかを検討します
• 認証、トークン、権限に触れる → 書き込みと読み取りのすべての経路を監査し、否定的なテストを追加します
• シークレットをディスクに書き込む → プラットフォームの原子的な非公開作成 API を使用し、書き込み後に chmod する方法は使いません
• await／ブロッキング呼び出し中にロックを保持する、またはロジック内で環境変数を読み取る → 純粋な判断関数として切り出します

進展がない場合のガード

修正を2回試みても同じ失敗が残る場合は、作業を止めます。見つかった問題を教訓ファイルに記録し、項目に [BLOCKED] を付けて、その状況を伝えます。闇雲に試行を繰り返してはいけません。