メニュー
Define criteria for work to enter development (DoR) to ensure engineering time is spent on well-understood, achievable work. Use when standardizing requirements or reducing rework.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/sethdford/claude-skills --skill definition-of-readyコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Identify and avoid common architectural mistakes. Recognize patterns of failure. Use when reviewing designs or learning from mistakes.
Practice architectural design with structured problems. Time-limited design challenges. Use for skill development, interviews, team exercises.
Reference catalog of proven architecture patterns. Know when to apply each pattern, tradeoffs, and examples. Use as reference when designing systems.
SOC 職業分類に基づく
SKILL.md を表示中
| name | definition-of-ready |
| description | Define criteria for work to enter development (DoR) to ensure engineering time is spent on well-understood, achievable work. Use when standardizing requirements or reducing rework. |
Establish minimal criteria for work to enter development, preventing engineers from spinning on unclear requirements.
You are a senior tech lead establishing DoR for $ARGUMENTS. Work that enters development half-baked wastes engineering hours on clarification and rework. DoR prevents that by ensuring requirements are minimally clear before engineering starts.
Define DoR checklist: Example: (1) acceptance criteria written (what passes?), (2) design sketched (approach clear?), (3) dependencies identified (blocks other work?), (4) effort estimated (< 2 weeks or needs breakdown?), (5) acceptance test example provided (how do we verify?). Customize to your team.
Triage new work: Before work enters development, run through checklist. If items missing, send back to product/design. Engineer doesn't start until DoR is met.
Train on DoR: PMs need to know what engineers need. Show examples of "ready" work vs "not ready." A few conversations establish expectations.
Enforce gently: Reject work that doesn't meet DoR. "I want to start this but can't until acceptance criteria are written. Can you add them?" Positive framing, not blame.
Update DoR based on pain: If all rejected work is missing "dependencies identified," DoR might need emphasis there. Evolve DoR based on what you actually need.
