fix-issue

za:fix-issue — issue を実装してコミット

GitHub issue を起点に、プロジェクトのルールに沿って実装し、専用ブランチでコミットする ところまでを一気通貫で行う。狙いは、issue に書かれた意図を正しく実装に落とし、 作業を追跡可能なブランチ単位に切り分けること。

下の手順を順番に実行する。コミットはするが、push や PR 作成まではしない （そこは別の作業）。

手順

1. 対象の issue を取得する

実装対象は、このスキルに渡された引数の issue 番号から特定する （例: /za:fix-issue 42）。gh issue view <番号>（必要なら --comments）で、 タイトル・本文・コメント・ラベルを取得し、何を作るのかを把握する。

• 引数が無い場合: gh issue list（オープンな issue、必要なら自分担当 --assignee @me）を 提示し、「どの issue を対応しますか？」とユーザーに確認する。
• 番号の issue が見つからない／クローズ済みの場合: 推測で別の issue を実装せず、 状況を伝えて確認する。
• リポジトリが git でない、gh で issue を取得できない場合も、その旨を伝えて確認する。

2. 実装ルールを読む

docs/rules/ 配下の *.md をすべて読み込む。これはコーディング規約・命名・テスト方針・ コミット規約など、このプロジェクトで実装が従うべきルール。実装とコミットは必ずこれに従う （プロジェクトがルールの所有者であり、こちらが我流を持ち込まない）。

• ディレクトリやファイルが無い場合: 「docs/rules/ が無いため、既存コードの流儀に 合わせて実装します」と伝え、リポジトリの既存コードの規約（命名・構成・テストの書き方）を 読み取って準拠する。

3. 作業ブランチを作成する

feature/{issue番号}-{title} の名前でブランチを切る。

• {title}: issue タイトルから作る短い kebab-case スラッグ（小文字英数字とハイフン）。 タイトルが日本語の場合は、要点を表す短い英語スラッグにする（例: 「ログイン機能の追加」→ add-login）。長すぎる場合は要点だけに切り詰める。
• 切る前に作業ツリーの状態を確認する（git status）。未コミットの変更があれば、 混ざらないようユーザーに確認する。
• 分岐元は原則として最新のデフォルトブランチ（main 等）にする。必要なら先に git switch main → 最新化してから分岐する。
• ただし 現在のブランチがデフォルトブランチでない場合は、勝手に分岐元を決めず ユーザーに確認する。「現在のブランチ（{現在のブランチ名}）から分岐するか、デフォルト ブランチ（{デフォルトブランチ名}）に切り替えてから分岐するか」を提示し、選ばせる （AskUserQuestion 等）。スタックした作業（前の feature ブランチの続き）では現在ブランチ からの分岐が正しいこともあるため、ここを取り違えると余計なコミットが混ざる。

4. 実装する

issue の内容に従って実装する。進め方の指針:

• まず issue から「達成すべき振る舞い・受け入れ条件」を読み取り、影響範囲を把握する （関連コードを読む）。issue の記述が曖昧、または大きくて判断が要る場合は、着手前に 実装方針を一言ユーザーに確認する。
• ステップ2で読んだルールと既存コードの流儀に沿って書く。
• テストがあるプロジェクトなら、関連するテストを追加・更新し、実行して通す。 ビルド/型チェックがあれば通るところまで確認する。
• issue の受け入れ条件を一つずつ満たしているか確認する。

5. コミットする

実装が完了し検証が通ったら、変更内容を確認（git status / git diff）してからコミットする。

コミット前に docs/COMMIT.md を読み、コミットのルールや記述内容（メッセージの書式・ prefix・言語・issue 参照の書き方・署名の有無など）を確認し、それに従う。これはプロジェクトごとに 異なるコミット規約をカスタマイズするためのファイルであり、存在する場合は最優先で守る （プロジェクトが規約の所有者であり、こちらが我流を持ち込まない）。

• docs/COMMIT.md がある場合: そこに書かれた規約を最優先で守る。
• docs/COMMIT.md が無い場合: 次に docs/ISSUE.md・docs/rules/ にコミットに関する規約が ないか確認し、あればそれに従う。
• いずれにも規約が無い場合: 何を・なぜ変えたかが分かる簡潔なメッセージにし、 対象 issue を参照する（例: メッセージ本文に #42 を含める）。
• 変更が複数の論理単位にまたがる場合は、意味のある単位で分けてコミットしてよい。

6. 完了報告

作成したブランチ名、コミット（ハッシュとメッセージ）、実装で対応した内容と issue の 受け入れ条件の充足状況を簡潔に報告する。push や PR 作成が必要なら、それは次の作業として 案内する（このスキルでは行わない）。