--- name: hoyeon-specify description: | Hoyeon requirements workflow for Codex. Use when the user invokes "$hoyeon-specify" or wants to turn an unclear goal into structured requirements.md for Hoyeon. This adapter loads the canonical specify skill and follows its Codex runtime surface. --- # hoyeon-specify This is the Codex-facing wrapper for Hoyeon's canonical `specify` skill. Canonical skill: - Installed root: `__HOYEON_PLUGIN_ROOT__/skills/specify/SKILL.md` - Repo-local fallback: `skills/specify/SKILL.md` from the current Hoyeon repo When this skill is invoked: 1. Read the canonical skill file above before executing the workflow. 2. Follow the `Runtime Surface` -> `Codex` section in that file. 3. Keep durable state changes Bash-first through `hoyeon-cli`. 4. Do not rely on hooks or MCP for Codex v1. 5. Use Hoyeon native-agent adapter names when dispatching subagents: `hoyeon-code-explorer`, `hoyeon-worker`, `hoyeon-verifier`, and `hoyeon-code-reviewer`. ## Interview obligation (Codex) The canonical skill is written around the `AskUserQuestion` tool, which Codex does not have. **Lack of `AskUserQuestion` is NOT a license to skip the interview.** You must still elicit user intent before writing `requirements.md`. Rules: - Ask **one concise plain-text question at a time**. Wait for the user's reply before continuing. Do not batch multiple questions into one turn unless they are trivially orthogonal yes/no items. - Phase 0.1 Mirror is **mandatory** — present your understanding (goal, non-goal, ambiguous) and ask the user to approve or revise before proceeding. - Phase 0.2 WHERE inference is **mandatory** — infer `PROJECT_TYPE`, `SITUATION`, `AMBITION`, `RISK factors` from the repo, present the "Inferred Context" block with evidence and confidence, and ask the user to confirm or override. - Any dimension marked **low confidence** (typically `AMBITION` on a truly new project) MUST be asked explicitly. Do not silently default. - Phase 1 axis interviews still apply. Convert each `AskUserQuestion` prompt in the canonical skill into a plain-text question that lists the same options inline (e.g., "Who is the primary user? (a) Senior developers, (b) Junior developers, (c) Both — or describe your own."). - Phase 4 Confirmation is **mandatory** — show the requirements preview and get explicit user approval before overwriting `requirements.md`. If the user repeatedly answers "you decide" or "whatever works", follow the canonical "I don't know" protocol (tentative judgment + Open Decision entry), not silent inference. The output contract remains the canonical Hoyeon contract: `/requirements.md`.