How do I install hoyeon?

Run these in Claude Code: /plugin marketplace add team-attention/hoyeon then /plugin install hoyeon@team-attention-dev. Then prompt normally.

Does hoyeon auto-invoke its skills?

Not yet. It is indexed on Flowy as a plain plugin. Request auto-invocation on its page and Flowy will route its skills for you as you prompt.

Yes. Flowy is free and open source, with nothing gated. You can read every skill in full before you install.

Agent Orchestration

Plugin

hoyeon

hoyeon is a Claude Code plugin with 37 hand-picked skills, indexed on Flowy in the Agent Orchestration category.

BOOST

team-attention@team-attention

GitHub

Plugin Signal61/100Solid

maintained34

capable90

documented75

adopted48

Install on Claude Code

> /plugin marketplace add team-attention/hoyeon
> /plugin install hoyeon@team-attention-dev

Stats

JavaScript CSS Bash Ruby Git

+6 tags

GitHub Markdown Anthropic OpenAI Gemini MCP

173

Stars

Forks

Maintained

Maintenance

Shell

Language

MIT

License

5mo ago

Last commit

9mo ago

Created

3h ago

Added

Repo: team-attention/hoyeon

In this plugin

37 skills 29 agents 7 hooks

See everything inside

What's inside

hoyeon

English | 한국어 | 中文 | 日本語

All you need is requirements. A Claude Code plugin that derives requirements from your intent, verifies every derivation, and delivers traced code — without you writing a plan.

Quick Start · Philosophy · The Chain · Commands · Agents

AI can build anything. The hard part is knowing what to build — precisely.

Most AI coding fails at the input, not the output. The bottleneck isn't AI capability. It's human clarity. You say "add dark mode" and there are a hundred decisions hiding behind those three words.

Most tools either force you to enumerate them upfront, or ignore them entirely. Hoyeon does neither — it derives them. Layer by layer. Gate by gate. From intent to verified code.

Requirements Are Not Written

You don't know what you want until you're asked the right questions.

Requirements aren't artifacts you produce before coding. They're discoveries — surfaced through structured interrogation of your intent. Every "add a feature" conceals unstated assumptions. Every "fix the bug" hides a root cause you haven't named yet.

Hoyeon's job is to find what you haven't said.

  You say:     "add dark mode toggle"
                    │
  Hoyeon asks: "System preference or manual?"     ← assumption exposed
               "Which components need variants?"   ← scope clarified
               "Persist where? How?"               ← decision forced
                    │
  Result:      3 requirements, 8 sub-requirements, 4 tasks — all linked

This is not just process. It's built on three beliefs about how AI coding should work.

1. Requirements over tasks

Get the requirements right, and the code writes itself. Get them wrong, and no amount of code fixes it.

Most AI tools jump straight to tasks — "create file X, edit function Y." But tasks are derivatives. They change when requirements change. If you start from tasks, you're building on sand.

Hoyeon starts from goals and derives downward through a layer chain:

Goal → Decisions → Requirements → Sub-requirements → Tasks

Requirements are refined from multiple angles before a single line of code is written. Interviewers probe assumptions. Gap analyzers find what's missing. UX reviewers check user impact. Tradeoff analyzers weigh alternatives. Each perspective sharpens the requirements until they're precise enough to generate verifiable sub-requirements.

The chain is directional: requirements produce tasks, never the reverse. If requirements change, sub-requirements and tasks are re-derived. This is why Hoyeon can recover from mid-execution blockers — the requirements are still valid, only the tasks need adjustment.

2. Determinism by design

LLMs are non-deterministic. The system around them doesn't have to be.

An LLM given the same prompt twice may produce different code. This is the fundamental challenge of AI-assisted development. Hoyeon's answer: constrain the LLM with programmatic control so that non-determinism doesn't propagate.

Three mechanisms enforce this:

requirements.md + plan.json as structured artifacts — /specify produces requirements.md (the what). /blueprint produces plan.json with contracts and task graphs (the how). Every agent reads from these shared artifacts. No agent invents its own context. No information lives only in a conversation. These artifacts are the shared memory that survives context windows, compaction, and agent handoffs.
CLI-enforced structure — hoyeon-cli validates plan structure and task state transitions. Field names, types, required relationships — all checked programmatically before the LLM ever sees the data. The CLI doesn't suggest structure; it rejects invalid structure.
Derivation chain as contract — Goal → Decisions → Requirements → Sub-requirements → Tasks are linked. Each layer references the one above it. A sub-requirement traces to a requirement. A task traces to requirements via fulfills. If the chain breaks, the gate blocks. This means: if you have valid requirements, the system will produce a result — deterministically routed, even if the LLM's individual outputs vary.

