☰ 분류

컨텍스트 이전 문서 프롬프트

현재 대화, 결정, 진행 상황, 프로젝트 구조를 넣으면 다른 AI 세션이나 에이전트가 이어받을 수 있는 종합 컨텍스트 문서를 만듭니다.

분류AI 사용법 › 대화 관리
태그요약형식변환개발자
프롬프트 (영어 본문 · 답은 한국어로 옵니다)
# Context Preservation & Migration Prompt

[ for AGENT.MD pass THE `## SECTION` if NOT APPLICABLE ]

Generate a comprehensive context artifact that preserves all conversational context, progress, decisions, and project structures for seamless continuation across AI sessions, platforms, or agents. This artifact serves as a "context USB" enabling any AI to immediately understand and continue work without repetition or context loss.

## Core Objectives

Capture and structure all contextual elements from current session to enable:
1. **Session Continuity** - Resume conversations across different AI platforms without re-explanation
2. **Agent Handoff** - Transfer incomplete tasks to new agents with full progress documentation
3. **Project Migration** - Replicate entire project cultures, workflows, and governance structures

## Content Categories to Preserve

### Conversational Context
- Initial requirements and evolving user stories
- Ideas generated during brainstorming sessions
- Decisions made with complete rationale chains
- Agreements reached and their validation status
- Suggestions and recommendations with supporting context
- Assumptions established and their current status
- Key insights and breakthrough moments
- Critical keypoints serving as structural foundations

### Progress Documentation
- Current state of all work streams
- Completed tasks and deliverables
- Pending items and next steps
- Blockers encountered with mitigation strategies
- Rate limits hit and workaround solutions
- Timeline of significant milestones

### Project Architecture (when applicable)
- SDLC methodology and phases
- Agent ecosystem (main agents, sub-agents, sibling agents, observer agents)
- Rules, governance policies, and strategies
- Repository structures (.github workflows, templates)
- Reusable prompt forms (epic breakdown, PRD, architectural plans, system design)
- Conventional patterns (commit formats, memory prompts, log structures)
- Instructions hierarchy (project-level, sprint-level, epic-level variations)
- CI/CD configurations (testing, formatting, commit extraction)
- Multi-agent orchestration (prompt chaining, parallelization, router agents)
- Output format standards and variations

### Rules & Protocols
- Established guidelines with scope definitions
- Additional instructions added during session
- Constraints and boundaries set
- Quality standards and acceptance criteria
- Alignment mechanisms for keeping work on track

# Steps

1. **Scan Conversational History** - Review entire thread/session for all interactions and context
2. **Extract Core Elements** - Identify and categorize information per content categories above
3. **Document Progress State** - Capture what's complete, in-progress, and pending
4. **Preserve Decision Chains** - Include reasoning behind all significant choices
5. **Structure for Portability** - Organize in universally interpretable format
6. **Add Handoff Instructions** - Include explicit guidance for next AI/agent/session

# Output Format

Produce a structured markdown document with these sections:

```
# CONTEXT ARTIFACT: [Session/Project Title]
**Generated**: [Date/Time]
**Source Platform**: [AI Platform Name]
**Continuation Priority**: [Critical/High/Medium/Low]

## SESSION OVERVIEW
[2-3 sentence summary of primary goals and current state]

## CORE CONTEXT
### Original Requirements
[Initial user requests and goals]

### Evolution & Decisions
[Key decisions made, with rationale - bulleted list]

### Current Progress
- Completed: [List]
- In Progress: [List with % complete]
- Pending: [List]
- Blocked: [List with blockers and mitigations]

## KNOWLEDGE BASE
### Key Insights & Agreements
[Critical discoveries and consensus points]

### Established Rules & Protocols
[Guidelines, constraints, standards set during session]

### Assumptions & Validations
[What's been assumed and verification status]

## ARTIFACTS & DELIVERABLES
[List of files, documents, code created with descriptions]

## PROJECT STRUCTURE (if applicable)
### Architecture Overview
[SDLC, workflows, repository structure]

### Agent Ecosystem
[Description of agents, their roles, interactions]

### Reusable Components
[Prompt templates, workflows, automation scripts]

### Governance & Standards
[Instructions hierarchy, conventional patterns, quality gates]

## HANDOFF INSTRUCTIONS
### For Next Session/Agent
[Explicit steps to continue work]

### Context to Emphasize
[What the next AI must understand immediately]

### Potential Challenges
[Known issues and recommended approaches]

## CONTINUATION QUERY
[Suggested prompt for next AI: "Given this context artifact, please continue by..."]
```

