記事一覧へ戻る
公式資料から考えたSkill案 品質保証

SKILL ARTICLE / issue-to-regression-eval

修正済みIssueから、回帰Evalを1件作る

直した不具合を、次のAI実装のテストケースにする。

Issueの再現条件、期待結果、修正差分を読み、通常テストに加えてAIエージェント向けの回帰シナリオへ変換するSkill案です。

この記事で紹介するSkill案は、参考資料を読んだうえで私が考えたものです。参照先が提供・評価・推奨しているものではありません。

OVERVIEW → CAN DO → BUILD

知ったことをSkillづくりに活かす

1 — OVERVIEW不具合から回帰Evalを作る

Issueを構造化すると再現情報は集めやすくなるが、修正後にその事例を将来のAI実装評価へ再利用する工程は別途必要になる。

2 — CAN DOできるようになること

同じ種類の失敗を、将来のエージェント変更でも検出できる資産にする。

3 — BUILD報告された事実と推測を分離する

Issue本文、コメント、関連PRから、再現できた事実と原因についての推測を別々に抽出します。情報が足りない場合はAIが補完せず、Eval化できない理由として返す設計にします。

01 / OVERVIEW

資料の概要

GitHubのフォームスキーマは、YAMLで入力フォームを定義する公式仕様です。textarea、input、dropdown、checkboxes、uploadなどの要素を組み合わせ、ラベル、説明、選択肢、必須条件といった制約を設定できます。公式例には再現手順を求めるtextareaや、利用バージョンを選ぶdropdownもあります。

確認時点ではフォームスキーマ自体がPublic Previewであり、仕様が変わる可能性も明記されています。

02 / CAN DO

できるようになること

Issue FormsはEvalを作る機能ではありません。この記事では、構造化されたIssueを回帰Evalの材料にするSkill案を考えます。再現手順、環境、期待した結果、実際の結果を取り出し、最小の入力、観測できる合格条件、避けるべき振る舞いに整理します。過去の不具合を、将来CodexやClaude Codeが行う実装の評価に再利用するためです。

構造化された入力はあくまで出発点です。何を合格とするかは、修正後の振る舞いと照らして人が確認する必要があります。

USE CASES 回帰テストAgent EvalIssue管理

活かしやすい場面

  • CodexやClaude Codeに継続的に実装を任せるチーム
  • 似た回帰不具合が繰り返されるプロジェクト
  • 修正の良し悪しを自動採点したい場面

使う前に確認したい場面

  • 個人情報を含むIssueを匿名化せず教材化する運用
  • 再現不能な報告を推測でテスト化する作業

03 / BUILD

自分たちのSkill作成に活かせること

文章やコードをそのまままねるのではなく、自分たちのSkillに取り入れたい判断基準や工程の分け方を整理しました。

01

報告された事実と推測を分離する

Issue本文、コメント、関連PRから、再現できた事実と原因についての推測を別々に抽出します。情報が足りない場合はAIが補完せず、Eval化できない理由として返す設計にします。

02

修正コードではなく振る舞いを正解にする

過去の差分と同じコードを書けたかではなく、同じ入力で不具合が起きないか、利用者から見える結果が期待どおりかを採点します。別の実装方法でも正しく合格できるEvalになります。

03

匿名化と人間の確認を工程に入れる

Issueには氏名、顧客データ、ログ、認証情報などが含まれる可能性があります。保存前に機密情報を除き、期待結果と採点条件を人間が確認してから継続利用する流れをSkillに組み込みます。

04 / WORKFLOW

Skillにするときの流れ

  1. 01

    事実を分離

    再現手順、期待、実際、環境をIssueから抽出する。

  2. 02

    最小ケース化

    余計な条件を削り、失敗を識別できる入力を作る。

  3. 03

    採点可能にする

    合格条件、禁止条件、実行コストを定義する。

05 / TRY

試すときに使える依頼文

これは完成したSkillではありません。先に依頼文として試し、期待する結果が返ってくるかを確かめるための試作プロンプトです。

PROMPT.txt
この修正済みIssueから、再現条件・期待結果・失敗時の観測結果を分離してください。個人情報や実装固有の答えを除き、将来のエージェント変更を採点できる最小Eval案を1件作ってください。

06 / BUILD BRIEF

試作するときの設計メモ

これは配布済みのSkillではありません。対象を小さく絞り、停止条件と評価ケースを足しながら確かめるための出発点です。

BUILD-BRIEF.md
修正済みIssueを回帰Evalへ変換するSkillを作る。
Issue本文、コメント、関連PRから事実だけを抽出し、個人情報を除去する。
入力、環境、期待する振る舞い、禁止する振る舞い、採点方法、実行コストを定型で出力する。
修正コードの文字列一致ではなく、利用者から見える結果を評価する。

07 / WATCHOUTS

人が確認するところ

  • Issue内の個人情報、秘密情報、顧客データを除去してからEvalへ保存します。
  • 修正差分そのものを正解として固定せず、観測可能な振る舞いを採点します。

Loading...