The LLM does the creative work. The system ensures it stays on rails.

3. Machine-verifiable by default

If a human has to check it, the system failed to automate it.

Every sub-requirement in requirements.md is a testable behavioral statement:

{
  "id": "R1.1",
  "behavior": "Clicking dark mode toggle switches theme to dark"
}

Sub-requirements serve as acceptance criteria. Workers verify their own implementation against sub-requirement behaviors (with optional --tdd for test-first workflow). Code review runs independently, catching cross-cutting integration issues that per-task verification misses.

Human review is reserved for what machines genuinely can't judge — UX feel, business logic correctness, naming decisions. Everything else runs automatically, every time, without asking.

4. Knowledge compounds

Most AI tools start from zero every session. Hoyeon remembers.

Every execution generates structured learnings — not logs, not chat history, but typed knowledge: what went wrong, why, and the rule to prevent it next time.

  /execute runs → Worker hits edge case
       │
  Worker records:
    { problem: "localStorage quota exceeded at 5MB",
      cause:   "No size check before write",
      rule:    "Always check remaining quota before localStorage.setItem" }
       │
  Next /specify → searches past learnings via BM25
       │
  Result: "Found: localStorage quota issue in todo-app spec.
           → Adding R5: quota guard requirement automatically"

This is cross-spec compounding. A lesson learned in one project surfaces as a requirement in the next. The system doesn't just avoid repeating mistakes — it actively strengthens future specs with evidence from past executions.

Three mechanisms make this work:

Structured learnings — Workers record structured learnings during execution, saved to learnings.json and auto-mapped to the requirements and tasks that produced them
Cross-project search — BM25 search across all projects: requirements, sub-requirements, constraints, and learnings. What you learned in project A informs what you ask in project B
Compounding loop — Each /specify session starts by searching past learnings. More projects → richer search results → more complete requirements → fewer surprises during execution → better learnings → the cycle continues

The result: the tenth project you run through Hoyeon is meaningfully better than the first — not because the LLM improved, but because the knowledge base did.

These aren't aspirations. They're enforced by the architecture — the CLI rejects invalid specs, gates block unverified layers, hooks guard writes, agents verify in isolation, and learnings compound across projects. The system is designed so that doing the right thing is the path of least resistance.

See It In Action

You:  /specify "add dark mode toggle to settings page"

  Hoyeon interviews you (decision-based):
  ├─ "User opens the app at night — should it auto-detect OS dark mode or require a manual toggle?"
  ├─ "User switches to dark mode mid-session — should charts/images also invert?"
  └─ derives implications: CSS variables needed, localStorage for persistence, prefers-color-scheme media query

  Agents research your codebase in parallel:
  ├─ code-explorer scans component structure
  ├─ docs-researcher checks design system conventions
  └─ ux-reviewer flags potential regression

  → requirements.md generated:
    3 requirements, 8 sub-requirements — all linked

You:  /blueprint
  → plan.json generated:
    4 tasks with contracts, dependency graph, and fulfills links

You:  /execute

  Hoyeon orchestrates:
  ├─ Worker agents implement each task in parallel (--tdd: tests first)
  ├─ Code review: cross-cutting integration review
  └─ Final Verify: goal + constraints + sub-requirements — holistic check

  → Done. Every file change traced to a requirement.

/specify → Interview exposed hidden assumptions
           → Agents researched codebase in parallel
           → Layer-by-layer derivation: L0→L1→L2→L3→L4
           → Each layer gated by CLI validation + agent review
           → requirements.md generated

/blueprint → Contract-first task graph planning
             → Tasks derived from requirements with contracts
             → plan.json generated

/execute → Orchestrator read plan.json, dispatched parallel workers
           → Workers self-verify against sub-requirement behaviors (--tdd: test-first)
           → Code review caught cross-cutting issues
           → Final Verify checked goal, constraints, sub-requirements holistically
           → Atomic commits with full traceability

The chain ran from intent to proof. Every derivation verified.

