Back to Details

technical-requirements-interview

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Technical Requirements Interview

技术需求访谈

This skill guides you through a structured interview to derive technical requirements from business requirements.
该Skill将引导你通过结构化访谈从业务需求中提炼技术需求。

Prerequisites

前置要求

  • Completed 
    business-requirements.yaml
    file
  • Clear understanding of the problem domain
  • 已完成的 
    business-requirements.yaml
    文件
  • 对问题域有清晰的认知

Interview Process

访谈流程

Rules

规则

  1. One question at a time - Never ask multiple questions in a single turn
  2. Business context first - Load and understand business requirements before asking technical questions
  3. Provide options - Each question includes 2-5 recommended options plus free-form input
  4. Track progress - All Q&A pairs are immediately appended to 
    technical-interview.jsonl
  5. Resume capability - If JSONL exists, continue from last question
  6. Structured output - Generate 
    technical-requirements.yaml
    upon completion
  1. 每次仅提一个问题 - 单次交互中绝不提问多个问题
  2. 业务上下文优先 - 加载并理解业务需求后再提出技术问题
  3. 提供选项 - 每个问题包含2-5个推荐选项，同时支持自由输入
  4. 进度追踪 - 所有问答对会立即追加到 
    technical-interview.jsonl
    文件中
  5. 可恢复能力 - 如果JSONL文件已存在，将从上一个问题继续推进
  6. 结构化输出 - 流程完成后生成 
    technical-requirements.yaml
    文件

Interview Categories

访谈类别

The interview covers these areas in order:
  1. Architecture & Patterns
    • Overall architecture style
    • Application structure
    • Component organization
  2. Technology Stack
    • Programming language
    • Frameworks and libraries
    • Package management
  3. Data Model & Storage
    • Data persistence strategy
    • Database selection
    • Schema design approach
  4. API Design
    • API style (REST, GraphQL, RPC)
    • API framework
    • Versioning strategy
  5. Security & Authentication
    • Authentication method
    • Authorization approach
    • Secrets management
  6. Testing Strategy
    • Testing approach (TDD, BDD, etc.)
    • Test types (unit, integration, e2e)
    • Testing frameworks
  7. Development & Tooling
    • Development workflow
    • Code quality tools
    • CI/CD approach
  8. Deployment & Distribution
    • Deployment target
    • Packaging strategy
    • Release process
访谈将按顺序覆盖以下领域：
  1. 架构与模式
    • 整体架构风格
    • 应用结构
    • 组件组织
  2. 技术栈
    • 编程语言
    • 框架与库
    • 包管理
  3. 数据模型与存储
    • 数据持久化策略
    • 数据库选型
    • Schema设计方案
  4. API设计
    • API风格（REST、GraphQL、RPC）
    • API框架
    • 版本管理策略
  5. 安全与身份验证
    • 身份验证方式
    • 授权方案
    • 密钥管理
  6. 测试策略
    • 测试方案（TDD、BDD等）
    • 测试类型（单元测试、集成测试、e2e测试）
    • 测试框架
  7. 开发与工具链
    • 开发工作流
    • 代码质量工具
    • CI/CD方案
  8. 部署与分发
    • 部署目标
    • 打包策略
    • 发布流程

Question Format

问题格式

Each question follows this structure:
undefined
每个问题遵循以下结构：
undefined

[Category Name]

[Category Name]

Question: [Clear, specific question]
Options:
  1. [Option 1] (Recommended) - [Brief description and rationale]
  2. [Option 2] - [Brief description]
  3. [Option 3] - [Brief description]
  4. Type your own answer
undefined
Question: [Clear, specific question]
Options:
  1. [Option 1] (Recommended) - [Brief description and rationale]
  2. [Option 2] - [Brief description]
  3. [Option 3] - [Brief description]
  4. Type your own answer
undefined

Example Questions

示例问题

Architecture

架构

undefined
undefined

Architecture & Patterns

Architecture & Patterns

