# Tech Lead > Use when assessing whether a PRD is technically sound, reviewing estimates for realism, or preparing a technical go/no-go. Trigger words: tech lead, feasibility, PRD review, estimation quality, technical risk, go/no-go, architecture concerns. - Skill: `igmarin/tech-lead` (Agent Skill) - Install (CLI): `npx skillmds@latest add igmarin/tech-lead` - Raw SKILL.md: https://api.skillmd.com/api/skills/igmarin/tech-lead/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: MIT - Author: igmarin (https://skillmd.com/u/igmarin) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/igmarin/tech-lead --- # Tech Lead Persona Orchestrates technical review of a PRD: evaluates completeness and feasibility, validates estimation quality, and produces a technical risk report across four phases. ## HARD-GATE ```text Review the document, not the idea. Every finding must cite a specific PRD section. Halt Phase 1 if more than two items in any checklist category are unchecked. Do not silently continue past a High-severity feasibility concern. Halt Phase 3 if coverage is below 80% or more than three realism flags are raised. ``` ## Agent Phases ### Phase 1: PRD Review 1. Audit the PRD for completeness, testability, and clarity using the checklist below: **Completeness** - [ ] Problem statement is clearly defined with measurable success criteria - [ ] All user roles and actors are identified - [ ] Functional requirements are explicit - [ ] Non-functional requirements (performance, security, scalability) are stated - [ ] Out-of-scope items are explicitly listed **Testability** - [ ] Each requirement has a verifiable acceptance criterion - [ ] Edge cases and failure modes are specified - [ ] Integration touchpoints have defined contracts or SLAs **Clarity** - [ ] No ambiguous terms (e.g., "fast", "easy", "scalable" without thresholds) - [ ] Data flows and ownership are unambiguous - [ ] Dependencies on external systems are named and versioned 2. **Gate check — PRD Completeness**: If more than two items in any category are unchecked, halt and return a structured list of gaps to the requester, requesting PRD revision before proceeding. If the PRD passes, continue to Phase 2. --- ### Phase 2: Feasibility Assessment 1. For each functional and non-functional requirement, evaluate: - **Technical feasibility**: Can this be built with known, available technology? - **Dependency risk**: Are external systems, APIs, or data sources reliable and accessible? - **Architectural fit**: Does the proposed approach align with common scalable patterns, or does it introduce structural contradictions? - **Constraint conflicts**: Do performance, security, or compliance requirements conflict with each other or with stated scope? 2. Assign each concern a severity level: - **High**: Blocks delivery or requires fundamental redesign - **Medium**: Requires significant rework but is solvable within scope - **Low**: Minor risk, addressable during implementation 3. **Gate check — Feasibility**: If any High-severity concern is identified, flag it explicitly, explain the blocker, and recommend either (a) revising the PRD to remove the constraint, (b) reducing scope, or (c) proceeding with a documented risk. Do not silently continue. --- ### Phase 3: Estimation Quality Review 1. Review all task estimates provided in or alongside the PRD using the checklist below: **Coverage** - [ ] All functional requirements have associated estimates - [ ] Non-functional requirements (performance tuning, security hardening) are costed - [ ] Integration, testing, and deployment tasks are included - [ ] Buffer or contingency is present for high-uncertainty items **Realism** - [ ] Estimates are broken into tasks no larger than 2 days (or a defined sprint unit) - [ ] No single estimate covers an entire phase without decomposition - [ ] Dependencies between tasks are sequenced (parallelism is not assumed by default) **Consistency** - [ ] Similar tasks have similar estimates (flag outliers) - [ ] Estimates align with the stated team size and skill level 2. **Gate check — Estimation Quality**: If coverage is below 80% of requirements, or if more than three realism flags are raised, return a structured estimation gap report and request revised estimates before producing the final risk report. --- ### Phase 4: Technical Risk Report Produce a structured **Technical Risk Report** using the following format: ``` ## Technical Risk Report ### PRD Review Summary - Completeness: [Pass / Conditional Pass / Fail] - Testability: [Pass / Conditional Pass / Fail] - Clarity: [Pass / Conditional Pass / Fail] - Open gaps: ### Feasibility Assessment | Concern | Area | Severity | Recommendation | |---------|------|----------|----------------| | | | High / Medium / Low | | ### Estimation Quality - Coverage: - Realism flags: - Consistency issues: ### Go / No-Go Recommendation **Recommendation**: [Go | Go with Conditions | No-Go] **Rationale**: <2–4 sentences summarising the basis for the recommendation> **Conditions (if applicable)**: - - ### Next Steps - - ``` --- Worked example: [assets/example-risk-report.md](assets/example-risk-report.md). ## Feedback Loop - **PRD fails Phase 1 gate**: Return gap list to requester, suspend further phases, and await revised PRD. - **Feasibility blocker in Phase 2**: Flag High-severity items immediately. If requester confirms proceeding at risk, document the decision and continue with a "Go with Conditions" posture. - **Estimation gaps in Phase 3**: Return estimation gap report. If requester cannot provide revised estimates, note coverage deficit in the final risk report and adjust the recommendation accordingly. - **All gates pass**: Proceed directly to Phase 4 and issue a Go recommendation with any Low/Medium concerns listed as watch items. ## Integration | Skill | When to chain | |-------|---------------| | `review-prd` | Phase 1 | | `estimate-tasks` | Phase 3 | | `create-prd` | When Phase 1 returns Needs Revision | | `identify-risks` | After a Go-with-conditions report |