The Derivation Chain

Six layers. Each derived from the one before it. Each gated before the next begins.

  L0: Goal           "add dark mode toggle"
   ↓  ◇ gate         is the goal clear?
  L1: Context        codebase analysis, UX review, docs research
   ↓  ◇ gate         is the context sufficient?
  L2: Decisions      decision interview → implications derivation (L2.5)
   ↓  ◇ gate         are decisions justified?
  L3: Requirements   R1: "Toggle switches theme" → sub-requirements
   ↓  ◇ gate         are requirements complete?
  L4: Tasks          T1: "Add toggle component" → fulfills, depends_on
   ↓  ◇ gate         do tasks cover all requirements?
  Plan Approval      summary + user confirmation → /execute

Each gate has two checks:

Merge checkpoint — CLI validates structure and completeness
Gate-keeper — agent team reviews for scope drift, blind spots, and unnecessary complexity

Nothing advances without passing both. The chain is only as strong as its weakest link — so every link is verified.

The Pipeline Contract

/specify produces requirements.md — the structured requirements. /blueprint produces plan.json — the task graph with contracts. /execute reads plan.json and dispatches workers.

The chain of evidence: requirement → sub-requirement → task (fulfills) → done. From intent to proof.

The Execution Engine

The orchestrator reads plan.json and dispatches parallel worker agents:

Star history of team-attention/hoyeon on GitHub, a chart by star-history.com — Star historyChart by star-history.com

File tree

More plugins by @team-attention.

View @team-attention’s profile

Plugin

Agent Orchestration

plugins-for-claude-nat…

A collection of Claude Code plugins for power users who want to extend Claude Code's capabilities beyond the defaults.

17 skills+3828

@team-attention

Install Plugin

FAQ

hoyeon is a Claude Code plugin with 37 hand-picked skills, indexed on Flowy in the Agent Orchestration category. Install it with the command on its page. It includes hoyeon-blueprint, hoyeon-browser-work, hoyeon-clarify. Its skills do not fire on their own yet. Request auto-invocation to have Flowy route them as you prompt. Free and open source.

What is hoyeon?: All you need is requirements. A Claude Code plugin that derives requirements from your intent, verifies every derivation, and delivers traced code — without you writing a plan. AI can build anything. The hard part is knowing what to build — precisely.
How do I install hoyeon?: Run these in Claude Code: /plugin marketplace add team-attention/hoyeon then /plugin install hoyeon@team-attention-dev. Then prompt normally.
Does hoyeon auto-invoke its skills?: Not yet. It is indexed on Flowy as a plain plugin. Request auto-invocation on its page and Flowy will route its skills for you as you prompt.
Is hoyeon free?: Yes. Flowy is free and open source, with nothing gated. You can read every skill in full before you install.

Is this plugin yours?

Claim it with GitHub Submit a plugin Promote it

Agent Orchestration

Plugin

hoyeon

hoyeon is a Claude Code plugin with 37 hand-picked skills, indexed on Flowy in the Agent Orchestration category.

BOOST

team-attention@team-attention

GitHub

Plugin Signal61/100Solid

maintained34

capable90

documented75

adopted48

Install on Claude Code

> /plugin marketplace add team-attention/hoyeon
> /plugin install hoyeon@team-attention-dev

Stats

JavaScript CSS Bash Ruby Git

+6 tags

GitHub Markdown Anthropic OpenAI Gemini MCP

173

Stars

Forks

Maintained

Maintenance

Shell

Language

MIT

License

5mo ago

Last commit

9mo ago

Created

3h ago

Added

Repo: team-attention/hoyeon

In this plugin

37 skills 29 agents 7 hooks

See everything inside

What's inside

Skill(37 skills)

Agent(29 agents)

Hook(7 hooks)

SessionStartRuns on the SessionStart event.PreToolUseRuns on the PreToolUse event.PostToolUseRuns on the PostToolUse event.

README

ExcerptRead the full README on GitHub

hoyeon

English | 한국어 | 中文 | 日本語

All you need is requirements. A Claude Code plugin that derives requirements from your intent, verifies every derivation, and delivers traced code — without you writing a plan.

Quick Start · Philosophy · The Chain · Commands · Agents

AI can build anything. The hard part is knowing what to build — precisely.

