Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From process-engineering
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.
npx claudepluginhub sethdford/claude-skills --plugin tech-lead-process-engineeringHow this skill is triggered — by the user, by Claude, or both
Slash command
/process-engineering:definition-of-readyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Establish minimal criteria for work to enter development, preventing engineers from spinning on unclear requirements.
Ensures work items are ready for development before sprint intake. Combines PM requirements skills + architect design feasibility + security threat assessment.
Transforms business analyses into epics, features, and tech-agnostic success criteria. Creates handoff documents, triages artifacts as FEATURE/IMP/FIX/ADR, manages BACKLOG.md entries, and runs GitHub integration for issues/PRs.
Share bugs, ideas, or general feedback.
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.