本文へ移動
cccskills
無料GitHub で公開

implementation-report

PR作成時に使用。実装レポート(計画との対応、品質チェック結果、レビュー指摘対応)をPR descriptionに出力する。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md9.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Implementation Report Skill - 実装レポート生成

概要

PR作成時に実装レポートを生成するスキル。quality-check スキル通過後、push → PR作成時に実行する(feature ブランチへの push はゲートされない。品質ゲートはマージ時および main への直接 push 時に .quality-check-passed を検証する)。

承認済みの設計・実装計画と実際の変更差分を比較し、設計との差異・品質チェック結果・レビュー指摘への対応をまとめたレポートを生成する。チャットで伝えるのは設計との差異だけで(documents/development/development-policy.md §1.0「承認後の進め方」)、テスト結果やレビュー対応の詳細はこのレポート(PR 本文)に書く。


前提条件

  • quality-check スキルが完了し .quality-check-report.json が存在すること
  • .quality-check-report.json が見つからない場合はエラーとし、先に quality-check スキルを実行する(AI が実行する。ユーザーに促さない)。例外: 差分がハーネスのみの免除(quality-check「ハーネスのみ変更の免除」)に当たる場合はエラーにしない(Step 1 を参照)
  • Step 5 の確認待ちで PR を作る場合(documents/development/development-policy.md §1.0「承認後の進め方」 7 の順序 B): quality-check はフラグ作成の前だが、.quality-check-report.json があれば通常の PR を作ってよい(draft にはしない)。確認の対象は「確認待ち(判断は最後の 1 通)」と書く。返答を受けて実行・記録し、追加するテストなどを同じ PR にコミットした後、レポートを再生成して PR 本文を更新する(gh pr edit <n> --body-file <file>)

実行手順

Step 1: .quality-check-report.json を読み取る
  ↓
Step 2: 実装計画ドキュメントを検索・参照
  ↓
Step 3: 計画とGit変更差分を比較し判定
  ↓
Step 4: レポートを生成
  ↓
Step 5: PR descriptionに実装レポートを含めてPR作成

Step 1: .quality-check-report.json を読み取る

プロジェクトルートの .quality-check-report.json を読み取る。

フォーマットの詳細は _schemas/quality-check-report.schema.md を参照。

ファイルが存在しない場合: 差分(git diff --name-only origin/main...HEAD)がハーネスのみの免除に当たるときは、レポートに「品質チェック: 免除(ハーネスのみの変更。変更ファイルの一覧)」と書いて作成を続ける。それ以外は、レポートを作らずに先に quality-check スキルを実行し(AI が実行する。ユーザーに促さない — 前提条件と同じ)、そのレポートでこの手順をやり直す。


Step 2: 設計・実装計画ドキュメントを検索・参照

docs/superpowers/specs/ 配下の設計(spec)と docs/superpowers/plans/ 配下の計画ドキュメントを検索し、設計の末尾の「## 実装時の差異」(無ければ計画の同じ節、作業メモ)を読む。現在のブランチ・Issue に関連する計画を特定する(Issue を使わない運用では、ブランチ名だけで探す)。

  • 計画ドキュメントが見つかった場合: その内容を参照する
  • 見つからない場合: 会話コンテキスト内の計画情報を使用し、レポートに「計画ドキュメント参照不可(会話コンテキストから生成)」と注記する

Step 3: 設計・計画とGit変更差分を比較・判定

git diff origin/main...HEAD

各Phaseについて以下を判定する:

判定条件
計画通り計画に記載された変更内容がdiffに反映されている
差分あり設計・計画と実際の変更に差異がある(追加・省略・変更)。記録された「実装時の差異」と照らし、記録に無い差異があれば足す

Step 4: レポートを生成

「品質チェック結果サマリ」「ゲート上書き・承認」の各項目は、該当なしの場合も「なし」と明記する(記載の省略と該当なしを区別できるようにする)。レポートに該当フィールドが存在しない場合は「未記録」と明記する。

レポートテンプレート

## 実装レポート

### 設計・計画との対応
| Phase | 計画内容 | 状態 | 備考 |
|-------|---------|------|------|
| Phase N | [計画内容] | 計画通り / 差分あり | [備考] |

### 設計・計画との差異
- なし / **[設計の該当箇所]** → [どうしたか] / 理由: [理由] / 影響: [影響]