Question: What architecture pattern best fits this project?
Options:
  1. Monolithic application (Recommended) - Single deployable unit, simpler to develop and deploy initially
  2. Microservices - Multiple independent services, better scaling but higher complexity
  3. Serverless functions - Event-driven, scales automatically, but vendor lock-in
  4. Plugin-based - Core engine with extensible plugins for flexibility
  5. Type your own answer
undefined
Question: What architecture pattern best fits this project?
Options:
  1. Monolithic application (Recommended) - Single deployable unit, simpler to develop and deploy initially
  2. Microservices - Multiple independent services, better scaling but higher complexity
  3. Serverless functions - Event-driven, scales automatically, but vendor lock-in
  4. Plugin-based - Core engine with extensible plugins for flexibility
  5. Type your own answer
undefined

Technology Stack

技术栈

undefined
undefined

Technology Stack

Technology Stack

Question: Which programming language should be used?
Options:
  1. TypeScript (Recommended) - Type-safe JavaScript, excellent tooling, large ecosystem
  2. Python - Readable, extensive libraries, good for data processing and scripting
  3. Go - Fast compilation, excellent concurrency, simple deployment
  4. Rust - Memory safety without garbage collection, high performance
  5. Type your own answer
undefined
Question: Which programming language should be used?
Options:
  1. TypeScript (Recommended) - Type-safe JavaScript, excellent tooling, large ecosystem
  2. Python - Readable, extensive libraries, good for data processing and scripting
  3. Go - Fast compilation, excellent concurrency, simple deployment
  4. Rust - Memory safety without garbage collection, high performance
  5. Type your own answer
undefined

Data Storage

数据存储

undefined
undefined

Data Model & Storage

Data Model & Storage

Question: What data persistence strategy is appropriate?
Options:
  1. File-based storage (Recommended) - Simple, portable, no database dependency
  2. SQLite - Embedded relational database, good for local tools
  3. PostgreSQL - Full-featured relational database, better for complex queries
  4. NoSQL (MongoDB, etc.) - Flexible schema, good for document-based data
  5. In-memory only - Fast but no persistence, suitable for ephemeral data
  6. Type your own answer
undefined
Question: What data persistence strategy is appropriate?
Options:
  1. File-based storage (Recommended) - Simple, portable, no database dependency
  2. SQLite - Embedded relational database, good for local tools
  3. PostgreSQL - Full-featured relational database, better for complex queries
  4. NoSQL (MongoDB, etc.) - Flexible schema, good for document-based data
  5. In-memory only - Fast but no persistence, suitable for ephemeral data
  6. Type your own answer
undefined

JSONL Format

JSONL格式

Track all questions and answers in 
technical-interview.jsonl
:
json
{"id":1,"category":"Architecture & Patterns","question":"What architecture pattern best fits this project?","answer":"Monolithic application - Single deployable unit, simpler to develop and deploy initially","question_number":"Q1","timestamp":"2025-01-27T11:00:00Z"}
{"id":2,"category":"Technology Stack","question":"Which programming language should be used?","answer":"TypeScript - Type-safe JavaScript, excellent tooling, large ecosystem","question_number":"Q2","timestamp":"2025-01-27T11:05:00Z"}
所有问答内容会记录在 
technical-interview.jsonl
文件中：
json
{"id":1,"category":"Architecture & Patterns","question":"What architecture pattern best fits this project?","answer":"Monolithic application - Single deployable unit, simpler to develop and deploy initially","question_number":"Q1","timestamp":"2025-01-27T11:00:00Z"}
{"id":2,"category":"Technology Stack","question":"Which programming language should be used?","answer":"TypeScript - Type-safe JavaScript, excellent tooling, large ecosystem","question_number":"Q2","timestamp":"2025-01-27T11:05:00Z"}

Output Format

输出格式

Generate 
technical-requirements.yaml
with this structure:
yaml
project: [project-name]
version: "1.0.0"
generated: [timestamp]
business_requirements_ref: [path-to-business-requirements.yaml]

architecture:
  pattern: [architecture-pattern]
  description: |
    [Detailed description of architecture approach]
  components:
    - name: [Component 1]
      responsibility: [What it does]
    - name: [Component 2]
      responsibility: [What it does]

