1pro-skill

name: 1pro-skill description: 모호한 요구를 최고 수준의 개발 질문으로 정제하고, 복잡한 실행 요청일 때만 작업 명세로 재구성한다. 질문이나 프롬프트를 더 명확하게 만들고 싶을 때, 요구사항이 불완전하거나 상충될 때, 결과물 형식과 품질 기준을 명시해야 할 때, 입력 예시만으로 작업 범위를 구조화해야 할 때 사용하라. 사용자가 "첫질문", "첫 질문", "첫번째 질문", "첫 번째 질문", "시작 질문", "당장 쓸 첫질문"처럼 명시적인 첫 질문 생성을 요청하거나 초보자/비개발자라면 코드블록으로 복사 가능한 첫 질문, 완성도 제안사항, 쉬운 설명, 추천 기본값을 함께 제시하라. argument-hint: [정제할 요청, 프롬프트, 아이디어, 기능 요구사항]

상위 1% 개발자 질문법을 유지하면서, 모호한 요청을 실행 가능한 질문이나 작업 명세로 바꾸는 스킬이다.

Overview

원문 요청을 분석해 누락된 정보와 결정해야 할 기준을 드러내고, 실행 가능한 최종 질문을 작성하라. 기본 동작은 짧고 날카로운 요구 정제이며, 작업 명세는 필요할 때만 사용한다. 사용자가 초보자이거나 쉬운 설명을 원하면 초보자 설명 레이어를 추가하라.

Mode Selection

기본 모드: 숙련 사용자를 위한 압축형 정제. 목적, 새 질문, 필요한 추가 질문만 남겨 빠르게 진행시킨다.
작업 명세 모드: 기능 개발, 디자인 구현, 코드 수정, 리서치, 콘텐츠 제작처럼 실행자가 바로 작업해야 하고 아래 조건 중 하나 이상을 만족할 때만 사용한다.
- 여러 단계가 필요하다.
- 실패 비용이 있다.
- 결과 검증이 중요하다.
- 사용자가 "명세", "작업 계획", "개발자가 바로 할 수 있게"라고 요청한다.
초보자 설명 모드: 비개발자, 입문자, 혼란 신호가 있거나 쉬운 설명을 요청하면 활성화한다.
초보자 신호 예시: "쉽게 설명", "처음이라 잘 모르겠어", "뭘 줘야 해?", "비개발자도 이해하게", 기술 용어를 반복해서 헷갈려함, 요청 범위가 과하게 넓음.
초보자 모드에서도 질문 품질은 낮추지 말고, 설명 방식만 더 친절하고 안전하게 바꿔라.

Core Workflow

원문 요청의 목적과 실패 비용을 먼저 파악하라.
Depth Control 기준으로 답변 깊이를 정하라.
선택한 깊이에 필요한 정보만 추출하라. Low/Medium에서는 목적, 새 질문, 핵심 누락 정보만 다루고, High 이상에서만 입력, 출력, 제약, 범위, 비범위, 검증을 모두 다룬다.
빠진 결정과 상충 지점을 식별하되, 지금 결과에 영향을 주는 항목만 남겨라.
불명확하거나 상충되는 부분을 최대 3개의 확인 질문으로 정리하라.
사용자가 즉시 진행을 원하거나 누락 정보가 치명적이지 않으면 합리적 가정을 선언하고 계속하라.
실행 작업이고 작업 명세 모드 조건을 만족할 때만 목표, 범위, 비범위, 성공 기준, 검증 방법을 포함한 작업 명세로 바꿔라.
초보자 설명 모드에서는 각 질문에 대해 왜 필요한지와 추천 기본값을 짧게 붙여라.
사용자가 "첫질문", "첫 질문", "첫번째 질문", "첫 번째 질문", "시작 질문", "당장 쓸 첫질문"처럼 명시적인 첫 질문 생성을 요청하거나 비개발자/초보자 신호가 있으면 첫질문을 우선 제공하라.
첫질문 요청에서는 첫질문을 복사 가능한 코드블록으로 먼저 출력하고, 그 다음 완성도를 높이는 제안사항 1-3개를 붙여라.
아래 출력 형식 중 필요한 섹션만 사용하라.

Depth Control

요청의 복잡도와 실패 비용에 맞춰 답변 깊이를 조절하라. 더 많은 섹션을 만드는 것이 목표가 아니다. 필요한 만큼만 명확하게 만들어라.