# Examples

**Example 1: Session Continuity (Brainstorming Handoff)**

Input: "We've been brainstorming a mobile app for 2 hours. I need to switch to Claude. Generate context artifact."

Output:
```
# CONTEXT ARTIFACT: FitTrack Mobile App Planning
**Generated**: 2026-01-07 14:30
**Source Platform**: Google Gemini
**Continuation Priority**: High

## SESSION OVERVIEW
Brainstormed fitness tracking mobile app for busy professionals. Decided on minimalist design with AI coaching. Ready for technical architecture phase.

## CORE CONTEXT
### Original Requirements
- Target users: Working professionals 25-40, limited gym time
- Must sync with Apple Watch and Fitbit
- Budget: $50k for MVP
- Timeline: 3 months to launch

### Evolution & Decisions
- ✓ Name: "FitTrack Pro" (rejected: "QuickFit", "PowerHour")
- ✓ Core feature: 15-min AI-personalized workouts (not generic plans)
- ✓ Monetization: Freemium ($9.99/mo premium)
- ✓ Tech stack: React Native (for iOS+Android simultaneously)

### Current Progress
- Completed: Feature prioritization, user personas, monetization model
- In Progress: None yet
- Pending: Technical architecture, database schema, API design
- Blocked: None

## KNOWLEDGE BASE
### Key Insights & Agreements
- Users want "smart short" over "long complete" - brevity is premium feature
- AI coaching must feel conversational, not robotic commands
- Social features deferred to v2 to avoid scope creep

(... rest of structure follows)

## CONTINUATION QUERY
"Given this context artifact for FitTrack Pro app planning, please design the technical architecture including database schema, API endpoints, and third-party integration strategy for Apple Watch and Fitbit."
```

**Example 2: Agent Handoff (Rate-Limited Automation)**

Input: "Browser agent hit rate limit while scraping competitor pricing. Generate handoff doc."

Output:
```
# CONTEXT ARTIFACT: Competitor Pricing Automation (Incomplete)
**Generated**: 2026-01-07 09:15
**Source Platform**: Browser Agent v2.1
**Continuation Priority**: Critical

## SESSION OVERVIEW
Automated scraping of 50 competitor websites for pricing comparison. Completed 32/50 before rate limiting. Need immediate continuation to meet Friday deadline.

## CORE CONTEXT
### Original Requirements
- Scrape pricing for "wireless earbuds under $100" from 50 e-commerce sites
- Extract: product name, price, rating, review count
- Output: Single CSV for analysis
- Deadline: Friday 5pm

### Evolution & Decisions
- ✓ Added retry logic after initial failures on JS-heavy sites
- ✓ Switched to headless Chrome (from requests library) for better compatibility
- ✓ Implemented 3-second delays between requests per domain
- ✓ User added instruction: "Skip sites requiring login"

### Current Progress
- Completed: 32/50 sites successfully scraped (2,847 products)
- In Progress: None (halted at rate limit)
- Pending: 18 sites remaining (list in "Continuation Query" below)
- Blocked: Rate limited on domains: amazon.com, walmart.com, target.com (need 2-hour cooldown)

## KNOWLEDGE BASE
### Established Rules & Protocols
- Respect robots.txt without exception
- Max 1 request per 3 seconds per domain
- Skip products with no reviews (noise in data)
- Handle pagination up to 5 pages max per site

### Challenges & Mitigations
- Challenge: Dynamic pricing (changes during scraping)
  Mitigation: Timestamp each entry
- Challenge: Anti-bot CAPTCHAs on 3 sites
  Mitigation: User approved manual data entry for these 3
- Challenge: Rate limiting
  Mitigation: Implement exponential backoff, rotate user agents

## CONTINUATION QUERY
"Continue pricing scraping automation. 18 sites remaining: [bestbuy.com, newegg.com, ebay.com...]. Use existing CSV 'pricing_data_partial.csv' (2,847 entries). Rate-limited domains need 2hr wait. Prioritize non-blocked sites first. Apply all established rules: 3-sec delays, skip no-reviews, 5-page pagination limit. Deliver final CSV by Friday 5pm."
```

**Example 3: Project Migration (Full Culture Transfer)**

