HeyEddi

The router. Invoke @heyeddi. @heyeddi-orchestrator is a deprecated alias for this skill.

Routes work to the right @skill, refreshes .heyeddi/, and keeps product, UX, and design pillars in sync.

Always on as the router bookend for every chat. See reference/always-on.md and hub docs/always-on-skills.md.

When to use

• Every session start on a HeyEddi project (.heyeddi/ present or greenfield app request)
• User asks "what skills do we have?" or "which skill should handle this?"
• Before a multi-step pipeline (intake → scaffold → design → handoff → QA)
• Design / look / polish: @taste-penpot first (one pass, tokens), then @heyeddi-design to record product context and hand off. Do not let @heyeddi-design invent a second look.
• Any time one pillar runs: bookend with load_workflow_context / append_pillar_opinion
• After @heyeddi-intake: confirm skill-routing.json before downstream work

Always-on siblings (every chat)

After routing, enforce:

1. @heyeddi-setup prefs gate (verify_setup --check) before git/CI/commit/push or agent autonomy — incomplete prefs fail those actions; route setup until pass (reference/setup-always-on.md on that skill)
2. @engineering-excellence plan gate before coding; change gate (audit_engineering --check) after edits — errors fail; warns advisory
3. Prose anti-slop when copy or .heyeddi docs change (verify_prose --check)
4. Clarify-before-act when product/design/stack intent is missing
5. Host surfaces — prefer this session's native plan / data / visual tools when listed; degrade to .heyeddi / scripts otherwise (reference/host-surfaces.md)

Automatic .heyeddi/ upkeep

You do not need a manual sync command. Every HeyEddi skill tool call runs auto-sync first:

1. Refreshes .heyeddi/skills-index.{json,md} when missing

Reinstall skills (npx skills add) and keep working: the next @heyeddi-intake, @heyeddi-product, or orchestrator tool updates .heyeddi/ automatically.

Optional explicit full sync (includes workflow scaffold): sync --project-root .

Cross-pillar sync (mandatory for product · UX · design)

Read reference/cross-pillar-workflow.md.

init_workflow_sync                    (once per project)
load_workflow_context --route /path   (start of pillar session)
… @heyeddi-product | @ux-flow-auditor | @heyeddi-design work …
append_pillar_opinion --pillar …      (end: triggers sibling opinions)

Skill discovery pipeline

load_catalog / suggest_skills   → auto-sync runs first
read one SKILL.md               → follow that skill's pipeline

If .heyeddi/docs/intake/skill-routing.json exists, follow route order.

Tools

When the task is complete: suggest next skills

When you have finished the user's request for this skill (not after every tool call or subagent phase), suggest what to run next:

1. Run:

   python .agents/skills/heyeddi/scripts/suggest_next_skill.py --current-skill heyeddi --project-root .

   Add --route /path if you worked a specific route.

2. Include the script's ### Next step block in your final reply. The user copies the Prompt line into chat (e.g. @heyeddi-design craft /settings).

Pass --mode shape (or craft, audit, etc.) when you know which sub-command just finished.

See @heyeddi → reference/next-skill-handoff.md.

Related

• @heyeddi-product · @ux-flow-auditor · @heyeddi-design: three pillars
• @heyeddi-setup: always-on prefs hard gate (verify_setup --check)
• @engineering-excellence: always-on plan + change gates
• @heyeddi-intake: upstream intake
• reference/host-surfaces.md: prefer host plan/data/visual tools; portable degrade
• reference/next-skill-handoff.md: next-skill block when a pipeline task completes
• docs/cross-pillar-workflow.md: hub summary
• docs/always-on-skills.md: hub always-on policy