Hub Context Skill
Purpose
Defines a context sensing protocol for the /epost smart hub. Before routing, the hub gathers a snapshot of the current working state to make informed routing decisions.
Context Snapshot Protocol
On every /epost invocation, gather these signals before parsing intent:
1. Git State
Run these commands and capture output:
| Signal |
Command |
Purpose |
| Branch |
git branch --show-current |
Detect feature branch vs main |
| Staged files |
git diff --cached --name-only |
Know what's ready to commit |
| Unstaged changes |
git diff --name-only |
Know what's being worked on |
| Untracked files |
git ls-files --others --exclude-standard | head -20 |
New files not yet tracked |
| Recent commits |
git log --oneline -3 |
Understand recent activity |
| Merge conflicts |
git diff --name-only --diff-filter=U |
Detect blocked state |
2. Platform Detection
Determine the dominant platform from changed files:
| Extension Pattern |
Platform |
Confidence |
.tsx, .ts, .jsx, .js, .scss, .css |
web |
high |
.swift |
ios |
high |
.kt, .kts |
android |
high |
.java |
backend |
high |
.md, .json, .yml |
unknown |
low — check directory path |
Rules:
- If 80%+ of changed files share a platform → that platform is dominant
- If mixed → set platform to
multi (triggers orchestrator delegation)
- If no changed files → check current working directory for platform signals
- Platform prefix in
$ARGUMENTS always overrides auto-detection
3. Error Signals
Check for recent errors (only if platform detected):
| Platform |
Check |
Command |
| web |
TypeScript errors |
npx tsc --noEmit 2>&1 | head -5 (only if tsconfig.json exists) |
| web |
Lint errors |
Check for recent lint output in terminal |
| ios |
Build errors |
Check for recent xcodebuild failure output |
| android |
Build errors |
Check for recent gradle failure output |
| any |
Test failures |
Check for recent test runner output with "FAIL" or "ERROR" |
Important: Error signal gathering should be fast (< 2 seconds). Skip checks that would be slow. TypeScript check is the most valuable — run it if web context is detected.
4. Session Hints
| Signal |
How to Check |
Purpose |
| Active plans |
ls ./plans/*.md 2>/dev/null |
Detect in-progress work |
| Data store |
ls .epost-data/ 2>/dev/null |
Detect persistent agent state |
| Branch pattern |
Parse branch name for feature/, fix/, hotfix/ |
Infer work type |
Context Summary Format
After gathering, produce a structured summary for the routing engine:
[Context] branch: {branch_name} | platform: {platform}
[Context] staged: {count} files ({extensions}) | unstaged: {count} files ({extensions})
[Context] errors: {error_summary} (or "none detected")
[Context] plan: {plan_file} ({status}) (or "no active plan")
[Context] hints: {branch_type}, {other_signals}
Context Boost Table
The routing engine uses context to boost intent categories:
| Context Signal |
Boosts Category |
Example Routing Effect |
| TypeScript/build errors detected |
Fix |
"what's wrong?" → /fix (auto-detects types) |
| Staged files present |
Git or Review |
"I'm done" → /git-commit |
| Active plan file exists |
Build |
"continue" → /cook with plan context |
| Test failures detected |
Fix or Test |
"help" → /fix (auto-detects test failures) |
| Feature branch, no changes |
Build or Plan |
"what's next?" → continue from plan |
| Clean main branch |
Plan or Explore |
show contextual menu |
| Merge conflicts detected |
Fix |
auto-suggest conflict resolution |
Smart Routing
Prompt Classification
- Dev task (action verbs: cook, fix, plan, test, debug, etc.) → route via intent map
- Kit question ("which agent", "list commands", "our conventions") →
epost-orchestrator
- External tech question ("how does React...", "what is gRPC") →
epost-researcher
- Conversational (greetings, opinions, clarifications) → respond directly, no routing
Intent → Skill Map
| Intent |
Signal Words |
Routes To |
| Build |
cook, implement, build, create, add, make, continue |
/cook skill |
| Fix |
fix, broken, error, crash, failing, what's wrong |
/fix skill |
| Plan |
plan, design, architect, spec, roadmap |
/plan skill |
| Test |
test, coverage, validate, verify |
/test skill |
| Debug |
debug, trace, inspect, diagnose |
/debug skill |
| Review |
review, check code, audit |
/review-code skill |
| Git |
commit, push, pr, merge, done, ship |
/git-commit, /git-push, /git-pr |
| Docs |
docs, document, write docs |
/docs-init or /docs-update |
| Scaffold |
bootstrap, init, scaffold, new project, new module |
/bootstrap skill |
| Convert |
convert, prototype, migrate |
/convert skill |
| A11y |
a11y, accessibility, wcag |
/fix-a11y or /review-a11y |
| Onboard |
get started, begin, onboard, new to project, what is this |
/get-started |
Routing Rules
- If user types a slash command explicitly → execute it directly, skip routing
- If ambiguous → use context boost to break tie; if still ambiguous → ask user (max 1 question)
- If multi-intent ("plan and build X") → delegate to
epost-orchestrator
- Platform detection delegates to
skill-discovery — never hardcode platform logic here
Rules
- Context gathering MUST complete before intent parsing
- If a git command fails (not a git repo), skip git state gracefully
- Never run destructive commands during context gathering
- TypeScript check should timeout after 5 seconds — skip if slow
- Context snapshot is read-only — never modify working state
1---2name: hub-context3description: Use when routing user prompts to the right skill or agent. Senses git state, detects platform, classifies intent, and applies context boosts before dispatching.4---5
6# Hub Context Skill
7
8## Purpose
9
10Defines a context sensing protocol for the `/epost` smart hub. Before routing, the hub gathers a snapshot of the current working state to make informed routing decisions.
11
12## Context Snapshot Protocol
13
14On every `/epost` invocation, gather these signals **before** parsing intent:
15
16### 1. Git State
17
18Run these commands and capture output:
19
20| Signal | Command | Purpose |
21|--------|---------|---------|
22| Branch | `git branch --show-current` | Detect feature branch vs main |
23| Staged files | `git diff --cached --name-only` | Know what's ready to commit |
24| Unstaged changes | `git diff --name-only` | Know what's being worked on |
25| Untracked files | `git ls-files --others --exclude-standard \| head -20` | New files not yet tracked |
26| Recent commits | `git log --oneline -3` | Understand recent activity |
27| Merge conflicts | `git diff --name-only --diff-filter=U` | Detect blocked state |
28
29### 2. Platform Detection
30
31Determine the dominant platform from changed files:
32
33| Extension Pattern | Platform | Confidence |
34|-------------------|----------|------------|
35| `.tsx`, `.ts`, `.jsx`, `.js`, `.scss`, `.css` | web | high |
36| `.swift` | ios | high |
37| `.kt`, `.kts` | android | high |
38| `.java` | backend | high |
39| `.md`, `.json`, `.yml` | unknown | low — check directory path |
40
41**Rules:**
42- If 80%+ of changed files share a platform → that platform is dominant
43- If mixed → set platform to `multi` (triggers orchestrator delegation)
44- If no changed files → check current working directory for platform signals
45- Platform prefix in `$ARGUMENTS` always overrides auto-detection
46
47### 3. Error Signals
48
49Check for recent errors (only if platform detected):
50
51| Platform | Check | Command |
52|----------|-------|---------|
53| web | TypeScript errors | `npx tsc --noEmit 2>&1 \| head -5` (only if `tsconfig.json` exists) |
54| web | Lint errors | Check for recent lint output in terminal |
55| ios | Build errors | Check for recent `xcodebuild` failure output |
56| android | Build errors | Check for recent `gradle` failure output |
57| any | Test failures | Check for recent test runner output with "FAIL" or "ERROR" |
58
59**Important:** Error signal gathering should be **fast** (< 2 seconds). Skip checks that would be slow. TypeScript check is the most valuable — run it if web context is detected.
60
61### 4. Session Hints
62
63| Signal | How to Check | Purpose |
64|--------|-------------|---------|
65| Active plans | `ls ./plans/*.md 2>/dev/null` | Detect in-progress work |
66| Data store | `ls .epost-data/ 2>/dev/null` | Detect persistent agent state |
67| Branch pattern | Parse branch name for `feature/`, `fix/`, `hotfix/` | Infer work type |
68
69## Context Summary Format
70
71After gathering, produce a structured summary for the routing engine:
72
73```
74[Context] branch: {branch_name} | platform: {platform}
75[Context] staged: {count} files ({extensions}) | unstaged: {count} files ({extensions})
76[Context] errors: {error_summary} (or "none detected")
77[Context] plan: {plan_file} ({status}) (or "no active plan")
78[Context] hints: {branch_type}, {other_signals}
79```
80
81## Context Boost Table
82
83The routing engine uses context to boost intent categories:
84
85| Context Signal | Boosts Category | Example Routing Effect |
86|---------------|----------------|----------------------|
87| TypeScript/build errors detected | **Fix** | "what's wrong?" → `/fix` (auto-detects types) |
88| Staged files present | **Git** or **Review** | "I'm done" → `/git-commit` |
89| Active plan file exists | **Build** | "continue" → `/cook` with plan context |
90| Test failures detected | **Fix** or **Test** | "help" → `/fix` (auto-detects test failures) |
91| Feature branch, no changes | **Build** or **Plan** | "what's next?" → continue from plan |
92| Clean main branch | **Plan** or **Explore** | show contextual menu |
93| Merge conflicts detected | **Fix** | auto-suggest conflict resolution |
94
95## Smart Routing
96
97### Prompt Classification
98- **Dev task** (action verbs: cook, fix, plan, test, debug, etc.) → route via intent map
99- **Kit question** ("which agent", "list commands", "our conventions") → `epost-orchestrator`
100- **External tech question** ("how does React...", "what is gRPC") → `epost-researcher`
101- **Conversational** (greetings, opinions, clarifications) → respond directly, no routing
102
103### Intent → Skill Map
104
105| Intent | Signal Words | Routes To |
106|--------|-------------|-----------|
107| Build | cook, implement, build, create, add, make, continue | `/cook` skill |
108| Fix | fix, broken, error, crash, failing, what's wrong | `/fix` skill |
109| Plan | plan, design, architect, spec, roadmap | `/plan` skill |
110| Test | test, coverage, validate, verify | `/test` skill |
111| Debug | debug, trace, inspect, diagnose | `/debug` skill |
112| Review | review, check code, audit | `/review-code` skill |
113| Git | commit, push, pr, merge, done, ship | `/git-commit`, `/git-push`, `/git-pr` |
114| Docs | docs, document, write docs | `/docs-init` or `/docs-update` |
115| Scaffold | bootstrap, init, scaffold, new project, new module | `/bootstrap` skill |
116| Convert | convert, prototype, migrate | `/convert` skill |
117| A11y | a11y, accessibility, wcag | `/fix-a11y` or `/review-a11y` |
118| Onboard | get started, begin, onboard, new to project, what is this | `/get-started` |
119
120### Routing Rules
121- If user types a slash command explicitly → execute it directly, skip routing
122- If ambiguous → use context boost to break tie; if still ambiguous → ask user (max 1 question)
123- If multi-intent ("plan and build X") → delegate to `epost-orchestrator`
124- Platform detection delegates to `skill-discovery` — never hardcode platform logic here
125
126## Rules
127
128- Context gathering MUST complete before intent parsing
129- If a git command fails (not a git repo), skip git state gracefully
130- Never run destructive commands during context gathering
131- TypeScript check should timeout after 5 seconds — skip if slow
132- Context snapshot is read-only — never modify working state
majiayu000