(Input context: Entire project repository with SDLC, agents, governance)

Output: *(Condensed example showing structure - real output would be comprehensive)*
```
# CONTEXT ARTIFACT: "SmartInventory" Project Culture & Architecture
**Generated**: 2026-01-07 16:00
**Source Platform**: GitHub Copilot + Multi-Agent System
**Continuation Priority**: Medium (onboarding new AI agent framework)

## SESSION OVERVIEW
Enterprise inventory management system using AI-driven development culture. Need to replicate entire project structure, agent ecosystem, and governance for new autonomous AI agent setup.

## PROJECT STRUCTURE
### SDLC Framework
- Methodology: Agile with 2-week sprints
- Phases: Epic Planning → Development → Observer Review → CI/CD → Deployment
- All actions AI-driven: code generation, testing, documentation, commit narrative generation

### Agent Ecosystem
**Main Agents:**
- DevAgent: Code generation and implementation
- TestAgent: Automated testing and quality assurance
- DocAgent: Documentation generation and maintenance

**Observer Agent (Project Guardian):**
- Role: Alignment enforcer across all agents
- Functions: PR feedback, path validation, standards compliance
- Trigger: Every commit, PR, and epic completion

**CI/CD Agents:**
- FormatterAgent: Code style enforcement
- ReflectionAgent: Extracts commits → structured reflections, dev storylines, narrative outputs
- DeployAgent: Automated deployment pipelines

**Sub-Agents (by feature domain):**
- InventorySubAgent, UserAuthSubAgent, ReportingSubAgent

**Orchestration:**
- Multi-agent coordination via .ipynb notebooks
- Patterns: Prompt chaining, parallelization, router agents

### Repository Structure (.github)
```
.github/
├── workflows/
│   ├── epic_breakdown.yml
│   ├── epic_generator.yml
│   ├── prd_template.yml
│   ├── architectural_plan.yml
│   ├── system_design.yml
│   ├── conventional_commit.yml
│   ├── memory_prompt.yml
│   └── log_prompt.yml
├── AGENTS.md (agent registry)
├── copilot-instructions.md (project-level rules)
└── sprints/
    ├── sprint_01_instructions.md
    └── epic_variations/
```

### Governance & Standards
**Instructions Hierarchy:**
1. `copilot-instructions.md` - Project-wide immutable rules
2. Sprint instructions - Temporal variations per sprint
3. Epic instructions - Goal-specific invocations

**Conventional Patterns:**
- Commits: `type(scope): description` per Conventional Commits spec
- Memory prompt: Session state preservation template
- Log prompt: Structured activity tracking format

(... sections continue: Reusable Components, Quality Gates, Continuation Instructions for rebuilding with new AI agents...)
```

# Notes

- **Universality**: Structure must be interpretable by any AI platform (ChatGPT, Claude, Gemini, etc.)
- **Completeness vs Brevity**: Balance comprehensive context with readability - use nested sections for deep detail
- **Version Control**: Include timestamps and source platform for tracking context evolution across multiple handoffs
- **Action Orientation**: Always end with clear "Continuation Query" - the exact prompt for next AI to use
- **Project-Scale Adaptation**: For full project migrations (Case 3), expand "Project Structure" section significantly while keeping other sections concise
- **Failure Documentation**: Explicitly capture what didn't work and why - this prevents next AI from repeating mistakes
- **Rule Preservation**: When rules/protocols were established during session, include the context of WHY they were needed
- **Assumption Validation**: Mark assumptions as "validated", "pending validation", or "invalidated" for clarity

- - FOR GEMINI / GEMINI-CLI / ANTIGRAVITY

Here are ultra-concise versions:

GEMINI.md
"# Gemini AI Agent across platform

workflow/agent/sample.toml
"# antigravity prompt template


MEMORY.md
"# Gemini Memory

**Session**: 2026-01-07 | Sprint 01 (7d left) | Epic EPIC-001 (45%)  
**Active**: TASK-001-03 inventory CRUD API (GET/POST done, PUT/DELETE pending)  
**Decisions**: PostgreSQL + JSONB, RESTful /api/v1/, pytest testing  
**Next**: Complete PUT/DELETE endpoints, finalize schema"

어떤 프롬프트인가

세션 이전, 에이전트 인수인계, 프로젝트 맥락 보존에 적합하다. 대화 맥락부터 규칙, 아키텍처까지 넓게 담도록 요구한다.

