메뉴
Clarify requirements before implementing. Do not use automatically, only when invoked explicitly.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill when the user wants to test a business idea, strategy, or initiative against real-world risk. Triggers include: 'test my idea', 'what are the riskiest assumptions', 'help me validate this', 'run EMT on this', 'extract assumptions', 'assumption mapping', 'what could go wrong with this plan', 'pressure test this', 'validate this plan', 'what could go wrong with this strategy', 'identify hidden risk in this idea', or any request to pressure-test a business decision before committing resources. Runs a guided Extract → Map → Test system based on David J. Bland's Precoil methodology.
Calibrate an LLM judge against human labels using data splits, TPR/TNR, and bias correction. Use after writing a judge prompt (write-judge-prompt) when you need to verify alignment before trusting its outputs. Do NOT use for code-based evaluators (those are deterministic; test with standard unit tests).
Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data. Use when the user asks for a diagram, architecture overview, diff review, plan review, project recap, comparison table, or any visual explanation of technical concepts. Also use proactively when you are about to render a complex ASCII table (4+ rows or 3+ columns) — present it as a styled HTML page instead.
This skill should be used when shaping a software change and needing to breadboard the solution at the right level of abstraction (places, affordances, connections), including mapping an existing system via UI + code affordances, producing a wiring diagram, a parts/BOM plan, a fit check, and (when relevant) an extract-vs-duplicate analysis.
This skill should be used when a user needs a demo package that starts with a live demo (not slides) and produces both a demo script and a navigable single-file HTML runbook, including caveats, respectful competitive comparison, and LLM architecture details (RAG, evals, observability).
Generate a Product Requirements Document (PRD) as JSON for Ralph by converting an existing PRD markdown file. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
| name | ask-questions-if-underspecified |
| description | Clarify requirements before implementing. Do not use automatically, only when invoked explicitly. |
Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).
Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
If multiple plausible interpretations exist, assume it is underspecified.
Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.
Make questions easy to answer:
defaults to accept all recommended/default choices)1b 2a 3c); restate the chosen options in plain language to confirmUntil must-have answers arrive:
If the user explicitly asks you to proceed without answers:
Once you have answers, restate the requirements in 1-3 sentences (including key constraints and what success looks like), then start work.
1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure - use default
Reply with: defaults (or 1a 2a)