バックエンド実装時に使用。DRY原則遵守。コーディング規約準拠。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
PR作成時に使用。実装レポート(計画との対応、品質チェック結果、レビュー指摘対応)をPR descriptionに出力する。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
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 を参照)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作成
.quality-check-report.json を読み取るプロジェクトルートの .quality-check-report.json を読み取る。
フォーマットの詳細は
_schemas/quality-check-report.schema.mdを参照。
ファイルが存在しない場合: 差分(git diff --name-only origin/main...HEAD)がハーネスのみの免除に当たるときは、レポートに「品質チェック: 免除(ハーネスのみの変更。変更ファイルの一覧)」と書いて作成を続ける。それ以外は、レポートを作らずに先に quality-check スキルを実行し(AI が実行する。ユーザーに促さない — 前提条件と同じ)、そのレポートでこの手順をやり直す。
docs/superpowers/specs/ 配下の設計(spec)と docs/superpowers/plans/ 配下の計画ドキュメントを検索し、設計の末尾の「## 実装時の差異」(無ければ計画の同じ節、作業メモ)を読む。現在のブランチ・Issue に関連する計画を特定する(Issue を使わない運用では、ブランチ名だけで探す)。
git diff origin/main...HEAD
各Phaseについて以下を判定する:
| 判定 | 条件 |
|---|---|
| 計画通り | 計画に記載された変更内容がdiffに反映されている |
| 差分あり | 設計・計画と実際の変更に差異がある(追加・省略・変更)。記録された「実装時の差異」と照らし、記録に無い差異があれば足す |
「品質チェック結果サマリ」「ゲート上書き・承認」の各項目は、該当なしの場合も「なし」と明記する(記載の省略と該当なしを区別できるようにする)。レポートに該当フィールドが存在しない場合は「未記録」と明記する。
## 実装レポート
### 設計・計画との対応
| 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回目 | [指摘内容] | [レビュアー名(統合レビュアーは観点も)] | 対応済: [詳細] / 対応不要(理由後述) |
### 対応不要と判断したもの
- **[指摘内容]**([レビュアー名]指摘): [判断理由]
.github/PULL_REQUEST_TEMPLATE.md)がある場合、テンプレートの実装レポートセクションを実データで埋めるgh pr create --title "[PRタイトル]" --body "[テンプレート + 実装レポート]"
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
バックエンド実装時に使用。DRY原則遵守。コーディング規約準拠。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
作業開始時に使用。mainブランチでの作業禁止。Issue先行作成必須。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
UI実装後の検証時に使用。agent-browser CLIでブラウザ上の動作を手動検証する。「UIを確認」「画面テスト」と言われたら使用(プロジェクトの E2E スイート実行は quality-check Step 5(推奨度・範囲で自動実施または確認)/ server-startup が担当)。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
DBマイグレーション作成時に使用。バージョン番号競合防止。mainブランチ確認必須。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when independent tasks benefit from parallel work without shared state or sequential dependencies
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.