모델 비교

ChatGPT는 형식은 가장 충실하지만 과도한 창작이 치명적이다. Gemini는 더 간결하나 역시 근거가 없고, [C]는 답변 자체가 없다.

Gemini종합 1위
25/ 50

+ 핵심 진행 상태와 인계 절차가 간결하다.

- 근거 없는 기술·정책 결정을 사실처럼 썼다.

ChatGPT
24/ 50

+ 요구된 섹션을 거의 모두 충실히 구성했다.

- 입력에 없는 프로젝트 정보를 대량 창작했다.

기준ChatGPTGemini앞선 모델
지시 준수76ChatGPT +17%
정확성11동점
구체성22동점
구성·가독성98ChatGPT +13%
분량 적정성58Gemini +60%

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력
[붙여 넣은 자료]
지난 2시간 동안 ChatGPT와 '스탬프투게더'(동네 단골가게 적립 앱) MVP 기획을 논의했어.
- 핵심 기능: 매장 QR 스캔으로 적립, 제휴 매장 5곳, 스탬프 10개 모으면 무료 음료 1잔
- 결제 연동은 이번 MVP에서 제외, 2차 버전으로 연기하기로 결정
- 타겟: 홍대·합정 지역 카페·소품샵 사장님
- 방금 막 DB 스키마 설계로 넘어가려던 참에 대화가 끊김
이제 이 세션을 Claude로 옮기려고 해. 위 내용을 바탕으로 컨텍스트 아티팩트를 만들어줘.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

컨텍스트 아티팩트: 스탬프투게더 MVP 기획 세션

생성일시: 2026-09-24
원본 플랫폼: ChatGPT
이관 대상: Claude
계속 진행 우선순위: 높음

SESSION OVERVIEW

지난 약 2시간 동안 동네 단골가게 적립 앱 **‘스탬프투게더’**의 MVP를 기획했다. 핵심은 고객이 매장 QR 코드를 스캔해 스탬프를 적립하고, 스탬프 10개 달성 시 무료 음료 1잔을 받는 구조다. 현재 기능 범위와 타겟을 정리했으며, 다음 단계로 DB 스키마 설계를 시작하려던 시점에 세션이 중단되었다.

CORE CONTEXT

Original Requirements

  • 서비스명: 스탬프투게더
  • 서비스 유형: 동네 단골가게 적립 앱
  • 주요 사용자:
    • 고객: 제휴 매장을 방문하고 스탬프를 적립하는 사람
    • 매장 사장님: 고객에게 스탬프를 제공하고 재방문을 유도하는 사람
  • 초기 타겟 지역:
    • 홍대
    • 합정
  • 초기 타겟 업종 및 고객:
    • 카페
    • 소품샵
    • 해당 지역의 소규모 매장 사장님
  • MVP 핵심 기능:
    1. 고객이 매장 QR 코드를 스캔
    2. 방문 및 구매에 따라 스탬프 적립
    3. 제휴 매장 5곳 운영
    4. 스탬프 10개 달성 시 무료 음료 1잔 제공

Evolution & Decisions

  • MVP의 중심 기능은 매장 QR 스캔 기반 스탬프 적립으로 확정했다.
  • 초기 제휴 매장은 5곳을 기준으로 기획한다.
  • 보상은 스탬프 10개 달성 시 무료 음료 1잔으로 정했다.
  • 타겟 시장은 전국 단위가 아니라 홍대·합정 지역의 카페 및 소품샵으로 좁혔다.
    • 이유: 초기 운영 및 제휴 매장 확보를 지역 단위로 관리하기 쉽기 때문으로 추정된다.
  • 결제 연동은 MVP에서 제외한다.
    • 이유: 초기 핵심 가치인 적립·보상 경험을 검증하는 데 필수적이지 않으며, 구현 범위를 줄이기 위해서다.
  • 결제 연동은 2차 버전으로 연기한다.

CURRENT PROGRESS

  • 완료:
    • 서비스 콘셉트 정의
    • 핵심 사용자 및 타겟 지역 정의
    • MVP 핵심 기능 정의
    • 초기 제휴 매장 수 결정
    • 스탬프 보상 정책 결정
    • 결제 연동의 MVP 제외 결정
  • 진행 중:
    • DB 스키마 설계 시작 직전, 진행률 약 0~10%
  • 보류:
    • 고객·매장 사장님 계정 구조
    • 매장 및 제휴 관계 모델
    • QR 코드 구조와 검증 방식
    • 스탬프 적립 이력
    • 보상 및 사용 이력
    • 관리자 기능
    • API 설계
    • 화면 및 사용자 플로우
    • 결제 연동
  • 차단 요소:
    • 없음
  • 중단 지점:
    • DB 스키마 설계를 논의하려던 시점에 ChatGPT 세션이 끊겼다.

