Skill

technical-requirements-translation

Translate business/user requirements into technical specifications that engineers can build against. Use when clarifying ambiguous requirements or discovering hidden technical constraints.

From cross-functional-leadership

Install

Run in your terminal

npx claudepluginhub sethdford/claude-skills --plugin tech-lead-cross-functional

Tool Access

This skill uses the workspace's default tool permissions.

Skill Content

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

138.6k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

evaluation-methodology

1 file

Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.

plugin-eval

32.9k

Stats

Parent Repo Stars3

Parent Repo Forks0

Last CommitMar 11, 2026

Actions

View Source View Plugin View on GitHub View README

Domain Context

Business obsession vs technical reality — "We need it to work for 100M users" is business obsession. "We need to handle 10K requests/second" is technical reality. Translation makes both sides concrete.

Constraints are opportunities — "Build it for mobile" is vague. "Build it for 4G networks, 4GB RAM phones" is concrete constraint that drives good decisions.

Hidden tradeoffs emerge in translation — business wants fast delivery + high quality + low cost. Translation reveals: pick 2 of 3. Choosing forces clarity.

Feasibility changes with options — "Real-time updates" is hard. "Real-time within 5 seconds" is moderate. "Real-time within 2 hours" is easy. Translation finds the line.

Instructions

Clarify the business outcome: "Users can share documents" is outcome. Not "Build a WebSocket-based real-time sync system." Don't assume technical solution; understand problem first.

Quantify constraints: "Fast" becomes "page load under 2 seconds on 4G." "Scalable" becomes "handle 100K concurrent users." Quantification enables technical decision-making.

List assumptions: "Assume user is logged in," "assume documents are <100MB," "assume network latency <200ms." Hidden assumptions surface when listed. Challenge unrealistic ones.

Discover hard parts: "Can users collaborate on same document simultaneously?" If yes, real-time sync is hard. If "yes but eventual consistency okay," that's easier. Questions reveal hidden complexity.

Create decision tree: "If we need real-time: approach X (expensive). If eventual-consistency okay: approach Y (cheaper). Business decides." Frame as choices, let stakeholder decide tradeoffs.

Anti-Patterns

Accepting vague requirements: "Make it fast" → unclear what fast means. Dig. "How fast? On what device? Network? Measure against what baseline?"

Over-translating: Turning business requirement into 50-page spec. Kills flexibility. 1-page spec: problem, constraints, assumptions, options. Enough to start.

Technical solution before problem: Business says "use machine learning," but haven't understood problem. Maybe simple rules work. Question first, tech second.

Ignoring non-functional requirements: Focus on features, ignore performance/reliability/security. "It works" ≠ "it works at scale" ≠ "it works securely."

No revisiting assumptions: Build based on assumptions that become wrong. Customer base grows 10x, scalability assumptions broken. Revisit periodically.

Domain Context

Constraints are opportunities — "Build it for mobile" is vague. "Build it for 4G networks, 4GB RAM phones" is concrete constraint that drives good decisions.

Hidden tradeoffs emerge in translation — business wants fast delivery + high quality + low cost. Translation reveals: pick 2 of 3. Choosing forces clarity.

Feasibility changes with options — "Real-time updates" is hard. "Real-time within 5 seconds" is moderate. "Real-time within 2 hours" is easy. Translation finds the line.

Instructions

Clarify the business outcome: "Users can share documents" is outcome. Not "Build a WebSocket-based real-time sync system." Don't assume technical solution; understand problem first.

Quantify constraints: "Fast" becomes "page load under 2 seconds on 4G." "Scalable" becomes "handle 100K concurrent users." Quantification enables technical decision-making.

List assumptions: "Assume user is logged in," "assume documents are <100MB," "assume network latency <200ms." Hidden assumptions surface when listed. Challenge unrealistic ones.

Create decision tree: "If we need real-time: approach X (expensive). If eventual-consistency okay: approach Y (cheaper). Business decides." Frame as choices, let stakeholder decide tradeoffs.

Anti-Patterns

Accepting vague requirements: "Make it fast" → unclear what fast means. Dig. "How fast? On what device? Network? Measure against what baseline?"

Over-translating: Turning business requirement into 50-page spec. Kills flexibility. 1-page spec: problem, constraints, assumptions, options. Enough to start.

Technical solution before problem: Business says "use machine learning," but haven't understood problem. Maybe simple rules work. Question first, tech second.

Ignoring non-functional requirements: Focus on features, ignore performance/reliability/security. "It works" ≠ "it works at scale" ≠ "it works securely."

No revisiting assumptions: Build based on assumptions that become wrong. Customer base grows 10x, scalability assumptions broken. Revisit periodically.

technical-requirements-translation

technical-requirements-translation

Technical Requirements Translation

Context

Domain Context

Instructions

Anti-Patterns

Further Reading

Technical Requirements Translation

Context

Domain Context

Instructions

Anti-Patterns

Further Reading