document-review
This skill should be used to refine brainstorm or plan documents before proceeding to the next workflow step. It applies when a brainstorm or plan document exists and the user wants to improve it.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o document-review.zip https://jpskill.com/download/22790.zip && unzip -o document-review.zip && rm document-review.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/22790.zip -OutFile "$d\document-review.zip"; Expand-Archive "$d\document-review.zip" -DestinationPath $d -Force; ri "$d\document-review.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
document-review.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
document-reviewフォルダができる - 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 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
ドキュメントレビュー
構造化されたレビューを通じて、ブレインストームや計画のドキュメントを改善します。
ステップ1:ドキュメントを取得する
ドキュメントパスが提供されている場合: それを読み込み、ステップ2に進みます。
ドキュメントが指定されていない場合: どのドキュメントをレビューするか尋ねるか、docs/brainstorms/またはdocs/plans/内で最新のブレインストーム/計画を探します。
ステップ2:評価する
ドキュメントを読み通し、以下の質問をします。
- 何が不明確ですか?
- 何が不要ですか?
- どのような決定が避けられていますか?
- どのような仮定が明記されていませんか?
- どこでスコープが意図せず拡大する可能性がありますか?
これらの質問は問題点を浮き彫りにします。まだ修正せず、見つけたものをメモするだけにとどめてください。
ステップ3:評価する
以下の基準に基づいてドキュメントを採点します。
| 基準 | 確認事項 |
|---|---|
| 明確性 (Clarity) | 問題提起が明確で、「おそらく (probably)」「検討する (consider)」「〜しようとする (try to)」のような曖昧な表現がないこと |
| 完全性 (Completeness) | 必要なセクションが存在し、制約が明記され、未解決の質問が示されていること |
| 具体性 (Specificity) | 次のステップに進むのに十分具体性があること(ブレインストーム → 計画可能、計画 → 実装可能) |
| YAGNI (You Ain't Gonna Need It) | 仮説的な機能がなく、最もシンプルなアプローチが選択されていること |
ワークフロー内(/workflows:brainstormまたは/workflows:planの後)で呼び出された場合は、以下も確認します。
- ユーザー意図の忠実性 (User intent fidelity) — ドキュメントが議論された内容を反映しており、仮定が検証されていること
ステップ4:重要な改善点を特定する
ステップ2〜3で見つかったすべての点の中で、際立った問題はありますか?ドキュメントの品質を著しく向上させるものがあれば、それが「対処すべき」項目です。それを目立つように強調してください。
ステップ5:変更を加える
調査結果を提示し、その後:
- 軽微な問題(曖昧な表現、書式設定)は、尋ねずに自動修正します。
- 実質的な変更(再構築、セクションの削除、意味の変更)の前に承認を求めます。
- ドキュメントをインラインで更新します。別のファイルやメタデータセクションは作成しません。
簡素化のガイダンス
簡素化とは、不必要な複雑さを意図的に取り除くことであり、単に短くすることではありません。
簡素化する場合:
- コンテンツが現在のニーズではなく、仮説的な将来のニーズに対応している場合
- セクションが他の場所で既にカバーされている情報を繰り返している場合
- 詳細が次のステップに進むために必要なものを超えている場合
- 抽象化や構造が明確さをもたらさずにオーバーヘッドを追加している場合
簡素化しない場合:
- 実装に影響を与える制約やエッジケース
- 代替案が却下された理由を説明する根拠
- 解決が必要な未解決の質問
ステップ6:次のアクションを提案する
変更が完了したら、以下の質問をします。
- 再度洗練する - もう一度レビューパスを行う
- レビュー完了 - ドキュメントは準備完了
反復のガイダンス
2回の洗練パスの後、完了を推奨します。収穫逓減の可能性が高いからです。ただし、ユーザーが続行を希望する場合は、それを許可します。
選択後、呼び出し元(ワークフローまたはユーザー)に制御を戻します。
行わないこと
- ドキュメント全体を書き直さないでください。
- ユーザーが議論しなかった新しいセクションや要件を追加しないでください。
- 過度に設計したり、複雑さを追加したりしないでください。
- 別途レビューファイルを作成したり、メタデータセクションを追加したりしないでください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Document Review
Improve brainstorm or plan documents through structured review.
Step 1: Get the Document
If a document path is provided: Read it, then proceed to Step 2.
If no document is specified: Ask which document to review, or look for the most recent brainstorm/plan in docs/brainstorms/ or docs/plans/.
Step 2: Assess
Read through the document and ask:
- What is unclear?
- What is unnecessary?
- What decision is being avoided?
- What assumptions are unstated?
- Where could scope accidentally expand?
These questions surface issues. Don't fix yet—just note what you find.
Step 3: Evaluate
Score the document against these criteria:
| Criterion | What to Check |
|---|---|
| Clarity | Problem statement is clear, no vague language ("probably," "consider," "try to") |
| Completeness | Required sections present, constraints stated, open questions flagged |
| Specificity | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
| YAGNI | No hypothetical features, simplest approach chosen |
If invoked within a workflow (after /workflows:brainstorm or /workflows:plan), also check:
- User intent fidelity — Document reflects what was discussed, assumptions validated
Step 4: Identify the Critical Improvement
Among everything found in Steps 2-3, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.
Step 5: Make Changes
Present your findings, then:
- Auto-fix minor issues (vague language, formatting) without asking
- Ask approval before substantive changes (restructuring, removing sections, changing meaning)
- Update the document inline—no separate files, no metadata sections
Simplification Guidance
Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
Simplify when:
- Content serves hypothetical future needs, not current ones
- Sections repeat information already covered elsewhere
- Detail exceeds what's needed to take the next step
- Abstractions or structure add overhead without clarity
Don't simplify:
- Constraints or edge cases that affect implementation
- Rationale that explains why alternatives were rejected
- Open questions that need resolution
Step 6: Offer Next Action
After changes are complete, ask:
- Refine again - Another review pass
- Review complete - Document is ready
Iteration Guidance
After 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.
Return control to the caller (workflow or user) after selection.
What NOT to Do
- Do not rewrite the entire document
- Do not add new sections or requirements the user didn't discuss
- Do not over-engineer or add complexity
- Do not create separate review files or add metadata sections