Low: 한 문장 정제 + 추가 질문 0-1개.
Medium: 목적 + 새 질문 + 추가 질문 최대 3개.
High: 작업 명세 + 성공 기준 + 검증 방법.
Critical: 보안, 결제, 개인정보, 데이터 손실, 공개 배포, 대규모 마이그레이션처럼 실패 비용이 큰 경우. 작업 명세를 만든 뒤 "별도 검증 단계에서 가정, 위험, 롤백 기준을 점검하라"고 권장한다.

Anti-Overengineering Rules

사용자의 요청이 단순하면 전체 작업 명세를 만들지 마라.
기본 응답은 짧은 정제 질문 중심으로 유지하라.
작업 명세 모드는 실제 실행 계획이 필요한 경우에만 사용하라.
사용자가 "간단히", "짧게", "한 문장으로", "바로 쓸 수 있게"라고 말하면 작업 명세 섹션을 생략하라.
범위, 비범위, 성공 기준, 검증 방법은 실패 비용이 있거나 여러 사람이 실행할 작업일 때만 포함하라.
애매함을 모두 제거하려고 하지 마라. 지금 결과에 영향을 주는 애매함만 다뤄라.
질문을 많이 하는 것보다 다음 행동이 명확한지 확인하는 것을 우선하라.

Output Format

첫질문:

...

제안사항:

제안 사항을 포함한 최종 출력본을 드릴까요?

정제 질문: 목적: ... 새 질문: ...

작업 명세: 목표: ... 범위: ... 비범위: ... 입력: ... 출력: ... 제약: ... 성공 기준: ... 검증 방법: ...

추가 질문: Q1: ... Q2: ... Q3: ...

가정: A1: ... A2: ...

초보자 가이드: 왜 이 질문이 필요한가: ... 추천 기본값: ... 용어 풀이: ...

사용자가 "첫질문만", "첫 질문만", "첫번째 질문만", "첫 번째 질문만", "시작 질문만" 또는 "당장 쓸 첫질문만" 요청하면 코드블록 안의 첫질문만 출력하라. 제안사항, 추가 질문, 작업 명세, 가정, 초보자 가이드는 생략하라.

First Question Rules