Most tools either force you to enumerate them upfront, or ignore them entirely. Hoyeon does neither — it derives them. Layer by layer. Gate by gate. From intent to verified code.

Requirements Are Not Written

You don't know what you want until you're asked the right questions.

Hoyeon's job is to find what you haven't said.

  You say:     "add dark mode toggle"
                    │
  Hoyeon asks: "System preference or manual?"     ← assumption exposed
               "Which components need variants?"   ← scope clarified
               "Persist where? How?"               ← decision forced
                    │
  Result:      3 requirements, 8 sub-requirements, 4 tasks — all linked

This is not just process. It's built on three beliefs about how AI coding should work.

1. Requirements over tasks

Get the requirements right, and the code writes itself. Get them wrong, and no amount of code fixes it.

Most AI tools jump straight to tasks — "create file X, edit function Y." But tasks are derivatives. They change when requirements change. If you start from tasks, you're building on sand.

Hoyeon starts from goals and derives downward through a layer chain:

Goal → Decisions → Requirements → Sub-requirements → Tasks

2. Determinism by design

LLMs are non-deterministic. The system around them doesn't have to be.

Three mechanisms enforce this:

requirements.md + plan.json as structured artifacts — /specify produces requirements.md (the what). /blueprint produces plan.json with contracts and task graphs (the how). Every agent reads from these shared artifacts. No agent invents its own context. No information lives only in a conversation. These artifacts are the shared memory that survives context windows, compaction, and agent handoffs.
CLI-enforced structure — hoyeon-cli validates plan structure and task state transitions. Field names, types, required relationships — all checked programmatically before the LLM ever sees the data. The CLI doesn't suggest structure; it rejects invalid structure.
Derivation chain as contract — Goal → Decisions → Requirements → Sub-requirements → Tasks are linked. Each layer references the one above it. A sub-requirement traces to a requirement. A task traces to requirements via fulfills. If the chain breaks, the gate blocks. This means: if you have valid requirements, the system will produce a result — deterministically routed, even if the LLM's individual outputs vary.

The LLM does the creative work. The system ensures it stays on rails.

3. Machine-verifiable by default

If a human has to check it, the system failed to automate it.

Every sub-requirement in requirements.md is a testable behavioral statement:

{
  "id": "R1.1",
  "behavior": "Clicking dark mode toggle switches theme to dark"
}

Human review is reserved for what machines genuinely can't judge — UX feel, business logic correctness, naming decisions. Everything else runs automatically, every time, without asking.

4. Knowledge compounds

Most AI tools start from zero every session. Hoyeon remembers.

Every execution generates structured learnings — not logs, not chat history, but typed knowledge: what went wrong, why, and the rule to prevent it next time.

  /execute runs → Worker hits edge case
       │
  Worker records:
    { problem: "localStorage quota exceeded at 5MB",
      cause:   "No size check before write",
      rule:    "Always check remaining quota before localStorage.setItem" }
       │
  Next /specify → searches past learnings via BM25
       │
  Result: "Found: localStorage quota issue in todo-app spec.
           → Adding R5: quota guard requirement automatically"

Three mechanisms make this work:

Structured learnings — Workers record structured learnings during execution, saved to learnings.json and auto-mapped to the requirements and tasks that produced them
Cross-project search — BM25 search across all projects: requirements, sub-requirements, constraints, and learnings. What you learned in project A informs what you ask in project B
Compounding loop — Each /specify session starts by searching past learnings. More projects → richer search results → more complete requirements → fewer surprises during execution → better learnings → the cycle continues

The result: the tenth project you run through Hoyeon is meaningfully better than the first — not because the LLM improved, but because the knowledge base did.

See It In Action

You:  /specify "add dark mode toggle to settings page"

  Hoyeon interviews you (decision-based):
  ├─ "User opens the app at night — should it auto-detect OS dark mode or require a manual toggle?"
  ├─ "User switches to dark mode mid-session — should charts/images also invert?"
  └─ derives implications: CSS variables needed, localStorage for persistence, prefers-color-scheme media query

  Agents research your codebase in parallel:
  ├─ code-explorer scans component structure
  ├─ docs-researcher checks design system conventions
  └─ ux-reviewer flags potential regression

  → requirements.md generated:
    3 requirements, 8 sub-requirements — all linked

You:  /blueprint
  → plan.json generated:
    4 tasks with contracts, dependency graph, and fulfills links

