Skip to content
cccskills
FreePublished on GitHub

hoyeon-specify

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.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md2.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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: <spec_dir>/requirements.md.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Analyze an open-source project from What/Why perspective (not how-it's-implemented). Use when the user says "/analyze-oss", "분석해줘 이 오픈소스", "이 레포 뭐하는거야", "analyze this repo", "what does X do", "이거 왜 쓰는거야", "이 라이브러리 분석", provides a GitHub URL and wants understanding, or asks to deeply understand an OSS project's purpose, value, target users, and usage flow. Clones the repo to ~/opensource-analysis/<repo-name>/ (git pull if already exists), dispatches parallel subagents per analysis lens, then synthesizes a What/Why-focused report in chat. Supports optional user-specific follow-up questions.

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

"/blueprint", "blueprint", "task graph", "contract derivation", "execution plan", "plan tasks from requirements", "contract-first planning" Turn requirements.md into an executable blueprint (plan.json + contracts.md). Five phases: Contracts → Tasks → Journeys → Verify Plan → Commit. Sits between /specify and /execute. Scope-adaptive (greenfield → bugfix). Uses hoyeon-cli (plan.json only; requirements.md is read as-is via Read tool).

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

Recon-first browser automation. Orchestrator explores the site first via chromux, saves a guide file with insights, then delegates execution to browser-explorer agent. Use when: "/browser-work", "브라우저 작업", "사이트에서 해줘", "웹에서 해줘", "LinkedIn에서", "크롬으로", "browser task", "automate this site".

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

bugfix

Free

Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

check

Free

This skill should be used when the user wants to verify their changes before pushing, or update the project's rule checklists. Phase 1: validate changed files against .hoyeon/rules/ checklists and report PASS/WARN. Phase 2 (conditional): propose rule additions when unmatched patterns are detected. Essential before git push. Trigger phrases: "check", "checklist", "verify changes", "what did I miss", "pre-push check", "cascading changes", "any more changes needed", "update checklist", "update rules", "rules update", "체크", "체크리스트", "변경 확인", "빠뜨린 거 없나", "push 전 확인", "뭐 더 건드려야 해?", "연쇄 변경 확인", "규칙 갱신".

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

"/clarify", "clarify this", "keep asking until clear", "remove ambiguity", "clarify requirements", "clarify design", "clarify the plan", "질문 계속해", "모호한 게 없게", "명확해질 때까지", "계속 물어봐", "Q&A로 정리", "질문답변 기록", "요구사항 명확화", "설계 명확화". Relentless ambiguity-resolution interview that records Q&A under .hoyeon/clarify/<topic>/ and hands off to specify/blueprint/docs when clear.

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

See all skills by team-attention

Report a problem with this skill