### 品質チェック結果サマリ
- リスクレベル: high / medium / low(`risk_level`)
- 静的チェック AI 修正パス: N回(打ち切り事由: なし / oscillation)(`lint_cycles` / `lint_abort_reason`)
- テスト設計メモ: verified / retroactive / out_of_scope / not_required(メモ: [パス] または なし)(`test_design.status` / `test_design.memo_path`)
- ミューテーションテスト: 提案 strong / recommended / none(根拠: [`recommendation_basis`])、判断 executed / declined / not_proposed と判断者 auto / user(`mutation.recommendation` / `mutation.user_decision` / `mutation.decided_by`。確認待ちなら「確認待ち」)。`declined` の場合は見送り理由(`mutation.decline_reason`)を明記する。実施した場合はスコア N%(生スコア、参考情報。最後の実行がキャッシュを再利用した計測なら「incremental」と付記 — `mutation.incremental`)、実行 N回、生存 N 件(killed n / equivalent n / accepted n / unresolved n / untriaged n / tool_false_negative n)(`mutation.score_raw` / `mutation.runs` / `mutation.survivors`)。判定・実行そのものが不能だった場合は理由(`mutation.reason`: not_configured / out_of_scope / empty_scope / scope_error / tool_error)
- 品質チェックサイクル数: N回(N回目で高/中指摘ゼロ達成 / 打ち切り事由: なし / cycle_limit / stagnation / 追加サイクル: N回)(`total_cycles` / `cycle_abort_reason` / `cycle_extensions`)
- E2Eテスト: 提案 strong / recommended / none(根拠: [`recommendation_basis`])、判断 executed / declined / added_only / not_proposed と判断者 auto / user(`e2e.recommendation` / `e2e.user_decision` / `e2e.decided_by`。確認待ちなら「確認待ち」)。`declined` の場合は見送り理由(`e2e.decline_reason`)を明記する。結果: pass / fail / skipped、検出した問題(`e2e.result` / `e2e.issues`)。新規シナリオがある場合は `e2e.new_scenarios` の各件(シナリオ名と判断: added_and_run / added_only / declined)を明記する
- ドキュメント更新: updated / not_required(`documentation.status`、updated の場合は対象ファイル)
- Flag commit (`.quality-check-passed` `commit`): `<sha>`(本番への反映で、反映元の PR が quality-check を通った commit を PR 本文から探せるようにする。フラグの作成前に PR を作るとき(順序 B・設計との差異の確認待ち)は「未作成」と書き、フラグの作成後に PR 本文を更新する)
- self-improvement: 実施した場合のみ `self_improvement.status` を記載。未実施なら省略(通常の完了条件ではない)

### ゲート上書き・承認
- ゲートパラメータ上書き: なし / [キー: 値](理由: [理由])(`gate_parameter_overrides`)
- 打ち切り承認: なし / [打ち切り事由(`gate_override.abort_reasons`: cycle_limit / stagnation)](理由: [ユーザーの判断根拠])
- リスクレベル引き下げ: なし / [メモ自己判定 → 採用レベル](理由: [根拠])(`risk_level_downgrade`)

### レビュー指摘への対応
| サイクル | 指摘内容 | レビュアー | 対応 |
|---------|---------|---------|------|
| N回目 | [指摘内容] | [レビュアー名(統合レビュアーは観点も)] | 対応済: [詳細] / 対応不要(理由後述) |

### 対応不要と判断したもの
- **[指摘内容]**([レビュアー名]指摘): [判断理由]

Step 5: PR descriptionに実装レポートを含めてPR作成

  • 既存のPRテンプレート(.github/PULL_REQUEST_TEMPLATE.md)がある場合、テンプレートの実装レポートセクションを実データで埋める
  • テンプレートがない場合、Step 4で生成したレポートをそのままPR descriptionに含める
gh pr create --title "[PRタイトル]" --body "[テンプレート + 実装レポート]"

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

backend-development

無料日本語概要

バックエンド実装時に使用。DRY原則遵守。コーディング規約準拠。

Crearize/ai-dev-helm42026年10月7日 更新

Use before implementing any feature, behavior change, or refactor - settles requirements and design, then gets the design independently reviewed and approved by the user before code is written

日本語の概要は準備中です。原文の説明を表示しています。

Crearize/ai-dev-helm42026年10月7日 更新

branch-workflow

無料日本語概要

作業開始時に使用。mainブランチでの作業禁止。Issue先行作成必須。

Crearize/ai-dev-helm42026年10月7日 更新

browser-agent

無料日本語概要

UI実装後の検証時に使用。agent-browser CLIでブラウザ上の動作を手動検証する。「UIを確認」「画面テスト」と言われたら使用(プロジェクトの E2E スイート実行は quality-check Step 5(推奨度・範囲で自動実施または確認)/ server-startup が担当)。

Crearize/ai-dev-helm42026年10月7日 更新

database-migration

無料日本語概要

DBマイグレーション作成時に使用。バージョン番号競合防止。mainブランチ確認必須。

Crearize/ai-dev-helm42026年10月7日 更新

Use when independent tasks benefit from parallel work without shared state or sequential dependencies

日本語の概要は準備中です。原文の説明を表示しています。

Crearize/ai-dev-helm42026年10月7日 更新

Crearize のスキルをすべて見る

このスキルの問題を報告する