KNOWLEDGE BASE

Key Insights & Agreements

  • MVP에서 가장 먼저 검증할 가설은 다음과 같다.

    고객이 제휴 매장에서 QR을 스캔해 간편하게 적립하고, 누적 보상을 받기 위해 재방문하는가?

  • MVP는 결제 시스템 자체보다 다음 경험에 집중해야 한다.

    • 매장 방문
    • QR 스캔
    • 스탬프 적립
    • 누적 현황 확인
    • 보상 획득 및 사용
  • 결제 내역을 직접 연동하지 않으므로, MVP에서는 적립 승인 방식이 별도로 필요하다.

    • 매장 직원이 QR을 제시하거나 확인하는 방식
    • 고객이 매장 QR을 스캔하는 방식
    • 고객별 부정 적립을 방지하는 검증 방식
      이 부분은 DB 설계 전에 결정해야 한다.

Established Rules & Protocols

  • MVP 범위에는 결제 연동을 포함하지 않는다.
  • 초기 운영 범위는 홍대·합정 지역으로 제한한다.
  • 초기 제휴 매장은 5곳을 기준으로 한다.
  • 기본 보상 정책은 스탬프 10개당 무료 음료 1잔이다.
  • 이후 설계에서는 MVP 필수 기능과 2차 버전 기능을 명확히 구분한다.
  • 새 세션이나 에이전트로 이관할 때 현재 결정 사항을 변경하지 말고, 변경이 필요한 경우 이유와 영향 범위를 먼저 설명한다.
  • 프로젝트 작업 시 Gotcha 테스트 하네스/스킬은 사용하지 않는다. 검증이 필요하면 직접 코드 점검과 프로젝트의 기본 테스트 명령을 사용한다.

Assumptions & Validations

  • 검증됨: 서비스 콘셉트와 핵심 적립 방식
  • 검증됨: MVP에서 결제 연동을 제외하기로 한 결정
  • 검증됨: 홍대·합정 지역 및 카페·소품샵 타겟
  • 검증됨: 초기 제휴 매장 5곳
  • 검증됨: 스탬프 10개 달성 시 무료 음료 1잔
  • 검증 필요:
    • 한 번 방문했을 때 적립되는 스탬프 수
    • 고객 QR과 매장 QR 중 어느 쪽을 스캔하는지
    • 매장 직원의 적립 승인 필요 여부
    • 무료 음료의 구체적인 제공 조건
    • 보상 사용 매장 범위
    • 고객·매장·관리자 계정 권한
    • 고객이 여러 매장의 스탬프를 통합 관리하는지
    • 매장별로 별도 스탬프 카드를 운영하는지
    • QR 위조 및 반복 스캔 방지 방식
    • 개인정보 및 위치 정보 수집 범위

ARTIFACTS & DELIVERABLES

현재 대화에서 생성된 파일이나 코드 산출물은 없다.

기획상 확정된 핵심 산출물:

  • 서비스명: 스탬프투게더
  • MVP 적립 방식: 매장 QR 스캔
  • 초기 제휴 매장 수: 5곳
  • 보상 기준: 스탬프 10개 → 무료 음료 1잔
  • 초기 시장: 홍대·합정
  • 초기 타겟: 카페·소품샵 사장님
  • MVP 제외 기능: 결제 연동
  • 결제 연동 시점: 2차 버전

PROJECT STRUCTURE

Architecture Overview

아직 기술 스택이나 시스템 아키텍처는 결정되지 않았다.

DB 스키마 설계 시 최소한 다음 도메인을 검토해야 한다.

  • 사용자
  • 매장
  • 매장 운영자 또는 사장님 계정
  • 제휴 매장 관계
  • QR 코드
  • 스탬프 카드 또는 적립 프로그램
  • 스탬프 적립 이력
  • 보상
  • 보상 사용 이력
  • 관리자
  • 감사 로그 또는 부정 적립 추적 기록

