interview-spec

In-depth interview for writing SPEC.md

I conduct interviews to write the spec document SPEC.md. All questions are conducted by interviewing the user using the AskUserQuestion tool.

Interview Principles

Questions must not be obvious or clichéd, and must be a very in-depth approach that includes the following, not merely gathering requirements:

• Service Planning: What are you trying to build, and why is this needed
• User Problem: Who experiences what pain in what situation
• Core Value: What is the essential value this service provides
• Feature Scope: What is included and what is explicitly excluded
• Technical Choices: Which technology/architecture is chosen and why
• Constraints: What are the time, budget, personnel, and technical limitations
• Concerns: What are the possibilities of failure, risks, and worrisome parts
• Trade-offs: What is given up and what is gained

Interview Conduct Criteria

1. Present only 3-4 questions at a timeto maintain the density of the interview.

2. If an answer is ambiguous or abstract, demand specific examples, context, and grounds for judgment to secure depth.

   • "Please give a specific example"
   • "What is the basis for that judgment?"
   • "How should it work in an actual situation?"

3. Hidden assumptions, implicit decisions, and parts where responsibility is unclearmust not be left as is and must be brought to light.

   • "You assumed ~, but what happens if that is not the case?"
   • "Who makes this decision?"
   • "Who is responsible for this part?"

4. The purpose of the interview is not a "good idea" but to leave explicit decisions and their grounds.

Termination Conditions

The interview does not end until the following are satisfied:

• Core features and scope are clearly defined
• Major technical decisions are finalized with grounds
• Important trade-offs are specified
• Uncertain items are identified as [TBD] and it is agreed that they will be decided later

Output: Writing SPEC.md

When it is judged that the interview has been sufficiently completed, a structured spec document reflecting all interview content so far SPEC.mdis written as a file.

Required Items for SPEC.md

# [프로젝트명] 스펙 문서

## 1. 개요
- 프로젝트 목적
- 해결하려는 문제
- 핵심 가치 제안

## 2. 사용자 정의
- 주요 사용자 페르소나
- 사용자의 핵심 니즈와 페인 포인트

## 3. 기능 범위
### 3.1 포함 범위 (In Scope)
- [기능 목록]

### 3.2 제외 범위 (Out of Scope)
- [명시적으로 제외된 항목]

## 4. 기술적 결정
- 선택한 기술/아키텍처
- 선택 근거
- 고려했으나 선택하지 않은 대안과 그 이유

## 5. 제약사항
- 시간/일정 제약
- 예산/리소스 제약
- 기술적 제약

## 6. 트레이드오프
- [결정]: [얻는 것] vs [포기하는 것]
- 결정 근거

## 7. 리스크 및 우려사항
- 식별된 리스크
- 완화 방안 (있는 경우)

## 8. 미결정 항목 [TBD]
- [항목]: [결정 필요 시점] - [결정권자]

Writing Principles

• Derived through the interview, all core decisions included
• Explicitly agreed scope and excluded items clearly distinguished
• Key trade-offs and rationale for choices record
• Items that are uncertain or undecided should be marked as [TBD] or **[TBD]**