Back to Details

implement-issue

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

implement-issue

implement-issue

GitHub Issue を読み込み、計画確認後にコードを実装します。
Read a GitHub Issue and implement the code after confirming the plan.

フロー

Flow

Step 1: Issue を取得する

Step 1: Fetch the Issue

Issue URL または番号から内容を取得:
bash
gh issue view <url-or-number>
Retrieve the content from the Issue URL or number:
bash
gh issue view <url-or-number>

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

Step 2: Investigate the codebase and create an implementation plan

Issue の内容をもとに関連コードを調査し、
_/local-plans/
に詳細な計画ファイルを作成する。
Investigate related code based on the Issue content and create a detailed plan file in 
_/local-plans/
.

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

2-1. Investigate related code

以下を並行して調査:
  • 変更対象ファイルの現状（Glob / Grep / Read）
  • 再利用可能な既存コンポーネント・ユーティリティ
  • 該当 API エンドポイント
  • 同様の実装パターン
Investigate the following in parallel:
  • Current status of target files (Glob / Grep / Read)
  • Reusable existing components and utilities
  • Relevant API endpoints
  • Similar implementation patterns

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

2-2. Save the plan file to 
_/local-plans/

ファイル名: 
<issue-number>-<issue-slug>.md
（例: 
_/local-plans/42-add-auth.md
）
計画の必須セクション:
markdown
undefined
File name: 
<issue-number>-<issue-slug>.md
(example: 
_/local-plans/42-add-auth.md
)
Required sections for the plan:
markdown
undefined

[Issue タイトル]

[Issue Title]

Context

Context

Issue の背景・目的・なぜこの変更が必要か。
Background and purpose of the Issue, and why this change is necessary.

Approach

Approach

実装方針。選択肢がある場合は採用理由も記述。
Implementation strategy. If there are options, also describe the reason for choosing this approach.

File Changes

File Changes

ファイルパス変更内容
src/...
〜を追加
lib/...
〜を修正
File PathChanges
src/...
Add ~
lib/...
Modify ~

Reuse

Reuse

再利用する既存実装のパスと用途。
Path and purpose of existing implementations to reuse.

Test Plan

Test Plan

  • 動作確認手順
  • エッジケース確認
undefined
  • Operation verification steps
  • Edge case verification
undefined

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

Step 3: Present the plan to the user and wait for approval

作成した計画ファイルの内容を表示し、ユーザーの承認を得てから実装を開始する。 承認なしに実装を開始してはならない。
Display the content of the created plan file and start implementation only after obtaining user approval. Do not start implementation without approval.

Step 4: コードを実装する

Step 4: Implement the code

CLAUDE.md やプロジェクトの規約に従って実装する。 広範な変更の場合は 
isolation: "worktree"
を使用して安全に実施。
Implement in accordance with CLAUDE.md and project guidelines. For extensive changes, use 
isolation: "worktree"
to implement safely.

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

Step 5: Security Review (Required)

Agent ツールでセキュリティ確認を行う。
確認項目:
  • OWASP Top 10
  • API キー・シークレットのハードコーディング
  • 入力バリデーション
  • XSS の可能性
問題が見つかった場合は修正してから次のステップに進む。
Perform security checks using Agent tools.
Check items:
  • OWASP Top 10
  • Hardcoding of API keys and secrets
  • Input validation
  • Potential XSS vulnerabilities
If issues are found, fix them before proceeding to the next step.

Step 6: テストを実行する

Step 6: Run Tests

プロジェクトのテストコマンドを実行する。テストが失敗した場合は修正する。
Run the project's test commands. Fix any issues if tests fail.

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

Step 7: Create a Commit

create-commit
スキルを使用して Conventional Commits 形式でコミットを作成する。
Use the 
create-commit
skill to create a commit in Conventional Commits format.

注意事項

Notes

  • ユーザーの承認なしに実装を開始しない
  • セキュリティ問題が未解決のままコミットしない
  • 大きな変更はステップを分けてコミットする
  • sandbox 環境での 
    GIT_SSL_NO_VERIFY=1
    併用    ：詳細は後述の「sandbox 環境での実行」節を参照
  • Do not start implementation without user approval
  • Do not commit with unresolved security issues
  • Split large changes into separate commits
  • Use 
    GIT_SSL_NO_VERIFY=1
    in sandbox environments    : For details, refer to the "Execution in Sandbox Environment" section below

sandbox 環境での実行

Execution in Sandbox Environment

sandbox で本スキルを実行する場合、ネットワーク越しの GitHub 操作には 
GIT_SSL_NO_VERIFY=1
の併用を検討してください。本スキルの主なリモート操作は 
gh issue view
/ 
gh issue comment
で、「リモート書き込み」判定は 要（本スキルは主に API 経由） です。コマンド分類の詳細と TLS 検証無効化の注意事項は 
docs/sandbox-tls.md
 を参照してください。
When running this skill in a sandbox environment, consider using 
GIT_SSL_NO_VERIFY=1
for GitHub operations over the network. The main remote operations of this skill are 
gh issue view
/ 
gh issue comment
, and the "remote write" determination is Required (this skill mainly uses APIs). For details on command classification and precautions for disabling TLS verification, refer to 
docs/sandbox-tls.md
.