technology_stack:
  language: [programming-language]
  runtime: [node/python/jvm/etc]
  frameworks:
    - [framework 1]
    - [framework 2]
  libraries:
    core:
      - [library 1]
      - [library 2]
    development:
      - [dev library 1]
  package_manager: [npm/pip/cargo/etc]

project_structure:
  type: [monorepo/multi-repo/single-repo]
  layout: |
    [Description of directory structure]
  key_directories:
    - path: [path]
      purpose: [what goes here]

data_model:
  strategy: [file/database/memory/etc]
  database: [type-if-applicable]
  schema_approach: [description]
  migrations: [strategy]

api:
  style: [REST/GraphQL/RPC/CLI]
  framework: [framework-name]
  versioning: [strategy]
  documentation: [approach]

security:
  authentication:
    method: [none/token/oauth/etc]
    implementation: [how]
  authorization:
    model: [none/rbac/abac/etc]
    implementation: [how]
  secrets:
    storage: [env-vars/keychain/vault/etc]
    rotation: [policy]
  data_validation:
    input: [approach]
    output: [approach]

testing:
  strategy: [TDD/BDD/manual/etc]
  types:
    unit:
      framework: [framework]
      coverage_target: [percentage]
    integration:
      framework: [framework]
      approach: [description]
    e2e:
      framework: [framework]
      approach: [description]
  mocking:
    strategy: [what to mock]
    tools: [frameworks]

development:
  workflow: [description]
  code_quality:
    linter: [tool]
    formatter: [tool]
    type_checker: [tool]
  pre_commit_hooks:
    - [hook 1]
    - [hook 2]

ci_cd:
  platform: [github-actions/circleci/etc]
  pipeline:
    - stage: [stage 1]
      actions:
        - [action 1]
        - [action 2]
    - stage: [stage 2]
      actions:
        - [action 1]

deployment:
  target: [local/cloud/hybrid/etc]
  packaging:
    format: [npm/docker/binary/etc]
    distribution: [approach]
  environments:
    - name: development
      config: [approach]
    - name: production
      config: [approach]
  release_process:
    strategy: [semver/calver/etc]
    automation: [level]

monitoring:
  logging:
    format: [structured/plain]
    destination: [file/console/service]
  metrics:
    collection: [approach]
    visualization: [tool]
  alerts:
    strategy: [when to alert]
    channels: [email/slack/etc]

performance:
  targets:
    response_time: [target]
    throughput: [target]
  optimization:
    strategy: [caching/lazy-loading/etc]
    monitoring: [approach]

scalability:
  approach: [vertical/horizontal/serverless]
  limits:
    concurrent_users: [estimate]
    data_volume: [estimate]
  bottlenecks:
    - [known bottleneck 1]
    - [known bottleneck 2]

constraints:
  technical:
    - [constraint 1]
    - [constraint 2]
  operational:
    - [constraint 1]
    - [constraint 2]

trade_offs:
  - decision: [decision made]
    rationale: [why]
    alternative: [what was not chosen]
    consequence: [impact]

open_questions:
  - question: [unresolved question]
    options:
      - [option 1]
      - [option 2]
    impact: [what this affects]
生成的 
technical-requirements.yaml
结构如下：
yaml
project: [project-name]
version: "1.0.0"
generated: [timestamp]
business_requirements_ref: [path-to-business-requirements.yaml]

architecture:
  pattern: [architecture-pattern]
  description: |
    [Detailed description of architecture approach]
  components:
    - name: [Component 1]
      responsibility: [What it does]
    - name: [Component 2]
      responsibility: [What it does]

technology_stack:
  language: [programming-language]
  runtime: [node/python/jvm/etc]
  frameworks:
    - [framework 1]
    - [framework 2]
  libraries:
    core:
      - [library 1]
      - [library 2]
    development:
      - [dev library 1]
  package_manager: [npm/pip/cargo/etc]

