implement-issue

GitHub Issue を読み込み、計画確認後にコードを実装します。

フロー

Step 1: Issue を取得する

Issue URL または番号から内容を取得:

gh issue view <url-or-number>

Step 2: コードベースを調査して実装計画を作成する

Issue の内容をもとに関連コードを調査し、_/local-plans/ に詳細な計画ファイルを作成する。

2-1. 関連コードを調査する

以下を並行して調査:

• 変更対象ファイルの現状（Glob / Grep / Read）
• 再利用可能な既存コンポーネント・ユーティリティ
• 該当 API エンドポイント
• 同様の実装パターン

2-2. 計画ファイルを _/local-plans/ に保存する

ファイル名: <issue-number>-<issue-slug>.md（例: _/local-plans/42-add-auth.md）

計画の必須セクション:

# [Issue タイトル]

## Context
Issue の背景・目的・なぜこの変更が必要か。

## Approach
実装方針。選択肢がある場合は採用理由も記述。

## File Changes

| ファイルパス | 変更内容 |
|-------------|---------|
| `src/...` | 〜を追加 |
| `lib/...` | 〜を修正 |

## Reuse
再利用する既存実装のパスと用途。

## Test Plan
- [ ] 動作確認手順
- [ ] エッジケース確認

Step 3: ユーザーに計画を提示して承認を待つ

作成した計画ファイルの内容を表示し、ユーザーの承認を得てから実装を開始する。 承認なしに実装を開始してはならない。

Step 4: コードを実装する

CLAUDE.md やプロジェクトの規約に従って実装する。 広範な変更の場合は isolation: "worktree" を使用して安全に実施。

Step 5: セキュリティレビュー（必須）

Agent ツールでセキュリティ確認を行う。

確認項目:

• OWASP Top 10
• API キー・シークレットのハードコーディング
• 入力バリデーション
• XSS の可能性

問題が見つかった場合は修正してから次のステップに進む。

Step 6: テストを実行する

プロジェクトのテストコマンドを実行する。テストが失敗した場合は修正する。

Step 7: コミットを作成する

create-commit スキルを使用して Conventional Commits 形式でコミットを作成する。

注意事項

• ユーザーの承認なしに実装を開始しない
• セキュリティ問題が未解決のままコミットしない
• 大きな変更はステップを分けてコミットする
• sandbox 環境での GIT_SSL_NO_VERIFY=1 併用：詳細は後述の「sandbox 環境での実行」節を参照

sandbox 環境での実行

sandbox で本スキルを実行する場合、ネットワーク越しの GitHub 操作には GIT_SSL_NO_VERIFY=1 の併用を検討してください。本スキルの主なリモート操作は gh issue view / gh issue comment で、「リモート書き込み」判定は 要（本スキルは主に API 経由） です。コマンド分類の詳細と TLS 検証無効化の注意事項は docs/sandbox-tls.md を参照してください。