AgentSkillsCN

impl

通过迭代开发、逐步审查与微调，在小范围内持续完善代码，直至项目完成。

SKILL.md
--- frontmatter
name: impl
description: Implementation cycle skill to iteratively develop, review, and refine code in small scopes until completion.
user-invocable: true

impl

このスキルは、ユーザーの要件を満たすためにコードを段階的に実装、レビュー、改善するプロセスを管理します。大きな変更を小さなスコープに分割し、各スコープごとに開発とレビューを繰り返すことで、高品質な実装を目指します。

引数

  • •Issue 番号 (例: /impl #123): GitHub Issue から要件を取得して実装する。gh issue view で内容を読み取る
  • •Issue URL (例: /impl https://github.com/owner/repo/issues/123): 同上
  • •テキスト (例: /impl ユーザー認証機能を追加): テキストをそのまま要件として扱う
  • •引数なし: ユーザーに要件をヒアリングしてから開始する

実行プロセス

フェーズ1: 要件分析とスコープ分割

  1. •引数から要件を取得する
    • •Issue が指定された場合: gh issue view で本文・コメントを読み取り、要件として整理する
    • •テキストが指定された場合: テキストを要件として扱う
    • •引数なしの場合: ユーザーに要件をヒアリングする
  2. •現在のブランチをベースブランチとして記録する（PR のマージ先になる）
  3. •作業ブランチを決定する
    • •Issue が指定された場合、まず Issue 本文にブランチ名が記載されているか確認する
      • •ブランチ名が記載されており、そのブランチがリモートまたはローカルに存在する場合:
        • •そのブランチをチェックアウトする（git fetch origin && git checkout <ブランチ名>）
        • •ベースブランチはチェックアウト前のブランチとする
        • •新しいブランチは作成しない
      • •ブランチ名が記載されていない、またはブランチが存在しない場合:
        • •以下のルールで新しいブランチを作成する
    • •新しいブランチを作成する場合のブランチ名:
      • •プレフィックスは要件の性質に応じて決定する：
        • •feat/ : 新機能の追加
        • •fix/ : バグ修正
        • •refactor/ : リファクタリング
        • •docs/ : ドキュメントのみの変更
        • •test/ : テストの追加・修正のみ
      • •Issue が指定された場合: Issue のラベル（bug → fix/、enhancement/feature → feat/ など）やタイトルから判定し、<type>/#<Issue番号> とする（例: feat/#39, fix/#42）
      • •テキスト / 引数なしの場合: 要件の内容から判定し、<type>/<要件を要約した短い名前> とする（例: feat/add-auth, fix/login-error）
      • •判定に迷う場合は feat/ をデフォルトとする
  4. •要件を「独立して実装・テストできる単位」に分ける
  5. •依存関係を整理して実装順を決める
  6. •Todo に並べる
  • •このフェーズでは必要に応じてコードベースの探索・検索・理解を行い、要件を正確に把握する
  • •不確定な仕様、要件などがある場合は必ずユーザーに確認する
  • •破壊的変更がある場合は機能ごとに下位互換性を保つかどうかを確認する

フェーズ2: 実装サイクル（各スコープに対して繰り返し）

各スコープに対して以下を実行：

ステップ2-1: Plan

  • •Planエージェントを利用し、スコープの実装計画を立てる
  • •変更箇所、影響範囲、テスト要件を明確にする
  • •TodoWriteツールでタスクを管理する

ステップ2-2: Develop

  • •developerエージェントを利用し、実装を行う
  • •現在のスコープの要件を明確に伝える
  • •最小限の変更で要件を満たす実装を行う
  • •テストも含めて実装する

ステップ2-3: Review

  • •reviewerエージェントを利用し、コードレビューを行う
  • •要件を満たしているか、コード品質、テストの十分性を評価する

ステップ2-4: 改善サイクル

  • •レビューで指摘された問題がある場合：
    • •再度developerエージェントで修正
    • •再度reviewerエージェントでレビュー
    • •指摘事項がなくなるまで繰り返す

ステップ2-5: Format & Lint

  • •プロジェクトの設定に従い、変更したファイルに対して format と lint を実行する
  • •自動修正可能なものは修正し、修正できないエラーがあれば対処する
  • •format/lint の設定が見つからない場合はこのステップをスキップする

ステップ2-6: Commit（必須）

  • •このステップは絶対にスキップしない。 各スコープの完了時に必ずコミットする
  • •git add で変更ファイルをステージし、git commit でコミットする
  • •コミットメッセージは CLAUDE.md の規約に従う
  • •コミットが完了したことを確認してから、次のスコープへ進む

フェーズ3: 完了確認とプルリクエスト

  1. •すべてのスコープの実装が完了したことを確認
  2. •全体のテストを実行して動作確認
  3. •gh pr create --base <ベースブランチ> でプルリクエストを作成する
    • •ベースブランチはフェーズ1で記録した開始時のブランチを指定する
    • •Issue が指定された場合: タイトルに Issue 番号を含める
    • •PR 本文に以下を含める：
      • •Issue が指定された場合: 本文の先頭に Closes #<番号> を必ず記載する（マージ時に Issue が自動クローズされる）
      • •変更内容のサマリー
      • •手動チェックリスト（後述）
  4. •実装内容のサマリーをユーザーに報告する

PR 手動チェックリスト

PR 本文に以下のチェックリストを含める。項目はプロジェクトの構成に応じて該当するもののみ記載する。

markdown
## 手動チェック項目

### 動作確認
- [ ] 主要な機能が正常に動作する
- [ ] エッジケース・異常系の動作確認
- [ ] レスポンシブ表示の確認（フロントエンド）

### 品質
- [ ] lint / format がパスする
- [ ] テストがすべてパスする
- [ ] 400 行を超えるファイルがない

### デプロイ
- [ ] ローカル環境で `docker compose up` が正常に動作する
- [ ] 環境変数の追加がある場合、`.env.example` を更新済み
- [ ] マイグレーションがある場合、ロールバック手順を確認済み

ルール

  • •各スコープは独立して実装・テスト可能な単位にする
  • •各スコープの完了時に必ずコミットする。 コミットせずに次のスコープへ進んではならない
  • •レビューで指摘された問題はすべての重大度（🔴🟠🟡🟢）で修正する
  • •各フェーズの進捗はTodoWriteツールで管理する