SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsimplement-issue

implement-issue

Security & auditing

View repository

Updated 10-16 05:07

About this skill

implement-issue

Read the GitHub Issue, and implement the code after plan confirmation.

Flow

Step 1: Get the Issue

Get the content from the Issue URL or number:

gh issue view <url-or-number>

If the network is unreachable, such as in a sandbox environment,gh issue view instead of, you may receive the Issue body directly from the user (via paste, file, etc.) and proceed with Step 2 onward using that as the Issue content.

Step 2: Investigate the codebase and create an implementation plan

Investigate the relevant code based on the Issue content, and_/local-plans/ create a detailed plan file in.

2-1. Investigate the relevant code

Investigate the following in parallel:

  • Current state of the files to be changed (Glob / Grep / Read)
  • Reusable existing components and utilities
  • The relevant API endpoints
  • Similar implementation patterns

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

File name: <issue-number>-<issue-slug>.md(e.g., _/local-plans/42-add-auth.md）

Required sections of the plan:

# [Issue タイトル]

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

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

## File Changes

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

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

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

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

Display the contents of the created plan file and start implementation only after obtaining the user's approval. Do not start implementation without approval.

Step 4: Implement the code

Implement according to CLAUDE.md and the project's conventions. For extensive changes, use isolation: "worktree" to carry them out safely.

Comment policy:

  • For code comments, rather than "what it does," write "why it exists / the role of the target as seen from the package or service."
  • Since subsequent readers (including Claude) can only judge from the information passed to them, explicitly state the perspective from other files, other services, and callers/callees (where this symbol is called from and which boundary it is responsible for).
  • If the target repository has .claude/rules/code-comment-style.md（init-claude is deployed), follow its detailed conventions. If it does not exist, follow the above points (clarifying roles, boundaries, and call relationships).

Step 5: Security review (required)

Perform a security check with the Agent tool.

Check items:

  • OWASP Top 10
  • Hardcoding API keys and secrets
  • Input validation
  • Possibility of XSS

If any issues are found, fix them before proceeding to the next step.

Step 6: Run the tests

Run the project's test command. If the tests fail, investigate the root cause before fixing.

Root cause debugging policy (if the target repository has .claude/rules/debugging.md , follow its four phases. If it does not exist, follow the points below):

  • Read the error message and stack trace carefully before writing fix code
  • If you fail 3 times at the same location, judge it as an architecture problem, and report the situation to the user without making additional fix attempts

Step 7: Create a commit

create-commit Use the skill to create a commit in Conventional Commits format.

Handling out-of-scope items

If, during implementation, matters arise that should be addressed but are judged out of the current scope (unaddressed improvements, separate features, technical debt, follow-up work), do not leave them unattended and always track them.

Procedure

  1. Check for existing Issues Search for an existing open Issue that implements the target:
gh issue list --state open --search "${KEYWORD}"

The keyword is "${KEYWORD}" and pass it quoted.

  1. Present to the user and obtain approval Present the out-of-scope items, whether an existing Issue exists, and the proposed action (add a comment to an existing Issue or file a new one) to the user.Execute only after obtaining approval(do not perform Issue operations without confirmation).

  2. If an existing Issue exists: add a comment

gh issue comment "${ISSUE_NUMBER}" --body "$(cat <<'EOF'
## 実装サポート情報（別作業から検出）

### 検出背景
今回の実装（Issue #N）の過程で発見した事項。

### 関連ファイル・シンボル
- `src/path/to/file.ts` — 対象関数名・クラス名

### パッケージ・サービスから見た役割・影響範囲
（このシンボルの担う境界、呼び出し元/呼び出し先）

### 着手時の注意点・依存関係
（依存パッケージ、順序制約など）
EOF
)"

  1. If no existing Issue exists: file a new one create-issue-tree if it is introduced, use it (linking to an existing route is --root <ルートissue番号>), and if not introduced, use create-issue to file it under the appropriate parent Issue. The title shall be in Conventional Commits format.

  2. State it explicitly in the PR body or Issue comment In the original PR body or the output report, describe the "items deemed out of scope" and the "Issue number they were split off to" (this may be done after creating the commit).

Security note: gh Quote the keywords and comment body passed to "${var}" with the variable<<'EOF'and pass the body via HEREDOC (

Verification

Run the test and build commands anew, confirm the entire output and the exit code, and only then declare completion (if .claude/rules/verification.md exists in the target repository, follow its 5-stage gate).

  • Claiming completion with speculative words such as "should be" or "probably works" is prohibited
  • Declare completion only after citing the test output and exit code as evidence

Example:

検証結果: `npm test` を実行。全22件パス、失敗0件（終了コード0）。

Common failures

Problem Workaround
Starting implementation before approval Do not skip waiting for approval in Step 3. Strictly follow the order: present plan → approval → implementation
Fixing by guesswork without investigating the cause of a test failure If .claude/rules/debugging.md exists in the target repository, follow its 4 phases; if not, follow the key points of Step 6 (investigation → analysis → hypothesis → fix) in order
Committing with security issues left unresolved If a problem is found in Step 5, always fix it before proceeding to Step 6
Declare completion based on previous test results Always run tests anew and check the exit code and the entire output

Notes

  • Do not start implementation without the user's approval
  • Do not commit while security issues remain unresolved
  • Commit large changes in separate steps

Execution in a sandbox environment

Planning, implementation, test execution, and creating the Step 7 commit can be performed in a sandbox environment (only writing within the workspace, without performing operations over the network).gh issue view Issue retrieval via can be omitted by using the alternative route for Step 1 (directly receiving the Issue body). The tracking steps in the "Handling out-of-scope items" section (gh issue list searching for existing Issues via ,gh issue comment adding comments via ,create-issue-tree / create-issue creating new tickets via ) also require the network if selected. Within this skill's flow, the only things requiring the network are gh issue view and these optional out-of-scope tracking steps, and all of them can be omitted (this skill's flow does not include git push . If you want to push to the remote after committing, separately use a subsequent skill such as create-pr ). When executing these, disable the sandbox on a per-command basis.