본문으로 건너뛰기
REPL WorksREPL Works
Menu

PROMPT SPECIFICATION

기술 스택 정의

TECH_STACK.md 작성을 위한 기술 선택 및 구현 규칙 정의 프롬프트

04B. 코딩형 AI를 위한 4종 문서 생성 단계 (Specification Phase)

`TECH_STACK.md` 생성

TECH_STACK.md Generation

생성 대상
TECH_STACK.md

사용 기술, 언어 버전, 파일 배치 규칙, Naming Rule 등 구현 컨벤션을 정의한 TECH_STACK.md 파일을 생성합니다.

🎯 프롬프트 목적

제품 명세를 실제로 구현하기 위해 필요한 언어, 프레임워크, 폴더 구조, 네이밍 규칙 및 명확한 구현 제약 조건을 정리합니다.

이 단계에서는 아직 전체 모듈 간 데이터 흐름을 설계하지 않습니다. 제품 요구사항을 만족하는 데 직접적으로 필요한 기술 명세와 가이드라인만 명확히 고정하는 것이 목표입니다.


📦 생성 산출물

TECH_STACK.md

💡 사용 방법 & 대화 가이드

  1. 사전 준비: PRODUCT_SPEC.md 작성이 끝난 후, ARCHITECTURE.md 설계 전 단계에서 사용합니다.
  2. 요구사항 기반 선택: 불필요하거나 과도한 오버엔지니어링 기술 스택을 배제하고, PRODUCT_SPEC.md 근거가 있는 기술 스택만 선택하도록 유도합니다.

🤖 AI 프롬프트 원문

아래 프롬프트를 복사하여 AI 대화창에 그대로 전달해 보세요.

TECH_STACK_PROMPT.txt
Generate TECH_STACK.md.
INPUTS
- PRODUCT_SPEC.md: correct and final. Source of product requirements.
- TECH_DECISIONS: correct and final. Sole source of technology names and versions.
- ARCHITECTURE.md does not exist yet. It will be written AFTER this document, using it as input.
SOURCE RULES
- Every technology, tool, library, version, file name, and env var name MUST come from TECH_DECISIONS.
- MUST NOT infer, invent, evaluate, or recommend technologies.
- MUST NOT restate product behavior from PRODUCT_SPEC (commands, options, sorting, error cases).
- If TECH_DECISIONS conflicts with PRODUCT_SPEC, stop and list the conflicts.
REQUIRED DECISIONS CHECK
Verify TECH_DECISIONS defines all of the following. For each missing item, ask one question.
- runtime + version
- language + compile/run method
- module system
- package manager + lockfile
- web framework + version
- libraries (name + version): config parser, CLI argument parser, YouTube API client/HTTP
- test tool + coverage threshold
- linter, formatter
- CI system
- deployment target + release/distribution method
- license
- config file format, env var names, secret storage
If any item is missing or conflicting: output ONLY the numbered question list. Nothing else.
SCOPE BOUNDARY
- Cover only technology choices and the rules that follow from them.
- MUST NOT define components, layers, modules, boundaries, data flow, responsibilities, or system structure.
- MUST NOT define directory layout beyond paths mandated by the chosen framework or tooling.
- MUST NOT include process rules (change control), product non-goals, or architectural invariants.
- State each rule once. MUST NOT repeat a rule across sections.
OUTPUT FORMAT
- Exactly these 8 sections, in this order, numbered headings, no other sections:
1. Languages / runtimes / frameworks / libraries (name + version constraint)
2. Framework- or tool-mandated paths and file names only
3. Coding conventions specific to the chosen stack
4. Testing rules (tools, naming, required coverage)
5. Configuration rules (env vars, config files, secrets handling)
6. Deployment rules (targets, build, release steps)
7. Security rules tied to the chosen stack
8. Non-goals (technologies and tools explicitly excluded)
- Flat terse bullets. "MUST / MUST NOT" phrasing. No prose, no explanations, no "why".
- Audience: AI implementer.