Agent Ecosystem

현재 별도 에이전트 구조나 서브에이전트는 정의되지 않았다.

다음 세션에서는 Claude가 우선 제품 기획자 겸 시스템 설계자 역할로 DB 모델을 제안하면 된다.

Reusable Components

다음 순서로 설계를 진행하는 것이 적절하다.

  1. 고객·매장·관리자 역할 정의
  2. 적립 및 보상 정책의 빈틈 확인
  3. QR 스캔 플로우 결정
  4. 핵심 엔터티와 관계 도출
  5. MVP용 DB 스키마 작성
  6. 주요 사용 사례별 데이터 흐름 검증
  7. 부정 적립 및 중복 스캔 방지 검토
  8. 이후 API와 화면 플로우로 확장

Governance & Standards

  • MVP와 2차 버전의 범위를 분리한다.
  • 확정된 의사결정과 아직 검증되지 않은 가정을 구분해 기록한다.
  • 설계 시 운영 현실성을 고려한다. 특히 매장 사장님이 쉽게 QR을 관리하고 적립을 승인할 수 있어야 한다.
  • 결제 기능을 다시 포함하려면 별도의 범위 변경 결정이 필요하다.

HANDOFF INSTRUCTIONS

For Next Session/Agent

  1. 먼저 스탬프 적립 플로우를 구체화한다.
  2. 다음 질문에 대한 합리적인 기본안을 제시한다.
    • 고객이 매장 QR을 스캔하는가?
    • 한 방문당 스탬프는 몇 개인가?
    • 매장 직원 승인 없이 자동 적립되는가?
    • 매장별 스탬프 카드인가, 통합 스탬프 카드인가?
    • 보상은 어느 매장에서 사용할 수 있는가?
  3. 질문만 나열하지 말고, MVP에 적합한 권장안을 함께 제시한다.
  4. 권장안을 바탕으로 ERD 수준의 DB 구조를 설계한다.
  5. 각 테이블의 목적, 주요 컬럼, 관계, 제약 조건을 설명한다.
  6. 중복 적립, QR 공유, 과거 보상 재사용 같은 부정 사용 사례를 검토한다.
  7. 마지막으로 MVP에서 반드시 필요한 테이블과 향후 확장용 테이블을 구분한다.

Context to Emphasize

  • 이 서비스의 핵심은 결제 처리가 아니라 지역 매장의 재방문을 유도하는 간편한 적립·보상 경험이다.
  • 대상은 대형 프랜차이즈가 아니라 홍대·합정의 소규모 카페 및 소품샵이다.
  • 매장 운영자가 복잡한 시스템을 사용하지 않아도 되는 구조가 중요하다.
  • 아직 기술 스택은 정해지지 않았으므로 특정 기술을 전제로 하지 말고, 먼저 도메인 모델을 확정해야 한다.

Potential Challenges

  • 고객이 QR 이미지를 공유해 여러 번 적립할 수 있는 문제
  • 동일 방문에 대한 중복 적립
  • 고객과 매장 양쪽의 사용성을 동시에 만족시키는 인증 플로우
  • 무료 음료 보상 사용 여부를 매장에서 확인하는 방식
  • 여러 매장의 스탬프를 통합할지 매장별로 분리할지에 따른 데이터 모델 차이
  • 결제 연동 없이 실제 구매 여부를 어떻게 신뢰할 것인지

CONTINUATION QUERY

다음 프롬프트로 이어서 작업하면 된다.

이 컨텍스트 아티팩트를 바탕으로 스탬프투게더 MVP의 DB 스키마 설계를 시작해줘.
먼저 고객, 매장 사장님, 매장, QR 코드, 스탬프 적립, 보상, 보상 사용 이력을 포함한 핵심 도메인 모델을 제안하고, QR 적립 플로우와 중복·부정 적립 방지 방식에 대한 MVP 권장안을 함께 제시해줘.
아직 정해지지 않은 사항은 질문만 하지 말고 합리적인 기본안을 제안한 뒤, 그 가정이 스키마에 어떻게 반영되는지 설명해줘.

같은 분류의 프롬프트

채팅 내역 내보내기 프롬프트
작업 이어가기 요약 프롬프트
긴 자료를 나눠 넣는 순서 짜는 프롬프트
서로 충돌하는 내 지시를 찾아내는 프롬프트
출력에 언어가 섞이는 것을 잡는 프롬프트