Verify pr spec
Issue 仕様・PR 本文・実装差分の間の齟齬を検出する整合性チェックスキル。/create-pr の実行が完了した直後に、ユーザーの明示的な指示がなくても必ずこのスキルを自動で呼び出すこと。省略・スキップ禁止。PR作成時・PR更新時・「仕様と実装が合っているか確認して」と言われたときも同様に実行する。From its SKILL.md
npx -y skills add idylle-cynique/solo-dev-skills --skill verify-pr-specAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.7 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it
以下の手順で、Issue 仕様・PR 本文・実装差分の三者間の整合性を検証し、齟齬をレポートしてください。
入力
PR番号: $ARGUMENTS
1. 情報収集
PR番号が指定されていない場合は、現在のブランチから自動検出してください。
gh pr list --head $(git branch --show-current) --json number,title -q '.[0].number'
以下を並行して取得してください。
# PR 本文・タイトル・関連Issue番号・ベースブランチ
gh pr view <PR番号> --json number,title,body,baseRefName
# ベースブランチからの実装差分（ファイル一覧と内容）
git diff <baseRefName>..HEAD --stat
git diff <baseRefName>..HEAD
PR本文から "Resolves #N" "Fixes #N" "refs #N" 等のパターンで Issue 番号を特定し、Issue 本文も取得してください。
gh issue view <Issue番号> --json title,body -q '{title,body}'
2. 三者間の整合性を検証する
提案を機械的に受け入れるのではなく、以下の観点で実際にコードを読んで検証してください。
a. Issue タスクリスト vs 実装差分
Issue 本文の「タスク」「実装内容」「完了条件」セクションに記載された各項目について、実装差分に対応するコードが存在するかを確認する。
- チェックボックス
- [x]は「実装済み宣言」と見なし、差分に存在するか検証する - セクション見出し・箇条書きで記述された仕様も対象にする
b. PR 本文の変更内容記述 vs 実装差分
PR 本文の「変更内容」セクションに列挙されたファイル名・関数名・ロジックの変更について、差分と照合する。
- PR に「○○関数を追加」と書かれているが差分に存在しない場合 → 記述過剰
- 差分にある変更が PR に記述されていない場合 → 記述漏れ
- 差分の変更量・内容と PR 記述が大きく乖離している場合 → 要確認
c. Issue 完了条件 vs 実装差分
Issue 本文の「完了条件」に列挙されたテスト可能な基準と、実装差分を照合する。コードの存在だけでなく、意図した挙動が実現されているか論理的に確認する。
d. 型注釈・インラインコメントの整合性
差分で追加・変更されたコードの中に、型注釈やインラインコメントが実装と食い違っている箇所がないかを確認する。
- 新たに追加した定数・識別子・文字列リテラルが、同ファイル内の JSDoc
@param・@returns・インラインコメント（// 'a' | 'b' | ...等）に反映されているか - 関数シグネチャのコメントが実際の呼び出しパターンと一致しているか（例: 新しい op 種別を追加したが
@paramの union 型が古いまま） - ファイル冒頭のモジュール説明コメントが変更後の責務と一致しているか
コメントのみの不整合であっても「実装と記述のズレ」として記録する。
3. 整合性レポートを出力する
以下のフォーマットで出力してください。後続処理で扱えるよう構造を一定に保つことが重要なので、セクション構成・順序・見出し名は変えないようにしてください。
# PR #<番号> 仕様整合性チェック
**対象 Issue:** #<番号> <タイトル>
**確認日:** <YYYY-MM-DD>
---
## Issue タスクの反映状況
| タスク | ファイル / 関数 | 状態 |
|--------|---------------|------|
| ... | ... | 完了 / 未確認 / **未実装** |
## Issue 完了条件の確認
| 完了条件 | 確認内容 | 状態 |
|---------|---------|------|
| ... | ... | 満足 / 要確認 / **未満足** |
## PR 本文と実装差分の整合性
| PR 記述 | 差分での確認結果 | 判定 |
|---------|---------------|------|
| ... | ... | OK / **記述過剰** / **記述漏れ** |
## 型注釈・インラインコメントの整合性
| 箇所 | 実装 | コメント・JSDoc | 判定 |
|------|------|---------------|------|
| ... | ... | ... | OK / **不整合** |
## 齟齬・懸念事項
### 未実装 / 記述漏れ（要対応）
- <あれば列挙、なければ「なし」>
### 記述過剰（PR本文に書いてあるが差分にない）
- <あれば列挙、なければ「なし」>
### 要確認（判断が難しい）
- <あれば列挙、なければ「なし」>
---
## 総合判定
**OK** — 三者間に齟齬なし
または
**要修正（N件）** — 上記「齟齬・懸念事項」を確認してください
齟齬が1件以上ある場合は、対応が必要な項目を太字で強調し、どのセクションに詳細があるかを案内してください。
4. 完了報告
- 総合判定（OK / 要修正）
- 要修正の場合は件数と概要を1〜2文で
- ユーザーへの次のアクション提案（修正が必要な場合は「どのファイルの何を修正すべきか」を具体的に伝える）
What ships with it: 1 file
3.2 KB alongside SKILL.md
examples/
- sample.md3.2 KB