You:  /execute

  Hoyeon orchestrates:
  ├─ Worker agents implement each task in parallel (--tdd: tests first)
  ├─ Code review: cross-cutting integration review
  └─ Final Verify: goal + constraints + sub-requirements — holistic check

  → Done. Every file change traced to a requirement.

/specify → Interview exposed hidden assumptions
           → Agents researched codebase in parallel
           → Layer-by-layer derivation: L0→L1→L2→L3→L4
           → Each layer gated by CLI validation + agent review
           → requirements.md generated

/blueprint → Contract-first task graph planning
             → Tasks derived from requirements with contracts
             → plan.json generated

/execute → Orchestrator read plan.json, dispatched parallel workers
           → Workers self-verify against sub-requirement behaviors (--tdd: test-first)
           → Code review caught cross-cutting issues
           → Final Verify checked goal, constraints, sub-requirements holistically
           → Atomic commits with full traceability

The chain ran from intent to proof. Every derivation verified.

The Derivation Chain

Six layers. Each derived from the one before it. Each gated before the next begins.

  L0: Goal           "add dark mode toggle"
   ↓  ◇ gate         is the goal clear?
  L1: Context        codebase analysis, UX review, docs research
   ↓  ◇ gate         is the context sufficient?
  L2: Decisions      decision interview → implications derivation (L2.5)
   ↓  ◇ gate         are decisions justified?
  L3: Requirements   R1: "Toggle switches theme" → sub-requirements
   ↓  ◇ gate         are requirements complete?
  L4: Tasks          T1: "Add toggle component" → fulfills, depends_on
   ↓  ◇ gate         do tasks cover all requirements?
  Plan Approval      summary + user confirmation → /execute

Each gate has two checks:

Merge checkpoint — CLI validates structure and completeness
Gate-keeper — agent team reviews for scope drift, blind spots, and unnecessary complexity

Nothing advances without passing both. The chain is only as strong as its weakest link — so every link is verified.

The Pipeline Contract

/specify produces requirements.md — the structured requirements. /blueprint produces plan.json — the task graph with contracts. /execute reads plan.json and dispatches workers.

The chain of evidence: requirement → sub-requirement → task (fulfills) → done. From intent to proof.

The Execution Engine

The orchestrator reads plan.json and dispatches parallel worker agents:

File tree

More plugins by @team-attention.

View @team-attention’s profile

Plugin

Agent Orchestration

plugins-for-claude-nat…

A collection of Claude Code plugins for power users who want to extend Claude Code's capabilities beyond the defaults.

17 skills+3828

@team-attention

Install Plugin

FAQ

What is hoyeon?: All you need is requirements. A Claude Code plugin that derives requirements from your intent, verifies every derivation, and delivers traced code — without you writing a plan. AI can build anything. The hard part is knowing what to build — precisely.
How do I install hoyeon?: Run these in Claude Code: /plugin marketplace add team-attention/hoyeon then /plugin install hoyeon@team-attention-dev. Then prompt normally.
Does hoyeon auto-invoke its skills?: Not yet. It is indexed on Flowy as a plain plugin. Request auto-invocation on its page and Flowy will route its skills for you as you prompt.
Is hoyeon free?: Yes. Flowy is free and open source, with nothing gated. You can read every skill in full before you install.

Is this plugin yours?

Claim it with GitHub Submit a plugin Promote it

hoyeon

Install on Claude Code

📦 What's inside

Skill(37 skills)

Agent(29 agents)

Hook(7 hooks)

README

hoyeon

Requirements Are Not Written

1. Requirements over tasks

2. Determinism by design

3. Machine-verifiable by default

4. Knowledge compounds

See It In Action

The Derivation Chain

The Pipeline Contract

The Execution Engine

File tree

More plugins by @team-attention.

plugins-for-claude-nat…

FAQ

hoyeon

Install on Claude Code

📦 What's inside

Skill(37 skills)

Agent(29 agents)

Hook(7 hooks)

README

hoyeon

Requirements Are Not Written

1. Requirements over tasks

2. Determinism by design

3. Machine-verifiable by default

4. Knowledge compounds

See It In Action

The Derivation Chain

The Pipeline Contract

The Execution Engine

File tree

More plugins by @team-attention.

plugins-for-claude-nat…

FAQ

What's inside

What's inside