zchary1106/claude-agent-toolkit/requirement-translator

Requirement Translator

Translates vague product requirements into precise technical specs, or translates technical limitations into language product managers understand.

Modes

Mode 1: PM → Dev (Requirement Translation)

Input: Product manager's raw requirement description (verbal, doc, screenshot)

Output structure:

## Requirement Translation Report
 
### 🎯 Core Objective
One sentence describing what problem this requirement actually solves
 
### ⚠️ Ambiguity Detection
Identify vague points, contradictions, and hidden assumptions
-🔴 Critical ambiguity: [details]
-🟡 Needs confirmation: [details]
-🟢 Clear: [details]
 
### 📋 Technical Spec
-**Task breakdown**: Split into executable task list
-**API definitions**: Endpoints, request/response structures
-**Data model**: Table/schema changes involved
-**Edge cases**: Error handling, extreme scenarios
-**Dependencies**: Parts requiring other teams/services
 
### ⏰ Time Estimate
Using 2.1x coefficient (includes integration, communication, testing, change buffer)
| Task | Base effort | With coefficient |
|------|------------|-----------------|
| ... | ... | ... |
| **Total** | X person-days | Y person-days |
 
### ❓ Questions for PM
Numbered list of questions that must be answered before development starts

Mode 2: Dev → PM (Technical Translation)

Input: Technical problem or limitation encountered by developer

Translation principles:

1. Never say "can't do it" — say "this approach costs X, alternative costs Y"
2. Describe impact in user value terms, not technical jargon
3. Every problem comes with at least one alternative
4. Use analogies for non-technical audience (e.g., "It's like changing the foundation of a building that's already built")

Output structure:

## Technical Translation Report
 
### Current Situation (Product Language)
Describe the current state in terms non-technical people understand
 
### Option Comparison
| Option | User Experience | Dev Cost | Risk | Recommendation |
|--------|----------------|----------|------|----------------|
 
### Recommended Option
Rationale (from user value perspective)

Mode 3: Scope Drift Tracking

When user mentions a requirement change:

1. Record the change content (diff from previous version)
2. Assess impact (additional effort, architecture changes, risk)
3. Calculate drift index: change_count × avg_impact / total_timeline
4. Alert when drift index > 0.5

Mode 4: Time Estimation

Auto-estimate based on requirement complexity, using coefficients from patterns.md.

Key rules:

• Never give "fastest possible" estimates — give "reasonable timeline"
• Explicitly list what's included and excluded
• Provide "scope cut" options: what can be dropped to shorten the timeline

Reference

• PM phrase translations, time coefficients, and Dev response templates: references/patterns.md

Example

User: "Product wants a sharing feature like Instagram, ship ASAP"

Triggers PM→Dev mode:

1. Ambiguity detection: "like Instagram" → which specific features? "ASAP" → need a concrete date
2. Task breakdown: Image/text posts, feed, likes/comments, recommendation algorithm...
3. Time estimate: MVP (posts + feed only) ~15 person-days, full version ~40 person-days
4. Recommendation: Build MVP first for validation, define scope before scheduling