project_structure:
  type: [monorepo/multi-repo/single-repo]
  layout: |
    [Description of directory structure]
  key_directories:
    - path: [path]
      purpose: [what goes here]

data_model:
  strategy: [file/database/memory/etc]
  database: [type-if-applicable]
  schema_approach: [description]
  migrations: [strategy]

api:
  style: [REST/GraphQL/RPC/CLI]
  framework: [framework-name]
  versioning: [strategy]
  documentation: [approach]

security:
  authentication:
    method: [none/token/oauth/etc]
    implementation: [how]
  authorization:
    model: [none/rbac/abac/etc]
    implementation: [how]
  secrets:
    storage: [env-vars/keychain/vault/etc]
    rotation: [policy]
  data_validation:
    input: [approach]
    output: [approach]

testing:
  strategy: [TDD/BDD/manual/etc]
  types:
    unit:
      framework: [framework]
      coverage_target: [percentage]
    integration:
      framework: [framework]
      approach: [description]
    e2e:
      framework: [framework]
      approach: [description]
  mocking:
    strategy: [what to mock]
    tools: [frameworks]

development:
  workflow: [description]
  code_quality:
    linter: [tool]
    formatter: [tool]
    type_checker: [tool]
  pre_commit_hooks:
    - [hook 1]
    - [hook 2]

ci_cd:
  platform: [github-actions/circleci/etc]
  pipeline:
    - stage: [stage 1]
      actions:
        - [action 1]
        - [action 2]
    - stage: [stage 2]
      actions:
        - [action 1]

deployment:
  target: [local/cloud/hybrid/etc]
  packaging:
    format: [npm/docker/binary/etc]
    distribution: [approach]
  environments:
    - name: development
      config: [approach]
    - name: production
      config: [approach]
  release_process:
    strategy: [semver/calver/etc]
    automation: [level]

monitoring:
  logging:
    format: [structured/plain]
    destination: [file/console/service]
  metrics:
    collection: [approach]
    visualization: [tool]
  alerts:
    strategy: [when to alert]
    channels: [email/slack/etc]

performance:
  targets:
    response_time: [target]
    throughput: [target]
  optimization:
    strategy: [caching/lazy-loading/etc]
    monitoring: [approach]

scalability:
  approach: [vertical/horizontal/serverless]
  limits:
    concurrent_users: [estimate]
    data_volume: [estimate]
  bottlenecks:
    - [known bottleneck 1]
    - [known bottleneck 2]

constraints:
  technical:
    - [constraint 1]
    - [constraint 2]
  operational:
    - [constraint 1]
    - [constraint 2]

trade_offs:
  - decision: [decision made]
    rationale: [why]
    alternative: [what was not chosen]
    consequence: [impact]

open_questions:
  - question: [unresolved question]
    options:
      - [option 1]
      - [option 2]
    impact: [what this affects]

Usage

使用方法

To start a new technical interview:
/technical-requirements-interview path/to/business-requirements.yaml
To resume an existing interview:
/technical-requirements-interview path/to/business-requirements.yaml
The skill will automatically:
  1. Load business requirements as context
  2. Check for existing 
    technical-interview.jsonl
  3. Resume from last question if found
  4. Ask targeted technical questions
  5. Generate 
    technical-requirements.yaml
    when complete
启动新的技术需求访谈：
/technical-requirements-interview path/to/business-requirements.yaml
恢复已有访谈：
/technical-requirements-interview path/to/business-requirements.yaml
该Skill会自动执行以下操作：
  1. 加载业务需求作为上下文
  2. 检查是否存在已有的 
    technical-interview.jsonl
    文件
  3. 如果找到则从上一个问题继续推进
  4. 提出针对性的技术问题
  5. 流程完成后生成 
    technical-requirements.yaml
    文件

Decision Tracking

决策追踪

Each technical decision should include:
  1. Decision - What was decided
  2. Rationale - Why this approach
  3. Alternatives considered - What else was evaluated
  4. Trade-offs - What was gained/lost
  5. Reversibility - How hard to change later
