Epost

Smart Hub v2 — /epost

The intelligent entry point to the epost agent ecosystem. Senses your current work context, detects intent from natural language, chains multi-step workflows, and shows contextual suggestions.

Execution Flow

On every invocation, follow these steps in order:

Step 1: Gather Context Snapshot

Before parsing arguments, follow the hub-context Context Snapshot Protocol to gather git state, platform detection, error signals, and session hints. Produce the context summary format defined there.

Step 2: Parse Intent from Arguments

If $ARGUMENTS is empty → skip to Step 4 (Contextual Discovery Menu).

Otherwise, classify the request using semantic intent categories:

Intent Categories

Context Boost Rules

When context signals match a category, that category gets priority even with weaker keyword matches:

Knowledge Question Routing

When the request is a question ("what is...", "how does...", "where is...", "show me...", "find..."):

Answer directly when asking about the kit itself (agents, skills, commands, hooks, conventions):

• Signals: "our agent", "which skill", "list commands", "what's our convention", "which agent handles X", "how does /cook work", "what skills exist"
• Action: Answer from context — no delegation needed

Project overview questions — check docs first, fall back gracefully:

• Signals: "what is this project", "what does this project do", "tell me about this project", "what is this repo", "what is this codebase", "give me an overview", "what are we building", "what does this do"
• Action (in order):
  1. Check if docs/index.json exists → if yes, read it + key ARCH/FEAT entries and synthesize a summary
  2. If no docs/, check README → summarize from README
  3. If no docs and no README → say: "No documentation found. Run /get-started to onboard — it will research the codebase, generate docs, and install dependencies."
• Example: "what is this project about?" → read docs/index.json or README, answer directly

Route to /scout when asking about project source code or codebase structure:

• Signals: "where is", "find the", "show me the code", "how is X implemented", "what does this file do", "search for", "which file", "where's the class/function/component", "how does the CLI work", "how does feature X work"
• Action: Delegate to scout skill — it explores files, traces patterns, searches across platforms
• Example: "where is authentication handled?" → /scout
• Example: "find the Button component" → /scout

Route to epost-researcher when asking about external tech:

• Signals: no project/kit reference + specific library, framework, or technology name
• Example: "how does JWT work?" → epost-researcher
• Example: "what is gRPC?" → epost-researcher

Fuzzy Matching

Don't require exact keyword matches. Use semantic understanding:

• "my tests are broken" → Fix (via "broken") + Test (via "tests"). Context boost breaks the tie.
• "I need to change the button" → Build (change ≈ modify ≈ implement)
• "what happened?" → context boost determines: if errors → Fix; if clean → Explore
• "I'm stuck" → if errors → Fix; if plan exists → Build; else → Guide

Step 3: Detect Multi-Intent and Route

Multi-Intent Detection

Check for compound requests via conjunctions:

Triggers: "and", "then", "after that", "followed by", comma-separated action verbs, semicolons

If multi-intent detected → delegate to epost-project-manager with a structured handoff (see Orchestrator Delegation below).

Single Intent Routing

If single intent detected:

1. Platform prefix check: If $ARGUMENTS starts with ios, android, web, or backend, route to platform-specific command.
2. Variant auto-selection based on complexity:

3. Route directly to the matched command.

Routing Decision Report

Always show the user what you decided and why:

Routing to `/fix` — detected TypeScript errors on web platform (branch: feature/auth)

or

Delegating to orchestrator — multi-intent detected: [Plan, Build] for notification system (web)

Step 4: Contextual Discovery Menu

When invoked with no arguments, show a context-aware menu instead of the static command list.

If active work detected (staged files, errors, plan):

## Suggested Actions

You're on `{branch}` with {context_summary}.

| # | Action | Command | Why |
|---|--------|---------|-----|
| 1 | {most relevant action} | `{command}` | {reason from context} |
| 2 | {second action} | `{command}` | {reason} |
| 3 | {third action} | `{command}` | {reason} |
| 4 | {fourth action} | `{command}` | {reason} |

> Describe what you want to do, or type a number. Full command list: say "show all commands"

Priority rules for suggestions:

1. If merge conflicts → suggest fix/resolve first
2. If errors → suggest fix commands
3. If staged files → suggest commit or review
4. If active plan → suggest continuing implementation
5. If feature branch, no changes → suggest starting work or checking plan
6. Always include at least one "escape hatch" (explore, plan, help)

If clean state (main branch, no changes, no errors):

## What do you want to do?

No active work detected on `{branch}`.

| Action | Command |
|--------|---------|
| Plan a feature | `/epost plan ...` |
| Build something | `/epost build ...` |
| Fix an issue | `/epost fix ...` |
| Explore codebase | `/epost scout ...` |
| Ask about the kit | `/epost which agent handles X?` |
| Research external tech | `/epost research ...` |

> Describe what you want to do in natural language.

Full command list (on "show all commands"):

### All Commands

| Category | Command | Flags |
|----------|---------|-------|
| Core Verbs | `/cook`, `/fix`, `/plan`, `/debug`, `/test`, `/bootstrap` | `--fast`, `--deep`, `--parallel`, `--ci`, `--ui`, `--validate` |
| Git | `/git` | `--commit`, `--push`, `--pr` |
| Docs | `/docs` | `--migrate`, `--scan`, `--verify`, `--batch` |
| Review | `/review` | `--code`, `--a11y`, `--improvements` |
| A11y | `/a11y` | `--audit`, `--fix`, `--review`, `--close` |
| Kit | `/kit` | `--add-agent`, `--add-skill`, `--add-hook`, `--optimize` |
| Onboarding | `/get-started`, `/epost` | — |
| Utilities | `/convert`, `/scout`, `/simulator` | — |

Orchestrator Delegation

When delegating to epost-project-manager, provide a structured handoff:

## Hub Handoff

**Original request**: "{user's exact words}"
**Intent chain**: [{Category1}, {Category2}, ...]
**Suggested commands**: [{/command1}, {/command2}, ...]
**Context**:
  - Branch: {branch_name}
  - Platform: {detected_platform}
  - Staged: {count} files
  - Errors: {summary}
  - Plan: {plan_file or "none"}
**Delegation reason**: {why hub can't handle directly — multi-intent / ambiguous platform / project-level}

Delegation triggers:

• Multi-intent chain detected (2+ intents)
• Ambiguous platform (files from multiple platforms changed)
• Project oversight request ("status", "progress", "what's left")
• Multi-platform task ("test everything", "review all platforms")

Platform Hint Detection

If $ARGUMENTS starts with a platform name, pass it as a hint to the unified verb command:

Rules

• ALWAYS gather context before routing (Step 1 is mandatory)
• If no clear intent detected → show contextual discovery menu
• If ambiguous between two intents → use context boost to break tie; if still ambiguous → ask user (max 1 question)
• Always show the routing decision and reasoning before executing
• Prefer fast variants unless complexity clearly warrants deep
• Multi-intent requests → always delegate to orchestrator
• Context gathering should be fast (< 5 seconds total). Skip slow checks.
• If not in a git repo, skip git state gracefully and proceed with intent-only routing