/specify

name: specify
description: |
  "/specify", "specify", "요구사항 정의", "requirements", "스펙 잡기",
  "뭘 만들어야 하는지", "기획 정리", "인터뷰해서 스펙"
  Turn a goal into structured requirements through systematic interview.
  Three phases: Interview → Extract → Cross-check.
  Writes requirements.md in the cli format (consumed by /blueprint).

specify: Goal → Requirements via Systematic Interview

Overview

Transform a vague goal into structured, traceable requirements through: 0. **WHERE Grounding** — establish project type, situation, ambition, and risk modifiers 0.5. **Context Research** (brownfield only) — scan existing codebase before asking the user 1. **Interview** — systematic Q&A across Business/Interaction/Tech axes (depth-calibrated by WHERE) 2. **Extract** — parallel requirements extraction by domain experts 3. **Cross-check** — conflict/gap/duplicate detection 4. **Confirmation** — user accepts assumptions + final `requirements.md` committed in cli format

Handoff contract

The final deliverable is `<spec_dir>/requirements.md` in the format that `/blueprint` consumes:

• Frontmatter: `type` (greenfield|feature|refactor|bugfix), `goal`, `non_goals[]`
• Body: flat list of `## R-X<num>:` parent requirements, each with nested `#### R-X<num>.Y:` sub-requirements carrying `given/when/then`
• `X` in the ID is axis code: **B**=Business, **U**=Interaction (user), **T**=Tech
• Optional `## Open Decisions` section with `### OD-N:` blocks

All intermediate files (qa-log.md, reqs-business.md, reqs-interaction.md, reqs-tech.md) stay in `<spec_dir>/` for traceability but are NOT read by /blueprint.

Runtime Surface

Claude Code

• Use `AskUserQuestion` for the structured interview forms described below.
• Use `Agent(subagent_type="...")` for brownfield research and extractor

subagents.

• Claude hooks may initialize skill session state, but the durable output remains

`<spec_dir>/requirements.md`.

Codex

• Keep the same interview protocol and output format, but use Codex-native

structured input when available; otherwise ask one concise plain-text question at a time.

• Use Bash-first CLI setup through `hoyeon-cli req init`.
• Use logical Hoyeon subagent names in prompts, mapped to Codex adapters when

installed. If adapters are not loaded in the current session, perform the smallest direct research pass needed to complete `requirements.md`.

• Do not rely on hooks for session initialization or cleanup in Codex v1.

Phase 0: WHERE Grounding

The **WHERE** is the combination of current situation and intended scope. It calibrates how deep the interview goes on each axis — without it, every project gets the same heavyweight treatment, which over-engineers toys and under-specs production systems.

Step 0.1: Mirror (prove understanding before asking)

Before asking for goal/non-goals, present your understanding of the user's request using this template:

**Mirror — Here's what I understood**

**Understanding:**
<1–2 sentences paraphrasing the user's request in your own words. Not a verbatim echo.>

**Goal:**
- <bullet 1: concrete outcome>

**Non-Goal (explicitly out of scope):**
- <bullet 1: exclusion — at least one must be inferred by you, not stated by user>

**Ambiguous (scope-level unknowns):**
- <ambiguity about what "done" means, what's included, or who the user is>

Then confirm via AskUserQuestion:

AskUserQuestion(
  question: "Does this match your intent?",
  options: [
    { label: "Approve", description: "Proceed to WHERE grounding" },
    { label: "Revise", description: "Fix goal/non-goal/scope" }
  ]
)

**Rules:**

• At least one Non-Goal and one Ambiguous item must be **inferred** by you — a pure echo is a violation
• Ambiguous items are **scope-level** only ("what are we building / for whom / done when?"), NOT tech choices
• Max 2 revision rounds. If still unclear, proceed and record residual ambiguities for Phase 1
• On Approve: extract `goal` and `non_goals` from the mirror (no need to re-ask in free-text)

Step 0.2: WHERE Inference (infer-first, ask-only-on-uncertainty)

**Default behavior: infer from the working directory and the user's goal. Only ask the user about dimensions you genuinely cannot determine from evidence.**

Don't burn 4 cold-start questions on facts the codebase already answers. Most of `PROJECT_TYPE`, `SITUATION`, and risk factors are visible to you. Only `AMBITION` is reliably user-intent-driven.

Step 0.2.a: Gather signals (read-only)

Inspect the repo. Use evidence — file paths, not vibes:

• **PROJECT_TYPE signals**:
• `package.json` + frontend deps (react, vue, svelte, vite) / `app/`, `src/components/` → user-facing
• `package.json` + backend deps (express, fastify, nest) / `routes/`, `api/`, `controllers/` → api-service
• `bin/`, `cli.ts`, `pyproject.toml` with `[project.scripts]`, single-binary Cargo project → dev-tool
• `terraform/`, `k8s/`, `helm/`, `Dockerfile` + no app code → infrastructure
• **SITUATION signals**:
• Empty repo or only scaffolding (single README, no src) → greenfield
• Existing src tree, many files, established conventions → brownfield (extension or refactor depends on user's goal verb)
• User's goal mentions a new module/feature inside existing project → hybrid
• **RISK signals**:
• `auth/`, `session`, `passport`, `oauth`, `cookie`, `jwt` references → sensitive-data candidate
• `prisma/schema.prisma` / `migrations/` with PII columns (email, phone, ssn) → sensitive-data
• Payment SDKs (stripe, toss, iamport, paypal) → sensitive-data + external-exposure
• Public route definitions (no auth middleware), webhooks, `/api/public` → external-exposure
• `migrations/`, destructive scripts, public SDK exports → irreversible
• Load balancers, queues (kafka, sqs, redis streams), CDN config → high-scale

If brownfield, you may dispatch a quick `code-explorer` here — but a cheap `ls` + `Read README.md` + `Glob` is often enough for inference. Don't over-spend on Phase 0.

#