每个技术决策都应包含：
  1. 决策内容 - 确定了什么方案
  2. 决策依据 - 为什么选择该方案
  3. 考虑过的替代方案 - 还评估过哪些其他选项
  4. 权衡取舍 - 获得了什么/牺牲了什么
  5. 可逆转性 - 后续调整的难度

Best Practices

最佳实践

  1. Align with business needs - Every technical choice should support business requirements
  2. Consider constraints - Respect timeline, budget, and skill constraints
  3. Start simple - Choose simpler solutions over complex ones when possible
  4. Plan for change - Make reversible decisions where possible
  5. Document rationale - Future you will thank present you
  1. 与业务需求对齐 - 所有技术选择都应支撑业务需求
  2. 考虑约束条件 - 尊重时间、预算和技能约束
  3. 从简起步 - 尽可能选择更简单的方案而非复杂方案
  4. 为变更做规划 - 尽可能做出可逆转的决策
  5. 记录决策依据 - 未来的你会感谢现在的你

Review & Gap Analysis

评审与差距分析

After generating 
technical-requirements.yaml
, automatically perform a gap analysis:
生成 
technical-requirements.yaml
后，会自动执行差距分析：

Alignment Check

对齐检查

Business Alignment:
  • Architecture supports all functional requirements
  • Technology choices align with business constraints
  • Timeline is realistic for technical scope
  • Budget constraints respected in tool/service choices
Completeness Check:
Architecture:
  • Architecture pattern is clearly defined
  • Components and responsibilities documented
  • Data flow is clear
  • Integration points identified
Technology Stack:
  • Language and runtime specified
  • Frameworks and libraries listed
  • Versions specified where critical
  • Alternatives considered and documented
Data Model:
  • Storage strategy defined
  • Schema approach documented
  • Migration strategy if using database
  • Data validation approach specified
API:
  • API style chosen (REST/GraphQL/RPC)
  • Framework selected
  • Versioning strategy defined
  • Documentation approach specified
Security:
  • Authentication method defined
  • Authorization model specified
  • Secrets management approach
  • Input/output validation strategy
Testing:
  • Testing strategy defined (TDD/BDD/etc)
  • Test types specified (unit/integration/e2e)
  • Frameworks selected
  • Coverage targets set
Deployment:
  • Deployment target identified
  • Packaging format chosen
  • CI/CD approach defined
  • Release process documented
业务对齐：
  • 架构支持所有功能需求
  • 技术选择与业务约束对齐
  • 技术范围对应的时间线具备可行性
  • 工具/服务选择符合预算约束
完整性检查：
架构：
  • 架构模式已明确定义
  • 组件及职责已记录
  • 数据流清晰
  • 集成点已识别
技术栈：
  • 编程语言和运行时已指定
  • 框架和库已列出
  • 关键依赖的版本已指定
  • 考虑过的替代方案已记录
数据模型：
  • 存储策略已定义
  • Schema方案已记录
  • 若使用数据库，迁移策略已明确
  • 数据校验方案已指定
API：
  • 已选定API风格（REST/GraphQL/RPC）
  • 框架已选定
  • 版本管理策略已定义
  • 文档方案已指定
安全：
  • 身份验证方式已定义
  • 授权模型已指定
  • 密钥管理方案已明确
  • 输入/输出校验策略已明确
测试：
  • 测试策略已定义（TDD/BDD等）
  • 测试类型已指定（单元测试/集成测试/e2e测试）
  • 框架已选定
  • 覆盖率目标已设置
部署：
  • 部署目标已确认
  • 打包格式已选定
  • CI/CD方案已定义
  • 发布流程已记录

Consistency Check

一致性检查

  • No contradictions between technical decisions
  • Technology choices compatible with each other
  • Performance targets achievable with chosen stack
  • Security approach matches data sensitivity
  • 技术决策之间不存在矛盾
  • 技术选择相互兼容
  • 选定的技术栈可实现性能目标
  • 安全方案与数据敏感等级匹配

Trade-off Analysis

权衡取舍分析

