quality-verify
最終成果物が、6つの品質基準すべてを満たしているかを検証し、ユーザーが求める品質水準に達していることを確認するための最終的な検証ステップとして活用するSkill。
📜 元の英語説明(参考)
Verify the final deliverable meets all quality criteria before delivery. Use as the final validation step to ensure the output meets the user's quality standards across all 6 dimensions.
🇯🇵 日本人クリエイター向け解説
最終成果物が、6つの品質基準すべてを満たしているかを検証し、ユーザーが求める品質水準に達していることを確認するための最終的な検証ステップとして活用するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o quality-verify.zip https://jpskill.com/download/16965.zip && unzip -o quality-verify.zip && rm quality-verify.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/16965.zip -OutFile "$d\quality-verify.zip"; Expand-Archive "$d\quality-verify.zip" -DestinationPath $d -Force; ri "$d\quality-verify.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
quality-verify.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
quality-verifyフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Quality Verify Skill
目的
フォーマットされた成果物が、納品前にすべての品質基準を満たしているかどうかの最終検証を行います。これは最後のゲートであり、ここで合格すれば、納品準備完了です。
品質ディメンション
システムは6つの品質ディメンションに対してチェックを行います。それぞれを評価してください。
1. 完全性
- 成果物に必要な部分はすべて揃っていますか?
- 何か欠けていたり、明らかに不完全な部分はありませんか?
- ユーザーからの要求はすべて満たされていますか?
2. 正確性
- コードは構文的に正しいですか?(エラーがないか)
- 事実/情報は正確ですか?
- 要求されたことを実行していますか?
- 論理的なエラーはありませんか?
3. 一貫性
- 全体を通してフォーマットは一貫していますか?
- 命名規則は一貫していますか?
- スタイルは一貫していますか?
- パターンは一貫して適用されていますか?
4. パフォーマンス (該当する場合)
- 効率的ですか?(コードが明らかに遅いということはないはずです)
- スケールしますか?(大規模な入力/データに対して)
- 明らかなパフォーマンス上の問題はありますか?
5. セキュリティ (該当する場合)
- 明らかな脆弱性はありませんか?
- 入力は検証/サニタイズされていますか?
- ハードコードされたシークレットはありませんか?
- セキュリティのベストプラクティスに従っていますか?
6. 保守性
- 読みやすいですか?
- ドキュメント化されていますか?
- 他の人が理解できますか?
- 後で簡単に修正できますか?
採点システム
各ディメンションを評価します。
- ✓ Excellent (90-100): 標準を上回り、プロフェッショナルな品質
- ✓ Good (75-89): 標準を満たし、納品準備完了
- ⚠ Acceptable (60-74): 最小限の標準を満たしているが、改善の余地あり
- ✗ Needs Work (0-59): 標準以下、修正が必要
採点アルゴリズム
総合スコア = 該当するすべてのディメンションの平均
0 クリティカルな問題 = ベーススコア
- クリティカルな問題ごとに -10 ポイント (例: コードが実行されない、重大なセキュリティ上の欠陥)
- 重大な問題ごとに -5 ポイント (例: セクションの欠落、フォーマットの一貫性の欠如)
- 軽微な問題ごとに -2 ポイント (例: タイプミス、軽微な一貫性の欠如)
最終スコア = ベーススコア - 減点
80+ = 納品準備完了 ✓
60-79 = 軽微な修正を推奨
<60 = 大幅な修正が必要
プロセス
- フォーマットされた成果物を確認します
StandardsRepositoryを使用してユーザーの標準をロードし、このタイプにとって「良い」とは何かを理解します- 各品質ディメンションに対して評価します
- 各ディメンションを採点します
- 全体的な品質スコアを計算します
- 発見された問題を特定します
- 詳細なフィードバックを提供します
標準のロード
StandardsRepositoryを使用して品質基準にアクセスします。
const standards = standardsRepository.getStandards(context.projectType)
if (standards && standards.qualityCriteria) {
// Check against their quality criteria definitions
const criteria = standards.qualityCriteria
// Verify deliverable meets: completeness, correctness, consistency, etc.
verifyAgainstCriteria(deliverable, criteria)
} else {
// Use general quality best practices
verifyAgainstBestPractices(deliverable)
}
インターフェースの詳細については、.claude/lib/standards-repository.mdを参照してください。
出力形式
{
"qualityScore": 92,
"readyToDeliver": true,
"dimensionScores": {
"completeness": 95,
"correctness": 90,
"consistency": 88,
"performance": 85,
"security": 90,
"maintainability": 95
},
"issuesFound": [
"list of specific issues (if any)"
],
"issuesSeverity": {
"critical": [],
"major": [],
"minor": ["Missing one edge case test"]
},
"notes": "One minor issue found - everything else excellent quality",
"summary": "Ready to deliver. Recommend adding edge case test.",
"recommendations": [
"Add test for empty array edge case"
]
}
成功基準
スコア 85+
✓ 品質スコアが85以上 ✓ クリティカルな問題がない ✓ すぐに納品準備完了
スコア 70-84
⚠ 品質は良好だが、軽微な問題がある ⚠ 納品前に軽微な問題を修正する必要がある ⚠ ユーザーに確認: 「これらを修正するか、現状のまま納品するか?」
スコア <70
✗ 重大な問題が見つかった ✗ 現在の状態では納品すべきではない ✗ 大幅な修正を推奨
品質チェックの例
コード機能の品質チェック
成果物: React ドロップダウンコンポーネント
チェック:
- ✓ 完全性: 必要なメソッド、props、イベントハンドラーがすべて揃っている
- ✓ 正確性: コードはエラーなしで実行され、キーボードナビゲーションが機能する
- ✓ 一貫性: 命名は一貫しており、フォーマットは一貫している
- ✓ パフォーマンス: 明らかな非効率性はない、妥当な再レンダリング回数
- ✓ セキュリティ: ユーザー入力を適切にサニタイズし、XSS 脆弱性がない
- ✓ 保守性: コメントが適切に記述され、明確な変数名、修正が容易
スコア: 94/100 問題: なし 推奨事項: 納品準備完了
ドキュメントの品質チェック
成果物: API エンドポイントのドキュメント
チェック:
- ✓ 完全性: すべてのエンドポイントがドキュメント化され、すべてのパラメーターが記述されている
- ✓ 正確性: 情報は実際の API の動作と一致する
- ✓ 一貫性: フォーマットは一貫しており、例は同じパターンに従っている
- ✓ 明確さ: 新しい開発者にとって理解しやすい
- ⚠ 保守性: エラーレスポンスの例が不足している (軽微)
スコア: 82/100 問題: ["エラーレスポンスの例が不足している"] 推奨事項: エラーレスポンスの例を追加してから納品
決定木
スコア 85+ → 納品準備完了 ✓
スコア 70-84 → 軽微な問題について確認
スコア <70 → 大幅な修正を推奨
実装に関する注意点
- 発見された問題について、曖昧ではなく具体的に記述する
- 修正を推奨する場合は、その理由を説明する
- ユーザーの標準が不明確な場合は、一般的な品質のベストプラクティスを使用する
- 品質は主観的ですが、一貫性は客観的です (ユーザーの標準に従っているか?)
- 悪い成果物を通すよりも、少し厳しくする方が良い
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Quality Verify Skill
Purpose
Final validation that the formatted deliverable meets ALL quality standards before delivery. This is the last gate - if it passes here, it's ready to go.
Quality Dimensions
The system checks against 6 quality dimensions. Evaluate each:
1. Completeness
- Does the deliverable have all required parts?
- Nothing missing or obviously incomplete?
- All requirements from the user met?
2. Correctness
- Is the code syntactically correct? (No errors)
- Are facts/information accurate?
- Does it do what was asked?
- No logical errors?
3. Consistency
- Formatting consistent throughout?
- Naming conventions consistent?
- Style consistent?
- Patterns applied consistently?
4. Performance (when applicable)
- Is it efficient? (Code shouldn't be obviously slow)
- Does it scale? (For large inputs/data)
- Any obvious performance issues?
5. Security (when applicable)
- No obvious vulnerabilities?
- Inputs validated/sanitized?
- No hardcoded secrets?
- Following security best practices?
6. Maintainability
- Is it readable?
- Is it documented?
- Would someone else understand it?
- Easy to modify later?
Scoring System
Rate each dimension:
- ✓ Excellent (90-100): Exceeds standards, professional quality
- ✓ Good (75-89): Meets standards, ready to deliver
- ⚠ Acceptable (60-74): Meets minimum standards, could be better
- ✗ Needs Work (0-59): Below standards, needs revision
Scoring Algorithm
Overall Score = Average of all applicable dimensions
0 Critical Issues = Base score
- 10 points per critical issue (e.g., code doesn't run, major security flaw)
- 5 points per major issue (e.g., missing section, formatting inconsistent)
- 2 points per minor issue (e.g., typo, minor inconsistency)
Final Score = Base score - deductions
80+ = Ready to Deliver ✓
60-79 = Minor fixes recommended
<60 = Major revision needed
Process
- Review the formatted deliverable
- Load user's standards using StandardsRepository to understand what "good" means for this type
- Evaluate against each quality dimension
- Score each dimension
- Calculate overall quality score
- Identify any issues found
- Provide detailed feedback
Loading Standards
Use StandardsRepository to access quality criteria:
const standards = standardsRepository.getStandards(context.projectType)
if (standards && standards.qualityCriteria) {
// Check against their quality criteria definitions
const criteria = standards.qualityCriteria
// Verify deliverable meets: completeness, correctness, consistency, etc.
verifyAgainstCriteria(deliverable, criteria)
} else {
// Use general quality best practices
verifyAgainstBestPractices(deliverable)
}
See .claude/lib/standards-repository.md for interface details.
Output Format
{
"qualityScore": 92,
"readyToDeliver": true,
"dimensionScores": {
"completeness": 95,
"correctness": 90,
"consistency": 88,
"performance": 85,
"security": 90,
"maintainability": 95
},
"issuesFound": [
"list of specific issues (if any)"
],
"issuesSeverity": {
"critical": [],
"major": [],
"minor": ["Missing one edge case test"]
},
"notes": "One minor issue found - everything else excellent quality",
"summary": "Ready to deliver. Recommend adding edge case test.",
"recommendations": [
"Add test for empty array edge case"
]
}
Success Criteria
Score 85+
✓ Quality score above 85 ✓ No critical issues ✓ Ready to deliver immediately
Score 70-84
⚠ Good quality, minor issues ⚠ Should fix minor issues before delivery ⚠ Ask user: "Fix these, or deliver as-is?"
Score <70
✗ Significant issues found ✗ Should not deliver in current state ✗ Recommend major revision
Example Quality Checks
Code Feature Quality Check
Deliverable: React dropdown component
Checks:
- ✓ Completeness: Has all required methods, props, event handlers
- ✓ Correctness: Code runs without errors, keyboard nav works
- ✓ Consistency: Naming consistent, formatting consistent
- ✓ Performance: No obvious inefficiencies, reasonable re-render count
- ✓ Security: Properly sanitizes user input, no XSS vulnerabilities
- ✓ Maintainability: Well-commented, clear variable names, easy to modify
Score: 94/100 Issues: None Recommendation: Ready to deliver
Documentation Quality Check
Deliverable: API endpoint documentation
Checks:
- ✓ Completeness: All endpoints documented, all parameters described
- ✓ Correctness: Information matches actual API behavior
- ✓ Consistency: Formatting consistent, examples follow same pattern
- ✓ Clarity: Easy to understand for new developers
- ⚠ Maintainability: Missing error response examples (minor)
Score: 82/100 Issues: ["Missing examples for error responses"] Recommendation: Add error response examples, then deliver
Decision Tree
Score 85+ → Ready to Deliver ✓
Score 70-84 → Ask about minor issues
Score <70 → Recommend major revision
Notes for Implementation
- Be specific about issues found, not vague
- When recommending fixes, explain why they matter
- If user's standards are unclear, use general quality best practices
- Quality is subjective - but consistency is objective (did it follow their standards?)
- Better to be slightly harsh than let bad work through