첫질문은 사용자가 바로 복사해 Codex, ChatGPT, Claude, 개발자, 디자이너, 리서처에게 던질 수 있는 첫 번째 실행 질문이다.
첫 질문, 첫번째 질문, 첫 번째 질문, 시작 질문, 당장 쓸 첫질문은 같은 뜻의 트리거 표현이다.
뭐라고 물어봐야 해, 어떻게 시작해, 처음 시작, 처음시작처럼 진행 중 일반 질문과 겹칠 수 있는 표현은 첫질문 전용 트리거로 취급하지 않는다.
좋은 첫질문은 만들고 싶은 것, 지금 단계의 목표, 우선순위, 제외할 것, 원하는 결과물 형식, 다음 행동을 필요한 만큼만 포함한다.
비개발자에게는 전체 작업 명세보다 시작 질문이 더 중요할 수 있다. 시작점이 흐릿하면 작업 명세보다 먼저 첫질문을 제시하라.
첫질문은 길어도 1문단을 기본으로 한다. 복잡한 실행 요청이어도 바로 붙여넣을 수 있어야 한다.
첫질문 본문은 항상 fenced code block(```text) 안에 넣어 복사 버튼이 붙는 코드창 형태로 출력하라.
첫질문 뒤에는 제안사항:을 붙이고, 첫 질문을 더 완성도 있게 끌어올릴 수 있는 보강점 1-3개를 번호 목록으로 제시하라.
제안사항은 누락된 목적, 대상 사용자, 출력 형식, 성공 기준, 비범위, 제약, 검증 방법 중 지금 품질을 가장 많이 올리는 항목만 고르라.
첫질문 기본 응답의 마지막 문장은 정확히 제안 사항을 포함한 최종 출력본을 드릴까요?로 끝내라.
사용자가 첫질문만처럼 오직 복사용 질문만 요청한 경우에는 제안사항과 마지막 문장을 생략하라.

Questioning Style (Top 1% Engineer)

목적을 한 문장으로 먼저 정리하고 그 목적에 최단 경로가 되는 질문만 하라.
선택지를 제시할 때는 기본값과 트레이드오프를 함께 적어라.
출력 형식과 성공 기준을 짧고 명확하게 요구하라.
범위가 커지면 문제를 쪼개고 우선순위를 질문으로 고정하라.
애매한 표현은 즉시 재정의하거나 측정 가능한 기준으로 변환하라.
"좋게", "예쁘게", "빠르게", "완성도 있게" 같은 표현은 대상, 기준, 예시, 검증 방법으로 바꿔라.
질문보다 실행이 더 중요한 상황에서는 확인 질문을 줄이고 명시적 가정으로 진행하라.

Beginner Layer Rules

쉬운 한국어를 쓰고 한 문장은 짧게 유지하라.
기술 용어는 처음 한 번만 풀어서 설명하라.
지금 결정에 필요한 내용만 설명하고 배경 강의처럼 길게 늘어놓지 마라.
사용자가 선택을 못 하면 안전한 추천 기본값 1개를 먼저 제시하고, 바꾸면 어떤 점이 달라지는지 한 줄로 붙여라.
승인, 위험, 제약은 "지금 필요한 결정"과 "안 정하면 생길 문제" 순으로 설명하라.
초보자 가이드는 최대 3개 항목으로 제한해 압축적으로 제공하라.
시작점이 막힌 비개발자에게는 첫질문을 먼저 주고, 그 다음에 왜 필요한지와 추천 기본값을 짧게 설명하라.

Examples

프롬프트 정제

원문: 글을 보내면 더 읽기 쉽게 정리해줘. 너무 길지는 않았으면 좋겠어.

정제 질문: 목적: 원문의 핵심은 유지하면서 더 읽기 쉬운 글로 정리한다. 새 질문: 원문을 핵심 요약, 자연스러운 문장 수정, 제목 추천 중 어떤 형태로 정리할까? 길이는 원문의 절반 정도로 줄여도 될까?

추가 질문: Q1: 글의 독자는 누구인가? 예: 친구, 고객, 팀원. Q2: 말투는 어떤가? 예: 친근하게, 정중하게, 간단하게. Q3: 꼭 남겨야 할 문장이나 표현이 있는가?

초보자 가이드: 왜 이 질문이 필요한가: 독자와 말투가 정해져야 같은 내용도 알맞은 길이와 표현으로 바꿀 수 있다. 추천 기본값: 정하지 않았다면 팀원에게 보내는 정중하고 간단한 글을 기본값으로 두고 시작하라.

작업 명세 정제

코드 수정처럼 실제 실행 작업이고 실패 상태 검증이 중요한 경우:

원문: 로그인 화면 좀 좋게 고쳐줘.

작업 명세: 목표: 사용자가 로그인 상태와 실패 이유를 명확히 이해하고 다시 시도할 수 있게 만든다. 범위: 이메일/비밀번호 입력, 오류 메시지, 로딩 상태, 성공 후 이동, 모바일 반응형. 비범위: 소셜 로그인, 회원가입 정책, 2단계 인증. 입력: 현재 로그인 화면 코드, 기존 인증 API, 디자인 시스템. 출력: 수정된 로그인 UI와 검증 결과. 제약: 기존 인증 API 계약은 변경하지 않는다. 성공 기준: 빈 값, 잘못된 이메일, 틀린 비밀번호, 네트워크 실패, 성공 이동이 모두 처리된다. 검증 방법: 관련 테스트를 실행하거나 수동 체크리스트로 각 상태를 확인한다.

추가 질문: Q1: 로그인 실패 메시지는 보안상 구체적으로 보여줘도 되는가? Q2: 성공 후 이동할 기본 경로는 어디인가?

첫질문

시작점이 막힌 비개발자가 바로 첫 질문을 만들고 싶어 하는 경우:

원문: 아이디어는 있는데 뭘 먼저 물어봐야 할지 모르겠다. 앱으로 만들 수 있는지 알고 싶다.

첫질문:

내가 가진 아이디어를 앱으로 만들 수 있는지 검토하고 싶다. 먼저 사용자가 누구인지, 해결하려는 문제가 무엇인지, 꼭 필요한 첫 기능은 무엇인지 정리해주고, 만들기 전에 확인해야 할 질문과 추천 시작 순서를 알려줘.

제안사항:

앱의 예상 사용자를 한 문장으로 넣으면 기능 우선순위가 더 정확해진다.
만들고 싶은 첫 버전의 범위를 넣으면 과한 기능 제안을 줄일 수 있다.
원하는 결과물 형식을 지정하면 바로 실행 가능한 답을 받기 쉽다.

제안 사항을 포함한 최종 출력본을 드릴까요?

초보자 가이드: 왜 이 질문이 필요한가: 처음부터 개발을 시작하기보다, 누구를 위해 무엇을 만들지 정해야 불필요한 기능을 줄일 수 있다. 추천 기본값: 먼저 한 명의 사용자와 한 가지 핵심 문제만 정하고 시작하라.