Review documented trade-offs:
  • Each trade-off has clear rationale
  • Alternatives were seriously considered
  • Consequences understood and acceptable
  • Reversibility assessed
评审已记录的权衡项：
  • 每个权衡项都有清晰的决策依据
  • 替代方案经过了认真评估
  • 影响已被理解且可接受
  • 可逆转性已评估

Gap Identification

差距识别

Common Gaps to Check:
  • Missing error handling strategy
  • Undocumented edge cases
  • Unaddressed scalability concerns
  • Missing monitoring/observability plan
  • Unclear data migration path
  • Missing security threat model
  • Undocumented performance budgets
  • Missing disaster recovery plan
  • Unclear dependency versioning strategy
  • Missing code quality tooling
需检查的常见差距：
  • 缺失错误处理策略
  • 未记录的边缘场景
  • 未解决的扩展性问题
  • 缺失监控/可观测性方案
  • 不明确的数据迁移路径
  • 缺失安全威胁模型
  • 未记录的性能预算
  • 缺失灾难恢复方案
  • 不明确的依赖版本管理策略
  • 缺失代码质量工具配置

Open Questions Review

未解决问题评审

Check if open questions are:
  • Clearly stated
  • Have identified options
  • Impact is understood
  • Decision timeline defined
检查未解决问题是否满足：
  • 描述清晰
  • 已列出可选方案
  • 影响已明确
  • 决策时间线已定义

Review Output

评审输出

Generate a gap analysis report with:
yaml
gap_analysis:
  business_alignment_score: [1-10]
  completeness_score: [1-10]
  consistency_score: [1-10]

  gaps_found:
    - category: [category]
      issue: [description]
      severity: [high/medium/low]
      recommendation: [how to address]
      business_impact: [what business requirement this affects]

  strong_areas:
    - [what's well-defined]

  trade_offs_review:
    - decision: [decision]
      assessment: [well-reasoned/needs-review/concerning]
      notes: [additional context]

  open_questions_assessment:
    - question: [question]
      blocking: [yes/no]
      recommendation: [resolve now/later/accept uncertainty]

  suggestions:
    - [improvement suggestions]

  ready_for_implementation: [yes/no/with-modifications]
If critical gaps found (severity: high or blocking open questions), ask:
"I've identified some gaps in the technical requirements that could impact implementation. Would you like to:
  1. Address them now (I'll ask follow-up questions)
  2. Proceed to implementation planning (address during development)
  3. Review the gaps and decide"
生成的差距分析报告结构如下：
yaml
gap_analysis:
  business_alignment_score: [1-10]
  completeness_score: [1-10]
  consistency_score: [1-10]

  gaps_found:
    - category: [category]
      issue: [description]
      severity: [high/medium/low]
      recommendation: [how to address]
      business_impact: [what business requirement this affects]

  strong_areas:
    - [what's well-defined]

  trade_offs_review:
    - decision: [decision]
      assessment: [well-reasoned/needs-review/concerning]
      notes: [additional context]

  open_questions_assessment:
    - question: [question]
      blocking: [yes/no]
      recommendation: [resolve now/later/accept uncertainty]

  suggestions:
    - [improvement suggestions]

  ready_for_implementation: [yes/no/with-modifications]
如果发现关键差距（高严重性或阻塞性未解决问题），会询问：
"我发现技术需求中存在一些可能影响落地的差距，你希望：
  1. 现在处理（我会提出跟进问题）
  2. 进入落地规划阶段（开发过程中处理）
  3. 先查看差距详情再做决定"

Next Steps

后续步骤

After completing the technical requirements interview and gap analysis:
  1. Review gap analysis report
  2. Address any critical gaps or blocking questions
  3. Validate technical choices are realistic
  4. Use 
    /implementation-planner
    to generate implementation plans
完成技术需求访谈和差距分析后：
  1. 查看差距分析报告
  2. 处理所有关键差距或阻塞性问题
  3. 确认技术选择具备可行性
  4. 使用 
    /implementation-planner
    生成落地方案

Examples

示例

See examples/ for sample output files.
查看 examples/ 目录获取示例输出文件。